Defeating Obfuscation With Dynamic Analysis And Powershell Logging
It all started with ‘Creative Content Production.js’
This script is the output of another malicious .js script and involved a malicious scheduled task. The scripts origins appear to be from a malicious .docx file, though the exact chain of events is not clear and unfortunately the system is no longer available.
Sounds like a fun script. Let’s check it out!
45.9 MB!
That’s a big script!
Ok, this looks benign. Time to go get an afternoon snack and have a quick nap!
Just kidding. Just looking at this giant blob of text makes me want to scream.
This is a massive, obfuscated .js file, which appears to be using a variety of obfuscation techniques like replacing extraneous characters, concatenating variables, and single line formatting.
It would take way too much brain power for me to try and manually deobfuscate this, and after 30-40 minutes of trying to clean it up, understand the flow and discern the purpose. I gave up.
Time to go get an afternoon snack and have a quick nap!
Ok, ok ok, let’s take another look.
Instead of relying on static analysis, lets approach this dynamically and see what we can glean.
We’re going to use two classic tools: Process Hacker and Procmon.
Let’s start with Process Hacker.
I know from the Crowdstrike Detection that the following commandline was used by the Scheduled Task to run the script:
And though you can use either wscript or cscript to run .js scripts, lets use cscript.
And we’ll open Process Hacker and wait to see what happens.
Let’s also open ProcMon now, set a filter for cscript.exe and run the capture. Then execute the script.
Cscript execution under cmd.exe, as expected because we launched the script from the command prompt.
And after a few seconds, what’s this! Powershell?!
Let’s take a deeper look!
Under the Properties for the powershell process we can immediately see a couple of interesting things:
The command line is a great example of the result of concatenating different strings together to form the word ‘powershell’. This is very common in obfuscated scripts. Secondly, the parent process is ‘non-existent’, which means the cscript process that launched it has been terminated.
What I want to draw attention to here is the empty commandline. Why would a malicious script launch powershell.exe with no arguments? Well, you can safely assume that’s not actually the case. Let’s see if Procmon has what we are looking for.
Procmon will have captured quite a bit of activity, and a lot of it will be benign actions from cscript as it spins up and accesses windows resources to run the script. Let’s filter by process creation events and look for powershell.
Unfortunately, same result here. No command line arguments!
This is a devious little trick that attackers can use. You can pass an entire command to powershell and evade simple detection/analysis by piping it to powershell followed by a dash ‘-‘ (there are probably other ways to do this as well).
Like this:
If we monitor for this in procmon, sure enough we get this:
Not quite the same as the malicious script, but it appears they used a similar method to achieve the same result.
So how do we know what the attacker ran with powershell? The powershell process has been running in the background this whole time! Clearly it’s up to something.
This is where Powershell host logging can really come in handy, luckily its quite easy to setup via group policy, either in a domain environment or individually for on the fly analysis like this.
First, kill the powershell process, then open gpedit.msc on the windows analysis machine.
Navigate to Computer Configuration - Administrative Templates - Windows Components - Windows Powershell and enable ‘Turn on PowerShell Script Block Logging’
This will fire Event Viewer events for powershell commands/scripts.
Also enable ‘Turn on PowerShell Transcription’ and configure an output directory to store the transcripts.
This will give you a nice text file with what we are looking for.
Now click OK and lets run the script again, wait for powershell to run and check the output.
Success!
If we open this up and take a look, we can quickly spot the malicious content
Now we can copy this into an ide and take a closer look.
It’s worth noting that you can also check the event viewer for similar information from eventid 4104
Now right away we can see this is setup as a one line script, meaning it has semi-colons where every newline should. So first thing I will do is replace every semi-colon with a new line.
This gives us something fairly readable.
Note that I have removed one of the domain names to due to its explicit nature.
And from here, a simple clean up can be performed to understand what the script is doing.
The while loop at the bottom runs the ConnectToUrl function and loops through these hardcoded urls and attempts to connect to them. It gathers the following system info: path variables, running processes, open windowtitles, desktop items, free disk space, and concatenates them with a hardcoded key, then plugs them into the http request header along with a useragent.
It then waits to receive a response from the php page it connects to and will run (iex = invoke-expression) the response.
Luckily, Crowdstrike prevented the process from connecting to the malicious domains, and there does not appear to be any further indicators of malicious activity.
The lesson here is that logging diversity(as well as host based logging) can be invaluable! We needed Powershell host logs to quickly and easily find the malicious Powershell code that ultimately ran here.
UPDATE 6-26-23:
I later read a Reliaquest blog post on a Gootloader infection they saw in a customer environment. A lot of the details in that blog match my investigation above, and while initially I wasn’t able to attribute the scripts to any particular family, I feel quite confident saying this was a Gootloader sample. I have added the article below. Happy Hunting!
https://www.reliaquest.com/blog/gootloader-infection-credential-access/