Part two in a series on Consequential Artifact Analysis
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?
Direct Artifacts
In part one, we contrasted consequential artifact analysis to Direct Artifacts, where attributes of malware such as MD5, file size, imports/exports, structural PE characteristics, etc. are direct artifacts, because they are the direct result of the malware, or at least a direct observation of the malware itself. In general, observing direct artifacts requires the ability to recover the malware directly.
Consequential Artifacts
Artifacts created by the operating system (OS) itself after a compromise, because of the presence of malware, yet not directly related to the malware itself. Because they are artifacts inherent to the OS, observation of these types of artifacts does not require the ability to directly observe or recover the malware - if it is even still present on the system.
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 called 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 infosecurity industry anyway), the terms 'kernel object' and ' handle' are used synonymously. Whenever a kernel object is created or opened, a reference (AKA 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:
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:
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:https://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 has 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 is 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:
Table 3: Example yakod output
Now let's 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 ( https://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 ( https://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:
\\192.168.74.93\lawdept\technology\NewSolarTech.doc
Can mean the same as:
M:\\lawdept\technology\NewSolarTech.doc
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 - https://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. These 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: https://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:
\device\harddiskvolume1\users\<name>\appdata\local\temp\low\a9r96e0.tmp
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.
Miscellaneous Indicators
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.
Summary
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!
DOWNLOAD THE YAKOD TOOL HERE
