The Antimalware Scan Interface (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 EmpireProject, 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 also 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.
PS C:\Users\Attacker> C:\Payloads\smb_x64.ps1
At C:\Payloads\smb_x64.ps1:1 char:1
+ Set-StrictMode -Version 2
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
This script contains malicious content and has been blocked by your antivirus software.
\
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.
beacon> jump winrm64 fs.dev.cyberbotic.io smb
[-] Could not connect to pipe: 2 - ERROR_FILE_NOT_FOUND
\
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, we see the bad strings.
Where the Artifact Kit was used to modify the binary (EXE & DLL) payloads; the Resource Kit is used to modify the script-based payloads including the PowerShell, Python, HTA and VBA templates.
