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.
Figure 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.
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.
Figure 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;
AlertInfo
| 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));
DeviceNetworkEvents
| 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:
|
SourceDeviceId |
<DeviceId> |
|
SourceComputerName |
CLIENT1.test.local |
|
TargetDeviceIP |
10.0.0.1 |
|
TargetDevicePorts |
[135, 49670] |
|
TargetComputerName |
DC1.test.local |
|
Timestamp |
2020-09-21 17:02:41 |
|
InitiatingProcessFileName |
python.exe |
|
InitiatingProcessCommandLine |
python.exe “C:\Users\CLIENT1\Documents\zerologon_tester.py” |
|
InitigatingProcessAccountSid |
<UserSid> |
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.