Chapter 27

SMB Forensics

SMB (Server Message Block) is the Windows file-sharing protocol — and the primary vector for lateral movement in enterprise networks. Every technique in the lateral movement playbook runs over SMB: PsExec (admin share + service creation), DCOM/WMI lateral movement, pass-the-hash authentication, file staging, and ransomware deployment. SMB2 sessions in PCAP reveal which shares were accessed, which named pipes were used, which files were read or written, and whether authentication was successful or failed — all without decrypting anything.

Scenario

You're investigating ransomware deployment across a network. The attacker used legitimate admin credentials obtained via pass-the-hash. In the PCAP you see: SMB2 sessions from one compromised workstation to 47 other workstations, each accessing the ADMIN$ share, writing a file named svchost32.exe, and then creating a service via the svcctl named pipe. This is PsExec-style lateral movement. The entire ransomware deployment is reconstructable from SMB alone.

SMB2 Key Forensic Fields

  SMB2 Session Structure — Forensic Map
  ═══════════════════════════════════════════════════════════════════

  TCP Connection: src:port → dst:445

  Session Setup Request / Response:
  ├── Negotiate: protocol version (SMB 2.0, 2.1, 3.0, 3.1)
  ├── SessionSetup: NTLM or Kerberos auth exchange
  │     smb2.ntlmssp.auth.username: who authenticated
  │     smb2.ntlmssp.auth.domain: from which domain
  │     smb2.sesid: Session ID for correlating all subsequent requests
  └── Status: NT_STATUS_SUCCESS (0x00000000) or LOGON_FAILURE (0xC000006D)

  Tree Connect:
  ├── smb2.tree: UNC path (\\SERVER\sharename)
  │     \\SERVER\C$, \\SERVER\ADMIN$, \\SERVER\IPC$
  └── TreeID: for correlating file operations

  Named Pipe Operations (IPC$ share):
  ├── Common malicious pipes:
  │     \pipe\svcctl  → Service Control Manager (PsExec, lateral movement)
  │     \pipe\atsvc   → Task Scheduler
  │     \pipe\samr    → SAM database (credential dumping)
  │     \pipe\lsarpc  → LSA (pass-the-hash, Mimikatz)
  │     \pipe\epmapper → RPC Endpoint Mapper (DCOM)
  │     \pipe\wkssvc  → Workstation service

  File Operations:
  ├── smb2.filename: path to file being accessed
  ├── smb2.cmd: CREATE/READ/WRITE/CLOSE/DELETE
  ├── smb2.create.disposition: what to do if file exists
  │     OPEN=1, CREATE=2, OPEN_IF=3, OVERWRITE_IF=5
  └── smb2.write.data: file content being written (for analysis)

SMB Analysis with tshark

bashsmb-analysis.sh

#!/bin/bash
PCAP="$1"

echo "=== SMB2 Authentication attempts ==="
tshark -r "$PCAP" -n -Y "smb2.cmd==1" -T fields \
  -E separator="\t" \
  -e frame.time_epoch \
  -e ip.src \
  -e ip.dst \
  -e smb2.ntlmssp.auth.username \
  -e smb2.ntlmssp.auth.domain \
  -e ntlmssp.auth.nt_response \
  | head -50

echo ""
echo "=== Failed SMB authentications (LOGON_FAILURE) ==="
tshark -r "$PCAP" -n \
  -Y "smb2.cmd==1 and smb2.nt_status==0xc000006d" \
  -T fields \
  -E separator="\t" \
  -e frame.time_epoch -e ip.src -e ip.dst -e smb2.ntlmssp.auth.username \
  | sort | uniq -c | sort -rn | head -20

echo ""
echo "=== SMB Tree Connects (share access) ==="
tshark -r "$PCAP" -n -Y "smb2.cmd==3" -T fields \
  -E separator="\t" \
  -e frame.time_epoch \
  -e ip.src \
  -e ip.dst \
  -e smb2.tree \
  | sort | uniq -c | sort -rn | head -30

echo ""
echo "=== Named pipe access (IPC$ operations) ==="
tshark -r "$PCAP" -n \
  -Y "smb2.cmd==5 and smb2.filename contains pipe" \
  -T fields \
  -E separator="\t" \
  -e frame.time_epoch -e ip.src -e ip.dst -e smb2.filename \
  | sort | uniq -c | sort -rn | head -30

echo ""
echo "=== Files created/written on remote shares ==="
tshark -r "$PCAP" -n \
  -Y "smb2.cmd==5 and (smb2.create.disposition==2 or smb2.create.disposition==5)" \
  -T fields \
  -E separator="\t" \
  -e frame.time_epoch -e ip.src -e ip.dst -e smb2.filename

echo ""
echo "=== PsExec indicators (ADMIN$ + svcctl pipe) ==="
echo "--- ADMIN$ access ---"
tshark -r "$PCAP" -n \
  -Y "smb2.cmd==3 and smb2.tree contains ADMIN" \
  -T fields -E separator="\t" \
  -e ip.src -e ip.dst -e smb2.tree \
  | sort -u

echo "--- svcctl named pipe ---"
tshark -r "$PCAP" -n \
  -Y "smb2.filename contains svcctl" \
  -T fields -E separator="\t" \
  -e ip.src -e ip.dst -e smb2.filename \
  | sort -u

Lateral Movement Patterns in SMB

Technique	Share	Named Pipe	PCAP Indicator
PsExec	ADMIN$ or C$	\pipe\svcctl	File write to ADMIN$ + svcctl IPC request
Scheduled Task	IPC$	\pipe\atsvc	IPC$ tree connect + atsvc pipe create
DCOM lateral movement	IPC$	\pipe\epmapper	RPC bind to epmapper, then specific DCOM interface UUID
WMI lateral movement	IPC$	\pipe\wkssvc or epmapper	High port connection following epmapper request (RPC dynamic port)
SAM dumping (Mimikatz)	IPC$	\pipe\samr + \pipe\lsarpc	samr/lsarpc within same session as other recon
Pass-the-hash	Any	Any	NTLM auth with no prior password prompt; Kerberos failure then NTLM fallback
Ransomware deployment	C$ + ADMIN$	\pipe\svcctl	File write + svcctl to many hosts in rapid succession

Why named pipes are the key lateral movement signal

Administrative operations on Windows happen through named pipes over IPC$. When an attacker runs PsExec, creates a scheduled task, or uses DCOM, the Windows API eventually makes an SMB connection to the target, connects to the IPC$ share, opens a named pipe to the relevant service (svcctl, atsvc, epmapper), and sends DCE/RPC calls over that pipe. The named pipe \pipe\svcctl is virtually always present in PsExec-style lateral movement because service creation is how the attacker gets code execution on the remote host. If you see a new SMB connection to a host, authentication, IPC$ tree connect, and a svcctl pipe open — followed by a file write to ADMIN$ — that's a near-certain lateral movement event. Wireshark's SMB2 dissector shows all of this clearly when you load the PCAP.

Q & A

Q: The SMB traffic is signed (SMB signing is enabled). Does that mean the payload is encrypted and I can't read the file contents being transferred?

SMB signing and SMB encryption are different controls. SMB signing adds a cryptographic signature to each SMB message to prevent tampering and relay attacks — but the payload (file data) is still transmitted in cleartext. If SMB signing is enabled but encryption is not, you can still read file contents, usernames, and filenames from PCAP. SMB encryption (separate from signing, enabled via UNC path hardening or Group Policy requiring EncryptData=true) actually encrypts the SMB payload. In that case, you lose file content visibility but retain: source/destination IPs, port 445, authentication success/failure (the Session Setup exchange happens before encryption begins), share names (Tree Connect with the share path), and connection timing. SMB encryption is increasingly common in modern Windows environments (Server 2019+, Windows 11) — test what you can actually see in your specific environment before assuming full visibility.