ZeroLogon is now detected by Microsoft Defender for Identity (CVE-2020-1472 exploitation)

Published Oct 01 2020 04:46 AM 36K Views

We know that all of you have been intrigued about the recently patched CVE-2020-1472 Netlogon Elevation of Privilege Vulnerability, widely known as ZeroLogon. While we strongly recommend that you deploy the latest security updates to your servers and devices, we also want to provide you with the best detection coverage possible for your domain controllers. Microsoft Defender for Identity (previously Azure Advanced Threat Protection) along with other Microsoft 365 Defender (previously Microsoft Threat Protection) solutions detect adversaries as they try to exploit this vulnerability against your domain controllers.


Here’s a sneak peek into our detection lifecycle

Whenever a vulnerability or attack surface is disclosed, our research teams immediately investigate possible exploits and come up with various methods for detecting attacks. This is highlighted in our response to suspected WannaCry attacks and with the alert for Suspected SMB packet manipulation (CVE-2020-0796 exploitation). These detection methods are tested in our lab environment, and experimental detectors are deployed to Microsoft Defender for Identity to assess performance and accuracy and find possible attacker activity.


Over the past month since the CVE-2020-1472 was first disclosed, the interest in this detection rapidly increased. This happened even if we did not observe any activity matching exploitation of this vulnerability in the initial weeks after the August security updates. It generally takes a while before disclosed vulnerabilities are successfully reverse-engineered and corresponding mechanism are built.


This lack of activity changed on September 13, when our triggered a surge in alerts. Simultaneously, this increase in activity was followed by the publication of several proof-of-concept tools and demo exploits that can leverage the vulnerability.


1.pngFigure 1 – Orgs with ZeroLogon exploitation attempts by red teams and real attackers starting September 13


Microsoft Defender for Identity can detect this vulnerability early on. It covers both the aspects of exploitation and traffic inspection of the Netlogon channel.


2.png  Figure 2 – Alert page experience


With this Microsoft Defender for Identity alert, you will be able to identify:

  • The device that attempted the impersonation
  • The domain controller
  • The targeted asset
  • Whether the impersonation attempts were successful

Finally, customers using Microsoft 365 Defender (previously Microsoft Threat Protection) can take full advantage of the power of the signals and alerts from Microsoft Defender for Identity, combined with behavioral events and detections from Microsoft Defender for Endpoint (previously Microsoft Defender Advanced Threat Protection). This coordinated protection enables you not just to observe Netlogon exploitation attempts over network protocols, but also to see device process and file activity associated with the exploitation.



A close look at some of the earliest ZeroLogon attacks

ZeroLogon is a powerful vulnerability for attackers to leverage, but in a normal attack scenario it will require an initial entry vector inside an organization to facilitate exploitation against domain controllers. During initial monitoring of security signals, Microsoft Threat Experts observed ZeroLogon exploitation activity in multiple orgs. In many cases, it was clear that the activity was originated by red teams or pen testers using automated vulnerability scanners to locate vulnerable servers. However, Microsoft researchers were also able to identify a few limited cases of real attackers jumping on the ZeroLogon train to expand their perimeter into organizations that, after a month of patch being available, were still running unpatched domain controllers.


3.pngFigure 3 – Typical ZeroLogon exploitation activity generated by a vulnerability scanner or a red team testing domain controllers at scale


One of the adversaries noticed by our analysts was interesting because the attacker leveraged an older vulnerability for SharePoint (CVE-2019-0604) to exploit remotely unpatched servers (typically Windows Server 2008 and Windows Server 2012) and then implant a web shell to gain persistent access and code execution. Following the web shell installation, this attacker quickly deployed a Cobalt Strike-based payload and immediately started exploring the network perimeter and targeting domain controllers found with the ZeroLogon exploit.


Using the @MsftSecIntel handle on twitter, we publicly shared some file indicators used during the attack. We also shared the variations of the ZeroLogon exploits we detected, many of which were recompiled versions of well-known, publicly available proof-of-concept code. Microsoft Defender for Endpoint can also detect certain file-based versions of the CVE-2020-1472 exploit when executed on devices protected by Microsoft Defender for Endpoints.



Hunting for ZeroLogon in Microsoft 365 Defender

Combining signals from Microsoft Defender for Endpoint with the ZeroLogon alerts from Microsoft Defender for Identity can help assess the nature of the alert quickly. Microsoft 365 Defender automatically leverages signals from both products. It has logic that constantly attempts to combine alerts and events using a variety of correlation logic based on knowledge of cause-effect attack flows, the MITRE ATT&CK framework, and machine learning models.


In this section, we provide an example (in the simplified form of an advanced hunting query) of how Microsoft 365 Defender correlation logic operates behind-the-scenes to combine alerts, reducing SOC fatigue and facilitating investigation.


The following Microsoft 365 Defender advanced hunting queries identify process and network connection details from the source device suspected to have launched the NetLogon exploit.


First, we gather the relevant details on recent Netlogon exploit attempts from Microsoft Defender for Identity alerts. This will help populate the AlertId for the second query.





// Find all Netlogon exploit attempt alerts containing source devices 
let queryWindow = 3d;
| where Timestamp > ago(queryWindow)
| where ServiceSource == "Azure ATP"
| where Title == "Suspected Netlogon privilege elevation attempt (CVE-2020-1472 exploitation)"
| join (AlertEvidence
    | where Timestamp > ago(queryWindow)
    | where EntityType == "Machine"
    | where EvidenceDirection == "Source"
    | where isnotempty(DeviceId)
) on AlertId
| summarize by AlertId, DeviceId, Timestamp





Next, populate one AlertId from the prior query into NLAlertId in the next query to hunt for the likely process that launched the exploit and its network connection to the domain controller:





// Find potential endpoint Netlogon exploit evidence from AlertId
let NLAlertId = "insert alert ID here";
let lookAhead = 1m;
let lookBehind = 6m;
let NLEvidence = AlertEvidence    
| where AlertId == NLAlertId
| where EntityType == "Machine"    
| where EvidenceDirection == "Source"    
| where isnotempty(DeviceId)    
| summarize Timestamp=arg_min(Timestamp, *) by DeviceId;
let sourceMachine = NLEvidence | distinct DeviceId;
let alertTime = todatetime(toscalar(ZLEvidence | distinct Timestamp));
| where Timestamp between ((alertTime - lookBehind) .. (alertTime + lookAhead))
| where DeviceId in (sourceMachine)
| where RemotePort == 135 or RemotePort between (49670 .. 49680)
| summarize (Timestamp, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountSid)=arg_min(ReportId, Timestamp, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountSid), TargetDevicePorts=make_set(RemotePort) by DeviceId, DeviceName, RemoteIP, RemoteUrl
| project-rename SourceComputerName=DeviceName, SourceDeviceId=DeviceId, TargetDeviceIP=RemoteIP, TargetComputerName=RemoteUrl





This query can return a result that looks like this:








[135, 49670]




2020-09-21 17:02:41




python.exe “C:\Users\CLIENT1\Documents\”




Tying Microsoft Defender for Endpoint data together with the original Microsoft Defender for Identity alert can give a clearer picture as to what happened on the device suspected of launching the exploit. This could save SOC analysts time when investigating alerts, because the relevant details are there to determine if it was caused by a curious researcher or from an actual attack.


Defend against ZeroLogon

As always, it’s important to keep your assets up to date with the latest security updates

Learn more about the alert.


Also, feel free to review our guidance on managing changes in Netlogon secure channel connections and how you can prevent this vulnerability


Customers with Microsoft Defender for Endpoint can get additional guidance from the threat analytics article available in Microsoft Defender Security Center.


Get started today

Are you just starting your Microsoft Defender for Identity journey? Begin a trial of Microsoft 365 Defender to experience the benefits of the most comprehensive, integrated, and secure threat protection solution for your organization.


Join the Microsoft Defender for Identity community for the latest updates and news about Identity Security Posture Management assessments, detections and other updates.

Regular Visitor

Great information, could I suggest that posted scripts can be copied and pasted and expected to work without allot of modification. Copying the scripts above do not appear to work.

Senior Member

Seconding @JoeMJoeM's comment - the scripts as provided do not work.  The scripts provided don't even match the screenshots of the scripts!  Can this be fixed please?


@MaxLian , @JoeMJoeM - can you please elaborate more about what's not working?


Does this query return any results?


| where Timestamp > ago(30d)
| where ServiceSource == "Azure ATP"
| where Title == "Suspected Netlogon privilege elevation attempt (CVE-2020-1472 exploitation)"



Regular Visitor





@JoeMJoeM are you using the MTP portal?

Regular Visitor

No I was using ATP portal.  Ok it does work in MTP portal, thanks for that.  I wasn't aware there is a difference between the two, and this script should be run from MTP portal.  I will have to get more educated on differences between the two.

Occasional Visitor

Great info. If an attacker sucessfully exploit one domain controller on the environment. How easy is it for the attacker to exploit

all the other domain controller?

Senior Member

@Daniel Naimthanks for that.  I was using the portal.  With so many portals, and Microsoft renaming things, it's hard to know what portal to use for what.  Are there any plans to make a single interface?


@MaxLian , @JoeMJoeM - To be honest, I sometimes use the wrong portal even myself so that's a common mistake.


The goal is to have Microsoft 365 Defender (MTP) as the unified portal that will aggergate and replace all the other portals (Defender for Identity, Endpoints and Emails\Office 365) - obviously this might take sometime, but this is the plan.


@amrakesh - This is a tricky question - it depends on the architecture and the purpose of the domain controller that was exploited. Basically with this exploitation and attacker can become domain admin and that's pretty much game over (for this specific domain), regardless if they can or can't do lateral movement to other domain controllers.




Version history
Last update:
‎Oct 01 2020 04:24 PM
Updated by: