Zerologon (CVE-2020-1472) is a vulnerability with a perfect CVSS score of 10/10 being used in the wild by attackers, allowing them to gain admin access to a Windows Domain Controller.
As more public exploits for this vulnerability are being published, including its support within mimikatz which is widely used, it’s expected to see even more attacks leveraging this vulnerability, and it's therefore crucial to be able to detect such attempts.
In this post we will see how this vulnerability can be exploited using mimikatz to gain administrative access to a Windows Domain Controller running on Windows Server 2019, and how the different stages of the attack can be identified by the RSA NetWitness Platform, leveraging Logs, Network and Endpoint data. This will include exploiting the Zerologon vulnerability, followed by the creation of golden tickets, and finally gaining admin access to the domain controller via a pass-the-hash attack/
We will assume that the attacker already has an initial foothold on one of the internal workstations, and now wants to move laterally to the domain controller.
Step 1
Attacker
The attacker downloads “mimikatz” on the compromised system using the “bitsadmin” command.
RSA NetWitness Endpoint
The executed command is detected by RSA NetWitness Endpoint and tagged as remote file copy using BITS. The exact target parameters are also provided, allowing to see from where the file was downloaded (identifying the attacker’s server) as well as the location of the downloaded file. In addition, mimikatz being a known malicious file, we are able to tag the event accordingly.
RSA NetWitness Network
And the resulted network session is captured by RSA NetWitness Network, identifying the client application as Microsoft BITS as well as the downloaded file (mimikatz.exe). If needed, the session can be reconstructed to extract the file for further forensics.
Step 2
Attacker
The attacker launches mimikatz, and tests whether the domain controller is vulnerable to the Zerologon vulnerability.
As the domain controller is vulnerable, the attacker executes the exploit.
RSA NetWitness Network
We know that the exploit starts with a “NetrServerReqChallenge” and spoofs the “NetrServerAuthenticate” with 8x ‘0’s (as seen in the previous screenshot). We also know that it takes an average of 256 of such attempts for the attack to be successful.
This consequently leads to the following:
- We expect to see “NetrServerReqChallenge” and “NetrServerAuthenticate”
- Due to the large number of attempts, we expect the size of the session to be larger than other similar connections
- The session to contain lots of 0's
In fact, by looking at the captured network session, we can see these indicators tagged by RSA NetWitness.
As seen in the above screenshot
- The session is related to netlogon (as the vulnerability targets this service)
- We can see both “NetrServerReqChallenge” and “NetrServrAuthenticate” within the session
- The most common byte (MCB.REQ) is “0”
- The size of the payload is around 200KB
- As we also have the RSA NetWitness Endpoint agent installed on the workstation, we can link the captured network session to the process that generated this connection, in this case “mimikatz.exe”
Using this information, the use of this exploit could be identified with the follow Application Rule:
service=135 && filename='netlogon' && action begins 'NetrServerAuthenticate' && action='NetrServerReqChallenge' && mcb.req=0 && size>40000
RSA NetWitness Logs
A successful attack would lead to the domain controller’s password being changed. This can be identified within the Windows Logs based on the following criteria:
- Event ID: 4742 (A computer account was changed)
- Source User: Anonymous logon
- Destination User: ends with “$” sign
- Hostname: specify your domain controllers
The following Application Rule / Query could be used for this detection:
device.type='windows' && reference.id='4742' && user.dst ends '$' && user.src='anonymous logon'
Step 3
Attacker
Once the attacker successfully exploits the domain controller, he now has access to it with replication rights. He can now use the “dcsync” feature of mimikatz to mimic the behavior of a domain controller and request the replication of specific users to get their password hashes. This can be done to get the password hash of the Administrator account as seen in the below screenshot.
RSA NetWitness Network
User Replication is requested using the “GetNCChanges” function, which would result in the domain controller providing the account hashes. This behavior can be seen based on the captured network traffic.
This behavior should me monitored and alerted on when initiated from an IP or subnet not expected to perform domain replication.
The following is a rule that can identify this behavior, it should be fine-tuned to exclude IP addresses that are expected to have this behavior:
action = ‘drsgetncchanges’ && ip.src != <include list of approved IP addresses>
RSA NetWitness Logs
This would also generate Windows Logs with the event ID 4662, but by default this log doesn’t provide enough granularity to avoid having too many false positives and is therefore not recommended to be used on its own as a detection mechanism.
Step 4
Attacker
The attacker then gets a golden ticket with a validity of 10 years for the Administrator account.
He is then able to use the ticket in a pass-the-hash attack.
He is now able to get shell access to the domain controller without the need for authentication and executes couple of commands to confirm he is connected to the Domain Controller (hostname, whoami ...).
RSA NetWitness Logs
The attacker gained shell access by using PsExec. This leads to the creation of a service named “psexesvc” on the domain controller that can be detected with Windows Logs and is tagged as a pass-the-hash attack by RSA NetWitness as seen below.
RSA NetWitness Network
Leveraging network data can uncover more details.
As seen in the below screenshot, we can identify:
- The use of the “Administrator” account to login over SMB
- The use of Windows admin shares
- The transfer of an executable within one of the sessions (psexe)
- The creation of a service (psexesvc)
RSA NetWitness Endpoint
The initial execution of “cmd.exe” by PsExec on the Domain Controller to gain the shell access can easily be identified by RSA NetWitness Endpoint.
Any other command executed by the attacker after he gets shell access would also be identified and logged by RSA NetWitness Endpoint, with the ability to track which commands have been executed, and by which processes they have been launched, providing a full picture of how and what the attacker is doing on the domain controller.
Conclusion
When dealing with such attacks and breaches, which often blend in within normal noise and behaviors, it becomes evident that the need for a rich data set based on a combination of Logs, Network and Endpoint is critical to both detect the breach as well as to identify the full scope of the breach from start to end, for each step done by the attacker.
Having visibility over East/West network traffic with rich metadata has also brought lots of value when compared to just relying on logs to detect and investigate more efficiently this attack. With the release of the RSA NetWitness Platform v11.5 it is now possible to setup policies to define for which network traffic to keep/drop the full payload in addition to the meta data, allowing to do east/west network capture in a more efficient way.
5 Comments
