18: More Windows Forensics

DRAFT

Announcements

Windows Forensics

Today we’ll do a few minutes on each of the tools I talked about last class, this time with live demos.

Remember, it’s usually a reasonable idea to start by flsing the entire drive image (and saving to a file), so that you can later grep for files of interest. (I will pull some of them directly from my Windows VM so that you can see how they’re created as I go.)

Also consider Autopsy (the GUI wrapper around TSK).

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.

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

As per last class, you can see various entries in the registry and learn about the recent use of the computer.

Demo regedit on running instance of Windows:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\TypedURLs
HKLM \SYSTEM\MountedDevices : list of mounted devices
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\ : similar
HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR: additional information about mounted USB storage devices
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\GUID: recent network configuration
HKLM\SOFTWARE\Microsoft\WZCSVC\Parameters\Interfaces\GUID: wireless configuration
HKCU\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. In other words include the previous 41 bytes.

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.