Malware Under The Microscope: Manual Analysis

All too often we find clever malware here at Huntress. We look for persistent footholds — the implants and backdoors that hackers leave behind so they can maintain access. Oftentimes, this takes the shape of code that needs to be started automatically, without any user interaction.

We tend to find these footholds in Windows autoruns, scheduled tasks or services, start-up files or even in the Windows Registry.

We recently came across a particular malware sample that used a very peculiar technique. It utilized a legitimate application inherent to Windows… but, interestingly enough, a very old rendition of Windows.

The First Footprints

On one host, we discovered this Windows Registry key:

HKLM\SYSTEM\CurrentControlSet\Services\system

The “HKLMSYSTEMCurrentControlSetServices” registry key inside of regedit.exe

For those that might not know, this is the “Services” registry tree inside the HKEY_LOCAL_MACHINE hive. This stores information about each service on the system, with the last string system referring to the name of the defined service.

Inside each key within the Service registry key, the interesting value to examine further is the ImagePath value, which specifies the full command that is run or executed as the service starts. For this system service, the ImagePath value was set to:

C:\Windows\System32\system\svchost.exe msg

On the surface, this doesn’t look too suspicious. It seems to be just an execution of svchost.exe which Windows operating systems run natively.

However, the real svchost.exe exists only within the C:\Windows\System32 location on the filesystem. What is it doing in a system subdirectory? Now, that is not normal.

Additionally, what is this msg argument that is being passed to svchost.exe?

Suspicious svchost.exe

Naturally, our ThreatOps team went to investigate. Considering this svchost.exe looked very out of place, we thought it might be malware — so we dug deeper.

As it turns out, this svchost.exe was in fact the legitimate svchost.exe program from Windows XP.

Yes, you read that right. Windows XP.

While this is very weird, it actually works as unique hacker tradecraft. After all, this is a legitimate Microsoft Windows application. The binary on its own is “not malware”, and it clears a virus scan.

Source: https://www.virustotal.com/gui/file/517c0d82c8f324e73e492a378a64fc862d3ecb4ef1f25780ad9a4d8b68711571/detection

Okay, so that is one piece of the puzzle, but now what about that strange msg parameter?

After a quick check in that C:\Windows\System32\system folder, we could see that msg was actually a directory. The service invoked this unfamiliar svchost.exe, and the attackers must have known the first argument would read out of a file path.

To support this claim, we found a config.txt file within the C:\Windows\System32\system\msg directory. This file contained:

DisplayName=msgDescription=DescriptionServiceType=272WaitActive=0StartType=2ErrorControl=1Source=C:\security\system.vbsResetPeriod=0RebootMsg=Command=nActions=0Actions=StartAtTime=OneTime

This looks like it outlines how this new msg service would run — indicating another artifact we could examine C:\security\system.vbs!

Before we dive into this new VBScript, I want to take a moment to highlight what we have just seen. The puzzle pieces we have found so far demonstrate an old, Windows XP rendition of the svchost.exe, used to kickstart a service based with a local file configuration. Truthfully, all of us at Huntress thought that was pretty neat. We have not seen that technique before… and in a strange way, we have to “tip our hats” to the hackers.

Exploring system.vbs

Next up we will take a look at the VBScript that was executed by our out-of-place svchost.exe msg call. C:\security\system.vbs contains:

set variable=createobject("wscript.shell") variable.run "svchost.exe /e:VBScript.Encode ""C:\security\blood.dat",false

Well, this was pretty tame. Short and sweet!

There are a few things to unpack here, though — this VBScript is creating a WScript.Shell object so it can start other processes and run other programs. It does run svchost.exe … but, this is not any of the svchosts that we know and love from our previous analysis!

This svchost.exe that is called is actually a renamed copy of wscript.exe, the Windows interpreter for running VBScript. Now it is trying to execute C:\security\blood.bat … yet another artifact.

One interesting tidbit, though, is that this executes that blood.dat file with a /e:VBScript.Encode flag. That tells us that blood.dat is an encoded script, and it will not immediately be human readable.

Walking Back the Hack

At this point, we have something to go off of. The blood.dat filename is very odd, and could be a telltale to uncover what this malware really is. We did our homework and tracked this down to a known threat.

It might not come as any surprise that this strain of malware was first discovered in 2014. Unfortunately, we are still fighting the same threats from the past decade.

This was identified as VBS/Satoban.A. All of our analysis matched up with the known research — the service name, descriptions, files and folders created… we could validate it all.

Decoding blood.dat

Our last artifact to explore is this C:\security\blood.dat file, which we know to be encoded VBScript that is executed by wscript.exe (under the guise of yet another svchost.exe).

The first order of business is decoding blood.dat so we can restore it to a human-readable form.

Thankfully, this is trivial. Plenty of VBScript decoders exist online. Personally, I am fond of this Python script that just gets the job done (admittedly this works best in Python2, so please forgive me, all you Python3 purists).

And with that we could pull back the original VBscript!

This is a long script (over 1000 lines — well, including comments). For the curious and inclined, you can find the whole script here.

Cursory VBScript Analysis

Since VBScript is… a scripting language, we can read through this code easily and not have to deal with reverse-engineering any compiled binary or droning through Assembly instructions.

There is a very fascinating banner including a “hacker handle.”

'==================================================================''' C0d3 N4me : S4T4n ' Cr34t0r : R4PTOR ' Created for personal use , modifications/others are not authorized ' For more informations, looking 4 me { - CNG4L on Race }''=================================================================='

While I won’t step through each-and-every function within the VBScript, there are some peculiar ones that I will leave “as an exercise for the reader” if they are interested. Personally I find the story of “how we got here” much more interesting than finger-pointing attribution. Some of the worthwhile tricks from the VBScript:

Ensuring Command Prompt, Task Manager, and Regedit are enabled.
Disabling the Windows Script Host timeout feature.
Spreading to attached USB drives to contaminate further.
Reach out to multiple external webservers to download more malware.
Silently delete shadow volumes.

The strings and variable names throughout the script indicate the malware author was French. “NomFichier” = “Filename”, “Amovible” = “Removable”, etc.

For your use, here is a collection of the other files or directories that may be created by this malware (potentially helpful IOCs).

C:\security\blood.datC:\security\system.vbeC:\security\system.vbeC:\security\system.vbsC:\security\system.batC:\security\system.exeC:\security\index.exeC:\security\zoneh.exeC:\security\bump.vbeC:\security\av.batC:\security\update.exeC:\kernel\explorer.exeC:\kernel\update.exeC:\system32\C:\Windows\System32\system\msg\config.txtC:\Users\{Username}\AppData\Local\Temp\uac.batC:\Users\{Username}\AppData\Local\Temp\temp.batC:\Users\{Username}\AppData\Local\Temp\tmp.batC:\Users\{Username}\AppData\Local\Temp\ADMIN.vbeC:\Users\{Username}\AppData\Local\Temp\CPBA.batC:\Users\{Username}\AppData\Local\Temp\tp.vbeC:\Users\{Username}\AppData\Local\Temp\booter.datC:\Users\{Username}\AppData\Local\Temp\reskp.exeC:\ProgramData\rescue.vbeC:\ProgramData\kernel\r00t3r

And potential domains or websites that may be called out to:

http://sauvegarde.1x.biz/booter.dathttp://registered.co.nf/sat39/index.phphttp://zoneh.me.pn/zoneh.dathttp://users2.Jabry.com/mysiteweb2/bump.jpghttp://newsonline.125mb.com/av.jpghttp://mysiteweb.eu5.org/system.jpghttp://mysiteweb.freezoy.com/explorer.jpghttp://babybot.125mb.com/update.jpg

When trying to connect to any of these, I notice that most of them seem to be down.

However, at the time of writing: http://users2.Jabry.com/mysiteweb2/bump.jpg and http://mysiteweb.freezoy.com/explorer.jpg do actually get a 200 HTTP response and spirals me down through multiple redirects, likely fingerprinting the connecting client all along the way. I would still like to do more research down this road and formalize which code paths download which artifacts (maybe blog post part two? 😜).

What’s next?

Truthfully, we aren’t done with this malware sample just yet. Sure, it has been “identified” already but we are interested in following these code paths to determine what is done when. By analyzing the source code and finding these artifacts, we will build out more automated detection systems to rapidly find this malware in the future. Huntress is committed to making hackers earn every inch of their access — we will hunt them down every step of the way.

Ultimately, this goes to show how manual analysis and contextual awareness scores another point. svchost.exe might seem innocent if it passes a VirusTotal scan, but we can no longer just say “I scanned it, it’s fine!” and wash our hands of it.

We have to dig deeper.

You’ve heard us say it before — we will look in the corners and crevices to find hacker’s footholds, and with an analytical eye, we will question and inquire each piece of the puzzle. Tricks like living off the land, using new tradecraft to evade detection… hackers are getting more sophisticated. And so should we.