How many logons do you have? Zero! You’re a threat-actor; you have zero logons, and you need some. Enter our new friend CVE-2020-1472, also known as ZeroLogon.
<ZeroLogon enters the chat>
You’ve probably heard about CVE-2020-1472, also known as ZeroLogon, by now. Since its announcement and patch in mid-August, nearly every IT and security professional has been talking about ZeroLogon. Here at FRSecure Labs, Team Ambush decided to put this exploit into action and share the results, concerns, potential indicators of compromise (IoCs), and what you can do to defend against this attack.
What is the CVE-2020-1472/ZeroLogon exploit?
As with anything, the foundation is important. The key is to understand how this attack works.
At the heart of it, ZeroLogon is abusing a flaw in an encryption implementation. The flaw exists in the Netlogon Remote Protocol (MS-NRPC), which handles machine authentication, among other things.
In a standard MS-NRPC authentication handshake, the following things happen:
- The client and server both send a challenge
- Both challenges and a shared secret are used to generate a session key (the shared secret being the client machine’s password)
- The session key is used to encrypt the original client challenge
- The encrypted client challenge is used as the client’s credential for further communication
This process should work. Without access to the machine’s password, an attacker can’t accurately generate or guess the session key used to encrypt and generate the client’s credential.
As mentioned before, a flaw exists in the encryption implementation. The encryption algorithm used during MS-NRPC authentication is AES-CFB8. The standard implementation of AES-CFB8 uses a 16-byte initialization vector (IV). In encryption, an IV is often used to pad initial data into an encryption algorithm that uses previous encrypted bytes to encrypt the next set of bytes.
It is also used as a method of somewhat randomizing the output of an encryption algorithm. For instance, if you were to encrypt the same word twice, the output should be different. As such, it is always important that an IV be different from one communication to the next. In Microsoft’s MS-NRPC implementation of AES-CFB8, the IV is static and hard-coded to 16 zero bytes.
How does the CVE-2020-1472/ZeroLogon exploit work?
Without digging too much into the way the encryption algorithm works, this results in a situation where sending a completely zeroed-out client credential will happen to be correct about 1 in 256 tries.
Once the attacker successfully authenticates with the all-zero credential, they can make MS-NRPC calls. Specifically, a call can be sent to set the client machine’s password to a new value. Now, this call requires encryption of the new password using the session key once again.
However, as we have already used this session key to authenticate with all zeroes, we know that we can also send a password parameter of all zeroes. The last byte of the password parameters specifies the password length. As this will be set to zero, the password will be set to a blank value.
At this point, an attacker can authenticate as this machine normally, using a blank password. With knowledge of the new password, the attacker can now perform any actions the computer could normally perform in the domain.
The common attack pattern is as follows:
- Use the ZeroLogon attack to authenticate as a domain controller to a domain controller
- Set the domain controller’s machine password to blank
- Authenticate properly with the domain controller’s account
- Perform a DCSync attack to extract password hashes from Active Directory
- (optional) Set the domain controller’s machine password back to its original value to prevent obvious issues and cover the attacker’s tracks
This can all be performed in seconds. It’s honestly enough to alarm anyone who knows anything about security.
What can you do about it?
Assuming you’re still reading and not frantically pushing Windows patches to your domain controllers, let’s talk about some potential IoCs for this attack. Spoiler Alert: there aren’t many.
The main IoC for this attack is the presence of an event ID (EID) of 4742 in the security event log on a domain controller. Additionally, you’ll often see this event combined with one with an EID of 4672 indicating “special privileges assigned to new logon.” But, there’s a catch: domain members, including domain controllers, will reset their computer account password every 30 days. From what we’ve seen in our lab, these normal 30-day reset events, also with an EID of 4742, appear to be indistinguishable.


One piece of data in those 4742 events that may be useful is the “password last set” timestamp. This is present in both the post-exploit and legitimate events, but we can compare the password last set timestamps between two events on the same domain controller and assume that if any are less than 30 days apart, that likely means that the host has been compromised.
The challenge here is going to be fairly obvious to Active Directory administrators: domain controller logs rollover very frequently. These logs are incredibly noisy, and unless you’re doing log retention through an SIEM or aggregation system, you’re unlikely to have 30 days of domain controller security event logs.
So far, event log comparison seems to be the most definitive way to confirm a past exploit. That said, during our testing, we ran a Wireshark and Procmon captures during the attack to determine if other types of monitoring may provide a level of detection. Fortunately, this was fruitful.
From Zero to Hero!
In the Wireshark capture below, we can see our attacker’s attempts to negotiate the session. This is a brute-force type attempt, where the attacker is essentially asking “Hey, here are some 0’s. Do those work?” and, essentially, the victim host is saying “Nope, not yet!”

As this progresses, the attacker will eventually succeed and be able to pass those 0’s as a legitimate client credential. Once that occurs, we see our attacker set a blank password for the computer account.

The takeaway from this Wireshark data is that it may be possible to configure a signature or a threshold to monitor for in-network monitoring systems (Netflow, Moloch, etc.) and alert upon as needed. Again, if you have historical logs of this type, you may be able to search for these IoCs; however, this may be more helpful in an active monitoring situation.
But wait! There’s more!
The second capture we performed during this attack was the Procmon (Sysinternals) capture. This monitored processes, and we limited it to showing only the lsass.exe interactions.
Windows processes are exceptionally noisy. Knowing that lsass.exe is involved with authentication, we determined this would be a good process to focus on.
In the screenshot below, you can see the pattern of our attacker and domain controller with two TCP connections followed by four registry functions. In this case, it appears this is also the sequence of the attacker asking if the session key allows a credential of all 0’s yet, and the victim host is opening registry keys, querying those keys, and then closing those keys because it does not.

The success of the attack appears to be noted in this sequence below, which we know because the pattern stops. We will see the second half of the attack shortly after that.

Hashes. Gotta catch ‘em all!
Once the attacker has reset the computer account password and can successfully impersonate the domain controller, they have the ability to get to the real meat of the attack: grabbing additional credentials for additional actions of evil, or AoEs.
We were able to grab a webcam capture during the attack as well. It was pretty enlightening to see who our threat-actor is:

Back to our Procmon captures, we can see the attacker initiating an Active Directory replication scenario and scooping up the hashes for all domain accounts.

As we mentioned, this is really where the attacker finds the value. Resetting a computer account password on a domain controller is potentially destructive in the environment, which would send up some huge red flags to an IT/security team.
Gathering hashes for all the other accounts in the domain to be used later allows the attacker to have a level of persistence before they move to the next phase, in which they reset the computer account password back to its original password. Doing this avoids any additional risk of noisy Active Directory failures.
It’s broken!

Assuming the attacker wants to limit the visibility of the attack, they will likely reset the password back to the original computer account password of the domain controller. Once this occurs, domain operations should return to normal and no additional IoCs will be noted. In our testing, we were able to capture this portion of the attack in Wireshark.

Now, for the most surprising part of all this. This entire attack—from the initial compromise to resetting the password back to normal—was carried out in roughly 30 seconds.
To be clear, this was a small domain with a very small number of users and computers, but the attack duration may not be very lengthy even on a larger domain.
The Takeaway
The important thing for IT and security folks to consider here is that any ill effects related to Active Directory would likely just look like a small blip. It may look like the effect of DNS not serving properly from that domain controller, a missed replication cycle, or some other Active Directory function may not work as intended for the duration of the attack. In our test, this span was only 30 seconds and would not likely raise any red flags.
Go patch your servers now, please.
This article was written by pinky and vimk1ng of Team Ambush
If this is overwhelming, we can help. Talk to one of our pen testers today to get your defenses up to snuff against vulnerabilities like this one.
