In some cases, an adversary attempts to maintain a foothold in a compromised environment in one way or another so, in the event of a system restart, a communication channel is reopened. Luckily for us, areas of the operating system which allow this behavior to occur are limited. This allows us to look for potential signs of malfeasance in predictable areas of the operating system. Better yet, a trend can be observed of commonly used persistence mechanisms which provide us with great areas to look in an attempt to find potential footholds setup by an adversary.

A quick note on triage. Each artifact of this post can take up a blog post on its own. The goal here is to dive into some common tactics to leverage during your first few minutes with a system.

The MITRE ATT&CK framework goes into some detail categorizing some persistence mechanisms for both Windows and Linux systems. Based on my experience, the large majority of commonly leveraged windows persistence mechanisms leveraged by adversaries I found to be the following categories:

  • Registry Run Keys
  • New Service
  • Scheduled Task
  • Startup Folder

This is the first part in a multi-part posting. This first post dives into information about the registry related to persistence mechanisms, a quick investigation flow leveraging X-Ways, and then recreating the same findings leveraging open source tools.

Registry Run Keys

Most people you talk to that attempt to dive into the inner workings of the windows registry will tell you that it is an absolute mess. Registry is essentially a monolithic file, or to word it better, registry can best be seen as its own file system. While not technically accurate, all the components are there - directories, extended attributes, inodes… etc. The major difference, however, is that registry is not a great file system if you want to call it that.

To add insult to injury, the naming convention of those nested keys and values is in no way obvious. For example, HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices details a list of currently mounted drives. However, a list of those devices which are visible to the end user is instead stored in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\. An exception exists to this rule which highlights mounted USB devices, this can be viewed in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR. The list of sectioned off information and exceptions goes on.

The point of this is that it is no wonder adversaries gravitate to the registry, it is a convoluted mess which has no obvious conventions showing what means what without referencing an external resource.

A post on Microsoft reports that there are four Run and RunOnce registry keys 1:

  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

It is important to note; there are many more than just the four registry keys listed above that can automatically start an executable given specific circumstances. A relatively quick google search can turn up lists that trumps the list of four Microsoft references. For example, a blog post from 20132 turns up a list of 23:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute
HKLM\System\CurrentControlSet\Services  
HKLM\System\CurrentControlSet\Services
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKCU\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices
HKCU\Software\Microsoft\Windows\CurrentVersion\RunServices
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\\Shell
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\\Shell
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\load
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\\AppInit_DLLs

All of this to say, manually reviewing a set list of registry keys can leave certain rocks left unturned. While it is ill-advised to build a reliance on tools, many of these that I will talk about maintain lists of autorun locations, which when used in conjunction with each other, can provide a simplified way to parse the registry “file system” to begin to triage a system.

Tooling

X-Ways

X-Ways is a tool that is available for a price tag. It is an excellent tool and has phased out Encase & FTK almost entirely in my professional career. While this is an excellent tool, it is not without its faults. In almost every situation, the purpose-specific open source tool can do just as good a job, if not better. The benefit here is that everything is available in one window (if you can figure out the not so intuitive UI).

X-Ways comes with a built-in registry viewer. By double clicking on a registry file, you can easily navigate through the crawling list of values and keys. Additionally, X-Ways comes with the ability to automatically generate a readable report of these common registry values and keys, which can output to an easy enough to read .html file.

In the root folder of where X-Ways is installed, several Reg Report*.txt files can be found, which are easily readable. In this case, the one we are interested in is Reg Report Autorun.txt. As of writing, this text file contains 191 lines of targeted registry values to build a Auto Run Report.

X-Ways Registry Auto Run Config Figure 1: Excerpt from Reg Report Autorun.txt

As seen in Figure 1, there is no complicated coding or any sort of convoluted language to learn if you wanted to generate your own Reg Report *.txt file. Simply referencing the exact location of the values you want to extract, followed by a wild card will do the trick in most situations. A review of the documentation will detail far more options such as unscrambling information which might be written in non readable formats.

To generate a report leveraging the Reg Report Autorun.txt provided file, all that is needed is to revisit the registry viewer in X-Ways by double-clicking on whichever registry file you wish to generate the report for, such as \Windows\System32\config\SOFTWARE or \Users\[user name]\NTUSER.DAT. Once in the viewer, clicking on the top left menu button will reveal a menu, of which there is an option to Create Report....

X-Ways Registry Reg Viewer Figure 2: Registry Viewer Menu In X-Ways

Once you click the Create Report... button, you will be asked to select a single, or multiple Reg Report*.txt files to instruct X-Ways what to extract for your report. Afterward, you will be asked where to save this report, and finally, view it.

X-Ways NTUSER AutoRun Report Figure 3: NTUSER.DAT Auto Run X-Ways Report Example

The final output of this report will look similar to what is detailed in Figure 3 where I run this report on my personal computer against my current active user NTUSER.DAT registry hive. In this particular example, nothing jumps out as malicious.

Here is an example of the same report, however this time, with known infected system.

X-Ways NTUSER AutoRun Report Bad System Figure 4: Infected NTUSER.DAT Auto Run X-Ways Report Example

As seen in Figure 4, one entry sticks out compared to the others. It appears that this system is configured to, on boot, launch a .jar based (java) binary. With this information in mind, we can easily compare our understanding of what is normal to what we see in our report. One could derive that based on the naming convention, and location alone of the referenced .jar file, that there might be foul play at work here.

RegRipper

RegRipper is a pearl-based tool. Similar to X-Ways, there is a folder within RegRipper named plugins where the opensource community can create scripts to extract and generate registry reports, however generating or modifying plugins with RegRipper comes with a higher learning curve when compared to X-Ways. Due to the fact that this is pearl based, this allows us to interact with the tool both via the GUI and command line.

Most of the tools I tend to leverage are available through CLI interfaces. I gravitate to Linux based tools, utilizing a Fedora OS with the CERT Repo installed, which includes near every tool I use during an investigation.

To generate a report leveraging RegRipper using either CLI or the GUI, the process is simple. In this example, I will go into generating a report via the CLI. If you are on windows, this would be interacting with RegRipper via the rip.exe file. To interact with the GUI on windows, you can use rr.exe instead.

Rip v.2.8_20180406 - CLI RegRipper tool
Rip [-r Reg hive file] [-f plugin file] [-p plugin module] [-l] [-h]
Parse Windows Registry files, using either a single module or a plugins file.

  -r Reg hive file...Registry hive file to parse
  -g ................Guess the hive file (experimental)
  -f [profile].......use the plugin file (default: plugins\plugins)
  -p plugin module...use only this module
  -l ................list all plugins
  -c ................Output list in CSV format (use with -l)
  -s system name.....Server name (TLN support)
  -u username........User name (TLN support)
  -uP ...............Update profiles
  -h.................Help (print this information)

Ex: C:\>rip -r c:\case\system -f system
    C:\>rip -r c:\case\ntuser.dat -p userassist
    C:\>rip -l -c

All output goes to STDOUT; use redirection (ie, > or >>) to output to a file.

copyright 2018 Quantum Analytics Research, LLC

The help page for RegRipper details the available options we can use. For our purposes, we are going to be using the -r, -f, and -c options.

rip.exe -r NTUSER.DAT -f ntuser -c > report.txt

Leveraging the same data from Figure 4, a similar report is generated and written to the report.txt file specified in our command above.

RegRipper NTUSER Report Figure 5: Infected NTUSER.DAT Auto Run RegRipper Report Example

Registry Explorer

Instead of a report based process like the other tools discussed in this post, Registry Explorer currently takes a bookmark based approach. There are several bookmarks provided by default.

Registry Explorer Bookmark Menu Figure 6: Registry Explorer Bookmark Menu

By clicking on the above bookmark, we are immediately taken to the same area as seen referenced in the other tools, where the same malicious .jar file can be seen automatically launching with this particular user.

Registry Explorer Findings Figure 7: Registry Explorer Findings

Honorable Mention: Sysinternals Autoruns

While not strictly focused on the registry, there is a tool part of the Sysinternals suite which displays via a GUI or CLI a list of noted applications which can be seen launching automatically via means of, among other things, registry. Further information about this tool can be found here.

References