EXOCET-AV-Evasion

EXOCET - strumento di consegna del payload che elude l'antivirus, non rilevabile

EXOCET è superiore ai moduli "Evasive Payloads" di Metasploit poiché EXOCET utilizza AES-256 in modalità GCM (Galois/Counter Mode). I payload di evasione di Metasploit utilizzano una crittografia RC4 facile da rilevare. Mentre RC4 può decifrare più velocemente, AES-256 è molto più difficile da determinare l'intento del malware.

Tuttavia, è possibile utilizzare Metasploit per creare un payload evasivo e poi incatenarlo con EXOCET. Quindi EXOCET decifra tramite AES-256, e poi il payload evasivo di Metasploit si decifra da solo tramite RC4.

Proprio come il mio progetto precedente, DarkLordObama, questo toolkit è progettato per essere un veicolo di consegna/lancio, proprio come fa Veil-Evasion.

Progetto Dark Lord Obama

Tuttavia, EXOCET non è limitato a un singolo codebase o piattaforme che eseguono Python. EXOCET funziona su TUTTE le piattaforme e architetture supportate da Go.

Panoramica di Exocet

EXOCET, è effettivamente un dropper di malware di tipo crypter che può riciclare payload facilmente rilevabili come WannaCry, crittografarli utilizzando AES-GCM (Galois/Counter Mode), che è più sicuro di AES-CBC, e quindi creare un file dropper per la maggior parte delle architetture e piattaforme esistenti.

In pratica...

1. Ingurgita malware pericolosi che ora sono rilevabili dai motori antivirus
2. Poi li crittografa e produce il proprio file Go
3. Quel file Go può quindi essere cross-compilato per il 99% delle architetture note
4. All'esecuzione, il payload crittografato viene scritto sul disco ed eseguito immediatamente sulla riga di comando
5. In alternativa, invece di un file-drop, eseguirà il shellcode ricostituito in memoria utilizzando il modulo go-memexec di amenzhinsky github.com/amenzhinsky/go-memexec
6. Un esecutore di shellcode personalizzato è in lavorazione, prende il normale shellcode C e dopo la trasformazione numerica, lo eseguirà creando un nuovo processo dopo aver allocato il corretto spazio di indirizzi virtuali e concedendogli permessi RWX su Windows

Ciò significa architetture a 32-bit e 64-bit, e funziona su Linux, Windows, Mac, Unix, Android, iPhone, ecc. Prendi qualsiasi cosa, e intendo QUALSIASI cosa, come il Morris Worm del 1988 che quasi mandò in crash Internet (che sfruttava una falla nel demone listener fingerd su UNIX), e rendila nuovamente un'arma informatica praticabile.

EXOCET è scritto interamente in Go.

Come usarlo

EXOCET, indipendentemente dal binario che usi per eseguirlo, richiede Golang per funzionare. Di default, genera un file .go crypter.

1. Utenti Windows: Installa Go Qui
2. Utenti Linux: esegui sudo apt-get update && sudo apt-get install -y golang
3. Devi installare i file sorgente di EXOCET in golang go get github.com/tanc7/EXOCET-AV-Evasion
4. I sotto-requisiti verranno anch'essi scaricati e installati
5. Per utenti Windows e Mac x64, i binari pre-compilati si trovano nella cartella /bin

Per eseguirlo

go run EXOCET.go detectablemalware.exe outputmalware.go

Una chiave viene generata automaticamente per te. La chiave è lunga 64 caratteri ed è interamente composta da reindirizzatori di pipe di shell bash e cmd.exe per confondere e disturbare i tentativi di forza bruta contro la chiave causando comportamenti imprevedibili e distruttivi sul dispositivo dell'analista forense.

Per target Windows a 64-bit...

env GOOS=windows GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.exe outputmalware.go

E viene fuori un file outputmalware.exe

Per target MacOS a 64-bit

env GOOS=darwin GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.macho outputmalware.go

Per target Linux a 64-bit

env GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.elf outputmalware.go

Vedi questo riferimento su github per i tuoi parametri per altri sistemi operativi come Android Riferimento per la cross-compilazione di Go

Nota che la chiave può ancora essere trovata con il comando strings, per favore usa il comando upx-ucl per impacchettare il binario e nascondere la chiave.

Inoltre, ci sono binari pre-costruiti che ho creato, il che significa che devi solo eseguire ./EXOCET o EXOCET-Windows.exe

Informazioni legali

Io, Chang Tan, e i creatori del modulo principale e dei sottomoduli di Exocet e dei pacchetti che incorpora NON siamo responsabili per l'uso improprio di questo strumento. Questo è semplicemente uno strumento di penetration testing. Ti è strettamente vietato distribuire binari di output di Exocet contro sistemi protetti non autorizzati o sistemi governativi protetti non autorizzati.

Sono consapevole che attori malintenzionati di APT41 e del gruppo NSO hanno utilizzato e/o adottato codice da questo strumento, in particolare il metodo go-memexec. Se dovessi essere avvicinato da investigatori federali riguardo all'uso improprio di questo strumento, non mi assumo la responsabilità.

Questa è la stessa cosa che è successa agli sviluppatori di Mimikatz e PowerShell Empire (che hanno deprecato il proprio sviluppo dopo aver realizzato il suo uso tra gli attori malintenzionati). I successori hanno ripreso lo sviluppo di Empire, e ci sono alternative gratuite come Covenant C2.

Demo live di EXOCET

Motivo del nome

Il 4 maggio 1982, durante la Guerra delle Falkland, uno squadrone di Super Eterdard argentini lanciò un missile Exocet francese contro la HMS Sheffield. Nonostante i tentativi della Royal Navy di fermare il missile, uno colpì, affondando la Sheffield. Quell'incidente mise letteralmente l'Argentina sulla mappa come dimostrazione di forza contro una potenza coloniale globale.

Articolo di giornale sull'affondamento della HMS Sheffield

Molto simile a come le azioni di Onel de Guzman con il virus ILOVEYOU hanno messo le Filippine sulla mappa come minaccia informatica.

Virus ILOVEYOU su Wikipedia

Aggiornamento in arrivo, note e ambizioni

.png)

Quindi questo mese e il prossimo saranno mesi impegnativi per me, e ci saranno ritardi nell'implementazione di questi metodi. Ma sono entusiasta di iniziare a implementare nuove tecniche di evasione AV come...

1. Inline hooking
2. Offuscamento emulando BlackRota e il modulo gobfuscate
3. Process hollowing
4. Reflective DLL injection
5. Remote process injection
6. Callback di ThreadLocalStorage
7. Registrazione di gestori di eccezioni di alto livello
8. Impacchettamento UPX personalizzato

Sono una persona molto impegnata, ho le seguenti priorità e vorrei richiedere un po' di aiuto, alcune pull request per aiutare il progetto. Poiché ho le seguenti cose da fare

1. Una comparizione in tribunale a fine ottobre
2. National Cyber League
3. Lezioni di Contabilità e Finanza, l'Informatica NON è mai stata la mia specializzazione universitaria e nelle prossime settimane avrò esami uno dopo l'altro
4. Condizioni di rilascio sotto supervisione federale e l'FBI che cerca di coinvolgermi in nuovi crimini non provati. Ho video della dash camera caricati nel cloud per provarlo che sto inviando ai miei avvocati. Ho documentato molteplici attacchi contro di me, vandalismo alla mia auto, alla mia casa, presentato denunce alla polizia e controdenunce e sto costruendo il mio caso per intentare una causa federale. Uno dei perpetratori, che ha strappato il paraurti anteriore della mia auto, è stato arrestato.
5. Un progetto privato che coinvolge l'interazione con l'API di CoinGecko
6. Gestione di cryptoscopeinitiative.org, un'organizzazione non profit 501c3 in fase di deposito
7. Insegnamento di tre corsi online sullo sviluppo di exploit

Aggiornamento in arrivo! Esecuzione diretta di shellcode crittografato! (Implementato nelle versioni di test, non ancora rilasciato)

Ho bisogno di un po' di aiuto, perché ho implementato con successo CGO per eseguire shellcode crittografato ma sta generando violazioni di accesso alla memoria con stato di uscita 0xc0000005. Non dovrebbe essere correlato a DEP (Data Execution Prevention) perché il file CGOTest/working-template-shellcode-executor.go è effettivamente stato eseguito.

Problema scoperto

A quanto pare, VirtualAlloc deve essere chiamato da kernel32.dll e ntdll.dll per rendere correttamente la pagina di memoria dove atterra lo shellcode, leggibile, scrivibile ed eseguibile, in altre parole, impostare PAGE_EXECUTE_READWRITE su ON. Leggi la Nota sul problema di violazione di accesso alla memoria qui sotto.

Una volta risolto questo, CGO è stato un dolore da implementare, possiamo ora creare crypters che eseguono INLINE-ASSEMBLY. Che era considerato un'impossibilità fino ad ora.

Nota che ciò richiede Golang e la toolchain MinGW installata su Windows mentre esegui e generi lo shellcode su Windows. La ragione è che CGO non può essere cross-compilato come gli altri moduli di EXOCET. Per installare la toolchain devi andare su https://www.msys2.org/ e seguire la guida. Poi devi aggiungere gcc alle variabili d'ambiente di Windows

Passo 1: Genera shellcode, potrebbe essere da payload Meterpreter di msfvenom, Beacon di Cobalt Strike, o il tuo shellcode personalizzato in formato compatibile con C

Passo 2: Copia solo i byte dello shellcode, escludendo le virgolette, in un file di testo come sc.txt

Passo 3: Il tuo file di shellcode dovrebbe apparire così. Shellcode grezzo

Passo 4: Ora esegui il comando go run exocet-shellcode-exec.go sc.txt shellcodetest.go KEY

Passo 5: Puoi provare ad eseguirlo, ma incontrerai errori di violazione di accesso alla memoria per qualche motivo, su cui sto ancora lavorando

Nota sul problema di violazione di accesso alla memoria

Apparentemente, oltre ai limiti maggiori di CGO che impediscono o frustrano drasticamente la cross-compilazione, il problema è che lo shellcode che vogliamo eseguire atterra in una sezione di memoria (analizzata in WinDBG x64) che non è RWX. In altre parole, a meno che non scriviamo codice C che permetta esplicitamente l'esecuzione in memoria dello shellcode, genererà sempre errori di violazione di accesso.

L'altro metodo, che ho osservato da altri sviluppatori di moduli Go rudimentali https://gist.github.com/mgeeky/bb0fd5652b234fbd1c7630d7e5c8542d, è che usano l'API Windows di Go per interagire con ntdll.dll e kernel32.dll per chiamare VirtualAlloc e specificare aree di pagine di memoria RWX. Questo metodo funziona meglio, ma sembra che lo shellcode debba essere solo in formato trasformato numericamente per funzionare.

Sto ancora lavorando su questo, ragazzi. Potrei combinare più linguaggi di programmazione insieme per scrivere un modulo di esecuzione di shellcode appropriato

Nota sui chip Apple M1 per binari pre-compilati

Sfortunatamente sto riscontrando errori per creare un binario pre-compilato per MacBook con le nuove CPU M1. Potrebbe essere un problema con la mia installazione di Golang

In ogni caso, hai ancora bisogno di Golang per compilare o cross-compilare il malware per la piattaforma che stai targettizzando.