Dirk-jan Profile picture
Sep 16, 2020 18 tweets 5 min read Read on X
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. Image
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. Image
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. Image
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. Image
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. Image
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. Image
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. Image
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. Image
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. Image
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-

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Dirk-jan

Dirk-jan Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(