This article is part of the series "Living off the Land With Microsoft". Check out the rest:
- Master Fileless Malware Penetration Testing!
- The Malware Hiding in Your Windows System32 Folder: Intro to Regsvr32
- The Malware Hiding in Your Windows System32 Folder: Mshta, HTA, and Ransomware
- The Malware Hiding in Your Windows System32 Folder: Certutil and Alternate Data Streams
- The Malware Hiding in Your Windows System32 Folder: More Alternate Data Streams and Rundll32
- 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
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.
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.
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.
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:
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.
