Aether

versión : 0.9 (versión estable)

Aether es una herramienta de análisis forense de memoria y caza de amenazas para Windows que escanea la memoria de procesos en vivo en busca de patrones maliciosos, detecta técnicas de inyección, firmas de implantes y ensamblados .NET cargados de forma reflectiva. Funciona con un modelo de confianza multicapa que reduce drásticamente la tasa de falsos positivos y caza comportamientos maliciosos. Aether tiene buenas capacidades para detectar técnicas de Hollowing, APC y secuestro de hilos. Los analistas de seguridad pueden utilizarla para escanear, cazar y capturar instantáneas (snapshots) de regiones sospechosas para su análisis sin conexión.

Documentación: https://0xsp.com/docs/aether-getting-started/

Artículos de investigación:

https://0xsp.com/security%20research%20%20development%20srd/aether-memory-forensics-and-threat-hunting-tool/

https://0xsp.com/research/game-of-hide-and-seek-detecting-dynamic-api-resolution-at-runtime-with-aether/

Características principales

Explicaciones rápidas de las características principales de Aether; puedes leer el artículo técnico completo para obtener más información:

Escaneo de firmas

• Coincidencia de patrones de bytes en la memoria del proceso con un índice de primer byte que proporciona una aceleración de 50-100x frente al escaneo ingenuo
• Codificación dual ASCII + UTF-16LE: detecta cadenas almacenadas por el CLR de .NET (donde "msxsl:script" se convierte en 6D 00 73 00 78 00 ...)
• Carga dinámica de reglas desde archivos JSON: coloca nuevas firmas en rules/ sin recompilar
• Detección de cabecera PE en regiones MEM_PRIVATE: marca ensamblados .NET cargados de forma reflectiva (metadatos MZ + PE + BSJB)

IOCs estructurales de memoria

Aether aplica cinco filtros sobre la señal bruta del conjunto de trabajo (working set), de modo que un hallazgo requiere múltiples indicadores coincidentes antes de notificarse con el filtrado de FP:

Otras comprobaciones estructurales:

• Referencia cruzada de módulos del PEB: asignaciones MEM_IMAGE que no están en la lista de módulos del PEB (DLL hollowing / module stomping)
• Escaneo del conjunto de trabajo: detección de páginas de código modificado mediante K32QueryWorkingSetEx, agrupado con una llamada al sistema por región en lugar de una por página de 4 KB (≈ 50-100× más rápido que el bucle ingenuo)
• Detección de RWX privado: marca asignaciones MEM_PRIVATE + PAGE_EXECUTE_* (produce resultados FP) (shellcode, JIT spray, asignaciones de stubs de código dinámicos)
• Sonda de prólogo de hook: lee los primeros 16 bytes de cada página de código privada y compara con trampolines clásicos x86/x64:
  • E9 ?? ?? ?? ?? — JMP rel32
  • FF 25 ?? ?? ?? ?? — JMP [rip+disp32]
  • 68 ?? ?? ?? ?? C3 — PUSH imm32 ; RET
  • 48 B8 ?? ?? ?? ?? ?? ?? ?? ?? FF E0 — MOV RAX, imm64 ; JMP RAX

Validación de dirección de inicio de hilo (TSAV / L8)

Aether comprueba los hilos con una clasificación más estricta y una correlación cruzada con los hallazgos L1–L5. Para cada hilo creado en el proceso objetivo, Aether lee su Win32StartAddress mediante NtQueryInformationThread y, cuando los permisos lo permiten, también el Rip / Eip en vivo mediante GetThreadContext / Wow64GetThreadContext. Cada dirección se clasifica según la siguiente tabla; para más detalles, lee el artículo del blog:

Lo que hace que esto sea más sólido que la comprobación básica de "la dirección de inicio está en algún módulo":

• Verificación cruzada con VirtualQueryEx: cada dirección se consulta por Type / Protect / AllocationBase en una sola llamada O(1) en lugar de un escaneo lineal sobre la lista de módulos
• Correlación cruzada con L1–L5: un hilo cuyo inicio cae dentro de una asignación ya marcada se actualiza de "OK" a TSAV_MODIFIED_HOST
• Coherencia del PEB: los módulos vaciados (hollowed) se detectan incluso cuando la dirección de inicio cae técnicamente dentro de un rango "real"
• Sonda de RIP suspendido: Win32StartAddress es escribible desde el proceso mediante NtSetInformationThread y es el campo suplantable; el Rip en vivo de un hilo suspendido es el que un cargador no puede reescribir fácilmente. Comparamos ambos y marcamos cualquier discrepancia que resuelva a una región sospechosa
• Consciente de WoW64: cambia automáticamente a Wow64GetThreadContext y lee Eip para hilos de 32 bits dentro de un proceso de 64 bits
• Escalera de derechos de acceso: degrada de → → por hilo, de modo que los escenarios de acceso parcial siguen produciendo clasificaciones útiles

L9 + L10 - Detección de tablas de API en el heap con correlación entre módulos

La resolución dinámica de API es una técnica que el malware utiliza con frecuencia. El mecanismo de detección de Aether identifica este comportamiento escaneando el heap en busca de direcciones y punteros de módulos válidos, y correlacionando los resultados con los criterios de filtrado descritos a continuación:

Cada filtro elimina una clase específica de FP observada en telemetría real:

Análisis de entropía y heurísticas de shellcode

Por ahora, Aether admite la detección de patrones XOR a nivel de stub y adopta el algoritmo de entropía de Shannon para comprobar la aleatoriedad de los valores de bytes en una región de memoria; marca todo lo que supera un umbral. Para abordar la alta cantidad de FP, Aether utiliza múltiples indicadores.

Detección de beacons C2

• Monitorización de conexiones TCP: consulta periódicamente GetExtendedTcpTable para un PID objetivo
• Detección de patrones de beacon: identifica conexiones periódicas de corta duración (comportamiento clásico de callback C2)
• Salida de tabla de conexiones: tabla de consola formateada con estado, endpoint, aciertos (hits) y protocolo

Modos de salida

• Informe de consola con colores: resaltado ANSI según la severidad
• JSON analizable por máquina: para integración con el pipeline SIEM / d-tect.py
• Salida de sospecha graduada: cada hallazgo MODIFIED_CODE_* incluye private_pages y region_pages para que el triaje tenga los números reales
• Salida con formato de tabla: utiliza caracteres Unicode de dibujo de cajas para la monitorización de conexiones

Uso

Aether.exe --scan --pid <PID> [OPTIONS]
Aether.exe --scan --lookup "ProcessName.exe"
Aether.exe --hunt <PID> SLEEP_MS PERIOD
Aether.exe --scan-all [OPTIONS]

Opciones

Cómo compilar

Requisitos previos

• Zig 0.16 — descárgalo aquí
• La compilación cruzada funciona desde cualquier sistema operativo anfitrión (Linux, macOS, Windows)

Compilación

git clone https://github.com/0xsp-SRD/aether
cd aether

# Debug build (safety checks enabled)
zig build

# Release build (smaller, faster binary)
zig build -Doptimize=ReleaseSafe
# or
zig build -Doptimize=ReleaseFast

El ejecutable compilado se encuentra en zig-out/bin/Aether.exe.

Despliegue

Copia zig-out/bin/Aether.exe y el directorio rules/ a la máquina Windows de destino si quieres realizar un escaneo de firmas adicional. Si el proceso objetivo requiere privilegios administrativos, debes ejecutar Aether.exe con privilegios de Administrador.

Limitaciones

• Solo modo usuario: sin controlador de kernel; no puede detectar rootkits ni manipulaciones a nivel de kernel
• Solo IPv4: la monitorización de conexiones TCP no admite endpoints IPv6 por ahora.
• El diff en disco L5 requiere acceso al archivo: si el archivo del módulo original se ha eliminado o está bloqueado, el diff en disco omite ese módulo silenciosamente (las demás capas siguen ejecutándose)
• La lista de trampolines suplantados de TSAV se resuelve en el propio proceso del escáner: detecta el caso común en el que las DLL del sistema comparten una base ASLR en toda la sesión, pero puede perder objetivos con bases únicas por proceso (raro en Win10+)
• La sonda de RIP de TSAV solo detecta hilos suspendidos: una reescritura de Win32StartAddress en un hilo ya en ejecución solo puede detectarse si el hilo está detenido en una espera cuando se sondea (misma limitación que Moneta)
• La detección XOR-PE es básica en esta versión

Licencia

Aether Community está licenciado bajo GNU GPL v3.0. Las licencias comerciales solo están disponibles a través del autor para uso propietario o comercial.