al-khaser: malware de prueba para evaluar la protección sin salir del «laboratorio»

al-khaser — es una de esas herramientas cuyo README provoca a la vez ganas de felicitar al autor en el hombro y de asegurar el servidor de pruebas en una caja fuerte. En esencia — es una aplicación de prueba de concepto (PoC) con intenciones “benignas”: los autores crearon un conjunto de técnicas que los atacantes reales suelen emplear para comprobar si pasan desapercibidas ante un antivirus, una sandbox o un monitor de comportamiento. Si estudia técnicas ofensivas o verifica su propio detector, al-khaser puede convertirse en su “examinador estricto”. Pero antes de ejecutarlo — lea este texto: no solo explicaré qué hace la herramienta, sino también cómo usarla de forma consciente y segura.

Qué es al-khaser y para qué sirve

En pocas palabras — es un conjunto de comprobaciones y trucos reunidos en un solo ejecutable. El objetivo no es infectar el mundo, sino dar a ingenieros y analistas la posibilidad de ver qué metodologías de evasión funcionan frente a sus soluciones. Imagine un equipo rojo que, en lugar de romper un sistema, demuestra vectores de ataque potenciales — pero sin cifrar discos, sin extorsión y sin actividad maliciosa “real”. Es como un entrenador de boxeo que da golpes controlados y con casco — duelen, pero son seguros.

al-khaser empaqueta con cuidado una gran cantidad de técnicas: desde trucos clásicos anti-debug hasta métodos para detectar máquinas virtuales y sandboxes, e incluso heurísticas “humanas” como la simulación del movimiento del ratón. Esto es útil porque a los defensores rara vez les resulta sencillo reproducir todo el espectro de métodos localmente: alguien olvida el TLS-callback, otro no probó la comprobación de direcciones MAC, y alguno no revisó cadenas extrañas en el registro. En una palabra — un conjunto útil y a la vez aburrido, pero precisamente por eso efectivo.

Cómo usarlo: interfaz y ejemplos de ejecución

al-khaser se ejecuta desde la línea de comandos. La interfaz es sencilla y pragmática: existe la opción --check, con la que se activan las pruebas deseadas, y la opción --sleep (también --delay), para fijar duraciones de pausa — útil al simular heurísticas de temporización de una sandbox. El programa acepta la misma opción --check varias veces, por lo que puede construir su conjunto de comprobaciones como un rompecabezas.

A continuación — un par de ejemplos típicos de uso:

• al-khaser.exe --check DEBUG --check TIMING_ATTACKS --sleep 30 — comprobamos anti-debug y ataques de temporización con una pausa reducida.
• al-khaser.exe --check VMWARE --check QEMU — comprobamos si la virtualización VMWare y QEMU son detectables.
• al-khaser.exe --sleep 30 — ejecución básica con una pausa corta, para un recorrido rápido.

Si planea descargar los binarios compilados, los autores suelen publicar releases con versiones para x86 y x64; esté preparado para que los archivos estén protegidos con contraseña — es una práctica común en PoC para evitar que bots de búsqueda distribuyan los binarios por equivocación.

Qué hace exactamente al-khaser

La herramienta está organizada de forma lógica: los autores dividieron los trucos en categorías semánticas — anti-debug, anti-inyección, anti-dump, anti-virtualización, etc. Cada uno de estos grupos cubre un amplio conjunto de técnicas, y a menudo se solapan con pequeñas variaciones (es normal — en la práctica un atacante prueba varias técnicas parecidas).

A continuación — un repaso de los grupos principales y de técnicas concretas que merecen atención.

1) Anti-debug y detección de depuradores:

• Llamadas WinAPI: IsDebuggerPresent, CheckRemoteDebuggerPresent y similares, que son la “primera horquilla” en el arsenal de cualquier PoC.
• Comprobaciones de campos del PEB: flags BeingDebugged y NtGlobalFlag, que se suelen leer mediante acceso directo a las estructuras del proceso.
• NtQueryInformationProcess para obtener ProcessDebugPort, ProcessDebugObject y otros indicadores “internos”.
• Trucos con excepciones, el flag TRAP, breakpoints de hardware e imitación del comportamiento de un depurador mediante OutputDebugString + GetLastError.

2) Anti-inyección y evasiones de detección de inyecciones:

• Multiples técnicas de inyección: desde CreateRemoteThread y SetWindowsHookEx hasta combinaciones complejas APC/RunPE.
• Enumeración de módulos por distintos métodos (EnumProcessModulesEx, ToolHelp32, lectura de estructuras LDR), para mostrar cómo se puede “ocultar” un módulo frente a listados simples.
• Comprobaciones de integridad de módulos y búsqueda de módulos “ocultos” en memoria evitando las API habituales.

3) Anti-dumping y protección contra extracción de código de la memoria:

• Borrado de cabeceras PE en memoria, modificación de SizeOfImage y otros trucos que dificultan a las herramientas volcar la imagen ejecutable.
• Formas de complicar el análisis estático y dinámico, por ejemplo rompiendo la desensamblabilidad correcta (ramificaciones improvisadas, rutas de ejecución “imposibles”).

4) Ataques de temporización y anti-sandbox:

• Mediciones mediante RDTSC (incluyendo llamadas CPUID para forzar la salida del hipervisor), variaciones de Sleep/Wait, temporizadores multimedia y otras técnicas para detectar aceleración o distorsión del tiempo.
• Ciclos grandes de cálculos tipo criptográficos (los autores prometen añadir más — “bucles criptográficos grandes (pendiente)”), que ayudan a identificar entornos que intentan acelerar el tiempo.

5) Anti-virtualización y artefactos de máquinas virtuales:

• Comprobaciones en el registro, archivos y controladores que típicamente aparecen en extensiones de invitado de VirtualBox, VMware, Parallels, QEMU, Hyper-V y otros.
• Comprobaciones de direcciones MAC, cadenas SMBIOS, lista de dispositivos y servicios, controladores y ejecutables específicos que “delatan” el entorno virtual.
• Los investigadores experimentados saben que verificar una sola clave del registro rara vez es suficiente — por eso al-khaser recorre muchos indicadores.

Aspectos prácticos

Aparte de llamadas API puras, al-khaser intenta simular aspectos que con frecuencia usa el malware real: nombres de archivos como sample.exe o sandbox.exe, comprobaciones de volumen de memoria y disco, intentos de interacción con el ratón y otros marcadores “de comportamiento”. Esto importa porque las soluciones EDR y UEBA no solo observan llamadas API, sino que construyen un modelo de comportamiento normal del usuario y detectan anomalías.

El autor añade simulaciones de interacción — movimientos de ratón, clics, temporizadores — que ayudan a entender cómo reacciona la sandbox al “comportamiento del usuario” y a detectar si el entorno ejecuta el código de forma automatizada. Por supuesto, parte de estas funcionalidades en al-khaser están marcadas como “pendiente”, pero el conjunto básico ya permite atrapar escenarios típicos.

Además, la herramienta contiene listas de nombres conocidos de procesos y herramientas de análisis (OllyDbg, IDA, x64dbg, ProcessHacker, Sysinternals, etc.), por lo que puede indicar que se está ejecutando en un entorno de investigador y no en el de un usuario real.

Seguridad en el uso

Ejecutar al-khaser solo debe hacerse en un entorno controlado. Suena obvio, pero hay muchas trampas: el binario demuestra deliberadamente técnicas que pueden parecer un ataque activo para sistemas de monitorización, por lo que su detección puede desencadenar bloqueos automáticos, alertas del SOC e incluso respuestas en producción si alguien por error ejecuta la prueba en una máquina de trabajo.

Consejos para un uso seguro:

1. Use una red de laboratorio separada, aislada de la infraestructura de producción.
2. Ejecute solo en máquinas virtuales de prueba con acceso controlado — y tenga cuidado: algunas comprobaciones de al-khaser precisamente buscan artefactos virtuales, así que el resultado puede ser falsamente negativo en su VM de pruebas si difiere mucho del entorno de producción.
3. No conecte la máquina de pruebas a la red corporativa sin supervisión y sin notificar a SIEM/SOC — de lo contrario recibirá una cantidad de alertas en tres dígitos y muchas preguntas por la tarde.
4. Leer el código antes de ejecutar — es una buena práctica obligatoria. Las PoC suelen incluir código fuente; si tiene acceso, revise qué hace el binario a nivel de llamadas al sistema.
5. Controle el acceso a los binarios y a los archivos: publicar en carpetas públicas puede llevar a que alguien ejecute por accidente un programa “divertido” en una máquina donde no conviene.

PoC ≠ malicioso

El conjunto de técnicas en al-khaser por sí mismo no está diseñado para causar daño, pero la frontera legal y ética es fina. Si utiliza una PoC para pruebas — hágalo con el consentimiento del propietario de la infraestructura. Ejecutar estas herramientas en sistemas ajenos sin permiso puede calificarse como acceso no autorizado o incluso preparación de un ataque.

Aparte del aspecto legal, existe la moral: el objetivo del defensor es aumentar la seguridad, pero demostrar técnicas sin contexto ni instrucciones de mitigación puede convertirse en un manual para personas con menos escrúpulos. Por eso los repositorios de este tipo suelen acompañarse de un llamamiento al uso responsable y de normas de contribución: los autores aceptan aportes, pero no fomentan abusos.

Si encuentra en entornos “wild” trucos similares — es preferible analizar, documentar y reportar por los canales adecuados (CSIRT interno, programas de bug bounty o informar al propietario del proyecto) antes que publicar “tal cual” con una breve instrucción “así se rompe”. El contexto es lo que hace útil a una PoC y no peligrosa.

Contribuir al proyecto: cómo ayudar y qué esperar

al-khaser es un proyecto con autores y una política abierta de “Pull requests welcome”. Si encuentra un buen detector para una técnica nueva o, al contrario, un método que evade su sistema — comparta mediante un PR o un issue. Tenga en cuenta las reglas de formato: documentación, pruebas y explicaciones en el código aumentan la probabilidad de que sus cambios sean aceptados.

Contribuciones típicas y útiles:

• nuevas comprobaciones y técnicas (con comentarios y banderas seguras de “solo demostración”);
• mejoras de la documentación: ejemplos de ejecución, notas sobre falsos positivos, recomendaciones de uso seguro;
• scripts de despliegue para laboratorio que ayudan a reproducir resultados sin riesgo de “infectar” la red exterior;
• informes sobre la eficacia de técnicas frente a EDR/AV comerciales concretos (si dispone de permiso para publicar esos datos).

Para los autores es importante no solo mostrar técnicas, sino promover una cultura de pruebas responsables alrededor del proyecto. Si va a publicar resultados, incluya recomendaciones de mitigación — eso aumentará el valor de su trabajo para la comunidad.

Conclusión

al-khaser es una herramienta útil para quienes construyen defensas o analizan el comportamiento de muestras en un entorno controlado. No es un “virus”, es un entrenador: muestra dónde su protección es débil y dónde es robusta. Pero el beneficio real aparece solo si aborda las pruebas con responsabilidad: entorno aislado, lectura del código fuente, notificación a las partes interesadas y publicación de informes con contexto — eso distingue el enfoque investigador serio del simple “toqué y me fui”.

Si decide probar al-khaser — tome la norma de desplegar primero un laboratorio estricto, documentar las observaciones y compartir correcciones o nuevas heurísticas con la comunidad. La seguridad es un juego de equipo, y las PoC como al-khaser son solo una de las herramientas que ayudan a entender por qué su “sellador de ventanas” aguanta más de lo que parece y por dónde aún hay filtraciones.