Accessing files with no access

Just to make it clear, this time I will address only one “no access” scenario you probably know: the process cannot access the file because it is being used by another process. Something I have referred to in my “Locker” message couple of weeks ago.
​
If you didn’t play with my “Locker” app, you can try to reproduce the situation by issuing the “copy c:\Windows\system32\config\sam .” command. SAM file is locked (open with no FILES_SHARE_xxx flags) which means you cannot touch it, regardless of account you use. There are well-known techniques you can use in such cases. To mention few of them: - turn your computer off, boot from external media and copy the file – working unsurprisingly well, requires access to the hardware and a BitLocker recovery password. - reach for the data directly from the physical drive, without politely asking Windows to open the file – quite a red flag for all EDR/XDR solutions. - terminate the process or close its handle – can be destructive and it’s not always allowed. The last one, most beautiful in my opinion, relies on VSS.
​
I will cover VSS sooner or later for sure, as it’s one of the fantastic Windows mechanisms with not-so-fantastic API, but today I will focus on usage only. Let’s assume that we want to grab the SAM file mentioned earlier. We cannot access it from the drive, but we can make a snapshot of the drive and grab the SAM file from the snapshot.
​
Theoretically vssadmin.exe built-in tool should help us, but in practice it checks the version of the operating system and if it is not a server, it does not allow to create snapshot. To make it clear: it’s about the tool actively limiting its own functionality, and not about the snapshot/VSS itself. It means that the snapshot can be created, but we need to approach the challenge differently.
​
The easiest way to make it is (obviously!) PowerShell, and its capabilities related to WMI. And WMI can ask for snapshots easily. Effectively, we can make a drive snapshot of the C: drive by issuing the command: (Get-WmiObject -List Win32_Shadowcopy).Create(‘C:',’ClientAccessible’) Vssadmin.exe allows to check it, regardless of the operating system version: vssadmin.exe list shadows /for=c: You can access the snapshot in multiple ways, but I would suggest the one I am usually using: mount it as folder. It allows you to reach snapshot files the same way you reach your “live” files, with working tab completion in console, explorer etc.
​
The procedure is: - note the “Shadow Copy Volume” value for your snapshot.
Somewhat like \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 - use it as a parameter for mklink.exe command: “mklink.exe /d c:\snapshot \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1"
​
Don’t forget to add trailing backlash at the end of your shadow copy volume name. Vssadmin does not display it, while it’s required by mklink, which means you must type it manually. And that’s it! You can now grab files from the c:\snapshot folder, e.g. with “copy c:\snapshot\Windows\System32\config\SAM .” command.
​
When you finish, you can unmount your snapshot by deleting the c:\snapshot folder (don’t use Recycle Bin) and deleting the snapshot itself with “vssadmin.exe delete shadows” command.