
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:
| Filter | Regel | FP-Klasse, die er entfernt |
|---|---|---|
| F1 | count >= 5 | zufällige zeigerförmige Daten, NULL, HMODULES |
| F2 | Läufe ablehnen, die nur in die Host-EXE zeigen | C++-Vtabellen der Anwendungsklasse |
| F3 | distinct_modules >= 2 | Single-DLL-Framework-Vtabellen (Qt, MFC, wxWidgets) |
| F4 | capability_modules >= 2 | Browser-/CRT-Vtabellen, die eine einzelne OS-DLL berühren (z. B. iertutil + ucrtbase + shlwapi) |
| F5 (L10) | >= 80% der prüfbaren Zeiger landen auf exportierten RVAs | Winsock-LSP-Dispatch-Tabellen, Plugin-Callback-Arrays, Vtabellen, die auf interne (nicht exportierte) Methoden zeigen |
Aether unterstützt derzeit die XOR-Erkennung auf Stub-Ebene und verwendet den Shannon-Entropie-Algorithmus, um die Zufälligkeit von Bytewerten in Speicherregionen zu prüfen; alles oberhalb eines Schwellenwerts wird gekennzeichnet. Um die hohe Anzahl an False Positives zu bewältigen, verwendet Aether mehrere Indikatoren.
GetExtendedTcpTable für eine Ziel-PIDMODIFIED_CODE_*-Fund enthält
private_pages und region_pages, sodass das Triage die tatsächlichen Zahlen hatAether.exe --scan --pid <PID> [OPTIONEN]
Aether.exe --scan --lookup "ProcessName.exe"
Aether.exe --hunt <PID> SLEEP_MS PERIODE
Aether.exe --scan-all [OPTIONEN]
| Flag | Beschreibung |
|---|---|
--pid, -p <PID> | Ziel-Prozess-ID, die gescannt werden soll |
--lookup, -l <name> | Alle PIDs finden, die zu einem Prozessnamen passen |
--json, -j | Ergebnisse als JSON ausgeben (für SIEM-Integration) |
--verbose, -v | Detailierte Scan-Informationen pro Region anzeigen |
--scan-all, -a | Alle Prozesse scannen |
--hunt, -b <PID> [ms] [Treffer] | Verbindungen überwachen – alle ms pollen (Standard 2000), Endpunkte mit ≥ Treffer Vorkommnissen kennzeichnen |
--networking | Netzwerküberwachungsmodus |
--rules, -r <Verz> | Regelverzeichnis (Standard: rules/) |
--config, -c <Datei> | Einzelne Regeldatei (Legacy-Format) |
--dump, `` | Bestimmte Speicherregion mit benutzerdefinierter Größe sichern |
--read, `` | Speicherregion live im Terminal lesen |
--help, -h | Hilfe anzeigen |
git clone https://github.com/0xsp-SRD/aether
cd aether
# Debug-Build (Sicherheitsprüfungen aktiviert)
zig build
# Release-Build (kleinere, schnellere Binärdatei)
zig build -Doptimize=ReleaseSafe
# oder
zig build -Doptimize=ReleaseFast
Die erstellte ausführbare Datei liegt in zig-out/bin/Aether.exe.
Kopiere zig-out/bin/Aether.exe und das Verzeichnis rules/ auf die Ziel-Windows-Maschine,
wenn du einen zusätzlichen Signatur-Scan durchführen möchtest. Wenn der Zielprozess Administratorrechte erfordert, musst du Aether.exe mit Administratorrechten ausführen.
Win32StartAddress-Überschreibung
bei einem bereits laufenden Thread kann nur erkannt werden, wenn der Thread zufällig in einem Wait geparkt ist, wenn die Sonde ihn prüft (gleiche Einschränkung wie Moneta)Aether Community ist unter der GNU GPL v3.0 lizenziert. Kommerzielle Lizenzen sind für proprietäre oder kommerzielle Nutzung ausschließlich vom Autor erhältlich.