Good things happen when Forensics and Malware Analysis work together.

The SpiderLabs Incident Response team worked a case earlier this year where previously unseen malware was discovered. This isn't all that unusual, but this case really showcased the cooperative talents inside of SpiderLabs.

The malware, named "mssvc.exe", was discovered onsite during memory analysis of a Windows 2003 Server. Nothing special here, the key to recognizing it as "suspicious" was that it had a valid "looking" process name but when you look a little bit closer, there are no valid Windows OS files named "mssvc.exe".

A quick look at the executable with "strings" turned up a few things that threw the red flag:

First: If the service description is "Windows RPC Assistant"(which I've never heard of) Why is the executable named "mssvc.exe"and why is the service named "rcpassist" ?

Second: Is that a regex embedded in the executable? (\d{15,19}=\d{13,})

And third: What is t5701.dat?

I couldn't answer all of these questions myself so I recovered all of the files necessary for analysis and turned them over to our reverse engineering team.

Within a couple of hours (because John, Josh and Ryan are that good) I had a handful of answers and, more importantly, a couple more important questions.

The big answers were:

"Yes, this is definitely a memory scraping malware that is looking for and aggregating credit card track data."

"Yes, that is a regex for credit card data." (we now call it "baby's first regex" because of its simplicity)

"t5701.dat is a trojan backdoor that provides command line access."

The big question posed was:

"Can you recover the \\HKEY_USER\.Default\CurrentUser registry key so that we can look at the configuration variables for the malware?"

I immediately answered with a "sure".

I already knew where to find that key.

It's the ntuser.dat file located in the "Default User" profile, right?

Wrong!

I extracted it, I opened it with Registry Viewer, I parsed it with regripper.

Nothing.

The keys that malware analysis wanted just didn't exist.

<Insert 2 hours of research here>

Very little is written about this registry hive. Once I finally figured out the right way to word my search, I found this post.

In short, the .Default user is not the same as the Default User. In fact, this is the "default" hive that is located with the rest of the Operating hives (SAM, System, Security and Software) in C:\Window\System32\config.

Once I opened it with Registry Viewer I immediately recognized some of the key names and the structure from ntuser.dat files that I have worked with in the past.

It looked so familiar that I decided to try to parse it with regripper and the defaults for the "nt user" hive.

It worked....perfectly.

C:\Windows\system32\config\default is not "like" an ntuser.datfile. It "is" the ntuser.dat file for the "System" user.

If I continue to see this malware I am planning to write a regripper plug into retrieve the information I need. For this one case I got everything we needed from the viewer.

Those encoded values translated to the processes being watched, the exfiltration timer, exfiltration server, dump file size, etc.

Law Enforcement was already involved and the investigation data was turned over to them at the customers request.

Score 1 for the good guys!