How Does It Smell? Sniffing SMB Traffic.

Intro

Server Message Block (SMB): what is it? I'll borrow the Wikipedia definition:

Server Message Block provides file sharing, network browsing, printing services, and interprocess communication over a network.

I wanted to confirm whether the SMB traffic on the network in question was unencrypted.  I was pretty sure it was, but looking at the traffic would confirm and be an interesting exercise. Security professionals should care (or at least be aware) as this means an attacker appropriately situated on the local network can sniff unencrypted traffic and capture file transfers to/from the thousands of shares around a large enterprise.  They may not have permissions to access the share directly so capturing the data in transit bypasses these restrictions.

On Windows, SMB shares can be encrypted relatively easily. Server Manager is one option using File and Storage Services. Alternatively, in PowerShell you can encrypt a designated share or all SMB traffic for a given server using:

Set-SmbShare –Name <sharename> -EncryptData $true

Set-SmbServerConfiguration –EncryptData $true

The same issue extends to any other unencrypted traffic on your network like FTP, Telnet, HTTP, SNMP, etc.  The point of mentioning this is that the traffic from these protocols can be captured and viewed in the same manner.

Setup

As a simple experiment I transferred a xlsx spreadsheet from my local workstation to a remote share.  Unlike an adversary, I was in a position and had the approval to request that our network team configure a SPAN port (Switched Port Analyzer) to mirror all switch traffic to a port of my choosing on one of the core switches.  An attacker would have to go through the extra step of setting up some type of man-in-the-middle (MitM), gain administrative privileges to the switch, or have physical access to install an inline network tap. My toolkit included a Fluke Optiview XG (Fluke Networks has since been acquired by NETSCOUT) which gives me a mobile capture platform and allows me to collect packets from the comfort of my desk (i.e., not freezing in loud server rooms).  To reduce additional traffic noise I restricted the packet capture to my local IP and to the IP of the share.  If I was doing this with tcpdump I'd capture the traffic using this command:

tcpdump -i <tap_interface> -w <output_file.pcacp> "src host <src_ip> and dst host <dst_ip>"

I opened the pcap within Wireshark and focused on SMBv2 traffic which uses destination port TCP 445 (also known as Microsoft Directory Services).  Note that older versions of Windows instead used the trio of NetBIOS related ports: UDP 137 and 138, TCP 139. Keep in mind that Wireshark uses the SMBv2 label for v2 and v3 SMB packets as the header is the same.  I wasn’t aware of this until a colleague pointed it out.  Also note that if you ever do this and happen to see SMBv1 traffic that’s bad and you should talk with the ops folks to get it disabled as soon as possible (i.e., unless it's needed for a legacy application in which case you should consider other mitigations).  For an example of the ramifications of running SMBv1 see ExternalBlue.

Analysis

The PCAP has a lot of dropped TCP packets.  I'd guess this is the result of the distance between my location and the share.  Fortunately, TCP is designed to keep retrying those transmissions so it will (usually) work.  To see the SMB session a little more cleanly I applied this display filter in Wireshark (my TCP stream was 0 so don't assume this as it can be anything depending on how much traffic you captured):

tcp.stream eq 0 && smb2

SMB traffic with a Wireshark display filter.

In Wireshark to view the complete data stream right-click on any one of the packets then go to Follow > TCP Stream. This will show all the SMB control data as well as the xlsx data that was transmitted (in UNICODE by default).  Don’t expect to make too much sense of this view but you can see somethings like the original xlsx file name along with the internal structure of the xlsx format.

SMB TCP stream.

As a quick aside did you know that the MS Office formats like xlsx, docx, and pptx are a collection of zipped XML files?  If you want to confirm this take a file that you have in one of those formats, make a copy of it (so you don’t ruin the original), change the extension to .zip, and then unzip it either by right-clicking and selecting Extract All; or you can use the PowerShell cmdlet called Expand-Archive.

To find and extract the transmitted file from the PCAP you’ll want to look for the SMB traffic that used the Write Request command.  For this example that was packet number 67.

SMB Write Request command.

Under the SMB2 layer details, Wireshark nicely breaks out a Data subsection.  It tells you that it’s 28947 bytes which is a good sign because that’s the same size as the original xlsx.

SMB2 Wireshark Data section.

You can export those raw bytes by clicking the Data: section and pressing Ctrl+H or by right-clicking on it and selecting Export Packet Bytes.  Save the data with whatever name you want.  Notice that it will default to the Raw data format with a .bin extension (for binary).  This means the bytes are saved as-is (i.e., bit-for-bit) as the operating system has no notion of known file formats when dealing with raw data.  After that, manually add the .xlsx file extension to the file.  The OS will take your word (no pun intended) for it and if MS Office, Open Office, LibreOffice, or some other program that can interpret that file format is installed, the xlsx extension will display the known, pretty icon.  If all is well and the correct data was exported it should open in a spreadsheet application exactly as the original. Perfectly sniffed!