Push the Red Button

If you follow Matthieu Suiche's blog (and if you don't, you really should!), you probably saw his post about an undocumented type of registry value -- CM_BIG_DATA. This is a registry optimization introduced by Microsoft with Windows XP that allows for more efficient storage of large amounts of data in the registry. You can read more about the details of this new way of storing large values in his post , but I wanted to announce the release of a new version of VolReg with experimental support for BIG_DATA values. As always, you can get the latest version of VolReg from my Volatility plugin page . This release also fixes a bug found by AAron Walters where an exception would be raised if the data returned for a value is less than the required amount for that type (e.g., only two bytes being available for a REG_DWORD). I also updated Volshell , fixing a regression found by J. Hewlett that broke the ability to use the "dt" command to examine a data structure without overl...

Tim Morgan was looking for some reference Windows 7 registry hives the other day to test reglookup , and it occurred to me that others might find them useful as well. So, without further ado, here's a link to download some registry hives I took from a fresh Windows 7 VM. Also, in case you were thinking of being clever, the VM password was "password" ;)

Peter Norris was kind enough to point me at his Masters Thesis, The Internal Structure of the Windows Registry . Much of the information was previously available from a variety of sources (including this blog), but Peter's work also goes into a lot of unexplored territory, and doesn't shy away from the more esoteric aspects of the registry -- like how and when the Configuration Manager decides to update the on-disk copy of the registry with changes from memory. Anyone who works with registry data for forensics or creates tools to work with the Windows registry would do well to give this a thorough read-through. Thanks to Peter for this excellent contribution!

This post could also be titled " Teaser ", part 2 :) As part of my research at GT, I've been looking at using Volatility to examine the state of running virtual machines. Using PyXa, a wrapper around Bryan Payne's XenAccess library (available in the tools directory of the latest XenAccess release), you can get access to the memory of Xen guest VMs in Python. From there, it's just a small step to create a new address space that Volatility can use to examine virtual machines just as if they were any other memory image. One application of this is using introspection to find out the state of windows on screen. This has advanced significantly since the last time I mentioned it, and it's now possible to track windows, including their z-order and some on-screen text, in near-real time. To demo this I used Volatility to examine the internal data structures of Win32k.sys and extract the locations and sizes of all visible windows, and then used PyGame to draw them ...

I don't have time for a full post right now, but I thought I'd offer a fun product of some things I've been working on recently. The work involves getting information about the windows on screen at the time a memory image was taken. One of the things you can extract is the position and size of each widget (called a "window", though I find this terminology a little confusing). Since I don't have time to go into the data structures and so on involved, I thought I'd give you all two "screenshots" that I reconstructed from the NIST XP SP2 memory images. Basically it's a white canvas as large as the screen resolution, with rectangles drawn on for each window on the screen. Without further ado: From the 6/25 image: From the 7/4 image: More details to come :)

I've found a couple bugs in the registry code I released recently, and at least one is significant enough that a new release is warranted. Teach me to release code I wrote in a couple hours on a plane ;) The list of fixes is: Fix a bug that prevented any volatile subkeys from appearing when using the subkeys() function. Add a check for None when using lsadump (reported by Paul Bobby, thanks!) Add appropriate license statements at the top of each file (thanks AAron!). For the record, the license is the GNU General Public License (GPL). You can download the new version as a zip or tarball , and install it exactly as the previous version, by extracting it into your Volatility directory. If you have a previous version installed, this should just overwrite it (though you may have to tell your unzip program that's okay). As before, PyCrypto is required for the credential extraction modules. One final note: I have seen some crashes when people attempt to use the hash extraction code...

By now, you all probably know that you can dump running programs from memory using the procdump module in Volatility. But not all malware runs as a user-mode process. What about malicious kernel modules? As it turns out, dumping these is also quite straightforward, and it's easy to write a plugin to do it. In fact, it's downright trivial -- kernel modules are just PE files mapped into kernel memory (in exactly the same way as normal programs are PE files mapped into user memory). So to dump a particular kernel module, we can use Volatility's built-in PE dumper (the source is in forensics/win32/executable.py , and point it at the memory address of a kernel module. Naturally, I've made a plugin that implements this: grab moddump.py and put it in your memory_plugins directory, and you'll be good to go. Here's what it looks like in action: $ python volatility moddump --help Usage: moddump [options] (see --help) Options: -h, --help show this help mes...

In which window messages are explored, a new plugin is created, and we learn the importance of reading messages sent to you regularly. In Windows, the GUI system is event-driven –actions occur in response to various events generated by the system. When you press a key on the keyboard, Windows generates a window message (specifically, WM_KEYDOWN ) and sends it to the thread that owns the window that's in focus. That thread then call's the window's event handling procedure (the so-called WindowProc ) to process the message. There are many such messages , covering input events such as keyboard and mouse actions, system-level events such as notification of a time change or a change in the system's power state , and events related to the windowing system, such as resizing or moving a window. How can these be forensically relevant? Well, as it turns out, some threads in buggy applications aren't always good at processing their messages, and messages they receive pi...

In the course of an investigation, it may be critical to be able to link up a process that's running to a particular user account. Particularly in a multi-user environment such as Windows Terminal Server, this isn't always as easy as checking who was logged in at the time. Luckily, each process in Windows has an associated token , a chunk of metadata that describes what Security Identifier (SID) owns the process and what privileges have been granted to it. As Larry Osterman explains , A SID is essentially a unique ID that is assigned to a user or group, and is broken into several parts: the revision (currently always set to 1), the identifier authority (describing what authority created the SID, and hence how to interpret the subauthoriries), and finally a list of subauthorities . In general, when users see SIDs (which they rarely do), they are in what's called the Security Descriptor Definition Language (SDDL) form. This is a string that looks like: S-1-5-21-1957994488...

When a user-mode application crashes in Windows, a built-in debugger known as " Dr. Watson " steps in and captures some basic information that can be sent back to developers to help debug the crash. As part of this process, it creates what's called a minidump that contains portions of the process's memory and a great deal of extra information about the state and attributes of the process. Among the information available is: CPU state for each thread. A list of loaded modules, including their timestamps. The Process Environment Block (PEB) for the process. Basic system information, such as the build number and service pack level of the perating system. The process creation time, and how long it has spent executing in kernel and user space. Detailed information on the exception that was raised. Using the userdump.exe utility provided by Microsoft, it is also possible to take a complete snapshot of the memory of any running process. This tool also, as i...

When performing memory analysis of Windows systems, there are a number of kernel variables that are extremely helpful in determining the state of the operating system. For example, the global variable PsActiveProcessHead is a pointer to the start of the kernel's list of _EPROCESS structures, and PsLoadedModuleList points to the list of currently loaded kernel modules (i.e., drivers). Unfortunately, these variables are not among those exported by the kernel, so finding them isn't as simple as looking them up in the export table of ntoskrnl.exe . How, then, do tools like Volatility find these addresses so that they can produce process listings from memory dumps? The simplest technique is just to hard-code the address of each variable. The "basic" version of Volatools does exactly this; if you open up vsyms.py , you will see the hardcoded values for PsLoadedModuleList , PsActiveProcessHead , PsIdleProcess , and HandleTableListHead . The downside of this is that the ...

When a Windows computer is joined to a domain, authentication of users is performed not against the local SAM database, but by querying the domain controller. From this description, we might be tempted to conclude that there won't be any useful credentials stored in the registry on a machine that is part of a domain; the users and their hashes don't actually exist on the local machine but rather on the domain controller. As it turns out, however, by default Windows does store domain credentials on client machines. The reason for this is simple: if the domain controller is unavailable for some reason, users would still like to be able to log into their machines using their credentials; for this reason Windows caches domain credentials of the last (by default) 10 users to log on to the machine. The exact number of cached logons is controlled by the value "CachedLogonCount" of HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinLogon . Cached Credentials in the Registr...

The LSA secrets store is a protected storage area used the the Local Security Authority (LSA) system in Windows to keep important pieces of information safe from prying eyes. As with Syskey, however, we will see that these secrets are only obfuscated, and once the mechanism is known, we can extract them from the registry with ease. Even without knowing the obfuscation algorithm, however, it is possible to read the values of this data using the LsarQuerySecret function exported by lsasrv.dll, but only if one has the LocalSystem privilege (for example, if the process is running under the SYSTEM account). What kind of data is stored in these secrets? Here are a few that I've come across: $MACHINE.ACC : has to do with domain authentication, see KB175468 DefaultPassword : password used to logon to Windows if auto-logon is enabled NL$KM : secret key used to encrypt cached domain passwords L$RTMTIMEBOMB_[...] : FILETIME giving the date when an unactivated copy of Windows w...

This is just a short post to talk about a new tool I've developed, called CredDump . CredDump is a pure- Python implementation of the bkhive/samdump2 , lsadump2 , and cachedump utilities commonly used to audit Windows password security. Why re-implement these tools? Well, for one thing, I like Python, and wanted to learn the details of how they all worked. Much more importantly though, this tool is completely cross-platform and requires only the registry hives recovered from the system to operate. Most other tools currently available rely on some aspect of Windows to provide their functionality. For example: lsadump2 calls advapi32.LsarQuerySecret to obtain the unencrypted LSA secrets. cachedump searches through the address space of lsass.exe to obtain the unencrypted LSA key, and uses advapi32.SystemFunction005 to decrypt the value of NL$KM with it. Cain & Abel is the closest to operating entirely offline, but still uses advapi32.SystemFunction005 to do the de...

The Windows registry can be an important forensic resource. Harlan Carvey has written extensively on various aspects of registry analysis, and is even considering writing a book on the topic. I have already written about attempting to extract hives from memory ; in this post, we will again look at registry hives in Windows memory, but this time in a more top-down fashion, by examining the data structures used to represent hives by the Configuration Manager. A hive is represented by the Windows Configuration Manager using the _CMHIVE data structure. You can examine this structure in detail using the dt command in Windbg: lkd> dt nt!_CMHIVE +0x000 Hive : _HHIVE +0x210 FileHandles : [3] Ptr32 Void +0x21c NotifyList : _LIST_ENTRY +0x224 HiveList : _LIST_ENTRY +0x22c HiveLock : Ptr32 _FAST_MUTEX +0x230 ViewLock : Ptr32 _FAST_MUTEX +0x234 LRUViewListHead : _LIST_ENTRY +0x23c PinViewListHead : _LIST_ENTRY +0x24...

As I mentioned last week, I moved to a new apartment this week, and as a result I didn't have a lot of time to do any serious work. Still, I didn't want to let the entire week go to waste, so I decided to try and tackle a problem that I thought would be relatively simple: extracting a copy of the binary registry hives out of memory. As it turned out, this was actually a bit more difficult than I expected, and I'll have to get back to the problem at a later date, but I thought in the meantime I'd write about what steps I took, where I ran into trouble, and describe the approach I hope to take when I revisit the issue. There were several reasons to suspect that one might find at least partial copies of the registry in memory: the registry stores all of the configuration data for the Windows operating system, and its contents are referred to and updated quite often during normal operation (let Sysinternals' Regmon run for few minutes and look at the output if you hav...

I've been taking a look at the structure of PDB files recently. PDB files are Microsoft's proprietary file format for storing debug information. They are generated by the Visual Studio family of products, and Microsoft has been kind enough to provide a full set of PDB files for its own operating system files since Windows 2000, which means that we get access to a whole bunch of great information like function symbols and type information. These can provide an excellent insight into the internals of the Windows operating system. Naturally, the file format is undocumented and proprietary (there used to be a page on MSDN stating as much, but I can't seem to find it now). However, Sven Schreiber, in his book Undocumented Windows 2000 Secrets: A Programmer's Cookbook , provides details on the format and some sample code for reading the information in such files. Although the original code only deals with PDB files created with Visual Studio 6.0 and below, he has recently r...

For the last couple days I've been playing with a sample of " Big Yellow ", worm that exploits a vulnerability in Symantec Antivirus to spread (yes, SAV actually listens on a network port--2967--to receive commands from some sort of central server. I was horrified too). I got interested in it after a warning was posted on the Internet Storm Center . Since the warning helpfully included the MD5 of the executable (f538d2c73c7bc7ad084deb8429bd41ef), I just went over to Offensive Computing and grabbed a copy for myself. Feel free to do the same in the discussion that follows, but be safe--don't do analysis on a machine connected to a network, and take some steps like renaming the executable to something that won't run when you double-click it. To start with, a lot of basic tools barf when run against the file. Dumpbin and pedump both crash, and OllyDBG complains that the file is not a valid 32-bit executable (though it goes ahead and runs it). On the UNIX side, objd...