optiv/ivyIvy è un framework per la creazione di payload per l'esecuzione di codice sorgente VBA (macro) arbitrario direttamente in memoria. Il loader di Ivy fa questo utilizzando l'accesso programmatico nell'ambiente degli oggetti VBA per caricare, decrittare ed eseguire shellcode.
Per visualizzare l'ultima versione di Ivy o per segnalare un problema, fare riferimento a https://github.com/Tylous/Ivy.
Se vuoi saperne di più sulle tecniche utilizzate in questo framework e sulle misure difensive per proteggerti, dai un'occhiata all'Articolo.
Ivy è un framework per la creazione di payload per l'esecuzione di codice sorgente VBA (macro) arbitrario in memoria. Il loader di Ivy fa questo abusando dell'accesso programmatico nell'ambiente oggetto VBA per caricare, decifrare ed eseguire shellcode. Questa tecnica è il più vicino possibile a essere veramente senza file, poiché la maggior parte degli attacchi senza file oggi richiedono qualche tipo di file depositato su disco, bypassando così le regole standard basate su firme per il rilevamento del codice VBA. I payload VBA tipici hanno le seguenti caratteristiche:
Eseguendo puramente in memoria, queste caratteristiche comportamentali rendono più difficile essere rilevati dagli EDR.
I loader di Ivy sono crittografati usando la crittografia RC4 (la crittografia AES causa molto gonfiore e impiega un'eternità per essere decifrata da VBA) e poi suddivisi in stringhe separate, impedendo a qualsiasi sandbox di riconoscere queste stringhe come stringhe crittografate che dovrebbero essere investigate. Questo impedisce anche a qualsiasi meccanismo di decodifica di riconoscere questi payload come altro che caratteri spazzatura.
Il loader di Ivy esegue prima una query di registro per abilitare "Trust access to the VBA project object mode". Questo valore di chiave di registro viene memorizzato in modalità utente, permettendo all'utente di modificare il valore senza richiedere permessi elevati. Il valore del registro viene impostato da zero a 1; se la chiave di registro non esiste, Ivy la creerà con un valore di "1". Con questo valore abilitato, è consentito l'accesso programmatico all'ambiente oggetto VBA da un processo diverso.
Una volta fatto ciò, il loader avvierà un processo Excel nascosto e caricherà le stringhe crittografate in una funzione VBA. Questo viene fatto utilizzando ActiveX per simulare le azioni GUI dello stesso compito. Questo aiuta a bypassare molti controlli tradizionali in atto per monitorare l'esecuzione. Di conseguenza, la funzione di decifratura e lo shellcode vengono spostati da un buffer di memoria all'altro, senza mai toccare il disco. Infine, il loader utilizza chiamate command-GUI ed esegue la funzione run, che simula l'atto di cliccare sul pulsante di esecuzione macro nel pannello GUI di VBA, iniziando la funzione di decifratura, seguita dall'effettiva esecuzione dello shellcode.
IMPORTANTE
L'endpoint di destinazione deve avere Microsoft Office installato e attivato per funzionare perché Ivy si basa sull'abuso dell'accesso programmatico all'ambiente VBA di Microsoft Office.
Questo permette a Ivy di utilizzare chiamate di sistema di basso livello per costruire la propria versione della funzione Windows WriteProcessMemory, facendo riferimento indirettamente all'indirizzo di memoria diretto e ai valori dei registri. Ivy può sovrascrivere sezioni di memoria che non sono scrivibili senza chiamare alcuna funzione API di modifica della memoria. Questo è possibile grazie a una caratteristica di WriteProcessMemory che modifica temporaneamente i permessi della regione di memoria per renderla scrivibile (se si dispone di privilegi sufficienti, che abbiamo poiché possediamo il processo). Scrive il valore e ripristina i permessi originali senza chiamare la funzione VirtualProtect, ma chiama automaticamente la syscall associata (NtProtectVirtualMemory).
Ivy non utilizza una propria versione di NtWriteVirtualMemory perché questo processo di modifica temporanea dei permessi di memoria non avverrebbe, il che significa che la protezione dell'indirizzo di memoria specifico non verrebbe modificata e l'esecuzione fallirebbe. Questa è una "funzionalità" rilasciata da Microsoft per rendere i debugger più stabili. Poiché i debugger vogliono modificare la memoria al volo, possono semplicemente modificare una sezione senza dover eseguire più operazioni. (Vedi devblogs.microsoft.com per informazioni)
Diamo un'occhiata alla serie di eventi che un EDR vedrebbe:
Una volta che tutti gli hook EDR sono stati rimossi, il loader esegue la sua normale azione per stabilire una sessione remota.
Ivy affronta ciò rimuovendo gli hook dalle DLL di sistema comuni su cui gli EDR si agganciano, tra cui:
Quando si utilizza unhook con un tipo di payload Inject, il loader di Ivy rimuoverà prima gli hook dal processo Office, liberandolo dall'EDR, e poi rimuoverà gli hook nel processo iniettato. Questo assicura che entrambi i processi siano liberi da hook, impedendo l'invio di qualsiasi telemetria dal processo padre e figlio all'EDR.
Utilizzando la stessa tecnica per rimuovere gli hook, Ivy può fare patch alle funzioni ETW, impedendo la generazione di qualsiasi evento da parte del processo. ETW utilizza syscall integrate per generare questa telemetria. Poiché ETW è una funzionalità nativa di Windows, i prodotti di sicurezza non devono "agganciare" le syscall ETW per ottenere le informazioni. Di conseguenza, per prevenire ETW, Ivy esegue patch su numerose syscall ETW, azzerando i registri e restituendo il flusso di esecuzione all'istruzione successiva. Il patching di ETW è ora predefinito in tutti i loader; se desideri non patchare ETW, usa l'opzione da riga di comando -noetw per disabilitarlo nel tuo loader.
Ivy è stato sviluppato con Go.
Il primo passo, come sempre, è clonare il repository. Prima di compilare Ivy, dovrai installare le dipendenze. Per installarle, esegui i seguenti comandi:
go get github.com/fatih/color
go get github.com/KyleBanks/XOREncryption/Go
Poi compilalo:
go build Ivy.go
$ ./Ivy -h