Post Execution - A New Paradigm for Debugging Malware

With the upcoming 2.0 Release of Responder, REcon plays a much more integrated role in the analysis of malware. The report automatically details all the important runtime behavior from a malware sample, including network activity, file activity, registry activity, and suspicious runtime behavior such as process and DLL injection activity. All activity is logged down to the individual disassembled instructions behind the behavior, nothing is omitted. Code coverage is illustrated in the disassembly view and data samples are shown at every location. This is like having a post-execution debugger, with registers, stack, and sampled data for every time that location was visited.

Post-execution debugging is a paradigm shift from traditional interactive live debugging. Traditional debugging is cumbersome and requires micromanagement to collect data. The traditional debugging environment is designed for CONTROL of the execution, as opposed to OBSERVATION ONLY. Typically, the malware analyst does not need to control the execution of a binary at this level, and instead only needs observe the behavior. HBGary's REcon approach to debugging is far superior because the analyst can see and query so much more relevant data at one time without having to get into the bits and bytes of single-stepping instructions and using breakpoints. It's like having a breakpoint on every basic block 100% of the time, without having to micromanage breakpoints.

HBGary and Palantir

I am very excited about our new partnership with Palantir. The Palantir link analysis capability is outstanding. Our team here in Sacramento is currently processing over 1.5 gigs of malware drops per day for Digital DNA, the new link analysis capabilities will allow us to move from the malware developer to the actual individuals who are operating the malware. We are already able to use forensic toolmarks to identify the individual malware developers, but this next step of analysis is to actually track those that have purchased or funded the development of the malware weaponry, and subsequently operate the malware in live operations. While tracking the developers themselves is easy due to the nearly impossible-to-avoid toolmarking caused by code and compiler, tracking the operators is much more difficult. But, HBGary is going to make a dent in this problem. We are approaching malware the same way an intelligence agency would.

Using Handle Tables in Physical Memory

One of the challenges we face at HBGary while developing Responder is the sheer volume of information available in physical memory. We have to reverse engineer a large volume of underlying data structures within the Windows operating system, not just for one operating system but for every single version of Windows (that includes service packs). In other words, a lot of time spent in windbg. One of the more interesting information sources available from the kernel is the handle table. Handle tables are extremely powerful and allow you to determine, for example, what files and registry keys are open by a given application.

Consider the way malware drops and installs itself. Many times, malware will inject itself into other processes as part of its "installation and deployment". At HBGary, we divide all the various behaviors of malware into categories we call "malware development factors". One of those malware development factors is called "installation and deployment" and it's all the stuff that malware does to survive reboot. In our Digital DNA(tm) we have well over 400 rules to detect just this kind of behavior. For example, malware may install itself as an extension to Internet Explorer and sniff online banking credentials. There are many ways to detect the presence of these capabilities. File handles can be used to detect when malware has been injected into secondary processes.

Malware injected into Internet Explorer opens a suspicious log file. This data is obtained from the kernel handle table.

Another anomaly that you can look for is a strange file path or executable name. Simply compare all the paths that are available in all the modules. In Responder, you can double click the drivers folder,m or the 'All Modules' folder, to view all drivers or modules along with their paths, respectively. Most modules are in consistent locations. When you examine all the module paths together in a single view, the anomalies will stand out. You don't really notice this until you see it in reference to all the other paths on the system. Seeing everything at once helps you detect an outlier quite quickly. This is just one of the types of things you can do when you have all the information at your fingertips.

Executables that are located in a suspicious temp directory. Also, one of executables has a non-standard file extension (.tmp).

A very suspicious kernel-mode device driver. This driver has no path, just an odd name with no file extension. This is a rootkit that was later identified as a variant of the "Black Energy" rootkit family. Notice that Digital DNA has automatically identified this driver as highly suspicious.

Executables that are running in a process that don't have a corresponding module name or path. These are very suspicious and we determined these were injected DLL's that were unlinked from the module list. Notice that Digital DNA has automatically identified these as highly suspicious.

One thing I really like about Responder is that you can sort the information in columns alphabetically and bring the outliers right to the top. Another thing that I like about Responder is that you can also write plug-ins that extend the functionality of the user interface at any point. For example, I could write a regular expression that would search all the file handles for certain patterns and that could include executables used in multi-stage installation, such as CMD.EXE or RUNDLL32.EXE, or files that appear to be in suspicious paths.

Regex r = new Regex(".*\\\\temp\\\\.*\\.exe$", RegexOptions.IgnoreCase);
Match m = r.Match(stringData.Name);
if (true == m.Success)
{
         // add an item to the report, associated with the DLL
 IReportObject wo = theDLLPackage.CreateReportObject(
             "suspicious exe in temp path",
             "This path looks suspicious, examine further");
} 

Responder scripts are written in C#.

I could even automatically add those to my report. The upcoming 2.0 release of Responder has an interactive report where you basically just drag and drop any specific data item to your report and drop it where you want the report item to appear. The dropped data actually just appears right there in the report at that location, including a description of what it is. Of course, this is editable by you, and you can expand upon it, but it makes it very easy for you to assemble a collection of those things that you find important in the memory snapshot. In summary, the report is a way to export and print the data I care about. I guess it also gives me a way to come back and reference those report items later (if you find yourself re-exploring old memory images). This is a short summary of some things you can do using the handles and the paths that are available to you in a physical memory snapshot.