Because PowerShell attacks are usually encoded,
another approach is to use msticpi's Base64 decoder.
You can run this directly on a panda's dataframe,
specifying the column you want to search and decode.
It will return only items that have decodable Base64 content.
Note that because we're looking at Windows data here,
which uses 16‑bit unicode characters, we need to specify the utf16=True flag.
This isn't required for Linux or MacOS data.
We found several events with decoded content, but not an unmanageable number.
The output dataframe has a column, src_index,
which contains the index of the original input row.
We want to join our decoded results back to the original process event data.
We do this using a pandas join and using the src_index column in
the decoded results dataframe to match up to the original events
with the encoded command lines.
Several of the events are immediately identifiable
as Windows housekeeping tasks.
These all share the same LogonId,
so we can use that to filter them out and print out
the remaining logon session IDs.
We're using pandas again to do this filtering,
telling it to return everything that doesn't match LogonId 0x3e7.
We want to use those remaining LogonIds to fetch all of the processes in
these logon sessions so that we can see our suspect commands in the
context of the other processes in the same session.
These processes may give us more clues as to what the attacker was doing.
We'll use msticpi's process tree visualization to do this.
This lets us see the relationship between child and parent
processes and to get a better idea of the context in which
our suspect process was operating.
The visualization is interactive,
so we can scroll through the tree and hover over processes to see more details.
We can see that one of our suspect encoded processes was spawned from
explorer.exe via the Windows scripting host wscript.
It doesn't have many child processes, but it does execute whoami.
Most Windows users don't even know this executable exists,
so when you see it, it's often an indicator of malicious activity.
There are some other interesting processes in the tree
that we may also need to look at, but we're going to focus on this one right now.
We need to make a note of the LogonId and ProcessId that we're
interested in so that we can easily find it in our data.
Using these values, we filter our process events to just return that process.
This is actually the same process that we identified by
looking at Commandline Length earlier.
Since we rejoined the decoded data to original dataframe,
we can also look at the decoded command line.
It looks something like PowerShell, but is not especially readable,
as well as encoding the script,
the attacker has tried to obfuscate the script content,
making it tricky to see what it is doing.
For PowerShell,
msticpi has a simple deobfuscator that we can use to
get something more understandable.
This just does some simple reformatting and changes all the text to lowercase.
For an even better rendering of the code, we can use msticpi's code_view module.
This uses the Python Pygments library to display the
code with syntax aware coloring.
Even at a very cursory glance, we can see that it appears to be doing
something to turn off script blocking. This alone is very suspicious.
Looking further down the script then, we can see that it is loadin\g the
.NET AMSI utilities library. You may not be familiar with this library. It
is the anti‑malware scripting interface.
Each script is a bit different, and you can use some of the system libraries
that are being loaded to infer its intent. It might be reasonable to assume
that it is doing something to interfere with the anti‑malware software on
the host. In this case, it is actually trying to exploit a previous
vulnerability in the AMSI library.
We can also see it load in the web client,
so it is communicating with the network. At the very end of the script,
we can see that it's downloading data from a remote location and piping the
data to iex. Iex is a PowerShell pneumonic for invoke expression, which
just executes whatever string is passed to it.
In other words,
the script is downloading some data from an unknown location
and passing this to PowerShell to execute.
In many cases,
these scripted attacks are taken from popular offensive code libraries, so
searching for a snippet of the code may tell us more about it.
In this instance,
we see that the code is from a well known vulnerability and is
available to browse in attack and research sites.
To summarize,
we looked at the use of event analysis and decoding to detect possible
script threats; we used msticpi process tree to view the context of the
script execution; we were able to decode, deobfuscate, and view the
script in readable format; and finally,
we took a snippet of the code to find proof of the concept code in GitHub.