The Malware Hiding in Your Windows System32 Folder: Intro to Regsvr32

In our epic series on Malware-Free Hacking, I wrote about techniques that let you use well-known Microsoft apps and tools to run evil custom scripts. This file-less hack-craft usually involves sneaking obfuscated VBA into Office documents. But there’s more file-less evil out there.

For this new mini-series, I want to dive into something call LoL, for Living off the Land, in which hackers reuse less well-known Windows utilities to hide script payloads and cloak other activities. This github page contains a nice collection of all the different binaries and scripts — with sample attack code — that falls under the LoL genre (h/t Oddvar Moe).

The more important point with LoL is its underlying philosophy: you hide your attack by using Windows software in ways that weren’t intended by the developers. Not only does this approach get past conventional malware scanning, but there are other benefits.

As we’ll soon see with regsvr32, which allows for JScript or VBScript to be injected into DLLs, LoL attacks can also evade Microsoft’s AppLocker and avoid easy spotting in the event logs.

Yeah, LOL techniques allow malware to blend into the scenery and make it difficult to spot in the wild.

Regsvr32 and Squiblydoo

From what I can decipher, one of the founding fathers behind using regsvr32 as a post-exploitation LoL tool is security researcher Casey Smith.

But first, do you know what regsvr32 even does? Answer: It registers DLLs into the Windows Registry, allowing other software to access the library as needed. Seems harmless.

In 2016, Casey discovered that regsvr32’s /i parameter, which is used to trigger any initial installation processing, accepts a COM scriptlet. In other the words, an administrator can insert dynamic code when the DLL sets itself up.

Remember scriptlets? I discussed them in my malware-free series. They are simply JScript or VBScript code embedded in XML, allowing them to be passed around as COM objects (below).

<?XML version="1.0"?>
  <scriptlet>
  <registration         
  progid="Pentest"       
  classid="{10001111-0000-0000-0000-0000FEEDACDC}" >
  <script language="JScript">
      ![CDATA[        
       var r = new ActiveXObject("WScript.Shell").Run("powershell -noe -nop -c write-host Boo!"); 
  ]]>
  </script>
  </registration>
  </scriptlet>

<?XML version="1.0"?>
  <scriptlet>
  <registration         
  progid="Pentest"       
  classid="{10001111-0000-0000-0000-0000FEEDACDC}" >
  <script language="JScript">
      ![CDATA[        
       var r = new ActiveXObject("WScript.Shell").Run("powershell -noe -nop -c write-host Boo!"); 
  ]]>
  </script>
  </registration>
  </scriptlet>

By using regsvr32 with /i, Casey showed he could run scripts in a directory that was locked down by AppLocker. AppLocker is the Windows security technology that I experimented with in my legendary PowerShell obfuscation series. Well, I was impressed with it at the time.

His clever proof of concept made some news in 2016. Ultimately his technique, known as Squiblydoo, found its way into real-world malware used by known APT groups — for example, in this spear fishing campaign against Russian businesses last summer, and more recently in some cryptomining craziness.

This is a serious security threat, and leveraging regsvr32 this way makes it far easier for hackers to go about their work undetected.

Microsoft did respond, in Windows 10 at least, with a way to detect  (not block) Squiblydoo – which it calls process hollowing — through an update to its Windows Defender ATP. (Yours truly has a trial copy of ATP, which is on my long list of things to test.)

The Microsoft band-aid helps a little. In the next post, I’ll present a few sensible mitigations to greatly lower security risks.

A Closer Look at Regsvr32

To preserve my AWS computing budget – thanks Sarah for paying the bills! – I decided to test Squiblydoo on my desktop Virtual Box environment. If you want to play along at home, you can download a free Windows 7 VM from Microsoft here.

I went into AppLocker, which can be found under the Local Security Policies console within Administrative Tools. You’re essentially working with a GPO editor that zooms into Security Setting. You’ll find AppLocker under Application Control Policies.

I simply disabled script rules (below) in the home directory of an ordinary user. This tells AppLocker not to run JavaScript, VBScript or PowerShell. The great thing about AppLocker over the older Software Restriction Policies is its selectivity: you can disable a specific user – bob, in my case – and administrators could still run scripts in that directory or anywhere else.

Pro tip: AppLocker depends on Application Identity service running. You may have to start this service depending on how the Applocker GPO entries were configured. In my case, I had to take a quick visit to the Services console, found under Administrative Tools, to start  the Application Identity service manually.

I then deposited a JScript  file (with a .js suffix), containing just the bit of ActiveX code in the above scriptlet into bob’s Documents directory. And then tried to start it — mimicking one phase of an attack.

AppLocker blocked it as expected.

And then I tried the same thing with regsrv32 using the Squiblydoo technique to run a COM scriptlet as part of a dll initialization.

This time AppLocker failed to prevent the code from being executed.

Game, set, and match for Casey.

And one more thing.

Squiblydoo also works if you enter a url after the /i parameter. In other words, you can go completely fileless and pull and execute the scriptlet from a remote site.

This brings up an important about how Squiblydoo is leveraged in real-world malware attacks. They are typically a multi-step sequence in which regsvr32 might be used initially with a url, and then later on in the attack (after more files are generated), this stealthy utility can also run a scriptlet directly from a directory.

Let’s Go to the Event Viewer

As other security expert have pointed out, squiblydoo avoids giving away too many details in the Windows Event Viewer. That’s kind of true as I discovered.

For my own testing, I turned on process creation auditing, which can be found under the aforementioned Local Security Policies. My Windows 7 environment in VirtualBox logs every process creation event, which is event id 4688 if you’re following at home.

I also turned on PowerShell logging. Remember that? Microsoft had to up its security game after it became clear that PS was being exploited by hackers, so it added more granular PS auditing capabilities. I enabled Module and Script Block logging in the PowerShell section of the GPO. console. It’s the same settings I used in my initial PowerShell testing, which you can read more about here.

Here’s what I learned.

If you run a JS script file, the Event Viewer tells you that the wscript engine was engaged. That’s underlying software environment used by Windows to run scripts. And then a little bit later in the log, you can see the details of a PowerShell session being started along with the command line that was passed in.

You could, perhaps, piece all this together, with a little help from some event correlation tools: “Oh, a JScript file was clicked and then an ActiveX object launched a PowerShell session.”

But when I used the Squiblydoo technique, I only saw the regsvr32 command (without the command line) in the event log. And then later, the PowerShell events show up. If you look more closely in the Application Logs section of the Event Viewer, under Windows PowerShell, you’ll see the actual command line used (because we enable more detailed PS logging through GPO.)

I strongly suspect even good correlation software on the market would not be able to connect regsvr32 and a PowerShell sessions. And in a quick scan of the raw logs, a harried sys admin who’s not up on the latest hack-craft could easily miss these clues.

Real-World RegSvr32

This brings up one last point as I mercifully close out this first post. Hackers are in the business of making it incredibly inconvenient for security pros to do their work.

Besides the PS obfuscations techniques I’ve written about, the entire attack sequence is normally broken into many different parts with some of the actions specifically designed to throw off security monitoring tools.

In other words, instead of the attack involving a single download  — the old way — it’s now spread out over several steps, with LoL Windows utilities, such as regsvr32, hiding the actual code pulls from the hacker’s site.

If you’re curious about what it’s like to analyze complex attacks like this, get yourself a few cups of coffee and watch this video. It covers Kovter malware. Enjoy!

In the next post, we’ll finish up with regsvr32 and then look at other Windows Lol-ware that can perform similar feats of malware deception