Skip to content

Back to the catalog

dfir.chwriteup

Today I Learned - Device Discovery

dfir.ch documents an incident response investigation where an NDR sensor flagged a suspicious internal port scan. The analyst used EDR telemetry to identify the responsible PowerShell script (hash-verified, Microsoft-signed) invoking Defender for Endpoint's Device Discovery feature (Scan-UdpTcpPorts, Scan-Vnc, Scan-WinRm, etc.), decoding its base64 ScannerArgs to reveal target IPs, MACs, and the CVEs it probes for (CVE-2021-44228, CVE-2022-22965). The scan turned out to be benign legitimate network discovery from Defender for Endpoint, explaining why it triggered an NDR false positive.

TL;DR DFIR walkthrough showing how Microsoft Defender for Endpoint Device Discovery can trigger NDR port-scan alerts that turn out to be benign.
Open original ↗
Document

What it is

A DFIR walkthrough (dfir.ch) showing that an NDR "port scan" alert from an internal Windows server was Microsoft Defender for Endpoint (MDE) Device Discovery in Standard mode, not an attacker. The value the summary omits is the concrete triage artifacts: the exact execution path, the integrity-check mechanism, and the discriminator that separates benign discovery from real reconnaissance.

How it works

MDE stages a signed script at:

C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads\PSScript_{GUID}.ps1

It is launched via powershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive, which first Get-FileHash -Algorithm SHA256 verifies the script against a hardcoded hash and exit 323 if it does not match (defeats tamper/re-sign), starts a transcript under ...\Temp\PSScriptOutputs\, then dot-sources the script with a -ParamsAsBase64 blob. Decoding that blob yields a JSON ScannerArgs object: IpsToScan, MachineId, CvesToScan (CVE-2021-44228 Log4Shell, CVE-2022-22965 Spring4Shell), TargetMacs, and an embedded signing Cert. Scan work is done by functions like Scan-UdpTcpPorts, Scan-Vnc, Scan-SLP, Scan-WinRm, Scan-RpcInterfaceMapper.

What to do

When triaging an internal "port scan" NDR alert, correlate against EDR telemetry for the PSScript_{GUID}.ps1 path and the -ParamsAsBase64 argument; decode the base64 to confirm the scanned IPs/CVEs match your environment's discovery config rather than attacker targeting.

The decisive discriminator the page states: malicious recon scans the whole network from a few compromised hosts, whereas MDE Standard discovery probing is initiated from all onboarded Windows devices. So if the "scanning" originates broadly across your onboarded fleet, it is benign discovery; concentration on one or two hosts is the red flag.

Caveats

Some of these MDE scripts fail under PowerShell Constrained Language Mode, so absence of the behavior on hardened hosts does not mean discovery is disabled. The post is a single case study, not a detection rule — it gives you the artifacts and the heuristic, not a tuned NDR signature. The full Standard-discovery protocol set (ARP, FTP, HTTP/S, ICMP, LLMNR, NBNS, RDP, SIP, SMTP, SNMP, SSH, Telnet, UPNP, WSD, SMB, NBSS, IPP, PJL, RPC, mDNS, DHCP, AFP, CrestonCIP, IphoneSync, WinRM, VNC, SLP, LDAP) explains why the traffic looks alarmingly broad.

CVEs named here

Technologies named here

Related in Blue Team & Detection