Detect and Respond to Adversary-in-the-Middle Attacks (T1557)

What is adversary-in-the-middle and why it is so dangerous

Adversary-in-the-Middle (T1557) describes techniques where attackers position themselves between two communicating parties to intercept or manipulate authentication traffic. In Active Directory environments, the most devastating variant is NTLM relay. The attacker coerces a high-privilege account (often a domain controller) into authenticating to them, then relays that authentication to a target service to gain access as the victim.

This technique belongs to the Credential Access (TA0006) tactic in the MITRE ATT&CK framework, and modern variants like PetitPotam represent some of the fastest paths to full domain compromise available to attackers. Unlike credential dumping or Kerberoasting, NTLM relay does not require cracking any passwords. The entire attack chain, from coercion to domain takeover, can execute in seconds.

The Mandiant M-Trends 2025 report identified NTLM relay as an increasingly common technique in targeted intrusions, particularly when combined with Active Directory Certificate Services (AD CS) misconfigurations. Patching alone is insufficient; organizations need real-time detection to catch these attacks as they happen.

Adversary-in-the-Middle at a Glance: Impact, Scope, and Risk

How PetitPotam NTLM Relay Works: Coercion-to-DCSync Attack Walkthrough

A PetitPotam NTLM relay attack achieves domain compromise in four stages.

Stage 1 - NTLM Coercion

The attacker exploits the PetitPotam vulnerability (abusing the MS-EFSRPC protocol) to force a domain controller to initiate NTLM authentication to a machine under the attacker's control. The attacker only needs network access to the domain controller and a low-privilege domain account. The domain controller's machine account authenticates to the attacker, who captures the NTLM challenge-response.

What this looks like in logs

Stage 2 - NTLM Relay to AD CS

Instead of using the captured NTLM authentication directly, the attacker relays it to the organization's Active Directory Certificate Services (AD CS) web enrollment endpoint. Using ntlmrelayx, the attacker requests a certificate on behalf of the domain controller. AD CS issues the certificate because the authentication is technically valid because it came from the domain controller's machine account.

Stage 3 - Certificate-Based Impersonation

With a certificate issued to the domain controller's identity, the attacker can now authenticate as the domain controller to any service using Kerberos PKINIT. They request a TGT as the domain controller, which grants them the same permissions as the DC itself, including the ability to replicate Active Directory data.

Stage 4 - Domain Takeover via DCSync

Authenticated as the domain controller, the attacker executes DCSync to extract every password hash in the domain, including the KRBTGT account. With the KRBTGT hash, they forge Golden Tickets for persistent, unrestricted access. The entire chain from coercion to domain takeover completes in seconds.

Real-World Attack: PetitPotam Exploitation (2024-2025)

PetitPotam, first disclosed by security researcher Gilles Lionel in 2021, continued to be actively exploited throughout 2024 and 2025 despite available patches, because many organizations had not fully mitigated the underlying NTLM relay vector. CISA advisories repeatedly warned about PetitPotam variants targeting organizations with AD CS web enrollment enabled.

In a notable 2024 incident documented by the CrowdStrike 2025 Global Threat Report, a threat actor used PetitPotam to compromise a manufacturing organization's Active Directory in under 5 minutes. The attacker gained initial access through a VPN credential, ran PetitPotam to coerce the primary domain controller, relayed the authentication to the AD CS endpoint, obtained a DC certificate, and executed DCSync to extract all domain hashes. Ransomware deployment began within 30 minutes of the initial VPN login.

The speed of this attack underscores why NTLM relay detection must be real-time. Organizations that rely solely on post-incident log review cannot respond fast enough to prevent domain compromise.

How to Detect and Investigate NTLM Relay with Log360

Log360 provides real-time detection for NTLM relay attacks through its correlation engine, targeting the specific tools and behaviors that characterize PetitPotam and related attacks.

Real-Time Detection

Detecting PetitPotam and NTLM Coercion

The Petitpotam detection rule (Critical, Windows) is Log360's primary defense against NTLM coercion attacks. This rule monitors for the process behavior and known tool signatures associated with PetitPotam execution, firing when the exploit tool is detected on any monitored endpoint. Because PetitPotam variants continue to evolve, the rule combines tool signature matching with behavioral indicators like unexpected EFS RPC calls to domain controllers.

Detecting Print Spooler-Based Relay

Before PetitPotam, the Print Spooler service (SpoolSample/PrinterBug) was the primary NTLM coercion vector. Log360's Suspicious NTLM Authentication on the Printer Spooler Service rule (Trouble, Windows) detects when the Print Spooler service triggers NTLM authentication to an unexpected host, which is the signature of a PrinterBug exploitation attempt.

Detecting AD CS Exploitation

The HackTool. ADCSPwn Execution rule (Trouble, AD) catches the ADCSPwn tool, which automates the AD CS certificate request relay. This rule fires on process creation signatures matching ADCSPwn's binary name and command-line arguments, providing detection at the exploitation stage even if the initial NTLM coercion was not captured.

Behavioral Detection with UEBA

Log360's UEBA module adds critical context by tracking NTLM authentication patterns. When a domain controller machine account authenticates to a workstation via NTLM (which almost never happens in normal operations), the behavioral anomaly triggers an elevated risk score. Combined with the rule-based detection, UEBA provides defense-in-depth for NTLM relay variants that evade tool signatures.

Investigation Workflow in Log360

1. Identify the target DC: Determine which domain controller was coerced into authenticating. Check Event ID 4624 with NTLM package for the DC machine account authenticating to a non-DC host.
2. Check AD CS enrollment logs: Search for certificate enrollment requests from the DC machine account around the time of the NTLM authentication. A certificate issued to the DC through web enrollment confirms successful relay.
3. Look for DCSync indicators: If the relay succeeded, the attacker likely executed DCSync immediately. Check for AD Replication from Non Machine Account alerts.
4. Identify the attacker's host: The source workstation in the NTLM authentication event reveals the attacker's machine. Trace all activity from that host.
5. Assess domain compromise scope: If DCSync was executed, assume all domain account hashes are compromised, including KRBTGT.

Coverage Gaps and Custom Rules

• DC Machine Account NTLM to Non-DC: Alert when any domain controller machine account authenticates via NTLM to a host that is not a domain controller. This catches all NTLM coercion variants, not just PetitPotam.
• AD CS Web Enrollment from Machine Account: Monitor AD CS enrollment logs for certificate requests from machine accounts through the web enrollment endpoint, which is the relay target.

How to Remediate and Prevent NTLM Relay Attacks

Immediate Containment

1. Isolate the attacking host immediately: Use Log360's automated response to trigger network isolation.
2. Revoke issued certificates: If the relay succeeded and a certificate was issued, revoke it immediately through AD CS.
3. If DCSync followed: Rotate the KRBTGT password twice and reset all privileged account passwords. Follow the DCSync remediation steps.
4. Preserve evidence: Export the NTLM authentication events, AD CS enrollment logs, and any DCSync indicators from Log360.

Root Cause Remediation

• Disable NTLM where possible: Migrate to Kerberos-only authentication. Use NIST guidance on eliminating NTLM.
• Enable Extended Protection for Authentication (EPA): Configure EPA on all IIS-hosted endpoints, including AD CS web enrollment.
• Disable Print Spooler on DCs: The Print Spooler service is not needed on domain controllers and is a primary NTLM coercion vector. Disable it via Group Policy.
• Patch and harden AD CS: Apply all CISA-recommended patches. Disable web enrollment if not required. Restrict certificate template permissions.

Long-Term Hardening

• LDAP signing and channel binding: Enforce LDAP signing on all domain controllers to prevent LDAP relay attacks.
• Network segmentation: Place domain controllers in a restricted network segment where only authorized management workstations can reach them.
• Regular AD CS audit: Use tools like Certify and PSPKIAudit to audit AD CS configurations for relay-vulnerable templates and endpoints.

Log360 Automated Response Configuration

• Isolate attacker host: Enable for Petitpotam detection and ADCSPwn Execution rules
• Emergency incident ticket: Auto-create Critical-priority ticket in ServiceDesk Plus
• Page incident response team: Configure SMS alerts for Petitpotam detection (Critical severity)

Need to explore ManageEngine Log360? Schedule a personalized demo

NTLM Relay Attacks: Frequently Asked Questions