This is Part 1 in a series about a topic I refer to as Consequential Artifact Analysis. In this series, we'll examine artifacts created after a compromise, yet not directly related to the malware itself. The practice of identifying these artifacts in a formal process allows an investigator to find troves of artifacts/intelligence, even when direct access to the malware is not possible (for example, on a live system with sophisticated kernel-level malware).
Direct versus Consequential Artifacts
We'll be examining a live compromise using live current malware on a live system. All analysis will use only standard Windows tools on the live system, from user land. Additionally, all analysis will focus only on the event logs (for this article anyways), and nothing else. Given all these constraints, it's still surprising to see how much information can be gleaned from a compromise.
Many event log entries we'll examine (and artifacts in later articles in this series) are quite innocuous by themselves. In fact, many will seem flat-out unrelated to anything malicious.
For example, I just looked at a different malware sample with the following characteristics:
- Creates c:\docume~1\[user]\locals~1\temp\mshtml2.exe
- Opens/modifies c:\autoexec.bat
- Creates c:\docume~1\[user]\locals~1\temp\ctxad.exe
- Copies file c:\docume~1\[user]\locals~1\temp\NDrv.exe to c:\docume~1\[user]\applic~1\fnts\jvaw.exe
- Connects to Port 80 IP: 63.251.135.24
- Connects to Port 80 IP: 66.11.119.72
Attributes such as those above, including 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.
However, what happens when the malware is too sophisticated to be recovered from a live system (especially in large-scale environments)? What happens when the malware/attacker is careful enough to clean up common tracks created by the malware?
This is where consequential artifact analysis comes in. Operating Systems are enormously complex systems. Even the simple act of running a simple program (like an exploit or malware) requires an incredible synchronization of OS components. Those internal OS components can leave a significant volume of auditable information behind, and that is what we focus on here.
Event log analysis
Did that subheading put you to sleep? I'm actually surprised if you're even still reading. When it comes to sexy places to look for artifacts, event logs hardly make the list.
Understanding Event Logs > XP
Event Logs on modern versions of Windows now come in two categories. The first are the "Windows Logs," and contain the familiar Application, Security, and System logs. This category also contains two new logs: Setup Log (containing events related to application setup and/or as a target log for application installers) and the ForwardedEvents Log (containing events forwarded by another computer).
The new second category of logs are very interesting from a consequential artifact perspective. The "Application and Services Logs" category stores events from a single application or component (rather than events that might have system-wide impact). How many separate logs are in this category? While the Windows logs contains five separate logs (Application, Security, System, Setup, and ForwardedEvents), the Application and Services Logs category contains about 461 separate logs. See a full listing here: http://social.technet.microsoft.com/wiki/contents/articles/4535.windows-7-event-logs.aspx
Figure 1: The left-pane shows a small sampling of the 461 logs found under the Application and Services category. Also pictured are some Operational subcategories.
It should be noted that while all logging examined in this article is enabled by default, this category of logs actually includes four subtypes: Admin, Operational, Analytic, and Debug logs. The Admin and Operational logs are enabled by default on 2008, Vista, Win7, and Win8. The Analytic and Debug are more verbose and technical, but they're not considered here since they are not enabled by default. For information on enabling the additional subcategories, please see:http://technet.microsoft.com/en-us/library/cc749492(v=ws.10).aspx
The Standard Windows Logs and Direct Artifacts
Direct artifacts are those caused directly by the malware or exploit, and those types of artifacts are most common in the standard Windows Logs. Let's look at a compromise from the point of view of the standard logs.
Figure 2: iexplorer crash with identified source of the crash in icucnv36.dll.
Figure 2 details:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Application Error" /> <EventID Qualifiers="0">1000</EventID> <Level>2</Level> <Task>100</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2013-03-01T00:17:25.000000000Z" /> <EventRecordID>322</EventRecordID> <Channel>Application</Channel> <Security /> </System> <EventData> <Data>iexplore.exe</Data> <Data>8.0.7601.17514</Data> <Data>4ce79912</Data> <Data>icucnv36.dll</Data> <Data>3.6.0.0</Data> <Data>470eff71</Data> <Data>c0000005</Data> <Data>000013df</Data> <Data>7a0</Data> <Data>01ce1611c8c8678b</Data> <Data>C:\Program Files\Internet Explorer\iexplore.exe</Data> <Data>C:\Program Files\Adobe\Reader 9.0\Reader\icucnv36.dll</Data> <Data>649e9497-8205-11e2-a194-c48508597bac</Data> </EventData> </Event>
In the above, we see that Internet Explorer crashed at 4:17 PM on 2/28/13. When sorting all events by "Source" (as well as "Task Category"), this is the only application fault event in the logs on this system. While iexplorer.exe was the faulting application, the faulting module (the dll loaded by the process that actually contains the source of the problem) was icucnv36.dll. In the subsequent event detail, we see that dll resides in: C:\Program Files\Adobe\Reader 9.0\Reader\icucnv36.dll.
How did this dll get injected into Internet Explorer's process space by the attacker for some reason?
We can do a quick check on another computer and see if this dll is normally loaded in Internet Explorer's process space, and we'll find that when the Adobe Reader helper is loaded by Internet Explorer, it is indeed on of the normally loaded dll's:
Figure 3: icucnv36.dll is normally loaded.
So it's normal, but it's an IBM dll? If this is an already-known vulnerability, Marco Giuliani at Prevx posted a good write-up about why this seemingly bizarre dll Is showing up in these logs:http://www.prevx.com/blog/156/New-Adobe-day-exploit-in-the-wild.html
At this point we can formulate and inductive hypothesis:
The computer was exploited by a vulnerability in Acrobat Reader at 4:17 PM on 2/28/13.
Let's assume our hypothesis is true (an inductive hypothesis), and continue to see if additional event log observations support this generalization.
One important question the above event does not answer for us is: How did the exploit PDF get on the system in the first place? We can presume it was a PDF, but was the user tricked into opening a malicious PDF, or was it delivered and opened without the user's interaction?
Examining other events in the standard event logs around the same time, the only other "interesting" event we see is the following:
Figure 4: System logon event
Figure 4 Details:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> <EventID>4624</EventID> <Version>0</Version> <Level>0</Level> <Task>12544</Task> <Opcode>0</Opcode> <Keywords>0x8020000000000000</Keywords> <TimeCreated SystemTime="2013-03-01T00:17:25.769387700Z" /> <EventRecordID>217</EventRecordID> <Correlation /> <Execution ProcessID="516" ThreadID="1900" /> <Channel>Security</Channel> <Security /> </System> <EventData> <Data Name="SubjectUserSid">S-1-5-18</Data> <Data Name="SubjectLogonId">0x3e7</Data> <Data Name="TargetUserSid">S-1-5-18</Data> <Data Name="TargetUserName">SYSTEM</Data> <Data Name="TargetDomainName">NT AUTHORITY</Data> <Data Name="TargetLogonId">0x3e7</Data> <Data Name="LogonType">5</Data> <Data Name="LogonProcessName">Advapi</Data> <Data Name="AuthenticationPackageName">Negotiate</Data> <Data Name="WorkstationName" /> <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data> <Data Name="TransmittedServices">-</Data> <Data Name="LmPackageName">-</Data> <Data Name="KeyLength">0</Data> <Data Name="ProcessId">0x1fc</Data> <Data Name="ProcessName">C:\Windows\System32\services.exe</Data> <Data Name="IpAddress">-</Data> <Data Name="IpPort">-</Data> </EventData> </Event> Here we see a "Type 5 Logon" around the same time as the previous event, but that still doesn't tell us anything. Typical assumptions around this event in close proximity to a compromise is that malware just installed a service, however this event is generated when many different services begin running as well - including Windows Error Reporting (which would happen after the IE crash previously examined). The primary way to resolve this is auditing the thread identified in the event details, however this article is keeping to event log examination only.
In other words, according to the standard logs, we only have one interesting artifact (the IE crash), and many more questions than leads.
The Application and Services Logs: Consequential Artifacts
The first stop we'll make under the Application and Services logs is with the log "microsoft-windows-wer-diag/operational." The name of the log given here is a standard convention showing the path to the log in question. Here is an example showing the path to a different log: "microsoft-windows-application-experience/program-inventory."
Figure 5: An example showing the path to "microsoft-windows-application-experience/program-inventory"
Most searches will take you into the Application Experience logs pictured above, however we'll start with the microsoft-windows-wer-diag/operational log because we already know there was a crash of some kind in Internet Explorer. Perhaps we can get more information about it in the WER logs. Windows Error Reporting (WER) is the service that notifies Microsoft of application faults, kernel faults, unresponsive applications, and other application problems. For reference, the registry keys that store WER configuration parameters are located at:
HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting
Figure 6: Only one event is present in the microsoft-windows-wer-diag/operational log.
Figure 6 Details:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-WER-Diag" Guid="{AD8AA069-A01B-40A0-BA40-948D1D8DEDC5}" /> <EventID>2</EventID> <Version>0</Version> <Level>4</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8004000000000000</Keywords> <TimeCreated SystemTime="2013-03-01T00:17:25.925388000Z" /> <EventRecordID>1</EventRecordID> <Correlation /> <Execution ProcessID="2904" ThreadID="4092" /> <Channel>Microsoft-Windows-WER-Diag/Operational</Channel> </System> <EventData Name="FTH_EXCEPTION_OF_INTEREST"> <Data Name="ExceptionCode">3221225477</Data> </EventData> </Event> In this case, we only see a single event here, and it perfectly coincides with the time of the crash event observed earlier. Now we know there was a crash in icucnv36.dll from the earlier event, and if it was an exploit, it was likely a heap overflow because of this event. If we Google icucnv36.dll and heap, we quickly find a publicly known vulnerability that bypasses ASLR and DEP:http://contagiodump.blogspot.com/2010/11/cve-2010-3654.html
So far, this only tells us we could be looking at CVE-2010-3654. However, we still need to find the actual exploit PDF (in a later article we'll examine non-standard ways of going about this on live systems) and validate it's actually CVE-2010-3654. This is important for many reasons, including:
- Validating our hypothesis about this being the point of entry exploit.
- We could actually be looking at a new zero-day without realizing it.
Going back to the previously mentioned microsoft-windows-application-experience logs, we see the following at the time of probable exploitation:
Figure 7: Application Compatibility Fix applied
Figure 7 Details:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Application-Experience" Guid="{EEF54E71-0661-422D-9A98-82FD4940B820}" /> <EventID>500</EventID> <Version>0</Version> <Level>4</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x1000000000000000</Keywords> <TimeCreated SystemTime="2013-03-01T00:17:02.776996500Z" /> <EventRecordID>5</EventRecordID> <Correlation /> <Execution ProcessID="3836" ThreadID="1920" /> <Channel>Microsoft-Windows-Application-Experience/Program-Telemetry</Channel> </System> <UserData> <CompatibilityFixEvent xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events" xmlns="http://www.microsoft.com/Windows/Diagnosis/PCA/events"> <ProcessId>3836</ProcessId> <StartTime>2013-03-01T00:17:02.761396500Z</StartTime> <FixID>{22624CAC-FE50-451E-9261-E7F22AAB93EC}</FixID> <Flags>0x10101</Flags> <ExePath>C:\Program Files\Java\jre6\bin\java.exe</ExePath> <FixName>000 Legacy Registry Entries (User Compat Flags)</FixName> </CompatibilityFixEvent> </UserData> </Event> Things get a little more interesting here.
AppCompat is built into the Windows executable (PE) loader and provides a way to patch the IAT (Import Address Table) of an executable being loaded. This is done with the purpose of shimming system calls for increased compatibility with older applications that reference older APIs. AppCompat is designed to allow older applications to run on newer Windows technologies with fewer problems. It's comprised of databases and dll's that define which shims apply to which binaries.
AppCompat has received quite a bit of attention in the forensics space since at least 2008. A good high-level explanation is here: http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx
To over-simplify the subject (for the purpose of this part in the series anyways), from a forensics perspective, many investigators examine the AppCompat registry key for indicators of an executable being run. That key (on Win7) is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache
However, in the Event Logs, we not only see if an executable requiring application compatibility modifications was run, we also see how many times and date/times it was run as well. This alone provides greatly enhanced indicators and timeline reconstruction.
In this case, we see an Application Compatibility fix was applied to the Java client on the system (in Figure 6) just before the heap corruption (eg: exploit) in Figure 5. Since we know it's not uncommon for PDF exploits to be delivered using Java Applets and an intermediary (especially in exploit kits), we can add the following to our hypothesis:
The client was exploited using an exploit PDF, delivered by a Java applet, likely from an exploit kit.
While our hypothesis is completely circumstantial (at this point), the use of a java dropper circumstantially indicates the use of an exploit kit. This will be tested in later articles in this series. For now, the potential use of an exploit kit, combined with probable use of an older Acrobat exploit, also tells us about the attacker's modus operandi, focus, and skill level. Although we'll need more than only event logs to validate this hypothesis and the points below, here's the potential scenario we have so far - based only on event log analysis:
How was the system exploited?
Heap overflow in Acrobat Reader.
How was the exploit delivered?
Java applet in Internet Explorer.
When did it happen?
2/28/2013 at 4:17 PM.
Is this a targeted attack or a random victim of mass malware attack?
We can't know for sure at this point, but the probable use of an exploit kit combined with probable use of an older Acrobat exploit indicate the attackers are likely pushing mass malware as opposed to highly targeted APT-like attacks.
What types of files will we need to focus on recovering as we move forward in this case?
Java applets to find the initial dropper.
PDF files to find the initial exploit.
Executable files to find the malware.
Other Interesting Logs in Application and Services Logs
Although the case we saw here only had a few artifacts in the Application and Services Logs, we typically see artifacts spread across many of the 461 possible logs. Here are some of the more interesting logs we commonly see malware related activity:
MICROSOFT-WINDOWS-APPLICATION-EXPERIENCE
In short, everything in here is related to the infrastructure that automatically applies software updates to programs to make sure that they run on newly released service packs and versions of the Windows operating system. As Microsoft is arguably more focused on compatibility between OS versions than anyone else on the market, there tends to be a wealth of information in here.
MICROSOFT-WINDOWS-DRIVERFRAMEWORKS-USERMODE
There has been a definite increase in malware writers choosing to utilize the User Mode Driver Framework over recent years. The advantage for malware authors writing UMDF drivers (as opposed to the KMDF, or Kernel Mode Driver Framework), besides stability advantages and decreased level of development effort (relative to KMDF drivers) is the fact that user-mode drivers can leverage all the Win32 APIs. For example, UMDF drivers can call APIs such as Winsock, Compression, Encryption APIs, and so on. Those APIs are not available to kernel-mode drivers.
Inversely... The advantage to investigators is that the use of UMDF drivers blast all kinds of information into these Event Logs as well.
MICROSOFT-WINDOWS-WPDCLASSINSTALLER
MICROSOFT-WINDOWS-USERPNP
MICROSOFT-WINDOWS-LOADPERF
When Microsoft-Windows-DriverFrameworks-UserMode contains malware related events, there is typically quite a few additional details these logs as well, pointing you toward "interesting" file and driver string artifacts to search for outside the event logs.
MICROSOFT-WINDOWS-WER-DIAG
This is the information used to notify Microsoft of application faults, kernel faults, unresponsive applications, and other application specific problems.
In following articles in this series, we'll dive down a little more while continuing to explore more uncommon (relative to status quo) techniques to examine live compromises using standard windows tools to harvest and analyze consequential artifacts.
Of course, if you know of additional "uncommon" tips and tricks related to event log analysis (especially logs under Application and Services), please be sure to share them below!
We're lucky to do what we do for a living - have fun exploring it!
