Obfuscation With PowerShell

I’e covered PowerShell auditing before but hopefully this shows why you need to start controlling and auditing PowerShell within your environment. If you don’t, malicious parties may be able to mask their tracks.

The reason why is that malicious parties, may chose to encode their commands or scripts before executing/deploying them. The reason why is that if your auditing isn’t up to scratch, it may go unseen. In some cases it can also help bypass the AV.

Imagine you don’t have auditing enabled and you go looking at the history. You use the search filter and try and identify Invoke-Mimikatz. It returns nothing….. It may be that it’s because it’s running as encoded and the initial command would be:
Powershell -encodedCommand SQBuAHYAbwBrAGUALQBtAGkAbQBpAGsAYQB0AHo

This is because they have encoded the command first and PowerShell has the ability to run as encoded. To do this, run the command: Powershell -encodedCommand *encoded value*

Lets go through an example. This is a simple command to encode my site URL to base64.

$base64 = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes(“securethelogs.com”))

This can be easily decoded as it’s standard Base64:

$DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($base64))

This is pretty simple stuff. Now imagine an attacker want’s to use encoding but with a little something else. What if for example, we replace the Base64 values and make it harder to follow. Let’s shift the text and add another layer to the encoded value. As you can see, it now becomes unreadable. Once I replace the 9s for As again, it works.

If you didn’t know that I shifted the values from A to 9, you may not be able to figure out what I was doing. This could help mask our attack.

This is somewhat bad practise however, as the attacker would most likely shift the values before you encoded. That way you avoid errors such as:

You may now be thinking, well they have to decoded the value before they can run it?

Well yes and no. Remember that I said PowerShell allows encoded commands to be ran.
Here is a simple example of an echo command:

Now if you have auditing enabled, PowerShell will record the decoded command as it runs. If not, it will only record the initial command (which is encoded). Lets run through an example.

Below is a simple example of encoding the command to run RedRabbit in memory.

I’ve encoded the command and uploaded to PasteBin

I then run the command and it’s blocked….. AV got me.

I can decode in the same command though but if I have auditing enabled, PowerShell will record the decoded command as well.

First event will look like this:

Second will be the decoded command:

This would be the same even if you managed to execute an encoded command.

For example:

What if you didn’t enable advanced auditing for PowerShell?

It could simply go unnoticed.
This is an example of disabling all firewall profiles. Notice how there are no logs generated.

Now lets run the encoded command to launch RedRabbit. As you can see, it loads and no log has the decoded command.

If you had time on your hands, you could in theory go through each line and decode it but this could take awhile. If they have shifted the text before the encoding or wrong a chained attack, it could be near impossible to trace what actually happened (through events alone).

These are just basic examples and an attacker would most likely encode the whole script or command. For these examples, it’s just the initial command for RedRabbit.

If you haven’t done so already, it’s worth reviewing your policy to make sure this type of activity is captured. I have covered a bit on this before, should you wish to read: https://securethelogs.com/hacking-with-powershell-blue-team/

I’ve also created a script to help identify the local auditing settings: https://github.com/securethelogs/Bluechecker