Advanced Evasion in Windows: Disabling AMSI and ETW via PowerShell
Executive Summary
This technical analysis reviews advanced techniques used by malicious code to evade AMSI and ETW in Windows through PowerShell and memory patching techniques, with the objective of bypassing antivirus and EDR solutions.
It is also particularly interesting to observe how a single .bat file can self-contain three PowerShell scripts, a malicious PE, and additionally implement AES encryption to keep the payload hidden, along with multiple obfuscation techniques and evasion of AMSI and ETW functionality.
Introduction
Advanced Evasion Techniques in Windows: Understanding AMSI and ETW Abuse
AMSI (Antimalware Scan Interface) is a native Windows interface implemented in the dynamic library amsi.dll, designed to enhance endpoint antivirus protection. It operates as an intermediary between different consumers—such as PowerShell, Windows Script Host (wscript.exe and cscript.exe), JavaScript, VBScript, and Office VBA macros—and the security provider.
This interface allows deobfuscated and decrypted script content to be sent to the local antivirus provider prior to execution for analysis. The provider then returns the scan result, allowing or denying the execution.

ETW (Event Tracing for Windows) is a native Windows mechanism designed for tracking and logging multiple events generated by applications and drivers. EDR solutions use this mechanism to identify malicious behavior by analyzing the event streams reported through ETW.

Once these components and their functionality have been briefly explained, we will review a couple of techniques implemented by the sample analyzed in this publication. For more detailed information on these Windows components, the official Microsoft documentation can be consulted:
- https://learn.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal
- https://learn.microsoft.com/en-us/windows-hardware/test/wpt/event-tracing-for-windows
Sample Under Analysis
Techniques Used to Evade AMSI and ETW in Windows
To demonstrate AV/EDR evasion techniques using real malicious code, we analyze a sample from the Remcos malware family. This malware features multiple execution and deployment stages, all initially integrated into a .bat file. This is a fileless malware, as it loads scripts and binaries directly into memory once the script is executed for the first time.
Initial Execution
The .bat file contains an obfuscated PowerShell command. This command is split across multiple variables and strings, which are later concatenated on line 191 to construct and execute the PowerShell command.

The command performs, among other tasks:
- Verifies that a copy of the
.batfile exists in the user directory - Reads all lines of the
.batfile searching for two specific strings: one starting with:::and another with:: - The first string (
:::) contains another Base64-encoded script, which is loaded into memory and executed - The second string (
::) contains a compressed file encrypted using the AES algorithm - Defines three functions: one for AES decryption, one for unpacking files, and one for loading and executing a payload in memory
Once the command is deobfuscated, the following is obtained:

The Base64 string beginning with ::: (these symbols are omitted, as they are only identifiers used by the script to locate the string) contains another PowerShell script. This script primarily performs two actions:
- Bypasses AMSI
- Bypasses ETW
Understanding AMSI and ETW Evasion Techniques Observed in the Sample
First, the script defines a set of functions used to identify function addresses and execute the delegate technique.

Next, to gain access to system functions, the malware loads System.Windows.Forms.UnsafeNativeMethods, then identifies the required functions. These function names are encoded in hexadecimal, serving as an additional strategy to evade detection through suspicious API usage.

Using the delegate technique, the script points to the amsi.dll and kernel32.dll libraries, as well as the AmsiInitialize and VirtualProtect functions.

Once delegation is completed, the script modifies the memory segment permissions to apply memory patching—changing the segment from read-only to read-write—and modifies the opcodes of the AMSI function.

The applied memory patch is:
0xb8, 0x0, 0x00, 0x00, 0x00, 0xC3
Which translates to the following opcodes:
mov eax, 0ret
By injecting these opcodes at the beginning of the AmsiScanBuffer function, the function immediately terminates and returns 0, which translates to AMSI_RESULT_CLEAN. This causes the function to always report the analyzed code as safe, without actually performing any analysis.
Once the memory patch has been applied, the script attempts to restore the memory segment permissions back to read-only.

In this manner, the script modifies the behavior of the AMSI function, preventing scans of subsequent commands and always reporting that no malicious code has been detected.
Memory Patch to Evade ETW in Windows
Similarly to the AMSI case, the script obtains the address of the EtwEventWrite function, defined in ntdll.dll, enables write permissions, and applies a memory patch. In the x64 case, it applies 0xC3; for x86, it applies 0xb8, 0xff, 0x55.

Once the memory patch is applied—serving the same purpose as in the AMSI case, i.e., entering the function and immediately returning control without performing any action—the script attempts to restore read-only permissions.

Payload Decryption
After applying memory patches to prevent detection, the script proceeds to decrypt two files contained within the line beginning with :: inside the .bat file.

Once decrypted, the files are decompressed and executed.

Payload Used to Evade AMSI and ETW in Windows
Continuing with the payload analysis, we observe that it uses the same detection evasion techniques, applying a memory patch to the ETW function:
- Loads the
ntdll.dlllibrary - Obtains the
EtwEventWriteaddress - Selects the memory patch based on the identified architecture
- Modifies memory permissions
- Applies the memory patch
- Restores permissions

This produces the same effect as in the previous case: the function is disabled and simply returns control without executing any action.
At this point, the malware can carry out its intended activities without being detected by antivirus solutions or even installed EDR systems.
Conclusions
This analysis demonstrates that evading AMSI and ETW in Windows is feasible when the integrity of runtime functions is compromised. The effectiveness of AMSI and ETW depends on the integrity of these functions at runtime. By applying memory patches via PowerShell or other methods, along with the use of delegate techniques, malicious code can successfully remain undetected within the system.
This analysis also leads to the conclusion that a more effective approach to protecting systems against malicious code is a defense-in-depth strategy, considering additional tools and secure configurations, operating system hardening, enforcing least privilege for users and processes, and implementing user awareness programs, among other controls that can help reduce the risk of security compromise.
Post Comment