Last updated
Last updated
The (AMSI) is a component of Windows which allows applications to integrate themselves with an antivirus engine by providing a consumable, language agnostic interface. It was designed to tackle "fileless" malware that was so heavily popularised by tools like the , which leveraged PowerShell for complete in-memory C2.
Any 3rd party application can use AMSI to scan user input for malicious content. Many Windows components now use AMSI including PowerShell, the Windows Script Host, JavaScript, VBScript and VBA. If we try to execute one of the PowerShell payloads on our attacking machine, it will get blocked.
The alert that Defender produces is tagged with amsi: rather than file:, indicating that something malicious was detected in memory.
And attempting to move laterally to the file server will also fail.
Even though this is in-memory, the detections are still based on "known bad" signatures. PowerShell files are a little easier to analyse compared to binary files - scanning it with ThreatCheck and the -e amsi parameter will reveal the bad strings.
Ensure real-time protection is enabled in Defender before running ThreatCheck against script artifacts.
The portion of the output that we want to pay attention to is the loop, which is on lines 26-28 of smb_x64.ps1.
As a quick test, use the find & replace in an editor such as VSCode to change the $x and $var_code variable names to something else, e.g:
ThreatCheck now reports the payload as clean.
To make this change permanent across all the PowerShell payloads, we can modify the relevant template in the Resource Kit. Where the Artifact Kit was used to modify the binary artifacts; the Resource Kit is used to modify the script-based artifacts including the PowerShell, Python, HTA and VBA payloads. The Resource Kit can be found in C:\Tools\cobaltstrike\arsenal-kit\kits\resource and the 64-bit stageless PowerShell payload is generated from template.x64.ps1.
Interestingly, if we check the content, Fortra have already provided different variable names - $zz in place of $x and $v_code in place of $var_code.
As before, use the included build script and specify an output directory, then load resources.cna into Cobalt Strike.
One common source of confusion is when hosting PowerShell payloads using the Scripted Web Delivery method, as these will generally get caught when your stageless PowerShell payloads do not.
The reason for this is that it uses the compress.ps1 template instead, which decompresses the payload from a Gzip stream. In my (limited) experience, AMSI will flag almost anything as malicious if it sees a binary file coming out of a Gzip stream. Unless you have a specific requirement for using a compressed version, in which case you can re-work this template as well, the easiest workaround is to just host your stageless PowerShell payload directly via Site Management > Host File.
