The Active Directory security issue discussed here concerns stolen credential material and Kerberos RC4-HMAC. In configurations that accept this encryption type, an NT password hash can serve as a Kerberos key. That helps explain why monitoring NTLM authentication alone is not enough to address every use of stolen NT hashes. It does not mean that every current Active Directory deployment has the same exposure.
This article revisits a historical disclosure and separates the protocol issue from present-day defensive guidance. It does not report a newly discovered vulnerability or claim that Impulsec developed the original proof-of-concept.
TL;DR: Disabling NTLM does not also disable Kerberos RC4-HMAC. Audit the encryption types your domain actually uses, resolve legacy dependencies, and test AES readiness before enforcing a change. Protect password-derived keys as credentials; removing RC4 alone does not resolve an existing compromise.
What the historical disclosure described
Aorato announced this password-change scenario on 15 July 2014. Its announcement made broad claims about detection limitations. A subsequent CERT-FR technical analysis dated 25 July 2014 clarified that the underlying risk was compromised Kerberos key material, including AES keys, and that password-change auditing could record Event 4723 when enabled. This is a historical credential-abuse scenario, not evidence that modern Windows authentication is universally vulnerable or unlogged. The explanation below is Impulsec’s editorial synthesis of those sources and Microsoft documentation, not our original discovery or a reproduced laboratory test.
The durable security lesson is that a password is not the only secret an organisation must protect. Password-derived keys can also establish identity. If an attacker obtains a usable key, the absence of the plaintext password is not necessarily a barrier to impersonation.
Why RC4-HMAC and the NT password hash are connected
RFC 4757 documents that Windows Kerberos RC4-HMAC uses the same key material as the NT password hash for compatibility. NTLM and Kerberos remain different authentication protocols; the connection is the shared key material in this particular Kerberos encryption type.
Consequently, disabling NTLM authentication is not the same action as disabling Kerberos RC4-HMAC. Organisations need to examine both their authentication protocols and their permitted Kerberos encryption types. AES-based Kerberos keys do not use this same direct NT-hash mapping, although stolen AES keys are still sensitive credentials.
The historical password-change scenario should also be understood narrowly: it concerned possession of an account secret that the relevant exchange accepted. It was not evidence that an unauthenticated outsider could change any domain password without first compromising credential material. Microsoft’s guidance on password changes using RC4 secret keys explains that the exchange validates possession of a password-derived key. The accepted encryption types and account controls matter; knowing the plaintext password is not the only way to possess a usable credential.
What this issue is, and what it is not
| Question | Practical answer |
|---|---|
| Does it mean Kerberos is simply NTLM under another name? | No. They are different protocols. The historical connection concerns RC4-HMAC key material. |
| Does every RC4 event prove an attack? | No. Legacy applications may legitimately use RC4. Investigate the context. |
| Does enabling AES prove RC4 is gone? | No. Verify what is permitted and what clients and services actually use. |
| Does removing RC4 solve every credential-theft problem? | No. Other secrets, tickets and sessions still require protection. |
Can Windows logs detect relevant activity?
The blanket claim that event logs and SIEM systems are useless is inaccurate. Microsoft documents updated Kerberos event data, including additional encryption information, on Windows Server 2016 and later with the applicable January 2025 or later security updates. The fields available depend on the operating system, patch level and event version.
Event 4768 concerns ticket-granting-ticket requests. Its updated format includes pre-authentication and session-key encryption fields alongside ticket encryption information. An AES value in one field should not be treated as proof that every cryptographic component in the exchange used AES.
Event 4769 covers service-ticket requests. Correlating these records with account, device and application activity is more useful than treating an isolated encryption value as a verdict.
Check the field as well as the number. In Microsoft’s ticket-encryption-type table, 0x17 identifies RC4-HMAC, while 0x11 and 0x12 identify AES128 and AES256. The msDS-SupportedEncryptionTypes attribute is a separate bitmask with different meanings. Do not interpret an attribute value as though it were a ticket-encryption result, or treat an available RC4 key as proof that a ticket actually used it.
Windows also documents Event 4723 for password-change attempts. A record of a password change is not, by itself, proof that the legitimate user initiated it. Equally, limited detail in a historical log sample does not establish that the activity leaves no evidence anywhere.
How to reduce exposure today
Begin with an inventory and evidence from your own environment. Microsoft’s RC4 detection and remediation guidance recommends auditing remaining use, addressing legacy dependencies and moving away from RC4. Its guidance also links to changes in Kerberos defaults. Check the documentation for your installed updates rather than assuming a calendar date proves your domain is configured securely.
- Identify dependencies. Establish which accounts, applications and devices still require RC4, and assign an owner to each exception.
- Prepare AES compatibility. Verify supported encryption settings and usable account keys. Coordinate any necessary credential changes with application owners.
- Test before enforcement. Pilot the change with representative services and a documented recovery plan before applying it broadly.
- Verify the result. Confirm expected authentication works and review telemetry for remaining RC4 use or new failures.
Treat privileged accounts separately. Microsoft’s Protected Users guidance documents restrictions on NTLM and RC4, but also compatibility and lockout risks. It explicitly warns against adding service or computer accounts. Membership should follow testing, not a blanket change to every account.
Protecting the devices on which credentials are used remains part of the response. Our endpoint security vs antivirus guide explains the device-protection layer. It complements identity controls; it does not replace a review of directory configuration.
What to check if compromise is suspected
Distinguish a hardening project from an active incident. Removing an obsolete encryption option does not establish that a compromised account or device is clean. Record the affected identities, preserve relevant evidence and involve the people responsible for incident response before making changes that could obscure the sequence of events.
A useful investigation should answer which secret may have been exposed, where it could have been used, what access the account held and whether other identities were affected. Recovery should then address those findings, rather than assuming that one password change or one encryption-policy change closes the incident.
For the separate problem of access continuing after an account is disabled, read our guide to disabled Active Directory accounts and Kerberos tickets. Encryption choice and access revocation are related security concerns, but they are not the same mechanism.
Frequently asked questions
Is this a newly discovered Active Directory vulnerability?
No. This article revisits a historical credential-abuse disclosure and explains the relevant protocol behaviour and defensive considerations. It does not report a new Impulsec discovery.
Can an NT password hash be used with Kerberos?
RC4-HMAC Kerberos uses the NT password hash as key material. Whether that material can be used in a particular environment depends on accepted encryption types and account controls.
Does disabling NTLM also disable Kerberos RC4?
No. NTLM authentication and Kerberos encryption settings are separate controls. Review both.
Are Kerberos attacks invisible to SIEM tools?
No. Windows provides useful authentication and account-event records. Detection depends on available fields, auditing, collection and correlation; no single event guarantees detection of every attack.
Should I disable RC4 immediately across the domain?
First identify dependencies, verify AES readiness and test the change. A staged migration reduces the risk of interrupting legitimate authentication.
Share this article
Stuart Kerr Spindlow is Impulsec’s Publisher, Chief Editor and Lead Reviewer. He writes and maintains coverage of consumer cybersecurity and digital-safety software, with a focus on practical suitability, limitations and the evidence behind product claims. Read Stuart’s full profile.
Wow. This is one of the clearest breakdowns I’ve read on the Active Directory RC4-HMAC issue. The fact that attackers can change passwords without triggering logs is absolutely chilling. Microsoft calling this a “limitation” doesn’t cut it. Thanks for shining a light on this – critical reading for any sysadmin!
Excellent write-up, Kevin. As someone managing a Windows 2019 DFL environment, this vulnerability makes me rethink our current logging and auditing stack. Time to push the Protected Users group and consider disabling RC4 across the board. Bookmarking this for my next security presentation!
This right here is why relying solely on SIEM logs is dangerous. Attackers bypassing detection completely through legacy protocol loopholes is a wake-up call. Appreciate the practical mitigation tips—especially the call to correlate unusual encryption use with access anomalies. Superb work.
Incredible analysis. The PoC validation makes this even more terrifying. What struck me most is how “well-known” this is in theory, but no one connected the dots like this before. RC4-HMAC is the silent backdoor we’ve all been ignoring. Time to review our domain policy—urgently.