Unexpected installation of Microsoft Defender (wdavdaemon) on GitHub-hosted Ubuntu runners

[varunsh-coder]

Description

We've observed network calls from the wdavdaemon process to various Microsoft Defender endpoints (*.microsoft.com) on GitHub-hosted Ubuntu runners. These observations were made by StepSecurity Harden Runner across multiple workflow runs, and the behavior suggests that Microsoft Defender is occasionally being installed or activated in specific instances, though this doesn't happen consistently.

Examples

Here is one example:

GitHub Action Run: PicnicSupermarket/error-prone-support Run #16319862376

Observed Network Calls:
x.cp.wd.microsoft.com
global.endpoint.security.microsoft.com
wdcp.microsoft.com

Full network details available here: StepSecurity Insights

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

https://github.com/PicnicSupermarket/error-prone-support/actions/runs/16319862376/job/46094587540#step:1:14

Is it regression?

Not sure

Expected behavior

Defender was not installed on GitHub-hosted Ubuntu runners earlier and there was no announcement that it would be installed. So expected behavior is for it to not be installed.

Actual behavior

Defender is installed on some instances of GitHub-hosted Ubuntu runners

Repro steps

Cannot repro it in every build. Observed it across multiple workflow runs using https://github.com/step-security/harden-runner

[hemanthmanga]

Hi @varunsh-coder, Thank you for bringing this issue to our attention. We will look into this issue and will update you after our investigation.

[subir0071]

Hello @varunsh-coder - We tried reproducing the error at our end but with no success.
Please see our workflow runs here, which is a close variation of the same workflow shared above.
Also, as you can see, Microsoft Defender is not installed in the Ubuntu runner.
Please see the report in stepsecurity UI for my workflow runs.

Could you please add theh Microsoft Defender test step in your workflow and test the result for ubuntu runner?

Thanks.

[maxim-lobanov]

@varunsh-coder , could you please try to add the following step at the begin of and at the end of your workflow and share logs of this step for workflow where you see unexpected call?

steps:
     - run: |
         which mdatp || true
         echo "-----"
         cat /etc/passwd | grep mdatp || true
         echo "-----"
         systemctl list-units --type=service --all | grep mdatp || true
         echo "-----"
         systemctl status mdatp.service || true
         echo "-----"
         ls -la /opt/microsoft/mdatp || true

[varunsh-coder]

Hi @subir0071 @maxim-lobanov thanks for looking into this.

Like I mentioned in the issue, calls to these destinations from wdavdaemon do not happen in every run, but only in some workflow runs, which makes it hard to repro.

Also, since we observe these calls in public repos using harden runner, we cannot ask those developers to make changes to their workflows. But we can share more instances of this happening whenever we observe them.

Sharing few more examples:
https://github.com/hplush/slowreader/actions/runs/16552920470/job/46810350481
https://app.stepsecurity.io/github/hplush/slowreader/actions/runs/16552920470?runAttempt=1&tab=network-events&jobId=46810350481

https://github.com/felddy/foundryvtt-docker/actions/runs/16517102362/job/46710190760
https://app.stepsecurity.io/github/felddy/foundryvtt-docker/actions/runs/16517102362?jobId=46710190760&tab=network-events&runAttempt=1

https://github.com/northwood-labs/mod-aws-resource-tags/actions/runs/16514195055/job/46701838765
https://app.stepsecurity.io/github/northwood-labs/mod-aws-resource-tags/actions/runs/16514195055?jobId=46701838765&tab=network-events&runAttempt=1

This may help see a pattern. I can continue to share more instances on a daily basis if that helps.

[dmex]

the behavior suggests that Microsoft Defender is occasionally being installed or activated in specific instances

Windows Dender is disabled on the runner images but not Defender Smartscreen which uses the same enpoints as defender for checking unsigned/unknown binaries for reputation:
https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-browser#allowsmartscreen

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer]
"SmartScreenEnabled"="Off"

The default security policy on Windows will also download definition updates while Windows Dender is disabled:

https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-microsoftdefenderantivirus#signatureupdate_disableupdateonstartupwithoutengine

If you don't configure this setting, security intelligence updates will be initiated on startup when there is no antimalware engine present.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender\Signature Updates]
"UpdateOnStartUp"=dword:00000000
"DisableUpdateOnStartupWithoutEngine"=dword:00000001

---

calls to these destinations from wdavdaemon do not happen in every run, but only in some workflow runs, which makes it hard to repro.

The signature updates start downloading in the background while the system is starting up and would normally be complete before your worrkflow starts logging any activity. The problem is I don't think anyone configured group policies on the runner images since there's at least 8-10 other system components that update during the week and cause the same issue?

[varunsh-coder]

This is being observed on Ubuntu runners.

I got more details. This is the process with arguments making one of the calls

runuser -u *** -- curl --cacert /tmp/tmp.55dUaaLOoT.pem -s -S -X POST -d {
        "client": {
            "appVersion": "101.25052.0007",
            "hostname": "pkrvmpptgkbjq6m",
            "platform": "Linux",
            "machineGuid": "***",
            "orgId": "",
            "releaseRing": "Production",
            "productGuid":"***"
        },
        "reports":[
            {
                "$type":"installationReport",
                "timestamp": "1753437842.723343035",
                "correlation_id": "***",
                "version": "101.25052.0007",
                "distro": "ubuntu 24.04",
                "scenario": "Install",
                "severity": "C",
                "stage": "postinstall",
                "code": "InstallSucceeded",
                "text": ""
            }
        ]
    } --max-time 5 --connect-timeout 1 https://global.endpoint.security.microsoft.com/x/api/report -o /dev/null -w %{http_code}

[varunsh-coder]

This is another recent instance. In this case you can see the process called when you click on the PID 3500
https://app.stepsecurity.io/github/step-security/arm-int-tests/actions/runs/16643398587?jobId=47098193531&tab=network-events&runAttempt=1

/usr/lib/systemd/systemd-executor --deserialize 69 --log-level info --log-target journal-or-kmsg

# PID: 3510
/opt/microsoft/mdatp/sbin/wdavdaemon diagnostic --log_level info