17: Windows Forensics
DRAFT
Announcements
Windows Forensics
So now we’ll turn our attention to Windows forensics. Like most modern OSes, Windows creates and modifies artifacts on the basis of user actions, ongoing processes, scheduled events, and so on. Today, we’ll dig into some of these artifacts.
Like before, we’re concerned mainly with on-disk artifacts.
Unlike before, we’re going to take a (mostly) high-level view of these artifacts. Instead of writing the parsers for the binary objects we’ll examine, we’ll use pre-written tools – but now you have the knowledge to understand how they work under the hood, so it’s not just “magically run the tool to get the answer.” If you had the specification for, say, a Windows event log, you’d be able to write a parser for it (I hope!) at this point.
Sleuth Kit + Autopsy
It’s usually a reasonable idea to start by fls
ing the entire drive image (and saving to a file), so that you can later grep
for files of interest.
Also consider Autopsy (the GUI wrapper around TSK). Depending upon your OS, different versions of Autopsy might work better/worse for you.
Side note: How do you show Hidden, etc., files within Windows? See https://support.microsoft.com/en-us/help/14201/windows-show-hidden-files for details.
bulk_extractor / scalpel
bulk_extractor is a computer forensics tool that scans a disk image, a file, or a directory of files and extracts useful information without parsing the file system or file system structures. It just does carving (in a very thorough, efficient, and recursive way) on the basis of various patters; this gets lots of data, but a non-trivial fraction is false positives.
Running it a whole disk image can be overkill; sometimes it’s best to run it on a single file or portion of the image. Or the whole image too, if you have time to read through all the results
scalpel is another, similar tool. We’ll use it below (note you could also use bulk_extractor if you wanted too; or both, and compare their results; etc.)
Thumbs.db / thumbcache
Most versions of Windows cache “thumbnails” of image files that are stored in users directories and opened by the user. Various tools can process these thumbnails, such as scalpel
.
Windows 7: This data has been moved to a centralized database located in \Users\%username%\AppData\Local\Microsoft\Windows\Explorer.
Note Scalpel is a little finicky about configuration files – you need one in the directory you’re running scalpel
in, not the directory where the scalpel
binary resides. (There are other ways to handle it but this is easiest.)
Copy thumbcache to directory, then:
/Users/liberato/src/scalpel/scalpel -o 256 thumbcache_256.db
(Most paths, like above, are the ones on my Mac. You’ll need to adjust to run them locally.)
Side note: Building Scalpel. You can download and build it (under a Unix-y OS) yourself or find packages, depending upon your OS. https://github.com/sleuthkit/scalpel
lnk files
LNK files are Windows shortcuts. Users might create them deliberately, but they are also created when files are opened by a user (to place in the “Recents” folder). Various tools exist to parse these files, for example, liblnk
.
Demo using liblnk: copy lnk file to directory then:
/Users/liberato/src/liblnk/lnktools/lnkinfo Marc\ Liberatore.jpg\ -\ Shortcut.lnk
Browser information
Depending upon the version of Windows, the browser information (cache, users-typed URLs, etc.) lives in various places. Tools exist to parse and extract relevant information (libmsiecf
for example).
~/src/libmsiecf/msiecftools/msiecfexport index.dat |less
There are similar tools for IE10+:
Firefox (and many, many other tools) use SQLite to store their data locally. You can explore these files using sqlite
directly, or by using a graphical viewer (like http://sqlitebrowser.org/), or programmatically (most programming languages, including Python, include binding to SQLite).
Registry
The Windows Registry is a binary key-value store that also supports subkeys. In other words, it is a hierarchical database that maintains configuration settings for applications, hardware, and users. Typically there are five top-level entries, or “hives,” in the registry:
- HKEY_USERS: all actively loaded user profiles for the system
- HKEY_CURRENT_USER: actively loaded profile for logged-on user
- HKEY_LOCAL_MACHINE: “vast array” of configuration information for the system (hardware and software)
- HKEY_CURRENT_CONFIG: hardware profile used at startup
- HKEY_CLASSES_ROOT: configuration information related to which applications open which files
You can directly access your local registry through regedit
. You can use various forensic tools to directly parse the registry. Where do the backing files live?
HKEY_LOCAL_MACHINE\System: %WINDIR%\system32\config\System
HKEY_LOCAL_MACHINE\SAM: %WINDIR%\system32\config\Sam
HKEY_LOCAL_MACHINE\Security: %WINDIR%\system32\config\Security
HKEY_LOCAL_MACHINE\Software: %WINDIR%\system32\config\Software
HKEY_LOCAL_MACHINE\Hardware: volatile
HKEY_LOCAL_MACHINE\System\Clone: volatile
HKEY_USERS\User SID: NTUSER.DAT; Documents And Settings\User
HKEY_USERS\Default: %WINDIR%\system32\config\default
Along with various event logs, you can use the registry to find evidence that certain apps were opened, or settings modified, or hardware inserted/removed, etc.
Demo regedit
on running instance of Windows:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\TypedURLs
HKLM \SYSTEM\MountedDevices
: list of mounted devicesHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\
: similarHKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR
: additional information about mounted USB storage devicesHKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\GUID
: recent network configurationHKLM\SOFTWARE\Microsoft\WZCSVC\Parameters\Interfaces\GUID
: wireless configurationHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist
: recent user access, though ROT13ed!
There are various resources online listing registry keys of interest; I’ll post links to some of them on the course schedule page. (Feel free to post other you might find on Piazza.)
Again, various tools are available to parse the registry forensically (for example, libregf
).
Partial printer files
.SPL
files are spoolfiles, that is, the file Windows creates when preparing to send a file to a printer. Find the EMF
marker, then go back 41 bytes, carve from there.
Then you have an EMF file, which is an enhanced Windows Metafile. These are most easily viewed on Windows, since the are typically parsed with Windows API functions.
(Demonstrate by pulling spoolfile from C:\Windows\System32\spool\PRINTERS
)
fls -o 206848 case.dd
fls -o 206848 case.dd 624
fls -o 206848 case.dd 2317
fls -o 206848 case.dd 3240
fls -o 206848 case.dd 3251
icat -o 206848 case.dd 95655 > FP00000.SPL
Note it’s not perfect; depending upon the print driver the text in particular is often transcoded in a way that’s not legible.
A Taste of Memory Forensics
It is only within the last few years that Windows has offered a file system with encryption that is easy to use and not completely riddled with holes. People in the know used to use a program called TrueCrypt. It would create a file on disk that could be mounted by your computer and appear to be a drive. But the person who wrote TrueCrypt retired the program after Windows finally started supporting encryption in a high quality way. (You can still get it at: http://truecrypt.sourceforge.net/, but it’s very clearly marked as insecure and deprecated. Local copy here.)
(FWIW, it’s actually a much deeper rabbit hole than that. See https://magazine.atavist.com/the-mastermind.)
TrueCrypt itself had some flaws. One of them was that you could grab the password from memory.
I have TrueCrypt installed on an old Windows 7 SP1 VM and will do a quick demo of recovering a password from a memory dump for you using Volatility, a memory forensics tool.
TrueCrypt stores data in encrypted files, that are then mounted as volumes (like a “T:” drive) using a driver that encrypts/decrypts on the fly. I’ll mount this one now using the super-secure password “no password is secure while in memory”. I will check the box to cache the password in memory. Since the password is in memory and not written to disk, it’s not a problem, right? Nope, it is a problem. Someone can come by and grab all the memory and recover the password that is stored there. Let’s be that someone. (Why would you do this in real life? So that users could mount, unmount, and mount again a file without re-entering the password.)
Here’s the TrueCrypt file I used: test.tc. The super-duper-secret password is “no password is secure while in memory”.
I’ll run a shell as admin, then use it to do the rest. Note that winpmem is a program to dump the memory of a running instance of windows. There are also ways to do this directly if you’re running in a VM (which we are) but you can’t count on that in real life.
.\winpmem_1.6.2.exe .\physmem.raw
This command dumps the contents of the Window’s VM’s “RAM” to a file. You can download the version I used at: http://releases.rekall-forensic.com/v1.3.1/winpmem_1.6.2.exe (or locally cached here).
Now I’ll use volatility to recover the contents of the memory. I could run this directly on my Mac (the memory file and forensics are cross platform) but I’ll do it in Windows just to save the time copying it back and forth.
.\vol26.exe –profile=Win7SP1x64 –f .\physmem.raw truecryptsummary
You can get the version of Volatility I used at: http://www.volatilityfoundation.org/26
Reminder
Why are we doing all this? Recall from Lecture 01:
A forensic investigation has several goals, depending on the context. Typically, the primary goals are to
- Determine if there is evidence that a crime, tort, or policy violation has been committed;
- Identify the related events and actions that occurred;
- And identify who might be responsible.
In many criminal investigations, the goal of the investigator may additionally include determining the motive and intent of the perpetrator, corroborating alibis of the innocent, and verifying statements of witnesses. Moreover, criminal investigators need to preserve a demonstrable link between the artifacts we find at a crime scene and our later presentation of the evidence in court.
So, given a scenario, you are looking for evidence that supports or refutes that scenario, and possibly digging deeper.