Security Ripcord

The other day I was handed a system that was known to be compromised with Hydraq.  The goals were to determine when, how, and what happened after the compromise.  Locating the malicious process during memory analysis was easy with so many known system artifacts.  Not really very useful although it did determine that the rasmon.dll program did contain a domain name unique to the rest of the intelligence from the Internet.

I follow a very specific initial process when appoaching compromises on Microsoft Windows systems.  Keyword searches, timeline generation, and registry analysis top my list unless inidcators point me in a different direction.  Keyword searches on unallocated space and the systems pagefile did not provide any positive information related to the goals.   So I moved onto identifying the backdoor’s service to have a little more information to use during timeline analysis.  Easy enough with a quick review of the Service Registry keys.

System\ControlSet001\Services\RaSuPoo – Date Modified: 1/12/2010 11:05:40 AM
Description – ** NONE PROVIDED **
DisplayName – ** NONE PROVIDED **
ImagePath – %SystemRoot%\System32\svchost.exe -k netsvcs
Parameters – Date Modified: 1/12/2010 11:05:40 AM
ServiceDll – c:\windows\system32\rasmon.dll
Security – Date Modified: 1/12/2010 11:05:40 AM

Right off the bat I noticed a few things that were interesting.  Neither the “Description” nor the “DisplayName” key values were present.  Although they are listed here it is only to note that they were missing completely.  Now these things might be unique to this system but they are definitely indicators that can be used to identify other compromised systems with in the environment, possibly even if the backdoor is rolled over to a different version by the attackers.

Something else that is important to note is the matching “Last Write” for the primary registry key and the subkeys “Parameters” and “Security”.  When these times do not match I rely on the times provided by the “Security” key to determine the likely date and time that the system was compromised.  As these times matched for this service I was initially inclined to utilize these times as indications of the initial compromise.

Additional review of the services using intelligence from the Internet located other malicious services.  The following Registry information represents one of these malicious services.

System\ControlSet001\Services\AppMgmt – Date Modified: 1/12/2010 11:05:40 AM
Description – Provides software installation services such as Assign, Publish, and Remove.
DisplayName – Application Management
ImagePath – %SystemRoot%\System32\svchost.exe -k netsvcs
Parameters – Date Modified: 10/14/2009 01:25:37 AM
ServiceDll – C:\Documents and Settings\Administrator\AppMgmt.dll
ServiceDllUnloadOnStop – 00000001
Security – Date Modified: 4/4/2005 12:24:16 PM

There are several interesting things to note about this process.  First of all is the location of the AppMgmt.dll.  This location should flag this service as malicious during a manual review of running services as well as when this service is running in memory.  The “Last Write” time of the “Parameter” key is a good indication of the date and time the system was compromised by this backdoor.  After additional review this seems to be the earliest indication of compromise.

Continuing with timeline analysis produced an interesting finding from the event logs.

2010 01 12 11:05:40|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaShniI,stop

As you can see, the backdoor service with a different random key name than the current registry setting has stopped.  Now, this could be typical behavior associated with the functionality of the backdoor or it could be indications of another malware rollover to a new version.  However, now we have additional indicators for the timeline analysis.  A little fancy searching produced sixteen other instances of randomly named services that stopped and produced an Event Log entry.  Timeline analysis also produced several instances of systems restarting as represented by the “Task Scheduler Service” starting.

2010 01 11 11:40:09|Task Log|INF-SYS|”Task Scheduler Service”   Started at 1/11/2010 9:40:09 AM|0

Continued review provided an even more interesting finding.  Instances of a LEGACY registry key for each “stopped” service associated with the backdoor.

2009 10 29 05:48:46|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RAS0HWK/0000

Additional investigation of the System Registry Hive produced the following information.

System\ControlSet001\Enum\Root\LEGACY_RAS0HWK – Date Modified: 10/27/2009 5:18:46 AM
0000 – Date Modified: 10/27/2009 5:18:46 AM
DeviceDesc – RaS0HWk
Service – RaS0HWk

Then, after trimming the fat from timeline entries the following details emerged.  I have trimmed these a bit for brevity.

2009 10 27 05:18:59|Task Log|INF-SYS|”Task Scheduler Service”   Started at 10/27/2009 13:18:59 PM|0
2009 10 27 05:18:46|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RAS0HWK/0000
2009 10 27 05:19:17|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaS0HWk,stop
2009 10 30 09:10:55|Task Log|INF-SYS|”Task Scheduler Service”   Started at 10/30/2009 17:10:55 PM|0
2009 10 30 09:10:43|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RAS1DBH/0000
2009 10 30 09:11:19|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaS1DbH,stop
[snip]
2010 01 11 01:10:49|Task Log|INF-SYS|”Task Scheduler Service”   Started at 1/11/2010 9:10:09 AM|0
2010 01 11 01:10:44|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RASX4NS/0000
2010 01 11 01:10:01|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaSX4nS,stop
2010 01 12 01:55:02|Registry Hive: system|INF-SYS|0|$$$PROTO.HIV/ControlSet001/Enum/Root/LEGACY_RASHNII/0000
2010 01 12 01:55:18|SysEvent.Evt – EVT|INF-SYS|S-1-5-18|Service Control Manager/7035;Info;RaShniI,stop

Now, this backdoor behavior is significant because I have not found any reference to this restart behavior in any of the Hydraq malware analysis reports.  It also means that the Last Write times for the “RaSuPoo” service registry key is not indicative of the time that the AppMgmt rolled over to the new backdoor.  Whether the restart behavior was intentional or not this behavior has successfully obfuscated some critical system information that may not have been apparent had it not been for timeline analysis.

Additional analysis of timeline data using the LEGACY data also revealed another significant finding.  Malware reports related to Hydraq provide mention of a backdoor service with the name “Upsxxx” where [xxx] are random.  Timeline review revealed a LEGACY key for this service.

System\ControlSet001\Enum\Root\LEGACY_UPSYVM – Date Modified: 10/27/2009 4:07:09 AM
0000 – Date Modified: 10/27/2009 4:07:09 AM
DeviceDesc – UpsyVm
Service – UpsyVm

The significance of this registry key is not the fact that it appears to have been created before the earliest RaSxxxx service keys.  Rather it is the fact that there are no Registry entries pertaining to the initial Upsyvm service keys.  This means that the original service keys were deleted once this backdoor was rolled over to the new backdoor.  Another significant finding revealed during timeline analysis.

Now, none of these indicators provide details about the “smoking gun” – manual activity – that has taken place on this system.  However, understanding all of these activities provides a complete understanding of the series of events that could lead up to manual malicious activity on other systems.  Details of system artifacts and backdoor activity times will help identify other compromised systems and other activities.  This information also provides new methods that are being used to obfuscate data and hide critical details about events following a compromise.  Hopefully the information provided here helps you overcome some of these techniques.

Go forth and do good things,

Don C. Weber

---

Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.

---

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.