Bypassing SMB Signing: Escalating Privileges via Cross-Protocol NTLM to LDAP Relaying

During a recent internal penetration test, I found myself staring down a well-configured Domain Controller. My initial plan was standard: find a way to relay SMB authentication. However, a quick check revealed that SMB Signing was set to "TRUE" on the DC. Pure SMB relaying was dead in the water.

But in Active Directory environments, when one door closes, a protocol port often opens. Instead of giving up, I shifted my focus to the Lightweight Directory Access Protocol (LDAP) and decided to test the waters with LDAP signing and Channel Binding.

Here is a breakdown of how I leveraged cross-protocol NTLM relaying to bypass the SMB roadblock, dump domain information, and ultimately gain full control over the forest.

The Pivot: Targeting LDAP

While SMB signing was strictly enforced, LDAP often suffers from legacy misconfigurations. My goal was to see if I could catch an NTLM authentication attempt over a different protocol and relay it directly to LDAP on the Domain Controller.

To execute this, I fired up impacket-ntlmrelayx, targeting the DC's LDAP service: ntlmrelayx.py -t ldaps://192.168.50.2

Then, I waited.

Because Active Directory environments are incredibly noisy, it didn't take long for authentication attempts to start rolling in. The beauty of this attack lies in the fact that ntlmrelayx doesn't care if the incoming connection is SMB, HTTP, or something else. It simply grabs the authentication and forwards it to the target LDAP service.

The Escalation

As the tool ran, multiple user authentications were relayed based on their specific privileges. I watched as the tool successfully queried the directory and enumerated permissions.

Eventually, the golden ticket arrived: a Domain Admin authenticated.

Because LDAP signing wasn't strictly enforcing a block on the relayed session and Channel Binding wasn't enforced, ntlmrelayx successfully relayed the DA's authentication. Capitalizing on those privileges, the tool automatically created a dummy Enterprise Admin account (as seen in the command output: NWSuoZKeRH).

Just like that, I bypassed the SMB signing restriction and achieved full control over the Forest.

Then I verified my new credentials against some SMB shares that i did not has access to before, and guess what ? they worked !

Key Takeaways & Misconceptions

If you are defending an AD environment, it's critical to understand why this attack worked. Here are three vital concepts to take away from this engagement:

1. Protocol Independence

This attack thrives because of protocol independence. The victim can connect to the attacker's machine via SMB, HTTP, or other protocols — the relay works completely cross-protocol. This is possible because the NTLM messages are identical regardless of the underlying transport mechanism. An NTLM hash over HTTP looks exactly the same as an NTLM hash over SMB to the receiving server.

2. The LDAP Signing Misconception

There is a dangerous misconception in the industry that NTLM relaying to LDAP only works if LDAP signing is completely turned off (set to false).

The Reality: Attackers use tools like ntlmrelayx that are remarkably smart. Even if the target LDAP server requires signing, the tool can often negotiate and establish signing using the victim's session context. Therefore, simply having LDAP signing enabled is often not enough to stop a sophisticated relay attack.

3. Channel Binding / EPA (The Real Blocker)

If SMB signing blocks SMB relays, what actually stops LDAP relays? The answer is Extended Protection for Authentication (EPA), also known as Channel Binding.

What it is: EPA cryptographically links the outer encrypted TLS channel directly to the inner NTLM authentication. The Reality: When EPA is enabled, the LDAP server essentially says: "I will only accept this NTLM login if it matches the exact cryptographic TLS certificate I am currently using." Why it stops the attack: Because the attacker is sitting in the middle (MitM), they are forced to use one TLS connection to the victim and a completely different TLS connection to the LDAP server. Because the certificates do not match, the cryptographic validation fails, and the attack is stopped dead in its tracks.

Conclusion

Relying solely on SMB signing creates a false sense of security. As long as NTLM is still enabled and EPA is not strictly enforced across your LDAP/LDAPS infrastructure, your domain remains vulnerable to cross-protocol relay attacks. To properly secure your perimeter, enforce LDAP Channel Binding and start the long (but necessary) journey of disabling NTLM entirely.