Aether

version : 0.9 (version stable)

Aether est un outil de forensique mémoire et de chasse aux menaces sous Windows qui analyse la mémoire des processus en direct à la recherche de motifs malveillants, détecte les techniques d'injection, les signatures d'implant, les assemblages .NET chargés de manière réfléchie. Il fonctionne avec un modèle de confiance multicouche qui réduit considérablement le taux de faux positifs et chasse les comportements malveillants. Aether possède de bonnes capacités de détection des techniques de Hollowing, d'APC et de détournement de threads. Les analystes de sécurité peuvent l'utiliser pour scanner, chasser et capturer des régions suspectes pour une analyse hors ligne.

Documentation : https://0xsp.com/docs/aether-getting-started/

Articles de recherche :

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/

Fonctionnalités principales

Explications rapides des fonctionnalités principales d'Aether, vous pouvez lire l'article technique complet pour plus de détails :

Analyse de signatures

• Correspondance de motifs d'octets dans la mémoire du processus avec un index du premier octet qui offre un gain de vitesse de 50 à 100 fois par rapport à une analyse naïve
• Double encodage ASCII + UTF-16LE — capture les chaînes stockées par le CLR .NET (où "msxsl:script" devient 6D 00 73 00 78 00 ...)
• Chargement dynamique de règles à partir de fichiers JSON — déposez de nouvelles signatures dans rules/ sans recompilation
• Détection d'en-tête PE dans les régions MEM_PRIVATE — signale les assemblages .NET chargés de manière réfléchie (métadonnées MZ + PE + BSJB)

IOC structurels de la mémoire

Aether superpose cinq filtres au signal brut de l'ensemble de travail, de sorte qu'une constatation nécessite plusieurs indicateurs concordants avant d'être signalée avec un filtrage FP :

Couche	Filtre	Objectif
L1	Structurel	Seules les sous-régions IMAGE exécutables sont considérées (élimine le bruit COW de .data / .rdata)
L2	Quantitatif	Évaluation par le nombre de private_pages et le private_ratio (faible / moyen / élevé)
L3	Corroboration	Promu seulement si un signal indépendant s'accorde sur la même base d'allocation — hit de signature, missing_peb_entry, private_rwx, prologue de hook, ou diff sur disque
L4	Sensible au CLR	Suppression par module pour les cibles ngen / R2R / tiered-JIT (*.ni.dll, mscor*, clr*, coreclr, system.private.corelib*) au lieu d'un saut global lorsque le CLR est chargé
L5	Diff sur disque	Mappe le fichier module avec CreateFileMappingW(SEC_IMAGE_NO_EXECUTE) ; compare les 16 premiers octets de chaque page privée exécutable avec la même RVA sur disque. Toute divergence est un IOC de modification réelle

Autres vérifications structurelles :

• Référence croisée du module PEB : allocations MEM_IMAGE qui ne sont pas dans la liste des modules du PEB (DLL hollowing / module stomping)
• Analyse de l'ensemble de travail : détection de pages de code modifiées via K32QueryWorkingSetEx, regroupée avec un seul appel système par région au lieu d'un par page de 4 Ko (environ 50 à 100 fois plus rapide que la boucle naïve)
• Détection de RWX privé : signale les allocations MEM_PRIVATE + PAGE_EXECUTE_* (cela produit des résultats FP) (shellcode, JIT spray, allocations de stubs de code dynamique)
• Sonde de prologue de hook — lit les 16 premiers octets de chaque page de code privé et correspond aux trampolines x86/x64 classiques :
  • E9 ?? ?? ?? ?? — JMP rel32
  • FF 25 ?? ?? ?? ?? — JMP [rip+disp32]
  • 68 ?? ?? ?? ?? C3 — PUSH imm32 ; RET
  • 48 B8 ?? ?? ?? ?? ?? ?? ?? ?? FF E0 — MOV RAX, imm64 ; JMP RAX
  • 49 BB ?? ?? ?? ?? ?? ?? ?? ?? 41 FF E3 — style Detours MOV R11, imm64 ; JMP R11
• Détection CLR — sonde d'objet de section pour Cor_Private_IPCBlock_v4_<PID> et la v2 Cor_Private_IPCBlock_<PID> (héritage .NET 2/3 / mscorwks), de sorte que les pools d'applications bruyants exécutant d'anciens runtimes ne soient pas mal classifiés

Validation de l'adresse de démarrage des threads (TSAV / L8)

Aether vérifie les threads avec une classification plus stricte et une corrélation croisée avec les résultats L1–L5. Pour chaque thread créé dans le processus cible, Aether lit son Win32StartAddress via NtQueryInformationThread et, lorsque les permissions le permettent, également le Rip / Eip en direct via GetThreadContext / Wow64GetThreadContext. Chaque adresse est ensuite évaluée selon le tableau suivant, pour plus de détails lisez l'article de blog :

Verdict	Sévérité	Condition
TSAV_SHELLCODE_PRIVATE	CRITIQUE	L'adresse se trouve dans une région MEM_PRIVATE + PAGE_EXECUTE_* — shellcode CreateRemoteThread classique
TSAV_SUSPENDED_RIP	CRITIQUE	Le Rip du thread suspendu diffère de Win32StartAddress et pointe vers une région suspecte — détecte l'usurpation de Win32StartAddress (astuces EarlyBird / APC) et les détournements SetThreadContext
TSAV_HOLLOWED_HOST	ÉLEVÉ	Adresse dans une allocation MEM_IMAGE qui n'est pas dans la liste des modules du PEB (DLL hollowing / module stomping)
TSAV_MODIFIED_HOST	ÉLEVÉ	Adresse dans une allocation MEM_IMAGE que le pipeline L1–L5 a déjà signalée comme MODIFIED_CODE_*, MISSING_PEB, PRIVATE_RWX, DISK_MEM_DIFF, ou HOOK_PROLOGUE
TSAV_STAGED_PRIVATE_RW	ÉLEVÉ	MEM_PRIVATE + PAGE_READWRITE — préparation de shellcode avant VirtualProtect
TSAV_MAPPED_NONPE	MOYEN	MEM_MAPPED (section basée sur le fichier d'échange) sans en-tête PE — chargeur réfléchi sRDI / pagefile
TSAV_SPOOF_TRAMPOLINE	MOYEN	L'adresse correspond à un trampoline en liste de blocage (LoadLibraryA/W/ExA/W, WinExec, CreateProcessA/W, VirtualAlloc[Ex], RtlExitUserThread, RtlExitUserProcess, NtTerminateProcess, ShellExecuteA/W)

Ce qui rend cette vérification plus forte que la vérification de base "l'adresse de démarrage est-elle dans un module" :

• Vérification croisée VirtualQueryEx — chaque adresse est interrogée pour Type / Protect / AllocationBase en un seul appel O(1) au lieu d'un balayage linéaire de la liste des modules
• Corrélation croisée avec L1–L5 — un thread dont le démarrage se trouve dans une allocation déjà signalée passe de "OK" à TSAV_MODIFIED_HOST
• Cohérence PEB — les modules hollowés sont détectés même lorsque l'adresse de démarrage se trouve techniquement dans une plage "réelle"
• Sonde RIP suspendu — Win32StartAddress est accessible en écriture via NtSetInformationThread et est le champ usurpable ; le Rip en direct d'un thread suspendu est celui qu'un chargeur ne peut pas facilement réécrire. Nous comparons les deux et signalons toute divergence pointant vers une région suspecte
• Conscience WoW64 — bascule automatiquement vers Wow64GetThreadContext et lit Eip pour les threads 32 bits dans un processus 64 bits
• Échelle des droits d'accès — descend de QUERY_INFORMATION | GET_CONTEXT → QUERY_INFORMATION → QUERY_LIMITED_INFORMATION par thread, de sorte que les scénarios d'accès partiel produisent toujours des classifications utiles