[BUG] Bad format for SMB ShadowCopy access

[PeterGabaldon]

When accessing Shadow Copies via the SMB protocol, the following format is typically utilized: '@GMT-%Y.%d.%m-%H.%M.%S'.

Impacket incorrectly implements this format by using %Y.%m.%d instead of %Y.%d.%m (noting the day before the month).

Here's a simple example:

Take note of the date in this example Shadow Snapshot:

Now, access it via SMB using the correct format:

Reference: https://www.4n6k.com/2017/02/forensics-quickie-accessing-copying.html

[enj5oy]

@PeterGabaldon
I'm attempting to replicate your example. When I accessed the 'shadow copy' through Explorer, it reflects my current system state. Within it, you can observe a file named 'test', which bears a timestamp indicating it was created after the shadow copy was generated

[PeterGabaldon]

Hi,

Just to clarify something after reveiwing it.

As pointed in #1719 (comment), there is no problem in order to access the Shadow Snapshot through Impacket. The format is not correct, but it is working fine. Snapshots are listed using the IOCTL FSCTL_SRV_ENUMERATE_SNAPSHOTS (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/5a43eb29-50c8-46b6-8319-e793a11f6226).

impacket/impacket/smbconnection.py

Line 796 in 37cc8f9

def listSnapshots(self, tid, path):

I am pointing this out because maybe we could close the PR, changing the format in timestampForSnapshot may result in errors when validating timestamps at some points because Impacket may use the "bad" format and then the validation with the format fail.

For example, when using smbconecction listSnapshots (

impacket/impacket/smbconnection.py

Line 796 in 37cc8f9

def listSnapshots(self, tid, path):

). After retreiving snapshots using this method a format error will be raised if listing/retriving files from it using smb3.py methods because the format returned by listSnapshots is the "bad" format, and after changing timestampForSnapshot with the "good" format a mismatch will occur.

[PeterGabaldon]

@PeterGabaldon I'm attempting to replicate your example. When I accessed the 'shadow copy' through Explorer, it reflects my current system state. Within it, you can observe a file named 'test', which bears a timestamp indicating it was created after the shadow copy was generated

Hi @enj5oy,

This ShadowSnapthot is (among other) of Differential type.

So, this SS should be using COW or Redirect on Write. https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service#how-the-provider-creates-a-shadow-copy.

Have you compared the contents of the file after modification in the live volume with the SS?

[enj5oy]

@PeterGabaldon I encountered an issue on my end, but after testing everything, it works fine. I had a mistake because of the wrong UTC time