Exploring Windows Error Reporting

Monday, February 24, 2014 Posted by Corey Harrell 2 comments
The Application Experience and Compatibility feature ensures compatibility of existing software between different versions of the Windows operating system. The implementation of this feature results in some interesting program execution artifacts that are relevant to Digital Forensic and Incident Response (DFIR). I already highlighted a few of these in my posts Revealing the RecentFileCache.bcf File and Revealing Program Compatibility Assistant HKCU AppCompatFlags Registry Keys. There are more artifacts associated with this feature and the Windows Error Reporting (WER) are one of them. Over the past few months WER has been discussed frequently due to the potential data it exposes when data is sent to Microsoft. However, WER can be a useful program execution artifact for incident response since malicious code - such as malware and exploited applications - can crash on systems. This short post provides discusses WER and illustrates how it is helpful to track malware on a system.

What is Windows Error Reporting


Windows Error Reporting is basically a feature to help solve problems associated with programs crashing on the Windows operating system. The Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7  goes into more detail by stating:

"WER is a sophisticated mechanism that automates the submission of both user-mode process crashes as well as kernel-mode system crashes."

The service analyzes the crashed application's state and builds context information surrounding the crashed program. The book continues by saying:

On default configured systems, an error report (a minidump and XML file with various details, such as the DLL version numbers loaded in the process) is sent to Microsoft's online crash analysis server. Eventually, as the service is notified of a solution for a problem, it will display a tooltip to the user informing her of steps that should be taken to solve the problem.

How Does Windows Error Reporting Work?


There are two registry keys responsible for WER's configuration. These keys are listed below; the first key affects system-wide behavior while the second is user specific.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting
HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting

The best resource I found explaining how WER works is a paper written by 0xdabbad00. Their paper is titled Notes on Windows Error Reporting and the actual PDF can be found here. The paper "attempts to better explain what is and is not possible and to generalize the attack classes for all error reporting" and touches on the following key points:

        - What traffic is sent unencrypted and what is sent encrypted
        - What data is in the unencrypted traffic

I won't try to rehash what is written in the paper since it really goes into great detail. Anyone who wants to know more about WER should read this.

What Artifacts Are Left By Windows Error Reporting?


One item I really liked about the Notes on Windows Error Reporting paper is its Appendix. The focus of the paper is on explaining the WER feature but the Appendix provides some useful DFIR tidbits about the WER artifacts present on the system. These artifacts are important because they show a program was running on the system and it eventually crashed. In the past, WER artifacts have given me more context about the other program execution artifacts located on a system. The WER artifacts outlined in the Appendix include: event logs, WER folder, AppCompat.txt file, and WERInternalMetadata.xml file.

WER records an entry in the event log when a crashed application is analyzed and then another event log entry is recorded if information is sent to Microsoft. The Appendix shows what this event log looks like including the information it contains. The event log also shows that the WER folder is located at C:\Users\username\AppData\Local\Microsoft\Windows\WER.

The paper also explains what the AppCompat.txt and WERInternalMetadata.xml files are while the Appendix shows the information stored in these files. Either one of the files provide a wealth of information about the program that crashed such as the parent process, parent process command line, and process path. 

Additional about Windows Error Reports


I wanted to provide additional information about one WER artifact mentioned in the paper. Specifically, the actual Windows Error Report themselves. A Windows Error Report records a ton of information about a program that was running at some point in the past. To illustrate I'll walk through a WER for a piece of malware that crashed on a system. The screenshot below shows the beginning of a report and some of the information shown is when the program crashed and program was 32-bit (notice the WOW64).



The next portion of the report starts to provide information about the crashed program.


A little bit further down in the report you can see part of the user interface message as shown below.


The report even recorded the program's loaded modules at the time of the crash. This section contains the file path to the crashed application and in this instance the program is highly suspicious (executable launching from a temp folder).


The end of the report contains the last piece of useful information about the crash.


A search on the AppName in the Malware Analysis Search provides some leads about what malware was present on the system. It leads to VirusTotal reports and sandbox reports showing malware crashing such as this one.

WER's Relevance


WER provides more artifacts that show program execution. Overall this artifact is not as beneficial as the other program execution artifacts but once in a while malicious code will crash or cause an application to crash. When this occurs WER provides more context about what occurred on the system and the relevance of the executable listed means the following:

1.  The program executed on the system.
2.  The program crashed on the system.
3.  The data in the WER artifacts is information about the program at the time it was running and crashed on the system.

Labels:

Linkz 4 Mostly Malware Related Tools

Tuesday, February 11, 2014 Posted by Corey Harrell 2 comments
It's been awhile but here is another Linkz edition. In this edition I'm sharing information about the various tools I came across over the past few months.

Process Explorer with VirusTotal Integration

By far the most useful tool released this year is the updated  Process Explorer program since it now checks running processes against VirusTotal. This added feature makes it very easy to spot malicious programs and should be a welcome toolset addition to those who are constantly battling malware. To turn on the functionality all you need to do is to select the "Check Virustotal" option from the Options menu.

 
After it is selected then the new Virustotal column appears showing the results as shown below:


The hyperlinks in the VirusTotal results can be clicked, which brings you to the VirusTotal report. The new functionality is really cool and I can see it making life easier for those who don't have DFIR skills to find malware such as IT folks. Hence, my comment about this being the most useful tool released. The one thing I should warn others about is to think very hard before enabling is the "Submit Unknown Executables" to VirusTotal since this will result in files being uploaded to Virustotal (and thus available for others to download).

Making Static Analysis Easier

I recently became aware about this tool from people tweeting about. PEStudio "is a tool that can be used to perform the static investigation of any Windows executable binary." It quickly parses an executable file presenting you with indicators, VirusTotal results, imports, exports, strings, and a whole lot more as shown below.




Automating Researching URLs, Domains, and IPs

The next tool up to bat automates researching domains, IPs, hashes, and URLs. It's a pretty slick tool and I can see it being an asset when you need to get information quickly. TekDefense describes Automater as "a URL/Domain, IP Address, and Md5 Hash OSINT tool aimed at making the analysis process easier for intrusion Analysts." If you are tasked with doing this type of analysis then you will definitely want to check out this tool. The screenshot below is part of the report generated for the MD5 hash ae2fc0c593fd98562f0425a06c164920; the hash was easily obtained from PEStudio.


Norben - Portable Dynamic Analysis Tool

The next tool makes the dynamic analysis process a little easier. "Noriben is a Python-based script that works in conjunction with Sysinternals Procmon to automatically collect, analyze, and report on runtime indicators of malware. In a nutshell, it allows you to run your malware, hit a keypress, and get a simple text report of the sample's activities." To see this tool in action you can check out Brian Baskin's post Malware with No Strings Attached - Dynamic Analysis; it's an excellent read. In order to get a screenshot, I ran the previous sample inside a virtual machine with Noriben running.


I'm Cuckoo for Cocoa Puffs

You can probably guess what my kids ate for breakfast but this next tool is not child's play. Version 1 of the Cuckoo Sandbox has been released. The download is available on their download page. For those who don't want to set up their own in-house sandbox then you can use Malwr (the online version).

Pinpointing

The next tool comes courtesy of Kahu Security. The best way to explain the tool is to use the author's own words from his post Pinpoint Tool Released.

"There are many times where I come across a drive-by download, especially malvertisements, and it takes me awhile to figure out which file on the compromised website is infected. I wrote Pinpoint to help me find the malicious objects faster so I can provide that info to webmasters for clean-up purposes."

The post provides some examples on the tool's use as well as their most recent post Pinpointing Malicious Redirects (nice read by the way.) You can grab the tool from the tools page.

What You See May Not Be What You Should Get

I thought I'd share a post highlighting shortcomings in our tools while I'm on the topic about malware. Harlan posted his write-up Using Unicode to hide malware within the file system and it is a well written post. The post discusses an encounter with a system impacted by malware and the anti-forensic techniques used to better hide on the system. One method used was to set the file attributes to hidden and system; to hide a folder from the default view settings. The second method and more interesting of the two use the use of Unicode in the file name path. What the post really highlighted was how multiple tools - tools that are typically in the DFIR toolset - do not show the Unicode in the file path. This would make it possible for anyone looking at a system to overlook the directory and possibly miss an important piece of information. This is something to definitely be aware about for the tools we use to process our cases.

Do You Know Where You Are? You're In The NTFS Jungle Baby

If you haven't visited Joakim Schicht's MFT2CSV website lately then you may have missed the tools he updated on his downloads page. The tools include: LogFileParser that parses the logfile (only open source logfile parser available), mft2csv that parses the $MFT file, and UsnJrnl2Csv that parses the Windows Change Journal. The next time you find yourself in the NTFS jungle you may want to visit the mft2csv site to help you find your way out.

Still Lost in the NTFS Jungle

Rounding out this linkz post are a collection of tools from Willi Ballenthin. Willi had previously released tools such as his INDX parser and python-registry. Over the past few months he has released some more NTFS tools. These include: list-mft to timeline NTFS metadata, get-file-info to inspect $MFT records, and fuse-mft to mount an $MFT. I haven't had the time to test out these tools yet but it's at the top of my list.
Labels: ,
Subscribe to: Posts (Atom)