Part 1: Weak Keys, Weaker Hashes
In this post, I’ll be diving into the NAA AD Solution Set reports, specifically the Weak Passwords report. This report highlights vulnerable account configurations that could be exploited in modern threat scenarios.
While most are familiar with Weak Password, Weak Historical Password, and Shares Common Password exceptions identified by this report, today I’m focusing on two less commonly understood but equally critical findings:
- AES Key Missing
- LM Hash
These two exceptions come from deep inspection of how account secrets are stored in AD, and both are surfaced via DCSync-level replication. That means Netwrix is analyzing what the domain controller actually stores, not just what the account claims to support via attributes like msDS-SupportedEncryptionTypes.
AES Key Missing – Why It Matters
In modern AD environments, when a password is set or reset, the domain controller is supposed to generate Kerberos encryption keys for supported algorithms. If AES keys are missing, it means the account is restricted to older cryptographic standards—typically RC4-HMAC or even DES.
What causes this?
- The account’s password hasn’t been changed in many years—often prior to AES being introduced or supported.
- Even if
msDS-SupportedEncryptionTypesis null or zero (default), a password reset under a patched DC (e.g., with KB4551762) will normally regenerate AES keys.
Why it’s dangerous:
- RC4-only encryption allows attackers to Kerberoast service accounts more efficiently.
- Tools like Rubeus and Impacket can request a service ticket encrypted with RC4 and brute-force it offline.
- Accounts with no AES keys are also more likely to support Silver Ticket forgery—an attacker can generate their own ticket with only the NT hash.
Bottom line: If you see “AES Key Missing” on a SPN-bearing or privileged account, it’s an immediate risk. These accounts are vulnerable to offline cracking, impersonation, and lateral movement via forged Kerberos tickets.
LM Hash – A Legacy Threat Still Lurking
LM (LAN Manager) hashes are a cryptographic relic from the early Windows days. They’re:
- Stored as uppercase-only
- Split into two 7-character blocks
- Based on a DES variant that is trivial to crack
Modern best practice:
- Group Policy should have
Do not store LAN Manager hash value on next password changeset to Enabled. - With this setting in place, any password change will remove the LM hash.
Why it still shows up:
- The account’s password hasn’t been reset in years.
- The LM hash was generated before hardening policies were in place and is still sitting in the AD database.
Why it’s dangerous:
- LM hashes are crackable in seconds—even short passwords fall easily to brute force.
- Attackers using tools like Mimikatz or DCSync can pull this hash and recover cleartext credentials rapidly.
- LM hash presence increases exposure to Pass-the-Hash and offline replay attacks.
Bottom line: If LM hashes are still present, it’s an indicator of highly neglected account hygiene. These accounts are low-hanging fruit for any adversary with read access to AD secrets.
Key Takeaway
Most environments that apply patch KB4551762, enable LM hash blocking GPO, and enforce routine password rotations will not see AES Key Missing or LM Hash on active accounts.
If you do see them:
- Investigate the account immediately.
- Reset the password to regenerate modern keys and wipe out LM hashes.
- Prioritize service accounts, privileged accounts, and accounts with SPNs, as these are the most likely targets for Kerberoasting or ticket forgery.
Coming Up in Part 2: Who Are These Vulnerable Accounts?
In the next post, I’ll focus on identifying which accounts are at risk:
- How to determine if an account is a service identity (SPN-bearing)
- How to identify if it has Tier 0 privileges (Admin)
- How to verify whether your domain is properly configured to block LM hash generation
- And how Netwrix Access Analyzer ties this all together using the Service Accounts and GPO Details reports
If Part 1 shows what’s wrong with the keys, Part 2 will show who’s holding them — and whether those identities should be remediated immediately.
Part 2: Service Accounts Report – Privileged Roles, Public SPNs
In modern environments, this is typically enabled on the Default Domain Policy.
If it’s missing or disabled, even new password resets will regenerate LM hashes, putting your environment at risk.