Aether

versione : 0.9 (versione stabile)

Aether è uno strumento di memory forensics e threat hunting per Windows che scansiona la memoria dei processi in esecuzione alla ricerca di pattern dannosi, rileva tecniche di injection, firme di implant e assembly .NET caricati in modo riflesso. Funziona con un modello di confidenza multistrato che riduce drasticamente il tasso di falsi positivi e dà la caccia a comportamenti dannosi. Aether ha buone capacità nel rilevare tecniche di Hollowing, APC e thread hijacking. Gli analisti di sicurezza possono usarlo per scansionare, cacciare e creare snapshot di regioni sospette per l'analisi offline.

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

Articoli di ricerca:

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/

Funzionalità principali

Brevi spiegazioni delle funzionalità principali di Aether; puoi leggere il post tecnico completo per maggiori approfondimenti:

Scansione delle firme

• Corrispondenza di byte-pattern nella memoria del processo con un indice di primo byte che offre un'accelerazione di 50-100x rispetto alla scansione semplice
• Doppia codifica ASCII + UTF-16LE — intercetta le stringhe memorizzate dal CLR .NET (dove "msxsl:script" diventa 6D 00 73 00 78 00 ...)
• Caricamento dinamico delle regole da file JSON — inserisci nuove firme in rules/ senza ricompilare
• Rilevamento dell'header PE nelle regioni MEM_PRIVATE — segnala assembly .NET caricati in modo riflesso (metadati MZ + PE + BSJB)

Indicatori di compromissione (IOC) strutturali della memoria

Aether applica cinque filtri sopra il segnale grezzo del working set, così un riscontro richiede più indicatori concordanti prima di essere segnalato con il filtraggio dei falsi positivi:

Altri controlli strutturali:

• Cross-reference dei moduli PEB : allocazioni MEM_IMAGE che non sono nella lista dei moduli del PEB (DLL hollowing / module stomping)
• Scansione del working set : rilevamento delle pagine di codice modificato tramite K32QueryWorkingSetEx, in batch con una sola syscall per regione invece di una per pagina da 4 KB (≈ 50-100× più veloce del loop semplice)
• Rilevamento Private RWX : segnala allocazioni MEM_PRIVATE + PAGE_EXECUTE_* (produce risultati FP) (shellcode, JIT spray, allocazioni di stub di codice dinamici)
• Sonda del prologo di hook — legge i primi 16 byte di ogni pagina di codice privata e confronta i classici trampoline x86/x64:
  • E9 ?? ?? ?? ?? — JMP rel32
  • FF 25 ?? ?? ?? ?? — JMP [rip+disp32]
  • 68 ?? ?? ?? ?? C3 — PUSH imm32 ; RET
  • 48 B8 ?? ?? ?? ?? ?? ?? ?? ?? FF E0 — MOV RAX, imm64 ; JMP RAX

Validazione dell'indirizzo di inizio dei thread (TSAV / L8)

Aether controlla i thread con una classificazione più rigorosa e una correlazione incrociata con i risultati L1–L5. Per ogni thread creato nel processo target, Aether legge il suo Win32StartAddress tramite NtQueryInformationThread e, quando i permessi lo consentono, anche il Rip / Eip live tramite GetThreadContext / Wow64GetThreadContext. Ogni indirizzo viene poi classificato come nella tabella seguente; per maggiori dettagli leggi il blog post:

Cosa rende questo più forte del semplice controllo "l'indirizzo di inizio è in un modulo":

• Controllo incrociato con VirtualQueryEx — ogni indirizzo viene interrogato per Type / Protect / AllocationBase in una singola chiamata O(1) invece di una scansione lineare dell'elenco dei moduli
• Correlazione incrociata con L1–L5 — un thread il cui inizio cade in un'allocazione già segnalata viene promosso da "OK" a TSAV_MODIFIED_HOST
• Coerenza PEB — i moduli hollowed vengono rilevati anche quando l'indirizzo di inizio ricade tecnicamente in un intervallo "reale"
• Sonda RIP sospeso — Win32StartAddress è scrivibile dal processo tramite NtSetInformationThread ed è il campo spoofabile; il Rip live di un thread sospeso è quello che un loader non può riscrivere facilmente. Confrontiamo i due e segnaliamo qualsiasi discordanza che risolva in una regione sospetta
• Consapevole di WoW64 — passa automaticamente a Wow64GetThreadContext e legge Eip per i thread a 32 bit all'interno di un processo a 64 bit
• Scaletta dei diritti di accesso — per ogni thread ripiega da → → , così gli scenari con accesso parziale producono comunque classificazioni utili

L9 + L10 - Rilevamento della tabella API nell'heap con correlazione cross-module

La risoluzione runtime delle API è una tecnica usata frequentemente dal malware. Il meccanismo di rilevamento di Aether identifica questo comportamento scansionando l'heap alla ricerca di indirizzi e puntatori validi di moduli e correlando i risultati con i criteri di filtraggio descritti di seguito:

Ogni filtro elimina una specifica classe di falsi positivi osservata nella telemetria reale:

Analisi dell'entropia ed euristiche per shellcode

Aether supporta al momento il rilevamento di pattern XOR a livello di stub e adotta l'algoritmo dell'entropia di Shannon per verificare la casualità dei valori dei byte nelle regioni di memoria; segnala tutto ciò che supera una soglia. Per gestire l'elevato numero di falsi positivi, Aether utilizza più indicatori.

Rilevamento beacon C2

• Monitoraggio delle connessioni TCP — interroga GetExtendedTcpTable per un PID target
• Rilevamento di pattern beacon — identifica connessioni periodiche di breve durata (classico comportamento di callback C2)
• Output tabellare delle connessioni — tabella console formattata con stato, endpoint, hit e protocollo

Modalità di output

• Report console colorato con evidenziazione ANSI basata sulla severità
• JSON leggibile da macchina per l'integrazione con pipeline SIEM / d-tect.py
• Output di sospetto graduato — ogni riscontro MODIFIED_CODE_* include private_pages e region_pages, così il triage ha i numeri reali
• Output formattato a tabella con caratteri Unicode box-drawing per il monitoraggio delle connessioni

Utilizzo

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

Opzioni

Come compilare

Prerequisiti

• Zig 0.16 — scarica qui
• La cross-compilazione funziona da qualsiasi sistema operativo host (Linux, macOS, Windows)

Compilazione

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

L'eseguibile compilato si trova in zig-out/bin/Aether.exe.

Distribuzione

Copia zig-out/bin/Aether.exe e la directory rules/ sulla macchina Windows target se vuoi eseguire ulteriori scansioni di firme. Se il processo target richiede privilegi amministrativi, devi eseguire Aether.exe con privilegi di amministratore.

Limitazioni

• Solo usermode — nessun driver kernel; non può rilevare rootkit o manipolazioni a livello kernel
• Solo IPv4 — il monitoraggio delle connessioni TCP non supporta per ora endpoint IPv6.
• Il diff su disco L5 richiede l'accesso al file — se il file del modulo originale è stato eliminato o è bloccato, il diff su disco salta silenziosamente quel modulo (gli altri livelli continuano comunque a funzionare)
• La lista spoof-trampoline di TSAV viene risolta nel processo dello scanner stesso — intercetta il caso comune in cui le DLL di sistema condividono una base ASLR a livello di sessione, ma potrebbe non rilevare target con basi uniche per processo (raro su Win10+)
• La sonda RIP di TSAV intercetta solo thread sospesi — una riscrittura di Win32StartAddress su un thread già in esecuzione può essere rilevata solo se il thread si trova in uno stato di attesa quando viene sondato (stesso vincolo di Moneta)
• Il rilevamento XOR-PE è basilare in questa versione

Licenza

Aether Community è concesso in licenza sotto GNU GPL v3.0. Licenze commerciali disponibili solo dall'autore per uso proprietario o commerciale.