A critical Active Directory vulnerability (CVE-2020-1472) has been making headlines for being the most notorious elevation of privilege bug because it can affect all computers and domain controllers in an organization.

This high-risk vulnerability, dubbed Zerologon, gives threat actors easy, instant access to domain controllers without requiring any additional privileges. This attack does not even require a user to be authenticated; the user just needs to be connected to the internal network.

What is the Zerologon vulnerability?

It is a vulnerability in Netlogon, the authentication protocol that validates the identity of a domain-joined computer to the domain controller. It’s categorized as high-risk (CVSS score of 10) because leveraging this vulnerability means the compromised user account does not even need to be authenticated to the domain—it just has to be connected to the internal network.

Assessing the vulnerability

Before we describe how this vulnerability can be exploited, it’s important for you to understand Netlogon. This protocol does not use the same authentication scheme as other RPC services.

Instead, it uses a customized cryptographic protocol to let a client (a domain-joined computer) and server (the domain controller) prove to each other that they both know a shared secret, and thereby authenticate with each other.

 

The steps involved in the authentication process are as follows:

1. A client challenge (random eight bytes) is sent from the client.
2. A server challenge (random eight bytes) is sent from the server.
3. A session key is created from the session secret (a hash of the client’s computer account password) and the challenges.
4. Both the client and server utilize the previously made session key and the challenges to create client and server credentials.
5. The credentials together with the session key are used to authenticate the user.

Where does the vulnerability occur?

The vulnerability is caused by a defect in the AES cryptography algorithm.

Both the client and server use the AES-CFB8 cryptography method to generate credential values, as mentioned in Step 4 above. All of this is implemented in a ComputeNetlogonCredential function.

This AES-CFB8 encryption has been implemented in an insecure way, creating this vulnerability.

• The ComputeNetlogonCredential function takes the 8-byte challenge (as in Steps 1 and 2 above) and performs a transformation on it with the secret session key to produce the client credential (as in Step 4).
• The 8-byte challenge is attached to 16 random bytes called an initialization vector (IV).
• AES encryption is applied to the said vector. The XOR condition is used to link the first byte of the value of the result to the first byte of the 8-byte expression on which the protocol is used. These steps are repeated until the phrase is all encoded.

So where is the problem?

AES-CFB8 security relies on the IV to be chosen randomly. Unfortunately, the ComputeNetlogonCredential function defines that this IV is fixed and should always consist of 16 zero bytes.

What can go wrong with an all-zero IV? For one in 256 keys, applying AES-CFB8 encryption to an all-zero plaintext will result in an all-zero ciphertext.

Take a look at the illustration below:

The “zero” logon attack

• After exchanging challenges with a NetrServerReqChallenge call, the client then authenticates itself by doing a NetrServerAuthenticate3 call.
• This call has a parameter called ClientCredential, which is computed by applying the ComputeNetlogonCredential to the client challenge that was sent in the previous call.
• There’s nothing stopping us from setting this challenge to eight zeroes. This means that for one in 256 session keys, the correct ClientCredential will also consist of eight zeroes!

Here’s an illustration of the attack technique:

Since computer accounts are not locked after invalid login attempts, we can simply try a bunch of times (256 on average) until we hit such a key and authentication succeeds. This entire process only takes about 10 seconds in practice.

With this method, we can log in as any computer in the domain. This includes backup domain controllers and even the targeted domain controller itself!

Using the NetServerPasswordSet2 call, we can reset the password for any system—all by using the all-zero IV!

Mitigating the Zerologon vulnerability

• Apply the relevant Microsoft patch as quickly as possible.
• Use this script to check if all your domain controllers are patched. Ensure that only authorized users run this script and that it is not used by malicious actors to identify unpatched domain controllers to leverage the Zerologon vulnerability.
• For non-Windows devices, a vulnerable Netlogon secure channel connection can be used.
  • The vulnerable Netlogon secure channel connection can be controlled by the “Domain controller: Allow vulnerable Netlogon secure channel connections” Group Policy setting, which only allows authorized devices to use the connection.
• Always monitor GPO changes: Any malicious account or group can be added to Group Policy, providing the Netlogon attack privileges to a malicious account.

Besides the above fixes, you can monitor for these event IDs:

• Track successful logon attempts in servers using Event ID 4624 with Logon Type 3 (network logon) followed by Event ID 4742 with TargetUsername “ANONYMOUS LOGON”.
• Event ID 5829 is generated whenever a vulnerable Netlogon secure channel connection is allowed.

Offensive open source tools are often used with the attack to gain deeper access or escalate privileges.

• Credentials can be dumped from local memory (LSASS.exe).
  • Detection: sysmon EventID=10 with TargetImage=*lsass.exe (GrantedAccess=0x1010 OR GrantedAccess=0x1410)
• Mimikatz can be used with Netlogon to gain access to the password hashes of domain users.
  • Detection: sysmon EventID=7 & ImageLoaded=*WinSCard.dll | *cryptdll.dll | *hid.dll | *samlib.dll | *vaultcli.dll

Detecting the Zerologon attack with ManageEngine Log360

ManageEngine Log360 is a one-stop solution that helps you maintain network security. The real-time correlation engine of Log360 correlates discrete security events, checks if they are indicators of the Zerologon attack, and alerts authorized users in real time if an attack attempt is detected.

Further, Log360 can automatically remediate this attack by performing mitigation actions, like terminating the suspected user’s session, shutting down devices, or even executing scripts based on a custom action.

Download Log360 now to protect your organization from the Zerologon attack.

** Optrics Inc. is an Authorized ManageEngine partner

---

The original article can be found here:

https://blogs.manageengine.com/active-directory/log360/2020/10/15/domain-controller-patch-alert-vulnerability-grants-domain-admin-access-in-10-seconds.html