Tag Archives: regsrv32

The Malware Hiding in Your Windows System32 Folder: More Rundll32 and LoL S...

The Malware Hiding in Your Windows System32 Folder: More Rundll32 and LoL Security Defense Tips

When we left off last, I showed how it’s possible to run VBScript directly from mshta. I can play a similar trick with another LoL-ware binary, our old friend rundll32. Like mshta, rundll32 has the ability to evade the security protections in AppLocker. In other words, hackers can leverage a signed Windows binary to run handcrafted scriptware directly from a command line even though AppLocker officially prevents it. Evil.

Oddvar Moe, one of this blog’s favorite security bloggers, has studied the LoLs workarounds to AppLocker. In my own experimenting, I was able to confirm that rundll32 can avoid AppLocker’s security defenses.

For example, AppLocker blocked direct execution of a line of JavaScript to pop-up an alert message, but when I fed it the same one-liner directly into rundll32, it ran successfully

AppLocker is not perfect.

I also gave rundll32 slightly more complicated JavaScript that pulls in a remote object and execute it using GetObject. Similar to what I did last time with mashta. It ran flawlessly even though AppLocker disabled scripts.

AppLocker can’t stop rundll32 from running a remote COM object.

As before, I had enabled more granular auditing. I took a peek at the event logs, and thankfully Windows logs the complete command line when the JavaScript is passed directly to rundll32. That’s good news for security defenders.

You can turn on granular logging in Windows to see command line details. Beware: you’re flooded with event details.

Where Is This Going? Lol-Ware Post-Exploitation!

These LoL-ware binaries have incredible abilities to run scripts stealthily. And one would think that pen testers would be working out some post exploitation tools based on this idea. One of the advantage of using scripting languages other than PowerShell is that IT security groups are not necessarily focused on, say, JavaScript.

This was some of the inspiration behind Koadic, which is a command and control (C2) environment, or more familiar to us as a  remote access trojan or RAT. Kodiac allows security testers to open up a reverse shell, dump hashes, pivot using PtH techniques, retrieve files, and run arbitrary commands.

LoL and RAT had a love child, and they called it Koadic. Note the mshta stager.

In the above graphic showing the Koadic environment, you can see that it leverages mshta as a payload launcher to get a foothold on the target computer.

The idea is that the attacker takes the “stager” — the mshta code with the URL — and then embeds it, as we saw, directly in an HTA file or in an Office document’s macros that’s executed when opened.

I’ll be delving more deeply into Koadic in a future post. And I’ll be proving that a corporate IT security group is no match for a capable high-school student. Stay tuned.

Defense Anyone?

AppLocker can’t completely disable script execution. You can resort to simply turning off the Internet spigot by using Windows Firewall. I showed you how to block outbound traffic for a specific binary here.

For a more complete solution, you’ll need to go back to AppLocker, and exclude or blacklist the offending utilities from being executed by “ordinary users”. Something like what I did below, where I prevented users in the “Plain User” group from executing rundll32 while still allowing administrators:

Use AppLocker to exclude ordinary users from being able to run non-ordinary Windows binaries.

The harsh reality is that there really isn’t a fool-proof solution to LoL hackery. There will always be phish mails that allow attackers to get a foothold and then leverage existing Windows binaries.

In this series, we explored regsvr32, mstha, and rundll32. And while the LoL-techniques behind them are well known and defenses available, these binaries are still being successfully used by attackers, as this recent article proves.

And there are the unknown unknowns: new LoL techniques that the security world may not be aware of and are currently being tried.

What do you do?

This brings us back to a familiar theme of the IOS blog: the hackers will get in, and so you need secondary defenses.

This means categorizing your data, finding and putting more restrictive access rights on those data files that contain sensitive information to limit what the hackers can potentially discover, and then using monitoring techniques that alert your security teams when the attackers access these files or exhibit unusual file access or creation activities.

Hold this thought! We’ll see that Koadic, though very clever, is not completely stealthy. It produces some noise, and it’s possible to detect a Kodiac-based attack even when it’s not directly accessing sensitive data.

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

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 it’s 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"?>
  classid="{10001111-0000-0000-0000-0000FEEDACDC}" >
  <script language="JScript">
       var r = new ActiveXObject("WScript.Shell").Run("powershell -noe -nop -c write-host Boo!"); 


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.

Saved by AppLocker: it prevents a JS file from being run.

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.

But if you encase the JScript in XML to make in a COM scriptlet, AppLocker fails.

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.

regsvr32 accepts a URL as well. #sneaky

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 enabled logging of all process creation events for my Windows 7 VM environment.

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.”

Under squiblydoo, this bit of evidence of a script being run is not available. #sneakier

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. Or take a peek at this blog post. 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


Continue reading the next post in "Living off the Land With Microsoft"