AMSI bypass y evasión de antivirus: qué es, cómo se explota y cómo se corrige

Cuando un operador ofensivo consigue acceso a un sistema Windows y abre una consola de PowerShell, lo primero que encuentra es AMSI: la Antimalware Scan Interface. Cada comando, cada script, cada bloque de código que se envía al intérprete pasa por AMSI antes de ejecutarse. Si el contenido coincide con firmas conocidas de malware, la ejecución se bloquea. AMSI es la barrera que convierte a PowerShell, VBScript, JScript y .NET en intérpretes vigilados.

Pero AMSI tiene una debilidad fundamental: opera en user-mode, dentro del mismo espacio de memoria del proceso que vigila. Un atacante con ejecución de código en ese proceso puede modificar AMSI en memoria para que deje de funcionar. Este tipo de técnica se conoce como AMSI bypass, y es una de las primeras acciones que un operador ofensivo ejecuta tras el acceso inicial. Es la segunda lección de la Tanda 10.

Esta lección explica técnicas de evasión con propósito defensivo. Comprender cómo se deshabilita AMSI permite diseñar detecciones que alertan cuando sucede. Toda práctica debe realizarse exclusivamente en entornos de laboratorio autorizados.

Qué es AMSI y cómo funciona#

AMSI (Antimalware Scan Interface) es una API de Windows introducida en Windows 10 que actúa como puente entre las aplicaciones que ejecutan contenido dinámico y los motores antimalware instalados en el sistema. No es un antivirus en sí mismo: es una interfaz que permite a cualquier antivirus registrado escanear contenido antes de su ejecución.

El flujo funciona así:

1. El usuario ejecuta un comando en PowerShell (o un script VBA, JScript, .NET Assembly).
2. El intérprete (PowerShell.exe, wscript.exe, cscript.exe, o el CLR de .NET) llama a la función AmsiScanBuffer exportada por amsi.dll.
3. AmsiScanBuffer envía el contenido al motor antimalware registrado (Windows Defender, CrowdStrike, etc.) a través de la interfaz COM IAntimalwareProvider.
4. El motor analiza el contenido y devuelve un veredicto: limpio, sospechoso o malicioso.
5. Si el veredicto es malicioso, el intérprete bloquea la ejecución y muestra un error.

Un detalle importante: AMSI escanea el contenido después de la desofuscación. Si un script de PowerShell usa -EncodedCommand con base64, AMSI ve el contenido decodificado. Si el script concatena strings para construir un payload, AMSI ve el resultado final. Esto lo hace efectivo contra la ofuscación básica, pero no contra la manipulación directa de la interfaz.

Las funciones principales de amsi.dll son:

• AmsiInitialize — inicializa la sesión AMSI para un proceso.
• AmsiOpenSession — abre una sesión de escaneo dentro de la inicialización.
• AmsiScanBuffer — envía un buffer de contenido para escaneo.
• AmsiScanString — variante para cadenas de texto.
• AmsiCloseSession y AmsiUninitialize — cierre de sesión e interfaz.

Por qué ocurre: la causa raíz#

La vulnerabilidad fundamental de AMSI es arquitectónica: opera en user-mode dentro del proceso que debe vigilar. Esto significa que el código que se ejecuta en ese proceso tiene los mismos privilegios sobre la memoria de amsi.dll que el propio AMSI.

En términos técnicos, amsi.dll se carga en el espacio de direcciones del proceso de PowerShell. Las funciones de amsi.dll residen en páginas de memoria que, por defecto, son de lectura y ejecución. Pero el proceso puede cambiar los permisos de esas páginas con VirtualProtect a lectura, escritura y ejecución, y luego sobrescribir los bytes de las funciones.

No es un bug: es una consecuencia del modelo de seguridad de Windows, donde un proceso tiene control total sobre su propia memoria. La protección real contra esta manipulación debe venir de capas externas al proceso: kernel callbacks, ETW protegido, o un EDR que monitorice la integridad de AMSI.

// Pseudocódigo conceptual del flujo de AMSI en PowerShell
// (simplificado para ilustrar la arquitectura)
string userInput = ReadCommand();

// PowerShell llama a AMSI antes de ejecutar
AMSI_RESULT result = AmsiScanBuffer(
    amsiContext,
    userInput,
    userInput.Length,
    "PowerShell_script",
    amsiSession
);

if (result == AMSI_RESULT_DETECTED) {
    throw new SecurityException("Script blocked by AMSI");
}

// Si AMSI dice que es limpio, se ejecuta
Execute(userInput);

Tipos y variantes de AMSI bypass#

Memory patching de AmsiScanBuffer#

Es el bypass más conocido y directo. El atacante modifica los primeros bytes de la función AmsiScanBuffer en memoria para que retorne inmediatamente con un resultado limpio, sin ejecutar el escaneo real.

El concepto es simple: la función AmsiScanBuffer comienza con instrucciones de prólogo (setup del stack frame). Si se reemplazan por instrucciones que escriben un valor de retorno limpio (AMSI_RESULT_CLEAN = 0) y un ret, la función retorna sin escanear nada.

Bytes originales de AmsiScanBuffer (x64):
  4C 8B DC          mov r11, rsp
  49 89 5B 08       mov [r11+08], rbx
  ...

Bytes parcheados (conceptual):
  B8 57 00 07 80    mov eax, 0x80070057  ; E_INVALIDARG
  C3                ret

ETW blinding#

Más allá de AMSI, los atacantes avanzados también parchean la telemetría ETW (Event Tracing for Windows). La función EtwEventWrite en ntdll.dll es el punto de entrada que envía eventos de telemetría. Parcheándola con un ret inmediato, se silencian todos los eventos ETW del proceso, incluyendo los de AMSI, .NET y PowerShell.

Esto es más peligroso que un bypass de AMSI solo, porque ciega no solo el escaneo sino toda la telemetría del proceso para herramientas que dependen de ETW en user-mode.

Reflective loading#

El reflective loading consiste en cargar un assembly de .NET directamente en memoria, sin escribirlo en disco. Esto evita el escaneo de archivos del antivirus (que opera sobre disco) y, combinado con AMSI bypass, también evade el escaneo en memoria.

Herramientas como Assembly.Load(byte[]) en .NET permiten cargar un assembly desde un array de bytes. Si los bytes se descifran en memoria justo antes de la carga, el payload nunca toca disco ni pasa por AMSI sin ofuscación.

Cuándo es explotable#

AMSI bypass requiere que el atacante ya tenga ejecución de código en el sistema. No es una vulnerabilidad de acceso inicial, sino una técnica de post-explotación que permite al atacante ejecutar herramientas ofensivas (Mimikatz, Rubeus, SharpHound) que serían bloqueadas por AMSI.

Los escenarios más comunes son:

• Acceso inicial vía phishing. El atacante obtiene una shell limitada y necesita cargar herramientas adicionales que AMSI bloquearía.
• Living off the Land. El atacante usa PowerShell como herramienta principal y necesita ejecutar scripts que contienen funciones detectadas por AMSI.
• Movimiento lateral. Al conectar a una nueva máquina vía WinRM, la sesión remota de PowerShell tiene AMSI habilitado.
• Evasión de EDR. AMSI bypass es a menudo el primer paso antes de descargar y ejecutar un payload más complejo.

Cómo se detecta#

La detección más robusta combina múltiples señales:

# Regla Sigma: detección de AMSI bypass por ScriptBlock Logging
title: Potential AMSI Bypass Indicators in PowerShell
logsource:
    product: windows
    category: ps_script
detection:
    selection:
        ScriptBlockText|contains:
            - 'AmsiScanBuffer'
            - 'amsiInitFailed'
            - 'AmsiUtils'
            - 'amsiContext'
            - 'Bypass'
    filter_legit:
        ScriptBlockText|contains: 'Get-Help'
    condition: selection and not filter_legit
level: high
tags:
    - attack.defense_evasion
    - attack.t1562.001

Explotación paso a paso en un laboratorio#

Paso 1: verificar que AMSI está activo#

Conecta al laboratorio Windows y abre PowerShell:

evil-winrm -i IP_DEL_LAB -u usuario -p contraseña

Verifica que AMSI bloquea strings conocidas:

# Este string debería ser bloqueado por AMSI
"Invoke-Mimikatz"
# Si AMSI está activo, verás un error de escaneo

Paso 2: observar el comportamiento de AMSI#

Antes de intentar cualquier bypass, comprueba que el motor antimalware está activo:

# Verificar el estado de Windows Defender
Get-MpComputerStatus | Select-Object AMServiceEnabled,
    AntispywareEnabled, RealTimeProtectionEnabled

Paso 3: analizar la memoria de amsi.dll#

Desde la perspectiva defensiva, examina cómo se carga amsi.dll en el proceso:

# Listar módulos cargados en el proceso actual
Get-Process -Id $PID | Select-Object -ExpandProperty Modules |
    Where-Object { $_.ModuleName -eq "amsi.dll" } |
    Format-List ModuleName, FileName, BaseAddress

Paso 4: verificar integridad post-bypass#

En un entorno de laboratorio, tras un bypass conceptual, verifica el estado:

# Comprobar si los bytes de AmsiScanBuffer fueron modificados
# (esto requiere herramientas de análisis de memoria)
$amsi = [System.Runtime.InteropServices.Marshal]::GetHINSTANCE(
    [System.Reflection.Assembly]::LoadWithPartialName(
        "System.Management.Automation"
    ).GetModules()[0]
)

Paso 5: revisar los logs de detección#

Desde el lado defensivo, revisa qué registró el sistema:

# Buscar eventos de PowerShell ScriptBlock Logging
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-PowerShell/Operational';
    Id=4104
} -MaxEvents 20 | Select-Object TimeCreated, Message

Qué puede lograr un atacante#

Cómo se corrige#

Fortalecer AMSI#

• Habilitar ScriptBlock Logging. La GPO Turn on PowerShell Script Block Logging registra todo script ejecutado en PowerShell, incluyendo los intentos de bypass, en Event ID 4104.
• Habilitar Module Logging. Registra qué módulos se cargan, complementando ScriptBlock Logging.
• Constrained Language Mode. Restringir PowerShell a CLM impide la mayoría de operaciones de reflection y acceso directo a la API de Windows, bloqueando los bypass basados en memory patching.
• PowerShell v2 deshabilitado. PowerShell v2 no tiene AMSI. Si está instalado, un atacante puede invocarlo con powershell -version 2. Desinstálalo.

# Verificar si PowerShell v2 está instalado
Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2

# Deshabilitar PowerShell v2
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root

Detección en profundidad#

• ETW protegido (ETW-TI). El provider Threat Intelligence opera desde kernel-mode y no es parcheable desde user-mode. Usar un EDR que consuma ETW-TI.
• Memory integrity checks. Verificar periódicamente que los bytes de AmsiScanBuffer y EtwEventWrite no han sido modificados.
• Eventos canario. Generar eventos ETW de control desde un proceso protegido. Si dejan de llegar, alguien parcheó ETW.
• Correlación de ausencia. Si un proceso de PowerShell deja de generar eventos AMSI repentinamente, es un indicador de bypass.

Políticas de sistema#

• WDAC (Windows Defender Application Control). Controlar qué scripts y assemblies pueden ejecutarse.
• AppLocker con reglas de script. Restringir la ejecución de scripts a ubicaciones aprobadas.
• Credential Guard. Aunque no relacionado directamente con AMSI, mitiga el impacto de un bypass exitoso al proteger las credenciales en un contenedor aislado.

Errores comunes al defenderse#

• Depender solo de AMSI. AMSI es una capa, no la defensa completa. Sin kernel callbacks ni ETW-TI, un bypass de AMSI deja al atacante invisible.
• No deshabilitar PowerShell v2. Un atacante puede invocar la versión antigua sin AMSI con powershell -version 2 si está disponible.
• Ignorar ScriptBlock Logging. Sin esta GPO habilitada, no hay registro de qué scripts se ejecutaron, ni siquiera los intentos de bypass.
• No monitorizar la integridad de amsi.dll. Si nadie verifica que AMSI sigue intacto, el bypass pasa desapercibido.
• Bloquear sin investigar. Si AMSI bloquea un string sospechoso, generar una alerta y no solo un bloqueo silencioso. El bloqueo indica que hay un adversario activo.
• Asumir que la ofuscación es suficiente defensa. La ofuscación del payload dificulta la detección por firma, pero AMSI ve el contenido desofuscado en tiempo de ejecución.

Preguntas frecuentes#

¿AMSI solo protege PowerShell?#

No. AMSI protege PowerShell, VBScript, JScript, macros VBA de Office, .NET assemblies (desde .NET 4.8), y Windows Script Host. Cualquier aplicación puede integrar AMSI mediante la API AmsiScanBuffer. Algunos terceros como navegadores y herramientas de desarrollo también lo integran.

¿Si desactivo PowerShell, elimino el riesgo de AMSI bypass?#

No necesariamente. El atacante puede usar otros intérpretes protegidos por AMSI (JScript, VBScript) o cargar .NET assemblies directamente. Además, deshabilitar PowerShell puede ser contraproducente: muchas herramientas de administración y detección dependen de él.

¿Constrained Language Mode es infalible?#

No es infalible, pero eleva significativamente la barrera. CLM impide operaciones de reflection, Add-Type para compilar C# inline, y acceso directo a la API de Windows. Existen bypass documentados para CLM, pero son más complejos y más fáciles de detectar que un bypass de AMSI estándar.

¿Los bypass de AMSI afectan a terceros como CrowdStrike?#

Sí. AMSI es una interfaz: cualquier motor antimalware registrado como provider de AMSI se ve afectado si la interfaz se deshabilita. CrowdStrike, SentinelOne y otros EDR que usan AMSI como una de sus fuentes de telemetría pierden esa capa. Por eso los EDR modernos no dependen solo de AMSI sino que tienen kernel callbacks y memory scanning propios.

¿ETW blinding es más peligroso que AMSI bypass?#

Sí, porque ciega más telemetría. AMSI bypass solo deshabilita el escaneo de scripts. ETW blinding silencia todos los eventos ETW del proceso, incluyendo AMSI, .NET CLR, PowerShell engine y cualquier otro provider. Es una técnica de evasión más amplia, pero también más detectable porque la ausencia de eventos ETW de un proceso activo es una anomalía clara.

Resumen#

• AMSI es la interfaz de Windows que permite a los antivirus escanear scripts y código dinámico antes de su ejecución, operando en user-mode dentro del proceso.
• Memory patching de AmsiScanBuffer es el bypass más directo: modifica los bytes de la función para que retorne sin escanear.
• ETW blinding parchea EtwEventWrite para silenciar toda la telemetría del proceso, no solo AMSI.
• Reflective loading carga código en memoria sin tocar disco, evadiendo el escaneo de archivos del antivirus.
• La defensa efectiva combina ScriptBlock Logging, Constrained Language Mode, ETW-TI a nivel de kernel, verificación de integridad de memoria y deshabilitación de PowerShell v2.
• Nunca dependas solo de AMSI: es una capa valiosa pero eludible. La detección en profundidad con kernel callbacks y ETW protegido sobrevive a los bypass de user-mode.

Fuentes y lecturas recomendadas#

• MITRE ATT&CK T1562.001 — Impair Defenses: Disable or Modify Tools
• Microsoft — Antimalware Scan Interface (AMSI)
• Microsoft — PowerShell ScriptBlock Logging
• Microsoft — Constrained Language Mode
• Microsoft — Event Tracing for Windows (ETW)
• Elastic — Detecting AMSI Bypass Techniques