The ultimate desire for malware authors is to be able to have their code run every time a computer starts, and leave no trace on the disk for us to find. Let me reassure you that it hasn’t happened just yet, at least not that I have seen. There have been plenty of examples over the years that have taken advantage of some clever techniques that disguise their disk-based homes, but that’s just it–disguise!
A couple of recent posts on “Poweliks” here and here shed light on creative measures attackers use to store malware in the Windows Registry. In short, there is a registry value that executes an encoded script stored in another registry value, which then drops a file on disk for execution.
Now the reason for this post: What to do? This persistence mechanism provides us with a practical challenge to sharpen our tools and skills. I’ll show how to use EnCase and EnScript to scour a machine for artifacts such as those left by our friend above. The implementation details will differ from tool to tool, but the basic investigative method should hold.
You may be thinking about RegistryClass from the EnScript API, and in that case you would be on the right track. This class is a generally underutilized part of the EnScript API: I know this because our customers on ForensicFocus forums were asking about RegistryClass fairly recently.
Diving Deep with MountVolume
Catch your breath, let’s dive deep. The RegistryClass is designed as a precision tool to carve out keys and values from specific locations. In this case, we’re taking a broader sweep because there have been several variants already that have used different locations for autostart functions. We’ll access the raw internal entries of the Registry through the EntryClass::MountVolume() method. This is the EnScript equivalent to the EnCase right-click > Entries > View File Structure tool.
The options listed also have further documentation provided at the top of that EntryClass page:
These flags determine how entries created from mounted volumes.
PERSIST - entries from mounted volume will not be destroyed when the variables go out of scope. The entries will stay in memory until the case they are linked to is destroyed.
CALCUNALLOC - calculate unallocated space inside the mounted volume
SCANDELETED - When mounting compound volumes, this flag will tell Encase to search for deleted entries inside the compound volume.
MOUNTNOPOPUP - prevents popups when a volume or file type is parsed which would cause a password dialog or other dialog to come up.
RESOLVEPATHS - This option is only relevant for Vista thumbs.db file. This file does not contain paths or names of any sort, just hash that relates back to the path. Using this option will get the path back.
FORCEKNOWN - When mounting, only known compound or encrypted files will be parsed. If EnCase encounters part of a compound file it isn't sure how to parse it will exit and not mount the whole volume.
The return value coming from MountVolume() is a VolumeClass object which inherits from EntryClass. That allows us to treat a volume like an entry and loop through its children. The two relevant lines of code are inside the blue squares here:
Let’s go for a quick review of the artifacts discovered so far.
EP_X0FF discovered a key name with a null character in it:
Paul Rascagnères of GData observed a key name with an invalid character in it:
and found code inside the default value for that key a little bit different:
Then, B-boy/StyLe/, aharonov, and Picasso found a new variant that moved locations and has different code again:
My first reaction was to look for key names that had non-ASCII characters until the later discovery didn’t use any of those characters. Instead, our EnScript will focus on some keywords inside the code that are consistent across the samples so far. Those are:
Here’s the rundown of the procedure in EnScript:
- Iterate through the files in evidence and determine which are reg hives
- Use the MountVolume() to have EnCase parse the internals
- Iterate through all the values of each hive and filter out values that are too small
- Do a keyword search in the data of values
- Verify that all three keywords have hits in the data
- Note the find in the console
Downloadable Code Sample
I’ve written sample code to illustrate one way of going about searching for this type of artifact on a disk. The sample code may be executed against an evidence file, a live preview of a local disk, or a remote disk via servlet.
In an effort to keep your EnCase machines clean of malware, I’ve created a .REG import file that has the characteristics of the malware discussed above, but none of the harmful effects. This way you can merge this file on a machine and run the EnScript to test. I would still suggest deleting the key when you are done testing, anyway.
You can download a ZIP archive containing the EnScript source code and the sample .REG file here.
As an aside, if you uncomment line 21 and comment line 20, the EnScript will run faster, but it will require you to find the registry hives manually and blue-check them.
If you’re interested, I’ve considered extending this into an EnCase Enterprise-enabled based EnScript that would allow the examiner to punch in a range of IP addresses to do this same scan. Let me know if you’d find this valuable in the comments below. Or, maybe I can show you how to do it at the next EnScript course.
Hashes of related malware for reference courtesy of GData (if you are feeling adventurous):
James Habben @JamesHabben
James is a Master Instructor with Guidance Software, Inc. and instructs digital investigators, incident responders and malware researchers alike as part of the Guidance Software Training team. James applies knowledge from his background in corporate investigations to his instruction and while he is not teaching EnScript Programming, Computer Forensics, or Host Intrusion Investigation Methodology, he enjoys his current duties as a Reserve Probation Officer.