Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with fourteen recommended actions. In a series of blog posts, I will go through all fourteen recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. Theninthone in the series is the “Stop weaker cipher usage” recommended action.
Introduction
You have fourteen recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.
- Resolve unsecure domain configurations
- Resolve unsecure account attributes
- Remove dormant accounts from sensitive groups
- Protect and manage local admin passwords with Microsoft LAPS
- Configure VPN integration
- Reduce lateral movement path risk to sensitive entities
- Stop clear text credentials exposure
- Disable Print spooler service on domain controllers
Stop legacy protocol communication- Stop weak cipher usage
- Remove unsecure SID history attributes from entities
- Modify unsecure Kerberos delegations to prevent impersonation
- Install Defender for Identity Sensor on all Domain Controllers
- Set a honeytoken account
Some recommended actions are easy to configure, but others take time, proper planning, auditing, and expertise. This blog post will review the “Stop weak cipher usage” recommended action.
Update:Microsoftupdatedthe recommended actions with six additional recommendations, which makes it a total of twenty. I will describe the six updated ones after this series.
Update: Microsoft removed the “Stop legacy protocol communication” from the Secure Score Recommended Actions.
Ciphers
Before we discuss the recommendation in detail, let me explain briefly what a cipher is. A cipher is a term used in cryptography to encrypt and decrypt data, and it is also known as an encryption algorithm. A cipher converts plain-text data into unreadable data, which is called encryption. To read the data, you often need a key to decrypt the encrypted data to make it readable again.
Most ciphers are complex and well beyond this blog post, but simple chipers like the ROT-13 cipher exist. ROT-13 is a substitution cipher that replaces the plain text with ciphertext, making it unreadable. Here is an example of using the ROT-13 cipher on the text “thalpius.”
Plaintext: thalpius
Ciphertext: gunycvhfROT-13 rotates the letters in the alphabet thirteen places. So, “t” becomes the letter “g” when moving thirteen places backward in the alphabet. ROT-13 is called the Caesar cipher, which Julius Caesar used in the 1st century BC. As you might have guessed, ROT-13 is a weak cipher. Luckily, ROT-13 is not a cipher used within a Microsoft environment. What is a weak cipher used in a Microsoft environment, though, is Data Encryption Standard (DES) Triple Data Encryption Algorithm (3DES) and Rivest Cipher 4 (RC4).
Weak Ciphers
Microsoft specifically discusses DES/3DES and RC4 as weak ciphers in theirdocumentation. DES is from the 1970s and is susceptible to brute-force attacks, and 3DES is from the 1980s and is vulnerable to collision attacks. There is an option in Active Directory to force DES encryption for Kerberos authentication.
Since DES and 3DES are forty years old, it is unsurprising that modern technology makes these ciphers easy to crack. I doubt that forcing DES encryption on any account within the Active Directory was done intentionally. If there is any account with DES as an encryption method, please check if the application or service only understands DES as an encryption type and if it supports a higher encryption method like AES256.
Auditing
Microsoft Defender for Identity identifies identities with a weak cipher like DES/3DES and RC4. There is an auditing option if you want to audit the Kerberos encryption types. Since Microsoft Defender for Identity does not require the “Kerberos Service Ticket Operations” audit, I guess Microsoft Defender for Identity identifies the encryption types checking the packets sent to the Domain Controllers.
The policy to enable auditing Kerberos encryption types is called “Audit Kerberos Authentication Service.“
The Domain Controller where the authentication occurs saves a log with Event ID 4769 in the security log.
In the Additional Information section of event 4769, you will find the encryption type used during authentication.
Additional Information:Ticket Options: 0x60810010
Ticket Encryption Type: 0x12
Failure Code: 0x0
Transited Services: -
The Kerberos Ticket Encryption Type in the example above equals the hexadecimal value 12. Here are the most common encryption types and their hexadecimal values.
| Type | Name |
| 0x1 | DES-CBC-CRC |
| 0x3 | DES-CBC-MD5 |
| 0x11 | AES128-CTS-HMAC-SHA1-96 |
| 0x12 | AES256-CTS-HMAC-SHA1-96 |
| 0x17 | RC4-HMAC |
| 0x18 | RC4-HMAC-EXP |
So, in my example, the encryption used for the authentication is AES256-CTS-HMAC-SHA1-96, which is the cipher we want to enforce for all our authentication.
Advanced Encryption Standard
DES, 3DES, and RC4 are considered weak ciphers, and there is an option to enforce a stronger cipher for Kerberos authentication like AES.
There is a catch, though, which I want to address using this blog post.
Important: Suppose you enable “This account supports Kerberos AES 256-bit encryption” on an identity. In that case, it only means the identitySUPPORTSAES encryption, but it still allows an attacker to request an RC4 encrypted ticket, which they can brute-force and get a plain-text password.
So, even when the recommended action shows no exposed identities and all identities can support Kerberos AES encryption, it does not mean the identity is safe. You have to force only AES encryption using a policy on the Domain Controllers to force AES and AES only.
Only then is the strong cipher AES used to encrypt Kerberos tickets, making a downgrade attack to RC4 impossible.
Conclusion
Be sure to turn off weak ciphers using the policy “Network security: Configure encryption types allowed for Kerberos” to prevent a downgrade attack to RC4 and lower the risk of a successful compromise.
Microsoft Defender for Identity is a perfect way to identify weak ciphers like DES/3DES and RC4, but be sure to turn off weak ciphers using the above mentioned policy.
