AMSI Bypass: Técnicas de Evasión y Contramedidas Defensivas

AMSI es la última barrera antes de la ejecución de scripts maliciosos

AMSI (Antimalware Scan Interface) es la interfaz que Windows ofrece para que los antivirus y EDR inspeccionen contenido dinámico (PowerShell, VBA, .NET, JScript) justo antes de que se ejecute. Cuando el malware fileless necesita ejecutar un script, AMSI es lo que permite al motor antimalware ver el contenido descifrado y deofuscado. Bypasear AMSI significa cegar al EDR en esa capa. Este artículo explica cómo funciona internamente, cómo se bypasea y cómo detectar cada técnica de evasión.

Arquitectura interna de AMSI

El flujo de escaneo

Cuando PowerShell (u otro host AMSI) necesita ejecutar un bloque de código, el flujo es:

1. PowerShell llama a AmsiInitialize()
   → Crea un contexto AMSI (amsiContext)

2. Por cada sesión de ejecución: AmsiOpenSession()
   → Crea una sesión (amsiSession)

3. Antes de ejecutar código: AmsiScanBuffer() o AmsiScanString()
   → Envía el contenido al proveedor antimalware registrado
   → El proveedor analiza y devuelve un veredicto

4. PowerShell comprueba el resultado:
   → AMSI_RESULT_CLEAN (0)         → Ejecutar
   → AMSI_RESULT_NOT_DETECTED (1)  → Ejecutar
   → AMSI_RESULT_DETECTED (32768)  → Bloquear

5. AmsiCloseSession() → Cierra la sesión

Componentes clave

Componente	Función	Ubicación
amsi.dll	DLL que expone la API AMSI	System32
AmsiScanBuffer	Función principal de escaneo	amsi.dll
AMSI Provider	Motor AV que recibe el contenido	Registrado via COM
AMSI Context	Handle de inicialización	Por proceso
AMSI Session	Handle de sesión de escaneo	Por bloque de código

Hosts AMSI nativos en Windows

AMSI no es exclusivo de PowerShell. Los hosts que envían contenido a AMSI incluyen:

• PowerShell (System.Management.Automation): todo script, incluyendo Invoke-Expression
• VBScript/JScript (wscript.exe, cscript.exe): scripts WSH
• Office VBA: macros de Word, Excel, Access
• .NET (CLR 4.8+): assemblies cargados dinámicamente via Assembly.Load()
• Windows Script Host: archivos .wsf, .wsc
• JavaScript en Edge/IE: contenido web dinámico

El punto clave es que AMSI ve el contenido después de cualquier deofuscación que haga el host. Si un script PowerShell usa Base64 + XOR para ofuscar un payload, PowerShell primero decodifica y después envía el resultado a AMSI. Esto hace que AMSI sea efectivo contra ofuscación simple, pero también lo convierte en un objetivo atractivo para bypass.

Técnicas de bypass AMSI

Categoría 1: Memory patching de AmsiScanBuffer

La técnica más extendida. El concepto es modificar los primeros bytes de la función AmsiScanBuffer en la copia de amsi.dll cargada en memoria del proceso, para que siempre devuelva un resultado limpio sin llegar a escanear nada.

Variante A: Patch con retorno inmediato

El malware sobrescribe el inicio de AmsiScanBuffer con instrucciones que devuelven E_INVALIDARG (0x80070057), lo que hace que el host AMSI interprete el fallo como "no hay problema":

Bytes originales de AmsiScanBuffer:
  4C 8B DC 49 89 5B 08 49 89 6B 10 ...

Bytes parcheados (variante clásica):
  B8 57 00 07 80    ; mov eax, 0x80070057 (E_INVALIDARG)
  C3                ; ret

El host recibe un error de la API, pero en la mayoría de implementaciones esto no bloquea la ejecución.

Variante B: Patch del campo amsiContext

En lugar de parchear la función, se corrompe el handle amsiContext que se pasa a cada llamada. Si el contexto es inválido (por ejemplo, se pone a cero), AmsiScanBuffer devuelve error antes de llegar al proveedor.

Variante C: Patch del resultado

Se modifica la lógica de comparación del resultado para que AMSI_RESULT_DETECTED nunca se interprete como bloqueo.

Detección de memory patching

Indicador	Método de detección	Herramienta
Escritura en páginas de amsi.dll	ETW: Microsoft-Windows-Threat-Intelligence provider	Cualquier EDR con ETW
Primeros bytes de AmsiScanBuffer modificados	Verificación periódica de integridad	Script de validación o EDR
VirtualProtect en amsi.dll	Hook de VirtualProtect / NtProtectVirtualMemory	EDR con hooks ntdll
Patrón conocido: B8 57 00 07 80 C3	Regla YARA en memoria	Volatility + YARA

Categoría 2: Reflection (manipulación .NET)

Desde PowerShell (que corre sobre .NET), se puede acceder a campos internos de la implementación AMSI del CLR usando reflection. El malware busca el campo interno amsiInitFailed de la clase System.Management.Automation.AmsiUtils y lo establece a true.

Cuando amsiInitFailed es true, PowerShell asume que AMSI no está disponible y ejecuta todo sin escanear.

Flujo del ataque:
1. Obtener tipo System.Management.Automation.AmsiUtils via reflection
2. Obtener campo no público amsiInitFailed
3. Establecer valor a true
4. Toda ejecución posterior omite AMSI

Detección de reflection

• Script Block Logging (Event ID 4104): registra el contenido del script incluyendo los comandos de reflection, incluso si AMSI se bypasea después
• PowerShell Module Logging: registra los módulos cargados y las llamadas a reflection
• Patrones en logs: búsqueda de strings como AmsiUtils, amsiInitFailed, NonPublic, SetValue en Event ID 4104
• CLR ETW events: el evento AssemblyLoad puede detectar reflection anómala

Categoría 3: COM hijacking del proveedor AMSI

AMSI encuentra su proveedor antimalware a través del registro de Windows (CLSID registrado en HKLM\SOFTWARE\Classes\CLSID). Si el malware modifica esta entrada para apuntar a una DLL propia (o a una DLL que no implementa la interfaz IAntimalwareProvider), AMSI pierde su conexión con el motor antimalware.

Clave de registro del proveedor AMSI:
  HKLM\SOFTWARE\Classes\CLSID\{GUID-del-proveedor}\InprocServer32
    (Default) = "C:\...\MpOav.dll"  (Windows Defender)

Ataque:
  Modificar (Default) a una DLL que devuelve AMSI_RESULT_CLEAN para todo

Detección

• Monitorización del registro: alertar sobre modificaciones en claves CLSID de proveedores AMSI
• Sysmon Event ID 13 (Registry Value Set): regla para detectar cambios en InprocServer32 de CLSIDs AMSI conocidos
• Integridad del proveedor: verificar periódicamente que el proveedor registrado es el legítimo

Categoría 4: Ofuscación y fragmentación de strings

En lugar de bypasear AMSI técnicamente, se evita que el escaneo detecte contenido malicioso fragmentando los strings que el proveedor busca. AMSI ve el contenido, pero si las signatures del AV dependen de strings completos, la fragmentación puede evitar la detección.

Ejemplo conceptual:
  String original: "Invoke-Mimikatz"
  Fragmentado:     $a = "Inv"; $b = "oke-Mimi"; $c = "katz"; &($a+$b+$c)

Esta técnica no bypasea AMSI en sí, solo evade las firmas del proveedor. Es la menos robusta porque:

• Los proveedores modernos hacen análisis semántico, no solo string matching
• AMSI ve el string reconstruido si se pasa por Invoke-Expression
• Microsoft actualiza firmas regularmente

Detección

Script Block Logging captura el contenido descifrado antes de que la fragmentación surta efecto, porque PowerShell registra el bloque completo.

Categoría 5: PowerShell downgrade

Ejecutar PowerShell v2 (powershell -version 2) omite AMSI completamente porque la versión 2 del engine no implementa AMSI (fue introducido en PowerShell v5).

Detección

• Sysmon Event ID 1 (Process Create): detectar powershell.exe con argumento -version 2 o -v 2
• Eliminar .NET 3.5: PowerShell v2 requiere .NET Framework 3.5. Si no está instalado, el downgrade falla
• AppLocker/WDAC: bloquear ejecución de PowerShell v2 mediante política

Categoría 6: Carga de amsi.dll corrupta

El malware carga su propia versión de amsi.dll (con funciones stub que devuelven limpio) antes de que el host AMSI inicialice. Cuando el host llama a AmsiInitialize, usa la DLL falsa en lugar de la legítima.

Detección

• DLL load monitoring: verificar que amsi.dll se carga desde System32 y no desde otra ruta
• Sysmon Event ID 7 (Image Loaded): alertar sobre amsi.dll cargada desde ruta no estándar
• Firma digital: verificar que amsi.dll tiene firma válida de Microsoft

Tabla resumen: bypass vs detección

Técnica	Complejidad	Efectividad	Detección principal
Memory patching AmsiScanBuffer	Baja	Alta	ETW Threat-Intelligence, integridad
Reflection amsiInitFailed	Baja	Alta	Script Block Logging (4104)
COM hijacking proveedor	Media	Alta	Sysmon Event 13, reg monitoring
String obfuscation	Baja	Media	Análisis semántico del AV
PowerShell downgrade v2	Baja	Alta	Process Create args, eliminar .NET 3.5
amsi.dll suplantada	Media	Alta	Sysmon Event 7, firma digital

MITRE ATT&CK mapping

Técnica MITRE	ID	Relación con AMSI bypass
Disable or Modify Tools	T1562.001	Memory patching, COM hijacking, reflection
PowerShell	T1059.001	Host principal de AMSI, downgrade a v2
Command and Scripting Interpreter	T1059	Todos los hosts AMSI (VBS, JS, .NET)
Impair Defenses	T1562	Categoría general de evasión de AMSI
Deobfuscate/Decode	T1140	AMSI ve contenido post-deofuscación

Contramedidas defensivas: checklist

Prevención

1. Eliminar .NET Framework 3.5 donde no sea necesario (bloquea PowerShell v2 downgrade)
2. Constrained Language Mode en PowerShell: limita reflection y acceso a APIs .NET
3. WDAC (Windows Defender Application Control): bloquear DLLs no firmadas, impedir carga de amsi.dll desde rutas no estándar
4. Script Block Logging habilitado (GPO): captura contenido incluso si AMSI se bypasea después

Detección

5. ETW provider Microsoft-Windows-Threat-Intelligence: detecta escrituras en páginas de código de DLLs del sistema (incluye amsi.dll)
6. Sysmon configurado con reglas para:
   • Event 7: carga de amsi.dll desde ruta no estándar
   • Event 13: modificación de claves COM de proveedores AMSI
   • Event 1: PowerShell con -version 2
7. Verificación de integridad periódica: comparar bytes de AmsiScanBuffer en memoria con los del archivo en disco
8. Reglas YARA en memoria: detectar patrones de patching conocidos (B8 57 00 07 80 C3)
9. Monitorizar Event ID 4104 (Script Block Logging): buscar AmsiUtils, amsiInitFailed, SetValue, NonPublic

Respuesta

10. Si se detecta bypass: el incidente indica actividad post-explotación activa. No es ruido, es un indicador fuerte de que un atacante está ejecutando herramientas en el endpoint. Escalar a N2/N3 inmediatamente.

Evolución: AMSI en Windows 11 y más allá

Microsoft sigue reforzando AMSI:

• AMSI para .NET 6+: extensión de cobertura a aplicaciones .NET modernas
• Hardware-backed integrity: en procesadores con soporte, verificación de integridad de código a nivel de hardware (HVCI) dificulta el memory patching
• AMSI en más hosts: integración progresiva en aplicaciones de terceros (SQL Server, Exchange)

Sin embargo, la carrera armamentística continúa. Los atacantes siguen encontrando variantes de bypass, y la comunidad defensiva responde con capas adicionales de detección. AMSI no es una solución definitiva, es una capa más en una estrategia de defensa en profundidad.

Conclusión

AMSI es una capa de visibilidad valiosa pero no infalible. Entender las técnicas de bypass permite construir detecciones específicas para cada una. La defensa efectiva combina AMSI con ETW, kernel callbacks, Script Block Logging y verificación de integridad, de forma que bypasear una capa active alertas en otra.

Fuentes y referencias

• Microsoft: Antimalware Scan Interface (AMSI) (documentación oficial)
• MITRE ATT&CK: T1562.001 Disable or Modify Tools
• Elastic Security Labs: AMSI bypass detection research (2024)
• SANS: Windows AMSI Internals and Bypass Techniques (whitepaper)
• Cybereason: AMSI Bypass Methods and Detections (2023)