Timestamp Changes between OS via SMB Share

Now that we have examined timestamps behavior on macOS, how does transferring a file to or from Windows impact those timestamps?

This time round, we will dive into how timestamp changes when a file is being moved or copied between macOS and Windows through SMB shared folders.

Specifications

Below are the specifications of the machine that I am using:

macOS Sequoia 15.5 - Default SMB version: 3.1.1
Windows 11 - Default SMB version 3.0.2

List of software/tool(s) used:

macOS
- iTerms 2 Build 3.5.14
Windows OS
- Velociraptor 0.73.3
- The Sleuth Kit 4.14.0
- FTK Imager 4.7.1.2
- KAPE 1.3.0.2
- Active Disk Editor 25.0
- HxD Hex Editor 2.5
- ExifTool on Ubuntu 24.04.1 LTS with Windows Subsystem for Linux (WSL)

Results

This section summarizes how file timestamps change when it is moved across the different operating systems, depending on the file operations performed, file types, and whether the SMB folder's host OS is macOS or Windows.

Each section is divided into two sub-sections:

When the SMB folder resides on macOS Sequoia
When the SMB folder resides on Windows

The results below are timestamps changes when the file is being transferred from one OS into the SMB folder, and from the SMB folder onto the other OS.

SMB folder on macOS Sequoia

Text File (.txt)

Windows → Sequoia-based Share Folder → Sequoia

Sequoia → Sequoia-based Share Folder → Windows

Image File (.png)

Windows → Sequoia-based Share Folder → Sequoia

Sequoia → Sequoia-based Share Folder → Windows

Compressed File (.zip)

Windows → Sequoia-based Share Folder → Sequoia

Sequoia → Sequoia-based Share Folder → Windows

SMB folder on Windows 11

Sequoia cannot see files moved into the Windows SMB share via the Windows command prompt and returns an error when a move is attempted from Sequoia.

From the GUI perspective, the file does not appear in Finder. Therefore, CLI file move results from Windows to Sequoia will be marked in red.

Text File (.txt)

Windows → Windows-based Share Folder → Sequoia

Sequoia → Windows-based Share folder → Windows

Image File (.png)

Windows → Windows-based Share Folder → Sequoia

Sequoia → Windows-based Share folder → Windows

For image file tests, macOS screenshots were used to evaluate timestamp changes, consistent with prior research. However, unlike results from the Sequoia-based SMB folder, when the SMB folder was on Windows 11, neither Velociraptor nor TSK istat returned the $STANDARD_INFORMATION ($SI) attributes. The steps to obtain the $SI attributes will be further explained in the Notable Findings section later.

Compressed File (.zip)

Windows → Windows-based Share Folder → Sequoia

Sequoia → Windows-based Share folder → Windows

Timestamps of the Original File

Previous research showed file copy operations sometimes updated the original file's MACB timestamps to the copy time. This research also checks if copying affects the original file's timestamp on macOS, Windows, or the SMB share. The results are below.

Notable Findings

This section contains notable findings that might be of use during an investigation.

As mentioned earlier, during the initial tests where the SMB folder resides on Windows 11, both Velociraptor and TSK istat returned null or did not display the $SI attributes.

To confirm the absence of $SI attributes, the MFT record for the image file was extracted from the $MFT file using FTK Imager.

The indicators within the MFT entry being examined are:

MFT record start: ASCII string "FILE" (0x46 49 4C 45)
Start of $STANDARD_INFORMATION ($SI) Attributes: 0x10 00 00 00 (contains $SI MACB timestamps)
Start of $FILE_NAME ($FN) Attributes: 0x30 00 00 00 (contains $FN MACB timestamps)

When the screenshot file was copied from the SMB share folder to Windows OS, the MFT record did not contain the start of the $SI attributes as shown below. This would explain why the tools show the $SI timestamps as NULL.

However, when the screenshot file was moved from the SMB share folder to Windows OS, the MFT record shows the $SI Attributes as highlighted below.

Since Windows Explorer file properties display $SI timestamps, the screenshot's Properties were checked as shown below. Despite the $SI attributes appearing missing from the MFT record, the $SI timestamps are visible in the properties and commercial forensics toolkits, indicating that the $SI attributes must be stored elsewhere.

Further investigation using TSK istat results clarifies why the $SI timestamp appeared missing - it was stored in the Base File Record / Base MFT Entry.

With reference to Brain Carrier’s File System Forensic Analysis book, when a file is unable to fit its attributes into one entry within the MFT, it can use multiple entries, and the first entry is called the Base File Record / Base MFT Entry. The subsequent entries would then contain the address of the base entry in one of its fixed fields.

Velociraptor, using a filename search, retrieved the 2nd MFT record belonging to the file, which contains $FN but not $SI attributes. This resulted in $SI timestamps appearing as NULL in Velociraptor.

Conversely, using the same MFT entry, TSK istat listed the Base File Record, as shown in the screenshot below.

Note: It is also possible to parse out the Base File Record manually as shown below.

From the Base File Record, we can see the $SI attributes listed with the timestamps.

Besides istat, it is also possible to use both ExifTool and the stat command in Ubuntu 24.04.1 LTS with Windows Subsystem for Linux (WSL) to obtain the $SI timestamps as shown below.

When using the WSL method, the Birth (Created) time appears as Null. However, Windows Explorer Properties, commercial forensics toolkits, and the istat tool displayed a Birth (Created) date and time. This discrepancy likely arises because Windows, unlike Linux, typically does not support Null timestamps. Therefore, when the file is copied to Windows, the Birth date and time are automatically updated to the time of the copy.

Besides the base file record, macOS extended attributes copied into the MFT could be relevant to investigations. Examples include but are not limited to:

kMDItemIsScreenCapture
- Flags the file as screen captures.
- Only available from macOS 10.8 and above
- Note: It is possible to remove this attribute from the file
kMDItemIsScreenCapture extended attribute
com.apple.lastuseddate
- Stores the last used date, which corresponds to the Last Modified date in $SI attributes
- istat tool does not parse this but it can be manually decoded using tools like HxD or DCode if needed.
Last Used Date

Conclusion

In conclusion, file timestamp changes across different operating systems via SMB can be affected by various factors. Some of the factors covered include:

File Type
File Operation(s)
OS hosting the SMB folder
Direction of file transfer (macOS ↔ Windows)

If a .png image file was created with macOS screen capture is copied from macOS to a Windows-hosted SMB share and then to Windows, attributes might appear missing or null due to multiple MFT entries. In such scenarios:

Examine the Base File Record / Base MFT Entry.
Alternatively, use WSL and ExifTool to extract the $SI timestamps.
- Note that the creation (Birth) time might be NULL, as Linux supports null timestamps.

Additionally, the MFT record may contain useful macOS extended attributes, including but not limited to:

kMDItemIsScreenCapture: Indicates whether the file is a screenshot.
- Please note that it is possible to remove this attribute from the file.
com.apple.lastuseddate: The date the file was last used.

References

Last updated 1 year ago