The Phantom Attack: A New NTLM Relay Method Evades EDR to Hijack Networks
Logan Goins, a researcher at SpecterOps, has unveiled a novel technique for exploiting NTLM authentication that enables adversaries to bypass low-level access restrictions in corporate networks and offload tool execution from an infected workstation.
The essence of the method lies not in stealing passwords or hashes, but in hijacking the context of the current user for HTTP authentication, which is then relayed into LDAP on the domain controller. Subsequent operations are conducted through a SOCKS5 proxy on a Linux host, thereby minimizing any detectable interaction with the compromised system under the scrutiny of security controls.
In most attacks, the entry point is a phishing document or another loader executed under the credentials of an ordinary domain user. Attempts to conduct reconnaissance directly from such an account on the infected machine are easily flagged by EDR systems, which monitor process behavior and inspect memory contents. Even “lighter” approaches, such as Beacon Object Files, still require some level of activity on the host. The new technique, however, allows adversaries to shift execution to an external server without compromising passwords or Kerberos tickets — resources often protected by Credential Guard, strict password policies, and other safeguards.
The approach leverages NTLM over HTTP. While Windows SMB and LDAP clients enforce traffic signing by default, preventing straightforward relays, HTTP requests — including those generated by the WebClient service — do not mandate such signatures. Traditionally, this gap opened the door to WebDAV attacks that escalated privileges to SYSTEM. Yet in mature infrastructures, WebClient is often disabled, its startup closely monitored, and auxiliary file or command usage blocked. Thus, the focus shifts to simple HTTP authentication, even if limited to the user context.
This technique has a significant limitation: critical account attributes such as msDs-AllowedToActOnBehalfOfOtherIdentity or altSecurityIdentities cannot be altered, since a user-class object cannot modify them independently. Consequently, relays must be directed exclusively into LDAP, using Impacket’s newly added ntlmrelayx LDAP-socks mode. This capability allows authenticated sessions to be proxied and tools like certipy to be executed from a Linux server, avoiding the deployment of detectable .NET assemblies (e.g., Certify) on the victim host.
Importantly, the attack fails if LDAP signing and LDAPS channel binding are enforced on the domain controller. These options are enabled by default in Windows Server 2025 when provisioning a new DC, but many large organizations have yet to adopt them universally due to compatibility concerns with legacy systems.
The proof-of-concept relies on a compact .NET utility that issues a single HTTP request with the UseDefaultCredentials flag, triggering NTLM authentication for the current user. From there, a development build of Impacket with LDAP-socks support and the Mythic C2 framework (using the Apollo agent) is employed. A SOCKS5 proxy, reverse port forwarding, and the ntlmrelayx server are configured. Once the helper tool SharpHTTP.exe runs, credentials are relayed over HTTP into LDAP, where ntlmrelayx spawns an auxiliary SOCKS port for interacting with the domain controller. Through this channel, Linux-based utilities can execute commands without explicit password handling, as ntlmrelayx transparently supplies the intercepted context.
The practical value of this method is highlighted in Active Directory Certificate Services assessments. Certipy can automatically detect vulnerable certificate templates, a capability absent from TrustedSec’s BOF toolset. Using the relay, certipy successfully retrieves LDAP data, even when the password field contains arbitrary values, since authentication occurs seamlessly in the background.
From a defensive perspective, the core takeaway is that attackers must be confined to the endpoint, where EDR visibility is strongest. Relaying NTLM authentication over HTTP leaves minimal telemetry, making it imperative to enforce LDAP signing and LDAPS channel binding. These policies, configured via GPO, require setting “Domain controller: LDAP server signing requirements” to Require signing and “Domain controller: LDAP server channel binding token requirements” to Always. Only their joint activation fully neutralizes the relay vector.
In conclusion, this technique demonstrates that NTLM contexts can be weaponized for LDAP interaction without harvesting passwords or hashes, keeping activity outside EDR’s detection scope. Its effectiveness, however, hinges entirely on the security posture of domain controllers — and therein lies administrators’ best opportunity to stop such attacks.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
