Windows-Tool für Speicherforensik und Threat Hunting, das den Speicher laufender Prozesse auf schädliche Muster, Injection-Techniken und reflektiv geladene .NET-Assemblys scannt und ein mehrschichtiges Konfidenzmodell verwendet, um Fehlalarme zu reduzieren.
Version: 0.9 (stabile Version)
Aether ist ein Windows-Tool für Memory-Forensik und Threat Hunting, das den Live-Prozessspeicher nach schädlichen Mustern durchsucht, Injektionstechniken, Implantat-Signaturen und reflektiv geladene .NET-Assemblys erkennt. Es arbeitet mit einem mehrschichtigen Konfidenzmodell, das die False-Positive-Rate drastisch reduziert und nach schädlichem Verhalten sucht. Aether verfügt über gute Fähigkeiten zur Erkennung von Hollowing-, APC- und Thread-Hijacking-Techniken. Sicherheitsanalysten können es zum Scannen, Jagen und Erstellen von Snapshots verdächtiger Regionen für die Offline-Analyse verwenden.
Dokumentation: https://0xsp.com/docs/aether-getting-started/
Forschungsartikel:
Kurze Erläuterungen zu den Kernfunktionen von Aether – den vollständigen technischen Blogbeitrag findest du unter den obigen Links:
"msxsl:script" zu 6D 00 73 00 78 00 ... wird)rules/
abgelegt werden, ohne neu kompilieren zu müssenMEM_PRIVATE-Regionen – kennzeichnet reflektiv geladene
.NET-Assemblys (MZ + PE + BSJB-Metadaten)Aether legt fünf Filter auf das rohe Working-Set-Signal, sodass ein Fund mehrere übereinstimmende Indikatoren erfordert, bevor er mit FP-Filterung gemeldet wird:
| Ebene | Filter | Zweck |
|---|---|---|
| L1 | Strukturell | Nur ausführbare IMAGE-Unterregionen werden berücksichtigt (eliminiert .data/.rdata-COW-Rauschen) |
| L2 | Quantitativ | Bewertung anhand der private_pages-Anzahl und des private_ratio (niedrig / mittel / hoch) |
| L3 | Korroboration | Nur heraufstufen, wenn ein unabhängiges Signal auf derselben Allokationsbasis übereinstimmt – Signaturtreffer, missing_peb_entry, private_rwx, Hook-Prolog oder On-Disk-Diff |
| L4 | CLR-bewusst | Modulspezifische Unterdrückung für ngen/R2R/tiered-JIT-Ziele (*.ni.dll, mscor*, clr*, coreclr, system.private.corelib*) statt pauschalem Überspringen, wenn die CLR geladen ist |
| L5 | On-Disk-Diff | Abbilden der Moduldatei mit CreateFileMappingW(SEC_IMAGE_NO_EXECUTE); Vergleich der ersten 16 Bytes jeder privaten ausführbaren Seite mit derselben RVA auf der Festplatte. Jede Abweichung ist ein echter Modifikations-IOC |
Weitere strukturelle Prüfungen:
MEM_IMAGE-Allokationen, die nicht in der
PEB-Modulliste enthalten sind (DLL-Hollowing / Module Stomping)K32QueryWorkingSetEx, stapelverarbeitet mit einem Syscall pro Region
statt einem pro 4-KB-Seite (≈ 50-100× schneller als die naive Schleife)MEM_PRIVATE + PAGE_EXECUTE_* (erzeugt FP-Ergebnisse)
Allokationen (Shellcode, JIT-Spray, dynamische Code-Stub-Allokationen)E9 ?? ?? ?? ?? — JMP rel32FF 25 ?? ?? ?? ?? — JMP [rip+disp32]68 ?? ?? ?? ?? C3 — PUSH imm32 ; RET48 B8 ?? ?? ?? ?? ?? ?? ?? ?? FF E0 — MOV RAX, imm64 ; JMP RAX49 BB ?? ?? ?? ?? ?? ?? ?? ?? 41 FF E3 — Detours-Stil
MOV R11, imm64 ; JMP R11Cor_Private_IPCBlock_v4_<PID>
und die v2-Variante Cor_Private_IPCBlock_<PID> (Legacy-.NET-2/3/mscorwks),
sodass laute App-Pools mit alten Laufzeiten nicht falsch klassifiziert werdenAether prüft Threads mit strengerer Klassifizierung und
Kreuzkorrelation mit den L1-L5-Ergebnissen. Für jeden erstellten Thread im
Zielprozess liest Aether seine Win32StartAddress über NtQueryInformationThread
und, sofern die Zugriffsrechte es erlauben, auch das Live-Rip/Eip über
GetThreadContext/Wow64GetThreadContext.
Jede Adresse wird dann gemäß der folgenden Tabelle bewertet – weitere Details im Blogbeitrag:
| Befund | Schweregrad | Bedingung |
|---|---|---|
TSAV_SHELLCODE_PRIVATE | KRITISCH | Adresse liegt in einer MEM_PRIVATE + PAGE_EXECUTE_*-Region – klassischer CreateRemoteThread-Shellcode |
TSAV_SUSPENDED_RIP | KRITISCH | Das Rip eines angehaltenen Threads weicht von Win32StartAddress ab und zeigt auf eine verdächtige Region – erkennt Win32StartAddress-Spoofing (EarlyBird-/APC-Tricks) und SetThreadContext-Hijacking |
TSAV_HOLLOWED_HOST | HOCH | Adresse liegt in einer MEM_IMAGE-Allokation, die nicht in der PEB-Modulliste ist (DLL-Hollowing / Module Stomping) |
TSAV_MODIFIED_HOST | HOCH | Adresse liegt in einer MEM_IMAGE-Allokation, die von der L1-L5-Pipeline bereits als MODIFIED_CODE_*, MISSING_PEB, PRIVATE_RWX, DISK_MEM_DIFF oder HOOK_PROLOGUE gekennzeichnet wurde |
TSAV_STAGED_PRIVATE_RW | HOCH | MEM_PRIVATE + PAGE_READWRITE – Shellcode-Staging vor VirtualProtect |
TSAV_MAPPED_NONPE | MITTEL | MEM_MAPPED (pagefile-backed section) ohne PE-Header – sRDI / Pagefile-Reflective-Loader |
TSAV_SPOOF_TRAMPOLINE | MITTEL | Adresse entspricht einem gesperrten Trampolin (LoadLibraryA/W/ExA/W, WinExec, CreateProcessA/W, VirtualAlloc[Ex], RtlExitUserThread, RtlExitUserProcess, NtTerminateProcess, ShellExecuteA/W) |
Was dies stärker macht als die einfache Prüfung „liegt die Startadresse in einem Modul":
VirtualQueryEx-Querprüfung – jede Adresse wird in einem einzigen O(1)-Aufruf auf
Type/Protect/AllocationBase abgefragt, statt eines linearen
Scans über die ModullisteTSAV_MODIFIED_HOST hochgestuftWin32StartAddress ist prozessbeschreibbar über
NtSetInformationThread und das fälschbare Feld; das Live-Rip eines
angehaltenen Threads ist das, was ein Loader nicht einfach umschreiben kann. Wir vergleichen
beide und kennzeichnen jede Abweichung, die auf eine verdächtige Region zeigtWow64GetThreadContext und liest
Eip für 32-Bit-Threads in einem 64-Bit-ProzessQUERY_INFORMATION | GET_CONTEXT → QUERY_INFORMATION → QUERY_LIMITED_INFORMATION zurück,
sodass Szenarien mit Teilzugriff weiterhin nützliche Klassifizierungen liefernDynamische API-Auflösung zur Laufzeit ist eine häufig von Malware verwendete Technik. Der Erkennungsmechanismus von Aether identifiziert dieses Verhalten, indem er den Heap nach gültigen Moduladressen und Zeigern durchsucht und die Ergebnisse mit den unten beschriebenen Filterkriterien korreliert:
Jeder Filter eliminiert eine bestimmte FP-Klasse, die in realer Telemetrie beobachtet wurde: