Bridging the Gap

I work for a large corporation that includes a vulnerability research organization. This organization is responsible for discovering vulnerabilities to operating systems, applications, etc. When they discover a vulnerability and develop a successful exploit, that information goes into the protection mechanisms produced by another part of the company, which are monitored by yet another part of the company. What this ultimately means is that attacks using those techniques are monitored or stopped before the systems themselves are compromised.

So I always think its cool when someone from a monitoring organization reveals some information about an attack that they've seen, such as this post from Symantec. I think its interesting to see this sort of thing, not only to see what an attack "looks like", but also to see if my analysis process includes the ability to find this sort of thing. As an analyst, I've been able to determine that yes, your system was compromised, Mrs. Jones, but when it comes down to it, how would I go about determining how it was compromised? There are a number of browser-borne attacks out there that are possible...how do you narrow down which one was used (if the initial compromise was via the browser?)?

In this particular case, the exploit involves overwriting a file opened by the MS Help and Support Center, so a quick way to check to see if this was the case is to use the following command (either on a live system, or on a system mounted with SmartMount):

C:\>dir /tw windows\pchealth\helpctr\system\sysinfo

Also, point #4 in the blog post states that the MS Help and Support Center Viewer handles "hcp://" links... to see the file association, check the Registry (in the following key) to see that:

HKEY_CLASSES_ROOT\HCP\shell\open\command

You should see something like this in the "(Default)" value:

%SystemRoot%\PCHEALTH\HELPCTR\Binaries\HelpCtr.exe -FromHCP -url "%1"

What posts like this allow us to do is to bridge the gap between vulnerability and exploit, and incident response and forensic analysis.

Another such example can be seen at the MS Malware Protection Center, particularly with this post about Win32\Rustock. Looking at the write-up, you're probably wondering how you'd go about using this information...the malware comes in three components, all encrypted, packed with ApLib, and oh, yeah...its polymorphic. Nice! However, as Jesse pointed out in his rootkit paradox paper, these things usually have a persistence mechanism, and in this case, a driver is installed. Even if it's not given the same name, RegRipper can be used to parse through the System hive file using the "services2" plugin, listing the installed services and device drivers, sorted by the key LastWrite times. If you don't want to acquire an image of the system, you can extract the System hive from a running system using FTK Imager, or show how cool you are by using F-Response.

One interesting piece that I pulled out of the write-up was that early versions of the malware apparently "...used alternative streams to store the installer...", but this technique was dropped. What they're referring to here is NTFS alternate data streams. Leave it to the folks at MS to use "polymorphic terminology" (MS has referred to these as "multiple", "alternate", and "alternative", as well as simply called them "data streams") to describe something so simple.