Plugins: soft_run user_run

The next two RegRipper plugins I wanted to highlight are: soft_run and user_run. Some may have been familiar with what these plugins did and the registry keys they checked. I’m referencing the past tense since Harlan has been busy working and he updated these plugins in the process. Not only were new run keys added to the plugins but Wow6432Node keys were added as well. The registry run keys are locations on a system which automatically start programs. Run keys are present in the Software registry hives which start programs when the operating system starts. Run keys are also present in the NTUSER.DAT hives and these execute programs when the user logs onto the system. These plugins are demonstrated against registry hives from a system infected with Symantec detection W32.SillyFDC (MD5 78c9d2949c81984414e6e1f5974905e1).

soft_run plugin

The soft_run plugin parses the run keys located in the Software hive. The following are the keys checked:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\Software\ Microsoft\Windows\CurrentVersion\RunServices
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run

Windows performs Win32 emulation on 64-bit operating systems to make 32-bit applications work. Part of the emulation is registry redirection. 32-bit applications are redirected to HKLM\Software\Wow6432Node when they try to access HKLM\Software. The additional Wow6432Node run keys parsed by the soft_run plugin are:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce

Running the soft_run plugin against the Software hive from the infected system produced the output below. In the output you will notice an entry for C:\Users\lab\Templates\cache\SFCsrvc.pif listed beneath a Wow6432Node. This malware entry provides us with a few different clues. First the malware obtained administrative privileges since a system-wide modification was made. The second was the malware was 32-bit executed on a 64-bit system.

soft_run v.20130329
(Software) [Autostart] Get autostart key contents from Software hive

Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 17:36:00 2013 (UTC)
VMware User Process - "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr

Microsoft\Windows\CurrentVersion\Run has no subkeys.

Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:34:33 2013 (UTC)
Microsoft\Windows\CurrentVersion\RunOnce has no values.
Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\RunServices not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey - C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent - C:\Windows\SysWOW64\fdisk.com

Wow6432Node\Microsoft\Windows\CurrentVersion\Run has no subkeys.

Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Tue Jul 14 04:53:25 2009 (UTC)
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no values.
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

user_run plugin

The user_run plugin parses the run keys located in the NTUSER.DAT hive. The following are the keys checked:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
Run value listed in HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

Similar to the soft_run plugin, user_run also takes into account Win32 emulation on 64-bit operating systems. The additional Wow6432Node run keys parsed are:

HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Running the user_run plugin against the Software hive from the infected system produced the output below. In the output notice the entries for C:\Users\lab\Templates\cache\SFCsrvc.pif and C:\Users\lab\AppData\Local\Temp\svchost.com. The biggest clue provided by the output is the lab user account should be focused on to determine the initial infecton vector.

user_run v.20130329
(NTUSER.DAT) [Autostart] Get autostart key contents from NTUSER.DAT hive

Software\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey: C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent: C:\Users\lab\AppData\Local\Temp\svchost.com

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:35:09 2013 (UTC)

Software\Microsoft\Windows\CurrentVersion\RunOnce has no values.

Software\Microsoft\Windows\CurrentVersion\RunServices not found.

Software\Microsoft\Windows\CurrentVersion\RunServicesOnce not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Windows
LastWrite Time Thu Apr 4 18:48:46 2013 (UTC)
Run value = C:\Users\lab\AppData\Local\Temp\svchost.com
run value = C:\Users\lab\AppData\Local\Temp\svchost.com
load value = C:\Users\lab\AppData\Local\Temp\svchost.com

Read More

Tracking Down Persistence Mechanisms

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 ***

Read More

Autoplay and Autorun Exploit Artifacts

Artifact Name

Autoplay & Autorun Exploit Artifacts

Attack Vector Category

Exploit

Description

Microsoft stated the main purpose of Autorun is "to provide a software response to hardware actions that you start on a computer". The software response is to start media or applications on a computer when a drive is mounted to the operating system. Prior to Windows XP, Windows only had the Autorun feature which would start items based on commands in the autorun.inf file located in the root of the drive.

With the release of Windows XP, a new feature called autoplay was included and this feature is enabled by default starting with XP SP2. Autoplay will review a mounted drive for content such as multimedia and will prompt the user to display the content using the appropriate application. Autoplay will start to examine a drive as soon as the drive is mounted and will parse an autorun.inf file if the is present.

The Autorun and Autoplay features have been leverage to automatically start malicious software. One example of this is the w32/Autorun.worm.g (McAfee’s detection). According to McAfee’s write-up, the worm spreads using an autorun.inf to automatically start the worm when the media (removable media or network shares) is connected to a computer.

Attack Description

1. Create an autorun.inf file with a command to launch the intended application.

2. Place the autorun.inf in the root of a drive that will be mounted such as removable media or a network share.

3. Place the application in a location where it can be executed.

4. Have the drive mounted on the target computer in order for the autorun.inf file to be parsed.

Exploits Tested

Two custom autorun.inf files, one file used the open command while the other file used the shellexecute command. A renamed Windows command prompt was the payload of both files.

The open command specifies the application to be started when a drive is mounted. The picture below shows the entire autorun.inf file with the open command.

The shellexecute command uses file association to determine what application is used to launch the file listed in the command. The picture below shows the entire autorun.inf file with the shellexecute command.

Target System Information

* Two Windows XP SP3 virtual machines using an administrative user account (one VM was used for each autorun.inf)

* Two Windows XP SP3 virtual machines using an administrative user account (one VM was used for each autorun.inf)

* Two Windows XP SP2 virtual machines using an administrative user account (one VM was used for each autorun.inf)

* Two Windows XP SP2 virtual machines using an administrative user account (one VM was used for each autorun.inf)

Different Artifacts based on Administrator Rights

No

Different Artifacts based on Tested Software Versions

No difference between XP SP2 and XP SP3

Potential Artifacts

The potential artifacts include the changes in the operating system environment. The artifacts can be grouped in the following two categories:

        * Windows Parsing the Autorun.inf File
        * Registry Modification When Autoplay Window Closes

Note: The testing to locate the exploit artifacts involved using the Autoplay window in XP SP3 while in XP SP2 the removable media icon in My Computer was double clicked to launch the payload. There were minimal exploit artifacts as compared to the artifacts left by the delivery mechanism (removable media) and payload (Windows command prompt). The identified artifact  filenames and values are inside of brackets in order to distinguish what may be unique to the testing environment.

        * Windows Parsing the Autorun.inf File

Windows makes modifications under \Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{GUID}\ registry key of the user account that mounted the drive. The modifications are made based on the contents of the autorun.inf file. The picture below highlights the relationship between the commands in the autorun.inf file and the registry modifications.

           - Autorun.inf action command altered the data in MountPoints2\{GUID}\Shell\AutoRun\command\(Default). [data for the open command was E:\dmc-test.exe while data for the shellexecute command was C:\WINDOWS\system32\RunDLL32.EXE Shell32.DLL,ShellExec_RunDLL dmc-test.exe]

           - Autorun.inf icon command altered the data in MountPoints2\{GUID}\_Autorun\DefaultIcon\(Default). [data was E:\dmc-test.exe,0]

           - Autorun.inf shell open command altered the data in MountPoints2\{GUID}\Shell\open\command\(Default). [data was E:\dmc-test.exe]

           - Autorun.inf shell explore command altered the data in MountPoints2\{GUID}\Shell\explore\command\(Default). [data was E:\dmc-test.exe]

           - Data in MountPoints2\{GUID}\Shell\Autoplay\DropTarget\CLSID was modified. [data was {f26a669a-bcbb-4e37-abf9-7325da15f931}]

        * Registry Modification When Autoplay Window Closes

           - The registry key MountPoints2\{GUID} was modified when the autoplay window closes (the window closes when the payload is executed).

Timeline View of Potential Artifacts

The image below show the above artifacts in a timeline of the registry (system, software, and ntuser.dat hives) from the Windows XP SP3 with an administrator user account (autorun.inf file with the open command). A few entries from the file system timeline were added.

References

   Autoplay Information

Microsoft support article on how to disable autorun http://support.microsoft.com/kb/967715

   Other information

Autorun.inf Wikipedia http://en.wikipedia.org/wiki/Autorun.inf

Autoplay Wikipedia http://en.wikipedia.org/wiki/AutoRun

McAfee W32/Autorun.worm.g AV write-up http://vil.nai.com/vil/content/v_142616.htm

Read More