Microsoft

Microsoft Defender for Identity Recommended Actions: Stop weak cipher usage

by thalpius

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. The ninth one 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.

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: Microsoft updated the 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: gunycvhf

ROT-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 their documentation. 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.

Image 1: Enforce DES encryption on identity

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.“

Image 2: Enable auditing for Kerberos tickets in security log

The Domain Controller where the authentication occurs saves a log with Event ID 4769 in the security log.

Image 3: Event ID 4769 after enabling auditing

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.

TypeName
0x1DES-CBC-CRC
0x3DES-CBC-MD5
0x11AES128-CTS-HMAC-SHA1-96
0x12AES256-CTS-HMAC-SHA1-96
0x17RC4-HMAC
0x18RC4-HMAC-EXP
Table 1: Kerberos Encryption Types

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.

Image 4: Support AES encryption, but not enforcing AES encryption

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 identity SUPPORTS AES 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.

Image 5: Allow AES256 as the only encryption type for all Domain Controllers

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.