Setacciare Windows per la Persistenza
Cos'è?
Trawler è uno script PowerShell progettato per aiutare gli Incident Responder a scoprire potenziali indicatori di compromissione su host Windows, focalizzato principalmente su meccanismi di persistenza tra cui Attività pianificate, Servizi, Modifiche al Registro di sistema, Elementi di avvio, Modifiche ai binari e altro ancora.
Attualmente, trawler è in grado di rilevare la maggior parte delle tecniche di persistenza specificamente indicate da MITRE e Atomic Red Team, con rilevamenti aggiunti regolarmente.
Caratteristiche principali
- Scansione del sistema operativo Windows per una varietà di tecniche di persistenza (elencate di seguito)
- Output CSV con tecnica MITRE e metadati di avvio dell'indagine
- Documentazione di guida all'analisi e alla correzione (https://github.com/joeavanzato/Trawler/wiki/Analysis-and-Remediation-Guidance)
- Assegnazione dinamica del rischio per ogni rilevamento
- Liste di autorizzazione integrate per configurazioni Windows comuni (Windows 10/Server 2012|2016|2019|2022) per ridurre il rumore
- Acquisizione di metadati di persistenza da un'immagine aziendale 'golden' (snapshot) per utilizzarli come lista di autorizzazione dinamica in fase di esecuzione
- Analisi di immagini disco montate tramite re-targeting dell'unità
Come si usa?
Basta scaricare ed eseguire trawler.ps1 da un prompt PowerShell/cmd amministrativo: tutti i rilevamenti verranno visualizzati nella console e scritti in un CSV ('detections.csv') nella directory di lavoro corrente. Il CSV generato conterrà Nome Rilevamento, Fonte, Rischio, Metadati e la relativa tecnica MITRE.
Oppure usa questo one-liner da un terminale PowerShell amministrativo:
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/joeavanzato/Trawler/main/trawler.ps1'))
Alcuni rilevamenti hanno liste di autorizzazione integrate per aiutare a rimuovere il rumore dalle configurazioni Windows predefinite (10/2016/2019/2022) - attività pianificate, servizi, ecc. previsti. Naturalmente, è sempre possibile che gli aggressori li dirottino direttamente e si mascherino con grande dettaglio come un processo predefinito del sistema operativo - fare attenzione a utilizzare più forme di analisi e rilevamento quando si ha a che fare con avversari esperti.
Se hai esempi o idee per rilevamenti aggiuntivi, sentiti libero di inviare una Issue o una PR con i dettagli tecnici/riferimenti pertinenti - la base di codice è un po' disordinata al momento e verrà ripulita nel tempo.
Inoltre, se identifichi falsi positivi evidenti, fammelo sapere aprendo un'issue o una PR su GitHub! I colpevoli più probabili per questo saranno COM, servizi o attività non standard.
Parametri CLI
-scanoptions : Tab-through for possible detections and select a sub-set using comma-delimited terms (eg. .\trawler.ps1 -scanoptions Services,Processes) or skip to do all detections
-quiet : Suppress Detection output to console
-snapshot : Path to a previous trawler JSON output to use as an allow-list.
-outpath : Define a custom file-path for saving detection output to (defaults to "$PSScriptRoot\detections.csv")
-drivetarget : Define the variable for a mounted target drive (eg. .\trawler.ps1 -targetdrive "D:") - (defaults to local system)
-daysago : Define how many 'days back' we want to take into consideration for time-based detections (defaults to 45)
-hashmode : Define which hashing algorithm we want to use for supported detections - supports sha1, md5 or sha256 (defaults to sha1)
-evtx : Enable creation of Event Log Source and Writing of Detections to Application event log under Source=trawler with EID=9001 (default is disabled)
Cosa differenzia questo da PersistenceSniper?
PersistenceSniper è uno strumento fantastico - l'ho usato pesantemente in passato - ma ci sono alcuni punti chiave che differenziano queste utility
- trawler è (attualmente) un'utilità locale - sarebbe abbastanza semplice avvolgerlo in un ciclo e utilizzare sessioni WinRM/PowerShell per eseguirlo su host remoti, comunque
- trawler implementa l'allow-listing per molti rilevamenti 'rumorosi' per aiutare a rimuovere rilevamenti previsti dalle configurazioni predefinite di Windows (10/2016/2019/2022) e questi vengono costantemente aggiornati (anche PS lo fa)
PersistenceSniper (per la maggior parte) non contiene alcun tipo di allow-listing - quindi, c'è più rumore generato quando si considerano elementi come Servizi, Attività pianificate, scansione generale di DLL COM, ecc.
- l'output di trawler è semplificato - Nome, Rischio, Fonte, Tecnica MITRE e Metadati sono gli unici elementi forniti per ogni rilevamento per aiutare gli analisti a dare il via ai loro sforzi di caccia alla persistenza - questa è un'arma a doppio taglio.
- Le espressioni regolari sono utilizzate in molti controlli per aiutare a rilevare parole chiave o pattern 'sospetti' in diverse aree critiche, inclusi i contenuti dei file scansionati, i valori del registro, ecc. Questo offre un po' più di flessibilità ma anche un tasso di falsi positivi potenzialmente più elevato.
- trawler supporta il 'drive-retargeting' per controllare macchine morte montate su una macchina di analisi.
Nel complesso, questi strumenti sono estremamente simili ma affrontano il problema da angolazioni leggermente diverse - PersistenceSniper fornisce tutte le informazioni all'analista per la revisione, mentre Trawler cerca di limitare ciò che viene restituito ai soli risultati che probabilmente sono potenziali meccanismi di persistenza avversari. Di conseguenza, c'è la possibilità di falsi negativi con trawler se un avversario imita completamente un elemento presente nella lista di autorizzazione.
Ad esempio - PersistenceSniper restituirà tutti i servizi Windows 'non sicuri' mentre trawler restituirà solo quelli che corrispondono a una regola di rilevamento specifica, ecc.
Ottimizzazione per il tuo ambiente
Trawler supporta il caricamento di una lista di autorizzazione da un 'snapshot' - per farlo sono necessari due passaggi.
- Eseguire '.\trawler.ps1 -snapshot' su un' "Immagine Golden" che rappresenta i server nel tuo ambiente - una volta completato, oltre al file 'detections.csv' standard, verrà generato un file denominato 'snapshots.csv'
- Questo file può quindi essere usato come input per trawler quando viene eseguito su altri host e i dati verranno caricati dinamicamente come lista di autorizzazione per ogni rilevamento appropriato
- '.\trawler.ps1' -loadsnapshot "path\to\snapshot.csv"
Ecco fatto - tutti i rilevamenti pertinenti attingeranno quindi dal file snapshot come lista di autorizzazione per ridurre il rumore e identificare eventuali modifiche all'immagine di base che potrebbero essere avvenute.
(L'allow-listing è implementata per la maggior parte dei controlli ma non per tutti - ancora in fase di implementazione attiva)
Re-targeting dell'unità
Spesso durante un'indagine, gli analisti possono finire per montare una nuova unità che rappresenta un dispositivo Windows clonato - Trawler ora supporta parzialmente la scansione di queste unità montate attraverso l'uso del parametro '-drivetarget'.
In fase di esecuzione, Trawler reindirizzerà le variabili temporanee a livello di script per l'uso nel controllo degli artefatti basati su file e tenterà anche di caricare i relativi hive del registro (HKLM\SOFTWARE, HKLM\SYSTEM, NTUSER.DAT, USRCLASS.DAT) sotto HKLM/HKU e preceduti da 'ANALYSIS_'. Trawler tenterà anche di scaricare questi hive caricati temporaneamente al completamento dello script.
Ad esempio, se hai un'immagine montata in un percorso come 'F:\Test' che contiene il file system NTFS ('F:\Test\Windows', 'F:\Test\User', ecc.) allora puoi invocare trawler come segue;
.\trawler.ps1 -drivetarget "F:\Test"
Nota che poiché trawler tenta di caricare i file degli hive del registro dall'unità in questione, mappare un percorso UNC a un dispositivo remoto attivo NON funzionerà poiché quei file non saranno accessibili a causa dei blocchi di sistema. Sto lavorando a un approccio che gestirà i dispositivi remoti attivi, rimanete sintonizzati.
Cosa non viene ispezionato durante il re-targeting dell'unità?
- Processi in esecuzione
- Connessioni di rete
- DLL 'Phantom'
- Consumatori WMI (in lavorazione)
- Processi BITS (in lavorazione)
- Analisi dei certificati (in lavorazione)
La maggior parte degli altri controlli funzionerà correttamente perché sono basati interamente sulla lettura di hive del registro o artefatti basati su file (o possono essere convertiti per farlo, come la lettura diretta dell'XML delle attività invece dell'uso di cmdlet integrati).
Eventuali limitazioni nei controlli durante il re-targeting dell'unità saranno discusse più approfonditamente nel Wiki di GitHub.
Immagini di esempio
Cosa viene ispezionato?
- Attività pianificate
- Utenti
- Servizi
- Processi in esecuzione
- Connessioni di rete
- Consumatori di eventi WMI (riga di comando/script)
- Rilevamento degli elementi di avvio
- Rilevamento dei processi BITS
- Modifiche alle funzionalità di accessibilità di Windows
- Esistenza del profilo PowerShell
- Documenti affidabili di Office
- Componenti aggiuntivi di Office da posizioni attendibili
- Monitoraggio di SilentProcessExit
- Hijacking della DLL Helper di Winlogon
- Hijacking delle opzioni di esecuzione dei file immagine
- Shadowing RDP
- Impostazione UAC per sessioni remote
- DLL del monitor di stampa
- Hijacking del pacchetto di sicurezza e autenticazione LSA
- DLL del provider di tempo
- DLL del processore di stampa
- Active Setup di avvio/accesso
- Hijacking dello script di accesso per l'inizializzazione dell'utente
- Hijacking dell'eseguibile dello screensaver
- DLL di Netsh
- DLL di AppCert
- DLL di AppInit
- Shimming delle applicazioni
- Hijacking degli oggetti COM
- Hijacking della notifica LSA
- Utilizzo di 'Office test'
- Utilizzo di Office GlobalDotName
- Hijacking della DLL dei servizi terminal
- Hijacking della DLL Autodial
- Abuso del processore Command AutoRun
- Hijacking di Outlook OTM
- Hijacking del provider di trust
- Scansione delle destinazioni LNK (termini sospetti, estensioni multiple, EXE multipli)
- Nomi di DLL Windows 'Phantom' caricati in processi in esecuzione (es. WptsExtensions.dll non firmata)
- Scansione delle directory critiche del sistema operativo per EXE/DLL non firmati
- Hijacking del percorso di servizio non quotato
- Hijacking dei binari PATH
- Hijacking di associazioni di file comuni e parole chiave sospette
- Caccia ai certificati sospetti
- Rilevamento/scansione di script GPO
- Sovrascritture DLL della piattaforma di sviluppo NLP
- Sostituzioni di debug AeDebug/.NET/Script/Process/WER
- 'Load' di Explorer
- Hijack di startOnUserLogin del terminale Windows
- Disallineamenti dei percorsi delle app
- Disallineamenti di DLL/ImagePath dei servizi
- DLL delle estensioni GPO
- Potenziali hijack COM
- Estensioni LSA non standard
TODO
Tecniche MITRE Valutate
Tieni presente che alcune di queste sono (ovviamente) più rilevate di altre - ad esempio, non stiamo rilevando tutte le possibili modifiche al registro, ma stiamo ispezionando determinate chiavi per modifiche evidenti e utilizzando la tecnica MITRE generica "Modify Registry" dove non è applicabile nessun'altra tecnica. Per altri elementi come l'hijacking COM, stiamo ispezionando tutte le voci nella sezione del registro pertinente, controllando rispetto a pattern 'noti come sicuri' e facendo emergere valori sconosciuti o non corrispondenti, ottenendo una superficie di rilevamento molto più completa per quella particolare tecnica.
- T1037: Script di inizializzazione dell'avvio o dell'accesso
- T1037.001: Script di inizializzazione dell'avvio o dell'accesso: Script di accesso (Windows)
- T1037.005: Script di inizializzazione dell'avvio o dell'accesso: Elementi di avvio
- T1055.001: Iniezione di processi: Iniezione di libreria a collegamento dinamico
- T1059: Interprete di comandi e script
- T1071: Protocollo a livello applicativo
- T1098: Manipolazione dell'account
- T1112: Modifica del registro
- T1053: Attività/processo pianificato
- T1136: Creazione account
- T1137.001: Applicazione Office Macro modello Office
- T1137.002: Avvio applicazione Office: Test di Office
- T1137.006: Avvio applicazione Office: Componenti aggiuntivi
- T1176: Estensioni del browser
- T1197: Processi BITS
- T1505.005: Componente software del server: DLL dei servizi terminal
- T1543.003: Creazione o modifica di un processo di sistema: Servizio Windows
- T1546: Esecuzione attivata da evento
- T1546.001: Esecuzione attivata da evento: Modifica dell'associazione di file predefinita
- T1546.002: Esecuzione attivata da evento: Screensaver
- T1546.003: Esecuzione attivata da evento: Sottoscrizione di eventi WMI
- T1546.007: Esecuzione attivata da evento: DLL Helper di Netsh
- T1546.008: Esecuzione attivata da evento: Funzionalità di accessibilità
- T1546.009: Esecuzione attivata da evento: DLL AppCert
- T1546.010: Esecuzione attivata da evento: DLL AppInit
- T1546.011: Esecuzione attivata da evento: Shimming delle applicazioni
- T1546.012: Esecuzione attivata da evento: Iniezione di opzioni di esecuzione dei file immagine
- T1546.013: Esecuzione attivata da evento: Profilo PowerShell
- T1546.015: Esecuzione attivata da evento: Hijacking del modello a oggetti dei componenti
- T1547.002: Esecuzione automatica all'avvio o all'accesso: Pacchetti di autenticazione
- T1547.003: Esecuzione automatica all'avvio o all'accesso: Provider di tempo
- T1547.004: Esecuzione automatica all'avvio o all'accesso: DLL Helper di Winlogon
- T1547.005: Esecuzione automatica all'avvio o all'accesso: Provider di supporto per la sicurezza
- T1547.009: Esecuzione automatica all'avvio o all'accesso: Modifica dei collegamenti
- T1547.012: Esecuzione automatica all'avvio o all'accesso: Processori di stampa
- T1547.014: Esecuzione automatica all'avvio o all'accesso: Active Setup
- T1553: Sovvertimento dei controlli di trust
- T1553.004: Sovvertimento dei controlli di trust: Installazione del certificato radice
Riferimenti
Questo strumento non esisterebbe senza la fantastica community InfoSec - i riferimenti più notevoli che ho utilizzato sono forniti di seguito.
Ulteriori Riferimenti