Sentinel Query: Detect ZeroLogon (CVE-2020-1472)

In August 2020 Microsoft patched the ZeroLogon vulnerability CVE-2020-1472. In summary, this vulnerability would allow an attacker with a foothold in your network to become a domain admin in a few clicks. The attacker only needs to establish a network connection towards the domain controller.

At NVISO we are supporting multiple clients with our MDR services, from that perspective our security experts analyzed the vulnerability and made queries for both Sentinel and threat hunting ( “Advanced Hunting”) to detect these types of activities in your network.

One requirement for running Sentinel queries is of course that you have on-boarded Active Directory event logs in your Sentinel log analytics workspace. This can be done by installing the Microsoft Monitoring Agent and forwarding the events towards said workspace.

In case these logs are available you can use the query below to detect activities related to the ZeroLogon vulnerability. Within this query, you have to replace DC1$ and DC2$ with the hostname(s) of your Domain Controllers.

//Search for anonymous logons, note this may produce FPs
SecurityEvent
| extend EvData = parse_xml(EventData)
| extend EventDetail = EvData.EventData.Data
| extend TargetUserName_CS = EventDetail.[1].["#text"], SubjectUserSid_CS = EventDetail.[4].["#text"], SubjectUserName_CS = EventDetail.[5].["#text"]
| project-away EvData, EventDetail
| where ((EventID == 4742)
    and (TargetUserName_CS in~ ("DC1$", "DC2$"))
     and ((SubjectUserName_CS contains "anonymous") or (SubjectUserSid_CS startswith "S-1-0") or (SubjectUserSid_CS startswith "S-1-5-7")))

The following image shows an example output of this query:

Should Sentinel not be available or the workspace has not been set up, we also include a KQL query (KUSTO rule) to be used in Advanced Hunting:

//Search for anonymous logons, note this may produce FPs
union DeviceLogonEvents, DeviceProcessEvents
| where AccountName in~ ("anonymous") or InitiatingProcessAccountName in~ ("anonymous") or
AccountSid startswith "S-1-0" or InitiatingProcessAccountSid startswith "S-1-0" or
AccountSid startswith "S-1-5-7" or InitiatingProcessAccountSid startswith "S-1-5-7"
//Remove FP
| where InitiatingProcessFileName != "ntoskrnl.exe"
| summarize by Timestamp, DeviceId, ReportId, DeviceName, AccountName, InitiatingProcessAccountName, AccountSid,
InitiatingProcessAccountSid, AccountDomain, InitiatingProcessFileName, ProcessCommandLine, AdditionalFields

Note that Anonymous Logons should be investigated either way. While this may be a False Positive such as the host itself, an Administrator or a Service account – it can also indicate malicious behavior. Use the Sentinel query below to investigate further.

//Once a detection from previous rule has hit, use the following to validate - if there IS a logon, investigate further. If not, it's likely a False Positive
SecurityEvent 
| where ((EventID == 4624) and (TargetUserName =~ "DC1$"))
| distinct SubjectUserName

One way of investigating further whether this is a False Positive or not, is to leverage the Netlogon log, and correlating or comparing the output with results from running the queries above. This log is by default disabled, but can be enabled as follows on the affected Domain Controller (DC):  

1. Execute the following commands in an elevated prompt:
   • Nltest /DBFlag:2080FFFF
   • net stop netlogon
   • net start netlogon
2. The same can be achieved with (elevated) PowerShell:
   • Nltest /DBFlag:2080FFFF
   • Restart-Service Netlogon
3. Investigate the log file that will be created. Note it may take a while to reproduce the event. The log file is found at: %windir%\debug\netlogon.log
4. Correlate the event(s) from before in the Netlogon log. Once identified, you can disable Netlogon logging again by setting the DBFlag as 0x0.

The following query will assist in detecting whenever a vulnerable Netlogon secure channel connection is allowed – keep in mind however this will only work should you have already applied the patch:

//This query will work ONLY after the patch has been applied. It warrants further investigation.
Event
| where EventID == 5829

On top of this we also wrote an additional KQL query to search for evidence – specifically, if someone has (intentionally or not) disabled Enforcement Mode.

//Netlogon enforcement explicitly disabled
union DeviceProcessEvents, DeviceRegistryEvents
| where RegistryKey contains "\\system\\currentcontrolset\\services\\netlogon\\parameters"
| where RegistryValueName == "FullSecureChannelProtection"
| where RegistryValueType == "Dword"
| where RegistryValueData == 0 or RegistryValueData == 0x00000000
| summarize by Timestamp, DeviceId, ReportId, DeviceName, RegistryKey, InitiatingProcessAccountName, InitiatingProcessFileName, ProcessCommandLine

Note that the KUSTO hunting queries can also be leveraged as a Detection Rule, which allows for proactive alerting.

In case you want additional details about the queries or Sentinel please do not hesitate to reach out! You can contact the blog authors or via filling in the contact form on our website https://www.nviso.eu.

References

Our research is based upon the following references

• This excellent blog post about the zero-logon vulnerability by Secura
• CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability
• How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472
• Microsoft technical details about the Netlogon Remote Protocol
• Well-known security identifiers in Windows operating systems
• 4742(S): A computer account was changed
• 4624(S): An account was successfully logged on
• SIGMA rule for CVE-2020-1472

Authors

This blog post was created based on the collaborative effort of :

• Thibaut Flochon –Linkedin
• Bart Parys
• Jeroen Vandeleur – Linkedin