This article is part of the series "PowerShell Obfuscation". Check out the rest:
Let’s step back a little from the last post’s exercise in jumbling PowerShell commands. Obfuscating code as a technique to avoid detection by malware and virus scanners (or prevent reverse engineering) is nothing really new. If we go back into the historical records, there’s this (written in Perl). What’s the big deal, then?
The key change is that hackers can go malware-free by using garden variety PowerShell in practically all phases of an attack. And through obfuscation, this PowerShell-ware then effectively has an invisibility cloak. And we all know that cloaking devices can give one side a major advantage!
Get the Free PowerShell and Active Directory Essentials Video Course
IT security groups have to deal with this new threat.
Windows PowerShell Logging Is Pretty Good!
As it turns out, I was little too quick in my review last time of PowerShell’s logging capabilities, which are enabled in Group Policy Management. I showed an example where I downloaded and executed a PowerShell cmdlet from a remote website:
I was under the impression that PowerShell logging would not show the evil malware embedded in the string that’s downloaded from the web site.
I was mistaken.
If you turn on the PowerShell module logging through GPM, then indeed the remote PowerShell code appears in the log. To refresh memories, I was using PowerShell version 4 and (I believe) the latest Windows Management Framework (WMF), which is supposed to support the more granular logging.
It’s a minor point, but it just means that the attackers would obfuscate the initial payload as well.
I was also mistaken in thinking that the obfuscations provided by Invoke-Obfuscation would not appear de-obfuscated in the log. For example, in the last post I tried one of the string obfuscations to produce this:
Essentially, it’s just a concatenation of separate strings that’s assembled together at run-time to form a cmdlet.
For this post, I sampled more of Invoke-Obfuscation’s scrambling options to see how the commandline appears in the Event log.
I tried its string re-order option (below), which takes advantage of some neat tricks in PowerShell.
Notice that first part $env:comspec[4,15,25]? It takes the environment variable $env:comspec and pulls out the 4-, 15-, and 25-th characters to generate “IEX”, the PowerShell alias for Invoke-Expression. The joinoperator takes the array and converts it to a string.
The next part of this PowerShell expression uses the format operator f. If you’ve worked with sprintf-like commands as a programmer, you’ll immediately recognize these capabilities. However, with PowerShell, you can specify the element position in the parameter list that gets pulled in to create the resulting string. So {20}, {5}, {9}, {2} starts assembling yet another Invoke_Expression cmdlet.
Yes, this gets complicated very quickly!
I also let Invoke-Obfuscation select a la carte from its obfuscation menu, and it came up with the following mess:
After trying all these, I checked the Event Viewer to see that with the more powerful logging capabilities now enabled, Windows could see through the fog, and capture the underlying PowerShell:
Does this mean that PowerShell obfuscation always gets de-obfuscated in the Window Event log, thereby allowing malware detectors to use traditional pattern matching?
The answer is no!
Invoke-Obfuscation also lets you encode PowerShell scripts into raw ASCII, Hex, and, yes, even Binary. And this encoding obfuscation seems to foil the event logging:
Quantifying Confusion
It appears at this point the attackers have the advantage: a cloaking device that lets their scripts appear invisible to defenders or at least makes them very fuzzy.
The talk given at Black Hat that I referenced in the first post also introduced work done by Microsoft’s Lee Holmes – yeah, that guy — along with Daniel Bohannon and other researchers in detecting obfuscated malware using probabilistic models and machine learning techniques.
If you’re interested you can look at the paper they presented at the conference. Holmes and his team borrowed techniques from natural language processing to analyze character frequency of obfuscated PowerShell scripts versus the benign varieties. There are differences!
In any case, Holmes and his group moved to a more complicated logistical regression model – basically classifying PowerShell code into either evil obfuscated or normal scripts. He then trained his logit by looking deep into PowerShell’s parsing of commands – gathering stats for levels of nesting, etc. – to come up with a respectable classifier with an accuracy of about 96%. Not by any means perfect, but a good start!
A Few More Thoughts
While I give a hat tip to Microsoft for improving their PowerShell logging game, there are still enough holes for attackers to get their scripts run without being detected. And this assumes that IT groups know to enable PowerShell Module logging in the first place!
The machine learning model suggests that it’s possible to detect these stealthy scripts in the wild.
However, this means we’re back into the business of scanning for malware, and we know that this approach ultimately falls short. You can’t keep up with the attackers who are always changing and adjusting their code to fool the detectors.
Where is this leading? Of course, you turn on PowerShell logging as needed and try to keep your scanning software up to date, but in the end you need to have a solid secondary defense, one based on looking for post-exploitation activities involving file accesses of your sensitive data.
Catch what PowerShell log scanners miss! Request a demo today.
