CQURE Hacks #69: SMB Signing – Why It Won’t Save Your Data from a Passive Traffic Sniffer

The Experiment Setup

Our test environment was configured for maximum network security, with both the server (SRV01) and the client (WIN11-01) explicitly set to support and require SMB signing.

1. The Attacker: We used a Kali Linux machine to act as the attacker and intermediary.
2. The Attack: We launched a bi-directional ARP Spoofing attack (Man-in-the-Middle) to intercept all traffic flowing between the client and the server.
3. The Capture: Wireshark was launched on the attacker’s machine to capture the SMB2 traffic.
4. The Test: From the client system, we accessed a file share (\\SRV01\CertEnroll) and created a new file with the content: “SMB signing test”.

The Critical Finding

Despite having SMB signing enforced on both endpoints, our packet capture yielded a critical, visible finding: the entire contents of the file, “SMB signing test,” were successfully captured and clearly readable in the Wireshark packets.

The conclusion is clear: SMB signing does not protect data from a passive traffic sniffer in a man-in-the-middle scenario.

The Security Takeaway: Signature ≠ Encryption

The reason for this failure is simple: A signature is not the same as encryption.

• SMB Signing is a mechanism that prevents session spoofing and relay attacks by verifying the identity and integrity of the data sender. It ensures that the traffic hasn’t been tampered with in transit.
• SMB Encryption is a distinct mechanism that scrambles the data, rendering it unreadable to anyone without the decryption key.

While SMB signing is vital for protecting the integrity of the communication, it does not automatically encrypt the data being transferred. As a result, an attacker who successfully performs an ARP spoofing attack can still read the unencrypted SMB traffic.For true confidentiality and to protect your data from passive snooping, SMB encryption must also be implemented alongside SMB signing.

Check out the Advanced Windows Security Course for 2026 offer >>

---

Transcript of the video:

Hi and welcome back to another episode of CQURE Hacks.

Today we will observe how packet sniffing behaves when SMB signing is enabled.

We begin in Kali Linux, the attacker’s machine.

The first step is to enable IP forwarding using the echo 1 command,

and that allows Kali to act as an intermediary for network traffic.

Next, we ensure the necessary tools are installed by checking for that dsniff package.

And with dsniff confirmed our environment is ready, we move to our target systems.

On the 1st system, SRV01 (at 10.10.10.20), we check the SMB configuration.

The settings confirm that the system supports and requires SMB signing.

We perform the same check on the client system, WIN11-01 (at 10.10.10.40).

From the client side we see it also supports and requires signing.

The connection we will test will run from the client, so .40 to the server .20.

Now we’ll launch the attack from our Kali machine.

We execute the ARP Spoofing attack.

The goal is to make the Kali host the intermediary.

The traffic flowing from host .40 to host .20 will be intercepted by Kali.

We poison the ERP cache in both directions, telling host .40 we are host .20 and telling host .20 we are host 40.

This establishes a bi-directional Man-in-the-Middle attack.

Next, we launch Wireshark to capture the traffic passing through our machine.

We’ll begin to capture on our active network interface and apply a display filter for SMB2 traffic.

On the Windows client, so .40 we initiate that file access by navigating to the server share and that is \SRV01\CertEnroll.

We then create a new text file and input the content:

SMB signing test.

We return to Kali. As we confirmed signing was enabled on both the server and the client.

Now we search the captured packets in Wireshark for the content we just wrote.

We search that packet bytes for the word signing.

The critical finding is visible.

We successfully capture the entire content of the file.

SMB signing test.

This demonstrates that signing does not protect against man in the middle attacks.

The reason is super simple.

A signature is not the same as encryption.

How good is the signature if a communication is not encrypted while the attacker can still read the unencrypted SMB traffic after performing an ARP spoofing attack?

While SMB signing prevents session spoofing and relay attacks, it does not automatically encrypt data being transferred.

Signing and encryption are two distinct mechanisms.

For true confidentiality, SMB encryption must also be implemented.

SMB signing does not provide encryption and fails to protect data from a passive traffic sniffer in a man in the middle scenario.

Thank you so much for watching our Secure Hacks episodes.

And as always, in order to continue this serial, please don’t forget to support us by hitting the subscribe button.

And as always, stay secure.