SANS Digital Forensics and Incident Response Blog

Digital Forensics: Persistence Registry keys

Some have called us log monkeys and claim our work is boring. Others recognize that what we do is a form of hunting. Computer Incident Response Team members watch security information event monitors (SIEMs) for indicators of compromise (IOCs). IOCs are like lycanthropes, they may be IDS/IPS alerts or blocks, or a system trying to connect to a resource it shouldn't be connecting to, or a user complaining of odd system behavior, or heaven forbid, a call from the Feds in the middle of the night.

Incident handlers may look for secondary IOCs to confirm an incident has occurred so they don't unnecessarily cause alarm or disrupt the organization. In the case of unsophisticated malware these secondary indicators can often be found by taking a quick look at the Windows Registry's run key. In many environments, this can be done remotely via:

reg query \\suspect.system.ip.address\HKLM\Software\Microsoft\Windows\CurrentVersion\Run

What comes back might look something like this:


HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\run
Windows Defender REG_EXPAND_SZ %ProgramFiles%\Windows Defender\MSASCui.exe -hide
RtHDVCpl REG_SZ RAVCpl64.exe
Skytel REG_SZ Skytel.exe
SMSERIAL REG_SZ C:\Program Files\Motorola\SMSERIAL\sm56hlpr.exe
SynTPEnh REG_SZ C:\Program Files\Synaptics\SynTP\SynTPEnh.exe
IgfxTray REG_SZ C:\Windows\system32\igfxtray.exe
HotKeysCmds REG_SZ C:\Windows\system32\hkcmd.exe
Persistence REG_SZ C:\Windows\system32\igfxpers.exe
SunJavaUpdateSched REG_SZ "C:\Program Files\Java\jre6\bin\jusched.exe"
MSSE REG_SZ "c:\Program Files\Microsoft Security Essentials\msseces.exe" -hide -runkey
xRqqzy REG_SZ c:\Windows\sysprot.exe

 

To an experienced incident responder, that last entry with the random looking name is clearly cause for concern.

Unfortunately, malware authors have moved on to less well known methods of maintaining persistence, many times the incident responder will find nothing in the Registry's run key. Unfortunately there are many places in the Registry that can be used as persistence mechanisms. But I have not seen a good list of Registry keys that could facilitate persistence despite the fact that there is a tool right under our noses that provides such a list.

If you're not familiar with AutoRuns it's a wonderful little utility from Microsoft Sysinternals that you can run on a system to see all the things that start running when your system starts up. Here's a screen shot of it in action on my Vista system:

Figure 1: Vista AutorunsFigure 1: Vista Autoruns

When I ran this on my XP system, I started counting the number of Registry keys (and other places) listed under the "Everything" tab in Autoruns. I stopped counting eventually, but there were around 130. I copied out all of the Registry entries and sorted them into two files, one for HKLM and one for HKCU. The reason for sorting them this way is because I'll be using them with the reg command for scripting and querying remote systems and unfortunately reg is unable to query HKCU on remote systems, which is a drag, but this can be overcome by pulling a shell on remote systems and then running the reg command.

For those who are interested, the two text files can be found here:

XPSP3_HKCU_Startup_Locations.txt
XPSP3_HKLM_Startup_Locations.txt

Over the next few days, I will post similar files for Vista and Windows 7 systems, but as I mentioned previously, the Registry is a complicated beast, there may be other keys that can be used for persistence, but this should be a decent start.

Dave Hull is a member of a Fortune 10K CIRT where he enjoys being the dumbest log monkey in the room. When he's not flinging poo at those outside the cage, he can be found at the command line doing forensics or in the classroom teaching Community events for SANS.

10 Comments

Posted October 20, 2010 at 7:55 PM | Permalink | Reply

Tom Yarrish

Dave,
Are there supposed to be that many "\\"''s? According to the help for reg query you don't need to double them for remote connections.
Great article though, didn't know about that little command''.
Tom

Posted October 20, 2010 at 8:07 PM | Permalink | Reply

Dave Hull

Tom ''" in my experience, to query remote systems, you have to lead with a double backslash before the system's IP address or system name. For local queries, no leading backslash is needed at all. YMMV.

Posted October 21, 2010 at 12:02 PM | Permalink | Reply

Tyler

One of the best things about Sysinternal's autoruns tool is its ability to verify the digital signatures of the executables that are set to autorun. The computer must have Internet access to do so, but once you verify you can start looking at the unverified programs first, as those are more likely to be potentially malicious.
(Of course this won't work in the case of a stolen digital certificate, but fortunately thats still fairly rare.)

Posted October 21, 2010 at 1:00 PM | Permalink | Reply

Dave Hull

Tyler thanks for pointing that out. You are correct. I probably should have mentioned in my post that Chad Tilbury did a post on Autoruns some time ago, (see: http://blogs.sans.org/computer-forensics/2010/06/28/autoruns-dead-forensics/). My main point was to let people know it was a good source for finding persistence mechanisms in the Registry.

Posted October 23, 2010 at 7:56 PM | Permalink | Reply

Adam

I agree with Tyler that one of the best things about Sysinternal's autoruns tool is its ability to verify the digital signatures of the executables that are set to autorun.
Great article Dave, keep up with the good work.

Posted October 28, 2010 at 5:20 PM | Permalink | Reply

Rob Lee

Did they fix autoruns completely to run on a mounted dead system (not live)? It was one of the things Chad pointed out that failed. I havent looked at it in about 2 months and need to again.

Posted October 28, 2010 at 7:25 PM | Permalink | Reply

Dave Hull

I just tried it with the latest version of Autoruns. I'm logged into a system as the local administrator. I have a Windows XP image mounted using the latest FTK Imager (sweet). I'm running: "autorunsc -a -z g:\\[root]\\Windows useracct" and am getting the following message: "Autoruns requires Administrator privilege to analyze an offline system"
Maybe it's wanting me to an account that matches the administrator account for the system I have mounted. If I get time, I'll try to dig into it further.

Posted November 3, 2010 at 9:36 PM | Permalink | Reply

Rob Lee

Are you on a Win7/Vista box? Try executing cmd.exe as admin.

Posted November 3, 2010 at 11:51 PM | Permalink | Reply

Dave Hull

This was on an XP Pro SP3 host. I tried a local admin account as well as an AD account with administrative privs, neither worked. I did do a RunAs for cmd.exe with the latter account, no joy. That's when I switched to the local admin account on the system, still no worky. I'm wondering if Autorunsc is expecting the user to be the admin from the dead system, that would be odd, but I can't rule it out. Need more time to test it.

Posted May 20, 2014 at 12:38 PM | Permalink | Reply

David Bernal

Hi,
You can get additional information with wmic script:
wmic /node:computer startup list full.