SMB Signing Not Enforced: Real-World Active Directory Attack Chains Explained

Many organizations we assess believe SMB signing is “handled.” The setting is present, and it’s often enabled. Sometimes it’s even configured via Group Policy. Yet, during internal penetration tests, we still exploit unsigned SMB traffic every single week.

The problem isn’t always that teams don’t know about SMB signing. Rather, the way it fails in real environments is subtle, quiet, and easy to miss, especially when everything looks to be configured correctly at first glance.

This post focuses on how unsigned or partially enforced SMB signing gets abused during internal assessments, and why it continues to enable attack chains long after organizations think the issue is resolved.

“Enabled” Is Not the Same as “Required”

One of the most common configurations we run into looks like this:

• SMB signing enabled
• SMB signing not required

As pentesters, we can check for a lack of SMB signing across one or many tools using tools such as Nmap, NetExec, or RunFinger.py (packaged with the Responder tool) to enumerate SMB signing enforcement across internal hosts. Systems that allow unsigned SMB connections remain vulnerable to relay-based attack chains.

$ python RunFinger.py -i 192.168.200.0/24 –a

Retrieving information for 192.168.200.7...
SMB signing: False
Null Sessions Allowed: False
Vulnerable to MS17-010: False
Server Time: 2024-10-31 15:55:44
OS version: 'Windows 10 Pro 18362'
Lanman Client: 'Windows 10 Pro 6.3'
Machine Hostname: 'DTAHD-2431'
This machine is part of the 'PRYSM' domain
 
Retrieving information for 192.168.200.20...
SMB signing: False
Null Sessions Allowed: False
Vulnerable to MS17-010: False
Server Time: 2024-10-31 15:55:44
OS version: 'Windows 7 Professional 7601 Service Pack 1'
Lanman Client: 'Windows 7 Professional 6.1'
Machine Hostname: 'DTA-1950'
This machine is part of the 'PRYSM' domain

From a defender’s perspective, the settings often look right. The control is present, modern systems support it, and nothing appears broken.

When signing is enabled but not required, systems will happily accept unsigned SMB connections if the client doesn’t insist on signing. That configuration gap is often all that’s needed to relay authentication, obtain a foothold, pivot deeper into the environment, or achieve a fast, easy domain compromise.

This exact configuration shows up on user workstations, file servers, application servers, and management hosts in otherwise mature domains.

If you’re looking for the technical breakdown of how SMB signing works and how to enforce it correctly, we cover that in detail here: → How to Enforce SMB Signing in Active Directory (And Why It Matters)

How This Gets Abused During Internal Penetration Tests

In real internal networks, SMB relay is not a flashy exploit; at this point, it's considered a "staple" attack, one of the first "low-hanging fruit" issues a tester looks for. It doesn’t require custom tooling or complicated attack chains. It may not even trigger endpoint detections, even though it happens entirely within “normal” Windows traffic.

A typical abuse path is as follows:

• A tool such as NetExec is used to find hosts where SMB signing is not required
• An authentication attempt is coerced or captured on the network, often using a network traffic response spoofing tool such as Responder
• That authentication is relayed to another system that accepts unsigned SMB
• Access is granted using the victim’s existing privileges, often granting local administrator access to the targeted host

At that point, the attacker isn’t doing password spraying or exploiting vulnerabilities; rather, they're reusing authentication credentials that the environment already trusts.

Depending on where a successful relay lands, the outcome may include:

• Administrative access to file or database services
• Local admin access to a workstation, which may lead to credential theft
• Credential reuse after successful relay(s) that enable lateral movement or privilege escalation
• A foothold in the Active Directory environment that can be leveraged for further abuse

Due to the attack's relative simplicity and power, SMB signing issues often appear early in internal attack chains.

Why This Can Be Hard to Detect

We've tested in well-buttoned-down environments that detect many enumeration and attack tactics but are blind to network traffic response spoofing, authentication coercion, and SMB Relay attacks. One reason this problem persists is that it often doesn't appear to be an attack unless you are explicitly monitoring for the behavior.

From a monitoring perspective, it often appears to be normal SMB traffic, valid authentication attempts, and access using legitimate credentials. Unless you are set up to detect and block NTLM relay attacks or enforce signing everywhere, this activity typically blends in with standard network traffic.

This is also why environments with strong EDR coverage are still vulnerable. Endpoint protection may not help when the protocol itself allows the behavior.

What SMB Relay Enables Downstream

Sometimes the tester gets lucky, and an unsigned SMB request, together with a successful LLMNR/NBT-NS Response Spoofing attack, results in direct domain compromise. This used to be the norm, setting up and taking over the domain with a successful relay in under a minute. Nowadays, it's more often used as an entry point. After a successful SMB relay, we typically chain it with other attacks to form attack chains that may involve Kerberoasting, ACL attacks, Active Directory Certificate Services (AD CS) attacks, or other Kerberos attacks to move laterally or perform domain privilege escalation.

In isolation, unenforced SMB signing may appear to be a low-risk issue. But when combined with other attacks, it can create reliable chains for lateral movement and privilege escalation. This is why SMB signing failures are so often tied to broader Active Directory compromise scenarios rather than standalone findings.

Why We Check for This Early

During internal penetration tests, SMB signing enforcement is one of the first things we validate, not because it’s an exotic attack, but much the opposite. Rather, it quietly enables so many other attack chains and has been a reliable attack across organizations of all sizes for well over a decade. Even with greater awareness of the importance of SMB signing, we still see environments where certain hosts slip through the cracks, or where it's enabled everywhere but enforced nowhere.

When SMB signing is fully enforced on both clients and servers, entire classes of relay-based attacks simply stop working. That single control removes a surprising amount of attacker flexibility, especially for initial access attacks. It's a low-effort, low-cost fix that delivers massive upside for the organization. Of course, as with any change, it should be tested and rolled out slowly to ensure nothing breaks in the environment.

Final Thoughts

Unsigned or partially enforced SMB signing remains one of the most consistently exploitable weaknesses we encounter in internal networks. It's not just present in legacy environments, or even in poorly managed ones. The issue (which consistently appears on our annual top 10 most common internal penetration test findings list ) and resultant attack chains exist in environments of all sizes, across all verticals.

It persists because the failure mode is quiet, the configuration often appears correct until pressure tested, and the impact isn’t obvious until it’s chained with something else. It's a fix that should be applied across every network.

Our Active Directory Security Hardening & Hygiene Checklist covers the most common issues we see during internal assessments and how to properly address them.

Unsure if SMB signing is enforced properly in your environment?

Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones.

Have a question about this article or a security challenge of your own? Fill out the form and we’ll get back to you shortly.