I currently have been tuning a “suspicious” PowerShell query that alerts in Carbon Black whenever PowerShell is launched using certain interesting parameters. Below is the query that I’ve been working on:
process_name:powershell.exe AND (cmdline:”-Enc” OR cmdline:”-NoP” OR cmdline:”-Exec” OR cmdline:”bypass” OR cmdline:”hidden” OR cmdline:”-EncodedCommand” OR cmdline:”IEX”)
Often I’ve seen PowerShell Remote Access Trojans (RATs) simply throw their full Command and Control (C2C) instructions into the query (as I wrote about in my PowerShell Empire blog post here)
In the case of something like this, all one needs to do is use any base64 decoder to decode the Base64 string and view the command.
Lately, I’ve been seeing a new type of PowerShell-based attack that has an interesting twist on the standard Base64 Encoded PowerShell attack. In this attack, it adds an additional level of obfuscation by Base64 Encoding a PowerShell script in a Gzip file:
Here is the complete command line for the malware payload.
(Note: given the fact that the sample below is active malware, I have obfuscated portions of the Base64 Encoded command)
When I first tried to reverse this Base64 string, I didn’t get anything of substantial value out of the string when I ran it through several Base64 decoders (below you can see the results from base64decode.org):
As you can see, nothing that was returned was quite helpful.
It was at this time that I noticed the statement “IO.Compression.GzipStream” just below the Base64 encoded PowerShell command, so I began to try and see what I could dig up on this.
After a good bit of trial amd error, I found a Base64 decode site that would enable me to not only decode the string as text, but also as a file (below you can see the decoder on motobit.com):
I went ahead and downloaded the file and .bin file in 7z and then extracted the file.
This time, I could see the PowerShell Function:
I tried on multiple attempts to convert the second Base64 encoded command, but was unsuccessful.
As I began to look at the surrounding code, I saw references to ‘InMemoryModule’ and I did a bit of research on the GetDelegateForFunctionPointer function and found the following article on MSDN confirming my suspicion that the second base64 encoded data was actually an encoded memory based function thus allowing an attacker to execute arbitrary commands on the system at will (ref: https://msdn.microsoft.com/en-us/library/zdx6dyyh(v=vs.110).aspx).
The granular level of monitoring and detection inside of Cb Response is the only indicator we had to this attack vector. If it had not been for the ability of Carbon Black to alert on the suspicious PowerShell command line parameters watchlist that I created, this attack would have completely slipped by traditional IDS & IPS style defenses.
Benjamin Tedesco is a Senior Technical Services Consultant working at Carbon Black as a digital forensics and incident response SME. He currently leads the Advanced Consulting Team and assists Carbon Black customers to leverage the Carbon Black tool suite in their existing incident response and detection capabilities. Before coming to Carbon Black, Benjamin was responsible for leading a number of high-profile APT hunt-and-detection engagements. Currently, he is pursuing a master’s degree in information security and forensics at Penn State University.
Recently, while in Europe, Ben discovered an ATM skimmer, click here to see a video of his discovery that went viral!
Click here to view other articles Ben has written: https://www.carbonblack.com/author/ben-tedesco/
To connect with Ben, drop him a line on LinkedIn: https://linkedin.com/in/bentedesco