At long last, I have been able to publish a whitepaper about a technique that I discovered some time ago for extracting locked files from a Windows system. This technique has proven useful for obtaining copies of the current SAM registry hive and NTDS.DIT files that contain user password hashes. The only requirement for this technique to work properly is that the user have local administrative rights. This means no escalating to SYSTEM rights or enabling of services (read: Volume Shadow Copy). As such, it is slightly safer to use in a commercial penetration test where rules of engagement might exclude other common techniques. For now, as well, the tool we use internally is not recognized by most antivirus software, and thus allows us to avoid having to go to significant lengths to escalate privileges when we compromise a system.
You can find the actual paper here:
The key concept is this: the Windows kernel blocks access to files that are open. You get a sharing violation or some such error, which keeps you from opening a file descriptor to read the file. This prevents you from viewing its contents, copying it to another location, etc. In some cases, a program opens a file with certain sharing flags that may permit another process to open the file for read-only access. This is not, unfortunately, the case with critical files like the SAM registry hive or a domain controller’s NTDS.DIT.
But, for some reason, when Microsoft was deciding on what users can do, they felt it was alright for a local administrator user to open a read file descriptor for the drive volume devices. This is analogous to the /dev/* hierarchy in Linux, but instead you need to specify a path like \\.\C (for the C: drive). This works just fine, and you can read data.
The hard part is how to find the data you want – filesystems aren’t exactly simple parsing. In the paper, I present a manual technique that relies on a Microsoft Resource Kit tool (nfi.exe) to parse NTFS and then you can easily enough use a Win32 ‘dd’ implementation to extract the blocks you need (NOTE: some “dd” implementations do not choose the right sharing flags, so make sure yours works).
I also present a tool named SAMex that we have been using successfully for some time. It features my own NTFS parser written in Haskell that I’ve been carting around for years. A few parts bolted on, and I had a working tool, which is generally much more user friendly than the more manual technique. The only caveat so far is that SAMex does not support systems where the MFT itself is fragmented (this does occur more often than you’d like, but it hasn’t been a real barrier on any of our penetration tests so far).
When I reported this technique to Microsoft, the response was that they consider this a “defense in depth” issue, which means they’re not going to change it. Thus, for the enduring future, I expect to be able to circumvent file locks, as well as nasty things like “deny” ACEs, on Windows systems.
If you have any questions about the technique or the tool, please feel free to Contact Me.