
Freeze è un toolkit per payload progettato per bypassare gli EDR utilizzando processi sospesi, syscall dirette e metodi di esecuzione alternativi.
Per visualizzare l'ultima versione di Freeze o per inviare un problema, fai riferimento a https://github.com/Tylous/Freeze.
Se vuoi saperne di più sulle tecniche utilizzate in questo framework, dai un'occhiata al SourceZero Blog
Freeze è uno strumento di creazione di payload utilizzato per aggirare i controlli di sicurezza EDR ed eseguire shellcode in modo furtivo. Freeze utilizza molteplici tecniche non solo per rimuovere gli hook EDR in userland, ma anche per eseguire shellcode in modo tale da aggirare altri controlli di monitoraggio degli endpoint.
Quando un processo viene creato, Ntdll.dll è la prima DLL caricata. Questo avviene prima che qualsiasi DLL EDR venga caricata. Ciò significa che c'è un piccolo ritardo prima che un EDR possa essere caricato e iniziare a hooking e modificare l'assembly delle DLL di sistema. Osservando le syscall di Windows in Ntdll.dll, possiamo vedere che nulla è ancora hookato. Se creiamo un processo in stato di sospensione (uno congelato nel tempo), possiamo vedere che nessun'altra DLL viene caricata, tranne Ntdll.dll. Si può anche notare che nessuna DLL EDR è caricata, il che significa che le syscall situate in Ntdll.dll sono non modificate.
Per utilizzare questo processo sospeso pulito per rimuovere gli hook dal loader Freeze, abbiamo bisogno di un modo per trovare e leggere programmaticamente la memoria del processo sospeso pulito. È qui che entra in gioco la randomizzazione del layout dello spazio degli indirizzi (ASLR). ASLR è un meccanismo di sicurezza per prevenire vulnerabilità basate sulla corruzione della memoria dello stack. ASLR randomizza lo spazio degli indirizzi all'interno di un processo, per garantire che tutti gli oggetti mappati in memoria, lo stack, l'heap e il programma eseguibile stesso siano unici. Ora, questo diventa interessante perché mentre ASLR funziona, non funziona per il codice indipendente dalla posizione come le DLL. Quello che succede con le DLL (in particolare le DLL di sistema note) è che lo spazio degli indirizzi viene randomizzato una volta all'avvio. Ciò significa che non abbiamo bisogno di enumerare le informazioni di un processo remoto per trovare l'indirizzo base della sua ntdll.dll perché è lo stesso in tutti i processi, incluso quello che controlliamo. Poiché l'indirizzo di ogni DLL è lo stesso per ogni avvio, possiamo ottenere queste informazioni dal nostro stesso processo e non dover mai enumerare il processo sospeso per trovare l'indirizzo.
Con queste informazioni, possiamo usare l'API ReadProcessMemory per leggere la memoria di un processo. Questa chiamata API è comunemente associata alla lettura di LSASS come parte di qualsiasi attacco basato sulle credenziali; tuttavia, di per sé non è intrinsecamente dannosa, specialmente se stiamo leggendo solo una sezione arbitraria di memoria. L'unica volta in cui ReadProcessMemory verrà segnalata come parte di qualcosa di sospetto è se stai leggendo qualcosa che non dovresti (come il contenuto di LSASS). I prodotti EDR non dovrebbero mai segnalare il fatto che ReadProcessMemory sia stata chiamata, poiché ci sono usi operativi legittimi per questa funzione e comporterebbe molti falsi positivi.
Possiamo fare un ulteriore passo avanti leggendo solo una sezione di Ntdll.dll dove sono memorizzate tutte le syscall - la sua sezione .text, invece di leggere l'intera DLL.
Combinando questi elementi, possiamo ottenere programmaticamente una copia della sezione .text di Ntdll.dll per sovrascrivere la nostra esistente sezione .text hookata prima di eseguire lo shellcode.
ETW utilizza syscall integrate per generare questa telemetria. Poiché ETW è anche una funzionalità nativa integrata in Windows, i prodotti di sicurezza non hanno bisogno di "hookare" le syscall ETW per accedere alle informazioni. Di conseguenza, per prevenire ETW, Freeze patcha numerose syscall ETW, svuotando i registri e riportando il flusso di esecuzione all'istruzione successiva. Il patching di ETW è ora predefinito in tutti i loader.
Poiché solo Ntdll.dll viene ripristinata, tutte le successive chiamate per eseguire lo shellcode devono risiedere in Ntdll.dll. Utilizzando Go (nota che puoi farlo in altri linguaggi ma in Go è piuttosto facile da implementare) possiamo definire e chiamare le syscall NT necessarie per allocare, scrivere e proteggere lo shellcode, saltando efficacemente le chiamate standard che si trovano in kernel32d.dll e Kernelbase.dll, poiché potrebbero essere ancora hookate.
Freeze è stato sviluppato in Golang.
Per installare Freeze, esegui i seguenti comandi, oppure utilizza il binario compilato:
go build Freeze.go
___________
\_ _____/______ ____ ____ ________ ____
| __) \_ __ \_/ __ \_/ __ \\___ // __ \
| \ | | \/\ ___/\ ___/ / /\ ___/
\___ / |__| \___ >\___ >_____ \\___ >
\/ \/ \/ \/ \/
(@Tyl0us)
Soon they will learn that revenge is a dish... best served COLD...
Usage of ./Freeze:
-I string
Percorso per lo shellcode raw a 64 bit.
-O string
Nome del file di output (es. loader.exe o loader.dll). In base all'estensione del file definita, si determina se Freeze crea una dll o un exe.
-console
Solo per payload binari - Genera informazioni dettagliate nella console quando il payload viene eseguito. Questo disabilita la funzionalità di finestra nascosta.
-encrypt
Crittografa lo shellcode utilizzando la crittografia AES 256
-export string
Solo per loader DLL - Specifica una specifica funzione di esportazione che un loader deve avere.
-process string
Il nome del processo da generare. Questo processo deve esistere in C:\Windows\System32\. Esempio 'notepad.exe' (predefinito "notepad.exe")
-sandbox
Abilita l'evasione della sandbox verificando:
L'endpoint è unito a un dominio?
L'endpoint ha più di 2 CPU?
L'endpoint ha più di 4 GB di RAM?
-sha256
Fornisce il valore SHA256 dei loader (utile per il tracciamento)
Freeze può generare file .exe o .dll. Per specificarlo, assicurati che l'opzione della riga di comando -O termini con .exe per i binari o .dll per le DLL. Nessun altro tipo di file è attualmente supportato. Nel caso di file DLL, Freeze può anche aggiungere funzionalità di esportazione aggiuntive. Per farlo, usa -export con il nome specifico della funzione di esportazione.
Freeze utilizza una tecnica per creare prima il processo e poi spostarlo in background. Questo fa due cose: prima aiuta a mantenere il processo nascosto, e secondo, evita di essere rilevato da qualsiasi prodotto EDR. Generare un processo direttamente in background può essere molto sospetto e un indicatore di dannosità. Freeze fa questo chiamando le funzioni Windows 'GetConsoleWindow' e 'ShowWindow' dopo che il processo è stato creato e gli hook dell'EDR sono caricati, e poi cambia gli attributi della finestra in nascosti. Freeze utilizza queste API invece di usare i tradizionali -ldflags -H=windowsgui, poiché questo è altamente firmato e classificato nella maggior parte dei prodotti di sicurezza come Indicatore di Compromissione.
Se l'opzione della riga di comando -console è selezionata, Freeze non nasconderà il processo in background. Invece, Freeze aggiungerà diversi messaggi di debug che mostrano cosa sta facendo il loader.
Un ringraziamento speciale a aahmad097 per aver sviluppato AlternativeShellcodeExec
Un ringraziamento speciale a mvdan per aver sviluppato Garble