You’ve probably already heard about the Zerologon vulnerability (aka CVE-2020-1472) but in case you haven’t, here is what it is in a nutshell; and more importantly here are our insights on how to detect it.

Zerologon is a critical vulnerability scored CVSS10.0 by Microsoft, essentially allowing an adversary to exploit the Netlogon Remote Protocol (MS-NRPC) aimed at acquiring domain admin privileges.

Many approaches for the Zerologon detection were posted out there, either leveraging Sysmon or IDS tools, all ending up with installing or running a tool. If the Zerologon patch became a headache for your organization as we predict it has; then with a pinch of built in windows auditing (no agent needed) and knowing where to look, you’ll be able to detect the exploit activity as it happens.

While examining the exploit, our research team found out that by inspecting the right ‘Windows Filtering Platform’ event you can detect the exploit activity.

Let’s go through the CYREBRO process

For the purpose of simulating the exploit, we used two Windows machines:

• Windows 10 – the attacker’s machine
• Domain Controller (Windows server 2019) – the victim machine

The exploit that was used for the testing was created by RiskSense

We started by executing the exploit from the attacker’s machine targeting the victim machine. The attacker’s machine was not a domain member; however, it was on the same network segment as the victim machine.

Successful execution of the exploit against an unpatched machine

As the exploit was doing its thing, we started seeing a bunch of ‘Windows Filtering Platform has permitted a connection’ (event id 5156) events being created on the victim machine.

‘Windows Filtering Platform’ events on the victim machine

While taking a closer look at the events that were generated, we have noticed that two Windows processes are populating the event’s application name field; the first was ‘svchost’ and the second was ‘lsass’. These events were spawned back to back in the event log with close proximity, in addition to the fact that the events timesteps matched the exploitation execution timeframe.

Then, we ran more tests to validate this behavior. As a result of these tests, we started establishing the pattern for detecting the Zerologon exploitation activity.

In all of our simulations, the first ‘Windows Filtering Platform’ event that was generated as a result of the exploitation activity, had ‘svchost’ as the application name and the destination port was 135 (RPC).

This behavior corresponds with the nature of using the Netlogon Remote Protocol (MS-NRPC), as ‘svchost’ is listening on port 135 on a Windows machine.

Example of event id 5156 with application name ‘svchost’

Following this first event, the application name ‘lsass’ showed up with destination port 49670 (Random High port)

Example of event id 5156 with application name ‘lsass’

This sequence of events, ‘svchost’ as the application name followed by ‘lsass’ as the application name, and their total event count; matched the number of attempts that were executed by the exploit. Meaning, for every exploitation attempt, two events were created, one where ‘svchost’ was the application name and one where ‘lsass’ was the application name.

To verify that our findings truly correspond with the exploitation activity, we analyzed the exploitation activity from the network point of view by running wireshark on the victim machine.

By inspecting the output of the packet capturing, we found that the total number of TCP streams matched the number of the Windows Filtering Platform events that were created on the victim machine event log.

Here is a screenshot of the last 4 request that were issued as a part of the exploitations attempt.

As you can see in the screenshot, the requests are in the following order:

1. RPC logon Map request, handled by svchost (port 135).
2. NetrServerAuhtenticate3 Access Denied, handled by lsass (port 49670).
3. RPC logon Map request, handled by svchost (port 135).
4. NetrServerPassowrdSet2, handled by lsass, that represents the successful exploitations in a form of password change [password set] (port 49670).

During the test, the average number of exploitation attempts it took to set the new password, varied from 86 (the lowest) to 1027 (the highest). However, the number of attempts can be lower (based on Secura’s discovery) and can also be higher (as the script has a hard limit of 2000 attempts).

From these experiences, we built a detection logic theory that was examined and evaluated against ‘big data’ events pool from multiple production environments across the globe.

That is how we came up with the following detection logic.

Detection

First, you’ll would need to make sure that the auditing policy is enabled.

Path to auditing:

Domain group policy edit: Computer Configuration > Policies > Windows Settings >
Security Settings > Advanced Audit Policy Configuration > Audit Policies >
Object Access > Audit Filtering Platform Connection [Success]

Now you can go ahead and apply the following detection logic in your SIEM or Logger solution.

Dataset 1:

Event ID IS 5156 (‘The Windows Filtering Platform has permitted a connection’)

AND

Application Name IS *\lsass.exe

AND

Protocol IS 6

AND NOT

Destination port IS 88

OR

Destination port IS 389

Dataset 2:

Event ID IS 5156 (‘The Windows Filtering Platform has permitted a connection’)

AND

Application Name IS *\svchost.exe

AND

Protocol IS 6

Alert Rule:

Now you’ll need to combine the both datasets to a single alert rule.

The rule should trigger an alert when:

20 or more matches of dataset1 [from the same source ip, to the same destination ip and same destination port]

And

20 or more matches of dataset2 [from the same source ip, to the same destination ip and same destination port]

have matched (a total of 40 events or more) from the same source ip to the same destination ip within 5 seconds.

Note: if your SIEM solution does not support ‘seconds’ timeframe, set the timeframe to 1 minute.

This detection is valid for both unpatched and patched windows machines as the same behavior was observed even after the victim machine was patched, even though the exploit was not successful.

Unsuccessful execution of exploit against a patched machine

This SIEM detection logic can be implemented in IBM QRadar, Splunk ES, ArcSight, ELK, etc.

Conclusion

In conclusion, we expect that Zerologon exploit will probably be a favored choice by attackers from now on, which is exactly why you should monitor this activity whether or not your organization is patched.

Appendix 1 – Sigma rule

title: Zerologon Expolit Activity Detected

description: Detects Zerologon expolit activity by ‘Windows Filtering Platform’ events for unpatched and patched machines <link for the blogpost>

author: Tomer Cohen, Nissim Ben-Saadon

date: 2020/09/23

tags:

– attack.privilege_escalation

– attack.lateral_movement

– attack.t1210

– CVE-2020-1472

logsource:

product: windows

service: security

detection:

selection1:

EventID:

– 5156

Application Name: *\lsass.exe

Protocol: 6

filter:

Destination Port:

– 88

– 389

selection2:

EventID:

– 5156

Application Name: *\svchost.exe

Protocol: 6

timeframe: 5S

condition: (selection1 | count(Event) by SourceIp,DestinationIp,DestinationPort >= 20) and (selection2 | count(Event) by SourceIp,DestinationIp,DestinationPort >= 20)

falsepositives:

– unknown

level: Critical