Thread by @_dirkjan

There seems to be quite some questions and confusion about the impact of exploiting Zerologon (CVE-2020-1472) on the environment. So here's a thread 👇

In the initial state, AD is working fine. There's a DC and a server. They trust each other because they have a shared secret: the machine account password. They can use this to talk to each other and establish encrypted channels. The shared secret is identical on both machines.

A user trying to log on on the server can do so via Kerberos with a service ticket. Simplified: This service ticket is encrypted by the DC using the machine account password. The server has the same secret, can decrypt the ticket, and knows it's legit. User gets access.

With the Zerologon exploit, an attacker can change the password of the machine account in AD, thus changing the secret on one side. Now the server can't log in anymore on the domain. In most cases, the server will still have valid Kerberos tickets, so some logins will still work.

The attacker can now log in on the domain using the machine account of this server, and abuse it's privileges. However this can't (directly) be used to compromise the server itself. In fact, logging in to this server will become almost impossible.

Kerberos tickets issued before the exploit will still work, but new ones will be encrypted by AD with the "new" (empty) secret, shown in blue. The server can't decrypt those and throws an error. No more Kerberos logins.

Logging in with NTLM is also no longer possible, because logins with an AD account are verified at the DC over a secure channel (via the same netlogon protocol zerologon abuses). But this channel can't be set up because the trust is broken, and the server throws an error again.

In the most common privilege escalation however, one targets the DC itself instead of a different server. This is interesting because now it all runs on a single host. But it isn't entirely different because the DC also has multiple places where credentials are stored.

Like servers, the DC has a machine account with a password, stored encrypted in the registry. Upon boot this is loaded into lsass. If we change the password using Zerologon, only the password in AD will change, not in the registry or in lsass.

After the exploit, whenever a new Kerberos ticket is issued, we run into the same issue as with the server. The DC can't decrypt the service ticket using the machine account password in lsass, and authentication using Kerberos breaks.

For NTLM however it is different. On a DC it seems the machine account isn't used but the NTLM login is verified via a different way (I haven't investigated how), which still works. This allows you to DCSync using the empty NT hash of the DC machine account.

If you really want to use Kerberos, I imagine (untested) it would work with 2 DCs. Syncing between DCs will likely keep working for a while because Kerberos tickets are still valid. So once the new password of DC1 is synced to DC2 you can use the account of DC1 to sync with DC1.

The reason this works is because DC2s tickets are encrypted with the kerberos keys of the DC2 machine account, which are unchanged. DC2 knows the new password of DC1, so you can use this to sync.

To restore the password, there are a few options. My preferred would be to decrypt the plaintext password from the registry and restore that. You can't do this using the machine account because they usually have no admin privs on themselves.

So either use a DA account whose hash/keys you DCSynced. Another option is to use Reset-ComputerMachinePassword, which will reset the password both in AD and in the registry/lsass. This is quite hard to do on non-DCs however since you can't log in on them anymore via the network.

The last option is to change the machine account password using the NT hash, which would drop the Kerberos keys stored in AD. For some reason however, I haven't been able to obtain the old machine password hash using DCSync.

It would seem that once you set the password to empty with the Zerologon exploit, the current password entry is replaced with an empty one and the previous password is NOT saved in the password history. Not sure why, but only once you restore it it is pushed to history.

If you do decide to exploit this in prod during a test, do consider your plan of restoring it and make sure to know the risks of your actions :)

-fin-