keyeroo is a Python research tool that relays coerced NTLM authentication to LDAP and recovers the victim's session key over a Netlogon secure channel, documented here for defenders running authorized assessments.
| Tool | grayhatkiller/keyeroo — wraps Impacket's ntlmrelayx.py to relay coerced NTLM to LDAP and bypass signing by recovering the victim's session key |
| Category | Active Directory attack research tooling (Python) |
| Primary Use | Demonstrating, in authorized lab and assessment environments, how an NTLMv1-ESS coerced authentication can be turned into a signed LDAP write such as an RBCD or shadow-credentials modification |
| Safe Use | Educational and documentary analysis for authorized penetration testers and defenders operating in owned labs or engagements with written permission; not for use against systems you do not control |
| Telemetry Note | Defenders should watch for Netlogon secure-channel validation calls (NetrLogonSamLogonWithFlags) from unexpected machine accounts, coerced-authentication spikes over SMB, NTLMv1 usage where LmCompatibilityLevel should be 3+, and writes to msDS-KeyCredentialLink or the msDS-AllowedToActOnBehalfOfOtherIdentity attribute |
keyeroo is the successor to the author's earlier switcheroo tool, and it exists to solve a very specific problem in NTLM relay research: when a domain controller enforces LDAP signing, a classic relay fails because the attacker never learns the victim's session key, which is the material used to derive the signing key for every LDAP message following the bind. Rather than sidestepping that requirement, keyeroo goes and gets the key itself, then signs the malicious operation exactly as the victim would. The README is unusually candid about the lineage: switcheroo stacked the bind and the operation into a single buffer signed with the attacker's own key, a trick closed off by the October 2026 patch, and keyeroo is the follow-on that remains effective against patched, signing-required controllers under specific legacy conditions.
The mechanics deserve close attention because they explain both the power and the limits of the technique. When a victim is coerced into authenticating to the attacker's listener over SMB, keyeroo responds with an NTLM CHALLENGE that deliberately strips the TargetInfo field. A legacy-capable victim answers with an NTLMv1-ESS — 24-byte — AUTHENTICATE message rather than the modern NTLMv2 response. That downgrade path is the linchpin of the entire chain, and it is where the tool's applicability begins and ends on most contemporary estates.
The recovered AUTHENTICATE blob is then submitted to the domain controller through a Netlogon secure channel established by a machine account the operator controls, via NetrLogonSamLogonWithFlags. The controller validates the victim's credential material and hands back the victim's base key; from that, keyeroo derives the NTLMv1-ESS key-exchange key and decrypts the victim's exported session key. This is essentially using the DC as a validation oracle — the same trust primitive that made the historical Netlogon weaknesses so consequential — but channeled through a legitimate machine account the operator provisioned. Under default MachineAccountQuota, the README notes, any ordinary domain user can create such an account, which is itself a hardening signal defenders should act on.
With the victim's session key in hand, the signing key falls out by standard derivation. keyeroo completes the relayed LDAP bind, re-keys the connection with the recovered session key, and sends the actual write operation — RBCD by default — inside its own SASL record signed with the victim's legitimate signing key. From the controller's perspective, everything checks out: the signature matches the authenticated identity, the channel policy is satisfied, and the write is attributed to the coerced account. That attribution is a double-edged property for blue teams, because the resulting directory change looks exactly like a legitimate action by the victim object.
Implementation-wise, keyeroo is a thin orchestration layer rather than a from-scratch protocol stack. The README describes it explicitly as a wrapper around Impacket's ntlmrelayx.py, which it launches on the operator's behalf. Practically, that means anyone who has run ntlmrelayx.py in an authorized lab will recognize the workflow: you point the tool at a domain controller FQDN, supply -dc-ip, -base-dn, and -domain, then specify the listener address via -listen-ip. The relay target connection starts anonymous unless you prefix the target spec with domain/user[:password]@, in which case it authenticates and enables a read-back verification step.
The oracle machine is configured through -oracle-machine plus either -oracle-password or -oracle-hashes in [LM]:NT form, and -oracle-dc-ip lets you select a different controller for the Netlogon channel than the one receiving the LDAP write. Payload options cover the usual privilege-escalation primitives: -rbcd-sid for resource-based constrained delegation, -shadow-credentials for appending a Key Credential to msDS-KeyCredentialLink, and generic -attribute with -value or -value-hex for arbitrary attribute writes. The victim and target object are named with -victim and -modify-dn, and the victim must legitimately hold write rights over the target — self-write on its own computer object being the canonical case.
The shadow-credentials mode is the most feature-complete path in the README. It performs an LDAP add rather than a replace on msDS-KeyCredentialLink, so pre-existing keys survive, and it emits a PFX file controlled by -pfx-out and -pfx-pass. The README notes the caveat that cashing in that certificate to recover the target's NT hash requires forest-level PKINIT support — an enterprise CA issuing KDC certificates — and suggests cleanup with certipy-ad shadow clear afterward. As a general point for documentation purposes only, these post-exploitation steps assume an environment built for exactly this kind of exercise.
The most important fact for any defender reading the README is the dependency statement: the entire chain requires the victim to emit NTLMv1-ESS, which means LmCompatibilityLevel of 2 or lower, or a genuinely ancient stack. Modern Windows defaults to NTLMv2, and Windows 11 and Server 2025 remove NTLMv1 support outright. In other words, keyeroo is explicitly a legacy-path tool. Where domains have enforced LmCompatibilityLevel 3+ or completed their NTLMv1 removal, the technique does not fire — this is precisely why the author labels it a legacy-dependent route despite it defeating the October 2026 patch on otherwise fully patched controllers.
For defenders, the defensive checklist almost writes itself. Enforce NTLMv2-only via LmCompatibilityLevel and track Microsoft's NTLMv1 deprecation milestones; audit and constrain MachineAccountQuota so any domain user cannot silently provision Netlogon-capable machine accounts; monitor for anomalous NetrLogonSamLogonWithFlags traffic from newly created or unexpected machine accounts; and alert on authentication-coercion patterns — unusual inbound SMB sessions to non-file-server hosts — plus writes to msDS-KeyCredentialLink and msDS-AllowedToActOnBehalfOfOtherIdentity. Each of these touches a distinct stage of the chain, giving layered detection opportunities.
For the offensive researcher working in an authorized lab, keyeroo is best understood as a well-documented reference implementation of a session-key recovery relay, joining switcheroo and the SpecterOps writeup on LDAP signing bypasses as a trilogy on the same root problem. Running it locally is the standard pattern for this class of tool: fetch the repository with git clone https://github.com/grayhatkiller/keyeroo alongside a current Impacket checkout, and invoke python3 keyeroo.py '<DC.fqdn>' ... with the flags described above pointed at lab-only infrastructure. The repository carries 36 stars at the time of writing, is written in Python, and lists no license, which matters if you plan to redistribute or adapt the code in training material.
There is also a broader architectural lesson here that outlives this specific tool. The chain works because the DC was convinced to disclose a session key to a party that had legitimately established a secure channel, and because legacy negotiation let the victim's response be downgraded. Any protocol environment where validation oracles and weak negotiation coexist is a candidate for the same structural attack, and keyeroo is a clean, readable demonstration of that principle. For educators and tool authors, the three-step breakdown in the README — downgrade, oracle validation, key derivation — is a template for analyzing similar designs well beyond NTLM and LDAP.
In sum, keyeroo is a narrowly scoped but technically sharp contribution: it keeps the coerced-authentication-to-signed-LDAP-write class of attack alive against patched controllers, but only where NTLMv1-ESS victims persist. Treated as documentation of that residual risk, it earns its place in an assessment toolkit for authorized engagements and, more importantly, on the reading list of any Active Directory defender still carrying LmCompatibilityLevel debt.
grayhatkiller/keyeroo.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.