Hunting for AMSI Bypassing methods
Introduction to AMSI
AMSI (Antimalware Scan Interface) is a Windows software component provided by Microsoft to be integrated with any applications to scan the user inputs such as executed scripts and commands. For example, Antivirus products usually integrated with AMSI to check for any script-based malware or suspicious command executions by the PowerShell.
How AMSI works
lets say that you have an AV product that want to check if any malicious command or script executed in the PowerShell, in this case, AMSI works by injecting itself into the PowerShell process’s Memory section, in this way, AMSI provide the AV application insight into the executed code to be checked against the AV’s signature database and to be blocked if matches found. See Figure 1.
As you see in the preceding screenshot, by integrating it with the AMSI, the AV software was able to detect that a malicious code was executed by the PowerShell and blocked it accordingly.
The following applications automatically are designed to send content to AMSI:
- PowerShell.
- VBScript.
- JScript.
- VBA macros in Office documents.
- Excel 4.0 macros.
- Exchange Server 2016.
- WMI.
- .NET in-memory assembly loads.
- Volume shadow copy operations.
- User Account Control (UAC) elevations.
AMSI Bypassing methods
Attackers know about AMSI and usually trying to bypass it by using several methods such as:
- Removing the AMSI Provider Registry Key.
- Modification of AmsiEnable Registry Key.
- PowerShell Downgrade.
- Obfuscation.
- DLL Hijacking.
Removing the AMSI Provider Registry Key
When an application such as the PowerShell attempts to submit content to be scanned by the AV which is referred as “AMSI provider”, the application loads “amsi.dll” and send the content to the AV’s AMSI provider DLL to makes a determination about the content. an AV can have more than one AMSI provider which registered as a subkey within the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers” Registry key using their associated COM GUID values. See Figure 2.
As you see in the preceding screenshot, Within the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers” key, there is a subkey with a name of {2781761E-28E0–4109–99FE-B9D127C57AFE} which is the GUID value of the Microsoft defender. If you use another AV product, you will see different GUID value here.
A threat actor may remove the registry subkey of the “AMSI provider” to disable the ability of the AV (Windows defender in this case) to prevent the AV from scanning the application content such script and command. for this case, the attacker may use the PowerShell command “Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\AMSI\Providers\{2781761E-28E0-4109-99FE-B9D127C57AFE}" -Recurse” to disable the AV from scanning the AMSI content.
To detect and hunt for this technique, you could query for the following:
- Hunt for a “powershell.exe” process executions with a command-line argument containing “
AMSI\Providers\” - Hunt for removing to items within this registry key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers”
Modification of AmsiEnable Registry Key
A threat actor could disable the AMSI function by adding a a registry value name “AmsiEnable” to the registry key “HKCU\Software\Microsoft\Windows Script\Settings\AmsiEnable” and set its value to 0.
To detect and hunt for this technique, As you may noticed that the value is created under the current user registry hive (HKCU), so, you can hunt for any creation attempt for the “AmsiEnable” registry value name and its value sited to 0. or Hunt for a “powershell.exe” process executions with a command-line argument containing “AmsiEnable”
PowerShell Downgrade
An attacker may downgrade the PowerShell version to 2.0 by entering this command"powershell -version 2" in the PowerShell console as AMSI is only supported beyond v2.0.
To detect and hunt for this technique, you may search for PowerShell execution with command-line argument including “-version 2” or by monitoring for EventID 400 as it includes the PowerShell Engine version. See figure 3.
As you see in figure 3, the EngineVersion is 2 which indicates that the system use the version 2 engine instead of v5. In general, take it as a note, attackers like to work on v2 instead of v5 for many reasons like the lake of logging and security features.
Obfuscation
As we mentioned before, AMSI protection is a signature-based mechanism of certain keywords, means that with little obfuscation, a threat actor could be able to bypass it. See Figure 4.
As you see in the above screenshot, with very basic obfuscation, I could bypass the AMSI mechanism because the “Invoke”+”-Mimi”+”Katz” simply didn’t match with the AV keywords signature.
Any obfuscation or encoding attempt is opportunity for hunting and detection, for example, create a filter detecting for PowerShell execution with command-line argument containing one of the following keywords “-encoding”, “-enc”, “+” ,”IEX” ,”-EncodedCommand” ,etc.
DLL Search Order Hijacking
DLL Search Order Hijacking is when threat actor plant his trojan dynamic-link library files (DLLs) in a directory that will be searched by the process before the location of a legitimate library that will be requested , causing Windows to load his malicious library when it is called for by the victim program.
As discussed, an application such as the PowerShell must load the “amsi.dll” to transfer the content to the AMSI Provider (AntiVirus) to be checked. A threat actor may create a non-legitimate “amsi.dll” file and plant it on the same folder as PowerShell. to do so, the attacker should the PowerShell program to any location outside the standard one and plant the fake “amsi.dll” at the same path.
To detect and hunt such technique, hunt for PowerShell execution outside of the standard directory or for a PowerShell process loading unsigned “Amsi.dll” file.
