PowerShell Obfuscation: Stealth Through Confusion, Part I

To get into the spirit of this post, you should probably skim through the first few slides of this presentation by Daniel Bohannon and Le Holmes given at Black Hat...
Michael Buckbee
3 min read
Last updated August 19, 2022

This article is part of the series "PowerShell Obfuscation". Check out the rest:

To get into the spirit of this post, you should probably skim through the first few slides of this presentation by Daniel Bohannon and Le Holmes given at Black Hat 2017. Who would have thunk that making PowerShell commands look unreadable would require a triple-digit slide deck?

We know PowerShell is the go to-tool for post-exploitation, allowing attackers to live off the land and prosper. Check out our pen testing Active Directory series for more proof.

Get the Free Pentesting Active
Directory Environments E-Book

However, IT security is, in theory monitoring user activities at, say,  the Security Op. Center or SoC, so it should be easy to spot when a “non-normal” command is being executed.

In fact, we know that one tipoff of a PowerShell attack is when a user creates a  WebClient object,  calls its Downloadstring method, and then executes the string contained in the remote web page. Something like the following:

Why would an ordinary user or even for that matter an admin do this?

While this “clear text” is easy to detect by looking at the right logs in Windows and scanning for the appropriate keywords, the obfuscated version is anything but. At the end of this post, we’ll show how this basic “launch cradle” used by hackers can be made to look a complete undecipherable word jumble.

PowerShell Logging    

Before we take our initial dive into obfuscation, let’s explore how events actually gets logged by Windows, specifically for PowerShell. Once you see the logs, you’ll get a greater appreciation of what hackers are trying to hide.

To their credit, Microsoft has realized the threat possibilities in PowerShell and started improving command logging in Windows 7. You see these improvements in PowerShell versions 4 and 5.

In my own AWS environment, the Windows Server 2012 I used came equipped with version 4. It seems to have most of the advanced logging capabilities — though 5 has the latest and greatest.

From what I was able to grok reading Bohannon’s great presentation and a few other Microsoft sources, you need to enable event 4688 (process creation) and then  turn on auditing for the  PowerShell command line. You can read more about it in this Microsoft document.

And then for even more voluminous logging,  you can set policies in the GPO console to enable, for example, full transcription logging of a PowerShell (below).

group policy management editor

More PowerShell logging features in the Administrate Template under Computer Configuration.

No, I didn’t do that for my own testing! I discovered (as many other security pros have) that when using the Windows Event Viewer  things get confusing very quickly. I don’t need the full power of transcription logging.

For kicks I ran a simple pipeline — — to print out process handles, and generated … an astonishing 114 events in the PowerShell log.

event view process

Got it! The original pipeline that spewed off lots of related events.

The good news is that from the Event Viewer,  I was able to see the base command line that triggered the event cascade (above).

Release the Confusion

The goal of the attacker is to make it very difficult or impossible for security staff viewing the log to detect obvious hacking activity or, more likely, fool analytics software to not trigger when malware is loaded.

In the aforementioned presentation, there’s a long, involved example, showing how to obfuscate malware by exploiting PowerShell’s ability to execute commands embedded in a string.

Did you know this was possible?

Or, at a more evil level, this:

Or take a look at this, which I cooked up based on my own recipe:

Yeah, PowerShell is incredibly flexible and the hackers are good at taking advantage of its features to create confusion.

You can also ponder this one, which uses environment variables in an old-fashioned Windows shell to hide the evil code and then pipe it into PowerShell:

You should keep in mind that in a PowerShell pipeline, each pipe segment runs as a separate process, which spews its own events for maximum log confusion. The goal in the above example is to use the %cmd% variable to hide the evil code.

However, from my Windows Event Viewer,  I was able to spot the full original command line — though it took some digging.

In theory, you could look for the actual malware signature, which in my example is  represented by “write-host evil malware”, within the Windows logs by scanning the command lines.

But hackers became very clever by making the malware signature itself invisible. That’s really the example I first started with.

The idea is to use the WebClient .Net object to read the malware that’s contained on a remote site and then execute it with PowerShell’s Invoke-Expression. In the Event Viewer, you can’t see the actual code!

This is known as fileless malware and has become very popular technique among the hackeratti. As I mentioned in the beginning, security pros can counteract this by looking instead for WebClient and Downloadstring in the command line. It’s just not a normal user command, at least in my book.

A Quick Peek at Invoke-Obfuscation

This is where Bohannon’s Invoke-Obfuscation tool comes into play. He spent a year exploring all kinds of PowerShell command line obfuscation techniques — and he’s got the beard to prove it! —to make it almost impossible to scan for obvious keywords.

His obfuscations are based on escape sequences and clever PowerShell programming to manipulate commands.

I loaded his Invoke-Expression app into my AWS server and tried it out for myself. We’ll explore more of this tool next time, but here’s what happened when I gave it the above Webclient.Downloadstring fileless command string:

invoke expression app

Invoke-Obfuscation’s string obfuscation. Hard to search for malware signatures within this jumble.

Very confusing! And I was able to test the obfuscated PowerShell within his app.

Next time we’ll look at more of Invoke-Obfuscation’s powers and touch on new ways to spot these confusing, but highly dangerous, PowerShell scripts.

What should I do now?

Below are three ways you can continue your journey to reduce data risk at your company:


Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.


See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.


Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

Disabling PowerShell and Other Malware Nuisances, Part III
One of the advantages of AppLocker over Software Restriction Policies is that it can selectively enable PowerShell for Active Directory groups. I showed how this can be done in the...
Disabling PowerShell and Other Malware Nuisances, Part II
Whitelisting apps is nobody’s idea of fun. You need to start with a blank slate, and then carefully add back apps you know to be essential and non-threatening. That’s the...
Disabling PowerShell and Other Malware Nuisances, Part I
Back in more innocent times, circa 2015, we began to hear about hackers going malware-free and “living off the land.” They used whatever garden-variety IT tools were lying around on...
PowerShell Obfuscation: Stealth Through Confusion, Part II
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...