Metadata in network forensics (2 Part Series)
After spending some years in network forensics field, hoarding tons of PCAPs and making cryptic notes on the topic I decided that I wanted to review it all and start sharing some concepts, interesting findings or cool ideas. I hope that someone might find them useful or just fun to follow. For the sake of sanity I am going to publish this as series.
This article will be dealing with SMB protocol and metadata hiding in it, often in plain sight. My knowledge on SMB is certainly limited and I still remember the time when "Samba" was just an easy way to share stuff on MS Windows network. In my experience this is also what many people think today, sometimes even in forensic world. The usual evidence is that files were transferred from A to B and metadata are often ignored because of the juicy payloads.
But SMB is pretty damn complex ecosystem and has much more to offer. So in this article I am going to ignore the typical file transfers.
Let's focus on metadata.
In this part I will describe some sources of metadata which either accompany common SMB file transfers or get transferred as files due to OS or app-specific behavior.
For brevity of this text I am going to expect that the reader is familiar with Wireshark and basics of SMB protocol. While a lot of information about SMB protocol can be found on Wireshark wiki, I highly recommend SMB Quick Introduction by Hats Off Security as the author can really look on things from forensic POV.
The important thing for our purpose is that SMB protocol has three major versions (SMB 1-3), but version 3 is technically just SMB 2.2 so the first Wireshark filter you should be aware of is
smb or smb2 which gives you all SMB packets regardless of the version.
File MACB (modification, access, change, birth) timestamps are one the basic forensic artifacts as they help to point a forensic timeline for a given case. Luckily Samba supports these timestamps in many common packets like SMB2/Create Response (downloads typically), SMB2/GetInfo Response, SMB2/SetInfo Request and SMB2/Close Response.
Note that these fields have type
Date and time, so to list files created since 2020 you would use
smb2.create.time > "Jan 01, 2020 00:00:00"instead of the raw value.
smb.access.time or smb2.last_access.time
PCAP sample: smb2_putty_xfer.pcap by Chris Sanders
Speaking of file metadata there can also be complimentary metadata files. These files are not always available, because their presence in the traffic is conditioned by a specific OS or application feature.
On MS systems one of the most common metadata files is Windows thumbnail cache, aka
Thumbs.db. The file is notoriously known and stores thumbnail images for
explorer.exe to load faster. What's not so widely known outside infosec community is that when browsing Samba shares using MS Explorer, this file gets created and transferred automatically over network (the thumbnail cache makes even more sense in this case).
smb.file contains "Thumbs.db" or smb2.filename contains "Thumbs.db"
Tool: Thumbs viewer
Another interesting metadata file is
Outlook.NK2. This is a MS Office AutoComplete list of names and email addresses. Outlook automatically updates this file according to user activity. If you happen to gaze into network where MS Office applications run over network, there's a chance that you can encounter a transfer of this file in the traffic.
smb.file contains ".NK2" or smb2.filename contains ".NK2"
You can find SMB file transfers of
ntuser.dat when Microsoft Roaming User Profiles are deployed. Citing MS docs:
Roaming User Profiles redirects user profiles to a file share so that users receive the same operating system and application settings on multiple computers.
This means that all user profile data are transferred over network including MS Registry Hives such as
ntuser.dat. This file contains anything that typically resides in
HKEY_CURRENT_USER, e.g. mount points, recent documents, typed URLs, connected wireless APs or remotely connected systems.
On MacOS a
.DS_STORE file is a hidden attribute store which can be automatically created by MacOS Finder in any folder (regardless of file system or network share) based on user activity.
The file has recently gained some attention in infosec community, because it can contain sensitive information. With the fact that it is hidden by default in the Finder, it can easily lead to data leaks. What sensitive information you ask? For example:
- all file and directory names in the corresponding folder
- selected items in the folder
- trash put backs
That's it for today. Do you know of any other forensic metadata sources in SMB protocol? Let me know.
- Hats Off Security: SMB tag archive
- Chris Sanders: Packet Carving with SMB and SMB2
- MS doc
- SMB2 Wireshark Wiki
- Wikipedia: Windows thumbnail cache
- Windows Registry analysis with RegRipper - A 'Hands-on' Case Study
- Nicole Ibrahim: .DS_Stores: Like Shellbags but for Macs
- Gehaxelt: Parsing the .DS_Store file format