Uncommon Handle Analysis in Incident Response and Forensics
Part two in a series on Consequential Artifact Analysis
By Gary Golomb
We have all seen reports talking about malware creating a specific mutex you can use to identify the malware. From a higher-level, how can we use attributes of mutexes and their relatives (other handles) in Incident Response and Forensic analysis?
In part one, we contrasted Consequential Artifact Analysis to Direct Artifacts, where:
Because we’re focusing on “Uncommon” analysis in this series, we’ll focus on everything that’s not a mutex. ;-)
Handles: A Young Analyst’s Illustrated Primer
At a high level, think of handles as a way to manage relationships between objects. For example, when you open a document with Microsoft Word, then attempt to delete the document through Windows Explorer, you get an error saying the file is already open in another window. This occurs because the handle Word has to the file is preventing other programs from deleting it. Close word.exe, and the handle disappears. This type of handle is a File Handle.
Another type of handle many people are familiar with is the Mutex. A mutex (short for mutual exclusion) is a way of preventing the simultaneous use of shared resources. In the case of malware, it's common to see Mutexes used to prevent duplicate infections. Typically the malware creates a special mutex at startup. Every time the malware runs, it checks to see if the mutex exists on the system first, so it knows if the system is already infected. If it did not do this, that malware might try to double-lock resources it needs, then crash.
Many people have a vague familiarity with mutexes, but mutexes are one of several kernel objects relevant to an analyst. In practice (in the infosec industry anyways), the terms “kernel object” and “handle” are used synonymously. Whenever a kernel object is created or opened, a reference (called a handle) to the object is also created. In fact, most analysis applications use the terms interchangeably as well.
Figure 1: Most applications (pictured here is Process Hacker) refer to kernel objects as handles, although strictly speaking, handles are pointers to kernel objects.
As we see in Figure 1, there are many types of objects beyond mutexes (which are correctly referred to as “mutants” in the Windows world, although the term mutex is most common in practice). In this article, I also use the terms Kernel Object and Handle relatively loosely.
Before digging down into the different types of kernel objects, let’s clarify the types of objects we’ll examine as part of this article. They are:
|Object Type||Examples||Managed By||Scope|
|Kernel Objects||events, mutexes, files, processes, threads, etc.||The Windows “Object Manager.” Each represents a data structure in system address space.||Handle values are private to each process.|
|GDI Objects||pens, brushes, fonts, etc.||Windows subsystem||Handle values are valid system-wide / session-wide.|
|User Objects||windows, menus, etc.||Windows subsystem||Handle values are valid system-wide / session-wide.|
Table 1: The three types of Windows Objects
For our purposes here, we’ll only consider handles related to those managed by the Windows Object Manager as opposed to the GUI and User objects described in Table 1.
Windows Object Manager
The Object Manager (internally called the Ob) manages objects typically shared between processes. The following table summarizes many of them:
|Access token||The access rights for an object.|
|Clipboard||A temporary repository for other objects.|
|CompositionSurface||A drawing surface object, part of DirectX.|
|Desktop||A logical display surface to contain GUI elements.|
|DxgkSharedResource||Undocumented/Unknown. Appears as an unnamed handle used by MS Office apps and Internet Explorer on known clean systems.|
|DxgkSharedSyncObject||Undocumented/Unknown. Appears as an unnamed handle used by MS Office apps, Internet Explorer, and Windows Explorer on known clean systems.|
|Event||An object that encapsulates information for notifying processes.|
|File||An open file or an I/O device.|
|File mapping object||A region of memory mapped to a file.|
|IoCompletion Queue||A method for threads to enqueue notifications of I/O completion.|
|IoCompletionReserve||Allow processes to reserve memory before performing certain system calls to avoid out-of-memory problems. For more information, see: http://goo.gl/84QtC|
|IRTimer||Undocumented/Unknown. Seen open in svchost.exe on known clean systems.|
|Job||A collection of processes.|
|Key||A registry key.|
|KeyedEvent||Similar to an "Event," except allows for finer granularity by allowing threads to block based on a key value. For more information, see: http://goo.gl/Rlv0k|
|Mutant||Synchronization construct to serialize resource access (aka: Mutex)|
|Object Directory||A container object for other objects that implements a hierarchical structure, like folders on a file system.|
|Port||A mechanism to pass messages between processes.|
|Process||A collection of executable threads along with virtual addressing and control information.|
|Section||A region of shared memory (file mapping object in the Windows API).|
|Semaphore||A counter and resource gate for critical section(s).|
|Symbolic link||A reference to other objects, via which the referred object can be used.|
|Thread||An entity containing code in execution, inside a process.|
|Timer||An object that notifies processes at fixed intervals.|
|TpWorkerFactory||Thread Pool manager. For more information, see: http://goo.gl/nvsdD|
|UserApcReserve||Allow processes to reserve memory before performing certain system calls to avoid out-of-memory problems. For more information, see: http://goo.gl/84QtC|
|WaitCompletionPacket||Undocumented/Unknown. Very prevalent.|
|WindowStation||An object containing a group of Desktop objects, one Clipboard and other user objects.|
|WmiGuid||Undocumented, but defines GUIDs that represent filter/query object that can be retrieved via WMI.|
Table 2: Objects managed by the Windows Object Manager
ADMINISTRATIVE NOTE TO THE READER: Table 2 has been compiled and shared in this article as a reference for responders. In this article, we’ll only examine a couple types, although other types will surface in your investigations over time. I have 30 object types listed above, however you will find inconsistencies between this table and others like it. For example, a similar table on the Wikipedia page for the Ob only lists 14 objects. See: http://en.wikipedia.org/wiki/Object_Manager_(Windows) Many objects are undocumented so similar tables only include around 15 entries (including sysinternals books and presentations). This is a compilation of the various objects you may encounter while using different tools, with descriptions provided where possible to help describe what you’re seeing. Because of this, please consider the information the table above to be “rough draft” type material - and definitely not gospel.
After reviewing Table 2, you should understand the basic concepts behind handles to kernel objects, so let’s get our hands dirty using them.
yakod.exe: Yet Another Kernel Object Dumper
First, what fun is a blog article without free warez to accompany it? None, of course. That’s why a tool called yakod is accompanying this post. Please note: It’s only been tested and targeted for Vista and above. It might work on XP, but the information discussed here has only been tested on Vista, Win7, 2008, Win8, etc.
Using yakod is simple. If you’d like to change its behavior, run it with the following options (at the time of this writing - they may expand over time so check the -help flag.)
Figure 2: Yet Another Kernel Object (Handle) Dumper
What are the advantages of yakod over the fifteen thousand other tools doing the same thing? Two marginally compelling advantages, specifically:
- Yakod output can be parsed and managed more easily than many other tools since it’s designed with the responder in mind (detailed single-line csv formatted logs). Because of this, it can be wrapped in your own toolsets quite easily.
- It has built-in logic to automate the discovery of everything described in this article. Handles with odd characteristics are logged in a separate file: smarts.csv.
Yakod outputs all objects to a file called (quite unimaginatively, like the name of the tool itself) AllObjects.csv, and looks something like this:
|Directory||\KnownDlls||bitcoin-qt||C:\Program Files (x86)\||3720|
|Directory||\KnownDlls32||bitcoin-qt||C:\Program Files (x86)\||3720|
|File||\Device\HarddiskVolume2\Wind||bitcoin-qt||C:\Program Files (x86)\||3720|
|File||\Device\HarddiskVolume2\Program Files (x86)\Bitcoin||bitcoin-qt||C:\Program Files (x86)\||3720|
|Key||ntrolSet001\Control\SESSION MANAGER||bitcoin-qt||C:\Program Files (x86)\||3720|
|ALPC Port||bitcoin-qt||C:\Program Files (x86)\||3720|
|Key||ntrolSet001\Control\Nls\Sorting\Versions||bitcoin-qt||C:\Program Files (x86)\||3720|
|Semaphore||bitcoin-qt||C:\Program Files (x86)\||3720|
|File||\Device\GNC||bitcoin-qt||C:\Program Files (x86)\||3720|
|Event||bitcoin-qt||C:\Program Files (x86)\||3720|
|WindowStation||\Sessions\1\Windows\WindowStations\WinSta0||bitcoin-qt||C:\Program Files (x86)\||3720|
|Desktop||\Default||bitcoin-qt||C:\Program Files (x86)\||3720|
|Key||ntrolSet001\Control\Nls\CustomLocale||bitcoin-qt||C:\Program Files (x86)\||3720|
|Key||\Registry\Machine||bitcoin-qt||C:\Program Files (x86)\||3720|
|Directory||\Sessions\1\BaseNamedObjects||bitcoin-qt||C:\Program Files (x86)\||3720|
|Thread||bitcoin-qt||C:\Program Files (x86)\||3720|
|Key||ntorlSet001\Control\Nls\Sorting\lds||bitcoin-qt||C:\Program Files (x86)\||3720|
|Key||\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\WinSock2\Parameters\Protocol_Catalog9||bitcoin-qt||C:\Program Files (x86)\||3720|
|Key||\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\WinSock2\Parameters\NameSpace_Catalog5||bitcoin-qt||C:\Program Files (x86)\||3720|
|IoCompletion||bitcoin-qt||C:\Program Files (x86)\||3720|
|TpWorkerFactory||bitcoin-qt||C:\Program Files (x86)\||3720|
|Timer||bitcoin-qt||C:\Program Files (x86)\||3720|
|WaitCompletionPacket||bitcoin-qt||C:\Program Files (x86)\||3720|
Table 3: Example yakod output
Now lets examine some of the more uncommon uses for handle examination in IR cases.
File Objects Non-Existent on Disk
This one is simple to understand. If a process has a handle open to a file object residing on the file system, then it must be there. Remember our first example about opening a file in Microsoft Word, then trying to delete it? So, if you query the file system for the file specified in a process’s open file handle list and get a “file not found” exception, well ... something must be hiding!
Figure 3: If a handle points to a file on disk, it should be there.
You can explore this by downloading a program like Process Hacker (http://processhacker.sourceforge.net/) and double-click any process. Select the tab labeled Handles, and look at the file handles for that process. You should be able to browse to any file handle though Windows Explorer.
Figure 4: Examining file handles
Of course, doing this manually during an investigation (like we did in the above example) is something you’d never do. Rather, you’d use a tool like yakod to automate it for you, or any tool like the Sysinternals tool handle.exe (http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx) to dump them, then use your own script to validate the files exist.
File Objects on Remote Systems
In data exfiltration cases with advanced attackers, it’s especially important to remember that files can be accessed the same way regardless of where they reside. A file can be on a local hard disk, a local attached device (like a USB drive), or a mapped drive - yet software accesses the file identically in all cases. For example, the following paths point to the same file, yet one is accessed through a direct or temporary connection to the remote system, and the other has established a drive letter for easy/continual access through Windows Explorer:
Can mean the same as:
Things can get interesting when finding remote file objects, as tends to be the case with tools like PsExec (used commonly in more advanced compromises - http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx). For example, consider the following:
Figure 5: PsExec is running programs on another system.
In this example, we see PsExec has several File Handles open to another system (as identified in the first part of the UNC path name). The files are the Standard In/Out/Err handles used by command line programs. While PsExec is used commonly this way in advanced compromises, you can also use the above example to imagine how malware (like key loggers and others that map remote files for data exfiltration) can be identified similarly as well.
This example leads directly to another example. If running PsExec on one system looks this way, how does it look on the other system executing the commands and programs passed to it?
NamedPipe File Objects
PsExec uses SMB and the hidden $ADMIN share to execute programs on a remote system and redirect input/output to a local console (similar in concept to most Remote Access Trojans). PsExec pushes a PsExecsvc service, then uses the Windows Service control Manager API to start the service on the remote system. Named pipes are then used to communicate between the local and remote systems.
Consider the following example:
Table 4: Output of yakod on a system running commands from another system via NamedPipes.
Here we see a number of interesting artifacts. First, we see the last three entries containing the NamedPipes created by PsExec. They have the format:
\Device\NamedPipe\psexecsvc-<computer name of other computer>-<process ID from other computer>-std*
Not only does this make the use of PsExec easily identifiable, it also clearly shows us where the connection is coming from - even down to the PID on the other system! This is an amazing way to find lateral movement in an organization.
Furthermore, we see that FTP is being executed (a common means of data exfiltration by certain groups) by looking at the process name/path column of the output. We also see an open file handle to \Device\HarddiskVolume4\Windows\asdf.txt, which is likely a set of automated FTP commands (we can guess this because such files are commonly used for unattended FTP automation in compromises). Regardless, we have a great lead here and we should recover that asdf.txt file for further analysis.
In the case of yakod, it tries to intelligently identify NamedPipes to remote systems, but it’s not very easy to do so. Definitely review them in the output of the tool contained in AllObjects.csv.
File Objects in User Temp Directories
This can be common/legitimate on some systems, but it’s also very common with malware. (To reduce the noise of “benign triggers when running yakod, ensure you’re not using the system while it’s running and close programs that don’t need to be opened.) To understand why file objects in temp directories can be so interesting to the analyst, we should probably explain something called User Interface Privilege Isolation first. For more information, see: http://msdn.microsoft.com/en-us/library/Bb250462(d=printer).aspx
Windows Vista and above includes an access control mechanism that labels processes and other securable objects with an integrity level. Securable objects like system directories and registry keys have an integrity level that defines the least privilege needed to access the object.
If you’ve been doing IR/Forensics for even a little while, certain directories appear on your radar frequently, especially:
C:\Users\<user>\AppData\LocalLow C:\Users\<user>\AppData\Local\Temp\Low C:\Users\<user>\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low
Most applications run from the Start menu typically run at a Medium integrity level. Most system apps run at a High integrity level. Internet-facing applications like Internet Explorer, Outlook, etc run at a Low integrity level - regardless of the user’s integrity level (which is usually Medium). That means there are few places they can write content. This is one of the limitations that have caused the shift in malware being saved to the system32 directory (in the days of Windows XP) to the directories listed above on current OS versions.
This frequently shows up in the output of tools like yakod as follows (taken from a live compromise) and in most cases should be followed-up on:
In general, ensure you understand why a process has *any* file system handle open in any user directory. Not only can they indicate hidden executables, but they can also point you to key loggers, data stealers, and similar types of files.
Handles Belonging to a Non-exe Process
If you’re enumerating process handles and see a running process whose filename doesn’t end with the normal .exe extension, it should be examined.
Object names should always be examined - especially Mutexes and Events. Event objects are increasingly used by malware instead of mutexes because mutexes have received so much attention over the years. Events can serve the same purpose for malware (that being: a way of marking if a system has been infected already).
When looking for odd names, look for names that don’t look like the others. Frequency analysis has been used for years in enterprise systems (sort by most common to least common occurrences), however, it’s frequently not possible to leverage those systems in investigations. Instead, look for silly sounding names (I just saw a malicious event named OpenForBusiness), or especially object names with IP addresses or URLs in them (yes, malware actually does this).
Although I don’t have a valid explanation for why this is the case (at the time of this writing), it’s not uncommon for malware to open a single handle to \device\harddiskvolume1\users\<user>\Desktop together with a single unnamed pipe (indicated by only \Device\NamedPipe\), yet it’s not common for legitimate applications to do the same. If yakod encounters processes with these characteristic, they will be flagged in the smarts.csv file also.
Although mutexes typically get the most attention in malware reports, many other handle types can be better indicators in many cases. Pay special attention to objects like Event(s), File(s), Key(s), Clipboard(s), and of course - mutexes.
And remember, we’re lucky to do what we do - so have fun exploring it!
Research and Development