Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Active Directory (AD) is a service that authenticates and authorizes all users and computers in a Windows domain type network.

The NetLogin Protocol (from the good ol' WindowsNT days) uses an RPC interface with a custom crypto scheme in order to authenticate a user to the system. To authenticate to the domain controller, the following is done to check to see if they both know the shared secret:

1. Client Challege
2. Server Challenge - at this point, the session key is known to the client.
3. Client Credential Encryption
4. Server Credential Encryption
5. Signed + Sealed with the session key

The author mentions that one tiny blunder (with cryptography) can lead to the entire system being compromised... and that is exactly what happened here.

In particular, the DC uses AES with CFB8 block cipher mode. The main vulnerability lies into a bad implementation of a block cipher mode with AES. The block cipher mode has a fixed IV of all zero bytes!

Using a choosen plaintext attack, the following was discovered: for 1 in 256 keys, applying AES- CFB8 encryption to an all-zero plaintext will result in all-zero ciphertext. Why is this bad though? There are multiple ways to exploit this.

First, recall step 3 from the authentication process. The security relies on the fact that the encrypting of the secret will be secure because of a unknown session key to malicious actors. However, because WE control the challenge (step 1) we can set the challenge to all 0's. From the previous vulnerability (discussed), we can then FORCE the ciphertext to ALSO be all 0's (1 out of 256 tries, or about 3 seconds).

Secondly, recall that step 5 from the auth process is Signed + Sealed. This is simply encrypting all traffic with the session key. With the vunlerability, we DON'T know the session key, but are authentication. Luckily, by setting a flag (on the client request) to NOT use the encryption, we can communicate with the DC still.

The next step is that all non-encrypted calls must contain a value called ClientStoredCredential + Timestamp. However, from the previous challenge used, we know this is 0.

Fourthly, we can change the password of any user on the domain. Most of the time, the password hash needs to be encrypted with the session key in order to use the NetrServerPasswordSet2 RPC call. However, it is possible to set a BLANK password by specifying a zero length password on the request!

Finally, it is time to become the domain admin. Because the domain controller's password is BLANK, we can authenticate as the domain admin and scrape all user hashes (from the network) including the krbtgt to create golden tickets. Game over!

This is a devastating finding for Microsoft AD, allowing for an unauthenticated user to become the domain admin on the network is terrifying. We will be hearing about this vulnerability for a while!