Listen to this Post
Introduction:
In the perpetual arms race between offensive security professionals and defensive patching, a recent Microsoft update silently neutralized a critical attack path: relaying NTLM authentication to LDAP to deploy Shadow Credentials. This technique, which allows attackers to backdoor accounts by writing a key credential to Active Directory, was abruptly halted by a validation change, leaving red teams and penetration testers scrambling. Thanks to rapid community research and a clever bypass involving the `CustomKeyInformation` flag, this powerful attack vector has been resurrected, underscoring the dynamic nature of Active Directory security.
Learning Objectives:
- Understand the Shadow Credentials attack and its reliance on the `msDS-KeyCredentialLink` attribute.
- Analyze how Microsoft’s validation patch broke the NTLM relay-to-LDAP technique.
- Implement the updated workaround using modified tools to successfully execute the attack in patched environments.
You Should Know:
- Shadow Credentials Primer: Exploiting Key Trust for Persistence
The Shadow Credentials attack exploits a feature designed for Windows Hello for Business and Azure AD PRT (Primary Refresh Token) management. It involves writing a public key to a user or computer object’s `msDS-KeyCredentialLink` attribute. An attacker can then perform Kerberos authentication as that principal using the corresponding private key, often leading to Silver Ticket issuance or full account compromise. The classic path used the `Whisker` tool or Impacket’s `ntlmrelayx.py` to perform a validated write via SELF, a permission that allows an account to write certain attributes to itself.
Relevant Command (Using Whisker):
Classic pre-patch attack to add a Shadow Credential Whisker.exe add /target:COMPUTER01$ /domain:underco.de /dc:DC01.underco.de
This command would add a new key credential to the computer account COMPUTER01$, granted the relayed authentication had sufficient rights (like SELF via LDAP).
2. The Breaking Change: Microsoft Tightens `msDS-KeyCredentialLink` Validation
Microsoft’s update, aligning with Windows Server 2026 changes, enforced stricter validation on the `msDS-KeyCredentialLink` attribute’s structure during writes. Post-patch, the relayed attack failed because the blob written by standard tools no longer passed these checks. The error `INSUFF_ACCESS_RIGHTS (00002098)` was misleading—authentication succeeded, but the write operation was blocked at the attribute validation level, not the permission level. This effectively closed the door on one of the most reliable lateral movement and persistence techniques.
- The Workaround: Decoding the “MFA Not Required” Flag
Researchers from RedTeam Pentesting GmbH discovered the key. Microsoft’s specification states the `CustomKeyInformation` field should not be present for a validated write. Paradoxically, the bypass requires adding a `CustomKeyInformation` field set with the “MFA Not Required” flag (0x00000001) and simultaneously removing the last logon timestamp field from the credential blob. This crafted blob satisfies the new server-side validation checks, allowing the write to proceed. This appears to be an oversight where Microsoft’s implementation diverged from its own published protocol specifications.
4. Implementing the Fix: Modifying Your Attack Toolkit
Logan G. has integrated this workaround directly into a fork of Impacket. The changes modify the `KeyCredential` structure generation within ntlmrelayx.py. To use the patched version, you must clone the updated repository and ensure you’re using the correct modules.
Step-by-Step Guide:
1. Clone the updated Impacket fork git clone https://github.com/logangoins/impacket.git cd impacket <ol> <li>Install the library in editable mode pip install -e .</p></li> <li><p>Execute ntlmrelayx with LDAPS relay and Shadow Credentials attack ntlmrelayx.py -t ldaps://DC01.underco.de --shadow-credentials --shadow-target 'CN=Server01,CN=Computers,DC=underco,DC=de'
This command will relay captured NTLM authentication to the LDAPS service on the domain controller and attempt to write the modified, compliant `msDS-KeyCredentialLink` attribute to the `Server01` computer account.
- From Compromise to Control: Requesting the Kerberos Certificate
A successful write is only half the battle. Once the Shadow Credential is planted, you must use your private key to request a Kerberos certificate (PKINIT) and obtain a Ticket-Granting Ticket (TGT).
Step-by-Step Guide with Rubeus:
1. Use Rubeus with the previously generated private key (in .pfx format) Rubeus.exe asktgt /user:Server01$ /certificate:key.pfx /password:MyPassword /domain:underco.de /dc:DC01.underco.de /ptt
/user:: The target principal (computer or user account).
/certificate:: The PFX file containing the private key.
/ptt: Injects the resulting TGT directly into the current session’s memory (Pass-the-Ticket).
6. Defensive Hardening: Detecting and Blocking the Attack
Defenders must adapt their detection strategies. Focus on auditing writes to the sensitive `msDS-KeyCredentialLink` attribute and monitor for unusual PKINIT certificate requests.
Relevant Windows Security Log & Sigma Rule Concept:
- Audit Policy: Enable `DS Access` auditing for
Directory Service Changes. - Detection Query (Simplified): Look for `Event ID 5136` (Directory Service Modification) where `Attribute Value` contains `’KeyCredentialLink’` and the `SubjectUserName` is the same as the `TargetUserName` (indicating a SELF write).
- Mitigation: Consider disabling NTLM where possible, enforcing LDAP signing/channel binding, and implementing protective solutions like Microsoft’s “Shadow Credentials Mitigations” if available.
What Undercode Say:
- The Patch Cycle is a Living Puzzle: This event is a textbook example of offensive security research. A patch is released, the community deconstructs it, finds a logical inconsistency in the validation logic, and engineers a bypass—often within days.
- Specifications vs. Implementation is a Critical Attack Surface: The divergence between Microsoft’s official protocol documentation (
[MS-ADTS]) and the actual validation logic created the loophole. Attackers and defenders alike must learn to scrutinize this gap.
The workaround is not a vulnerability in the classic sense but an exploitation of a validation logic flaw. It highlights that complex systems like Active Directory have deep, interdependent features where a “fix” in one area can reveal unexpected behaviors in another. For defenders, this underscores that patching alone is insufficient; robust monitoring for the behavior of an attack (writing key credentials, unusual PKINIT requests) is essential. For offensive practitioners, it reinforces the need to understand underlying protocols and structures, not just tool usage.
Prediction:
This cat-and-mouse game will accelerate a shift towards certificate-based authentication hardening and increased scrutiny of all KeyCredential-related operations within Azure AD and hybrid identities. Microsoft will likely respond with a more comprehensive patch that strictly enforces the specification, potentially breaking legitimate MFA-exemption scenarios and causing compatibility issues. Consequently, we anticipate a rise in detection rules focused on anomalous `msDS-KeyCredentialLink` writes and a push from Microsoft towards newer, cloud-centric authentication models that are less susceptible to these traditional on-premises relay attacks. The core conflict, however, will persist: adding security constraints creates new validation logic, and that logic itself becomes the next battlefield.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Logan Goins – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
