Rilevamento dell'iniezione di una DLL riflettente

Question

Rilevamento dell'iniezione di una DLL riflettente

#1 da (8 voti)
#2 da (2 voti)
#3 da (0 voti)
#4 da (0 voti)

15

Negli ultimi anni, il malware (e alcuni strumenti di pen-test come il payload del metrometro di Metasploit) hanno iniziato a usare injection DLL riflettente (PDF) per caricare una DLL nella memoria di un processo. Il vantaggio è che il file non viene mai scritto su disco ed è difficile da rilevare. Molti esempi che ho visto si basano su lavoro di Joachim Bauch .

Tuttavia, in DEF CON 20 Andrew King ha dimostrato di essere in grado di rilevare La DLL viene iniettata mediante l'iniezione di una DLL riflettente . La sua presentazione è stata chiamata " Rilevazione dell'iniezione riflessa ". ~~Sfortunatamente, non ha rilasciato il codice sorgente (che non è assolutamente obbligato a fare).~~

UPDATE: Apparently I missed it, but Andrew did open-source this work a couple years ago: https://github.com/aking1012/dc20

Inoltre, uno strumento chiamato " Antimeter " è in grado di rilevare il motore meterpreter quando viene caricato mediante iniezione di dll riflettente. Di nuovo, closed source.

Capisco che lo strumento di Andrew King e Antimeter sono entrambi scritti in Python e usano pydbg / pydasm per enumerare la memoria degli eseguibili in esecuzione.

Qualcuno ha qualche codice sorgente generale (in Python o in altro modo) che è disposto a condividere e dimostra come rilevare l'iniezione di una DLL riflessiva? Esistono strumenti forensi di memoria che possono analizzare un dump di memoria e trovarlo, ma sto cercando di eseguire un'applicazione su un sistema in esecuzione (come fa l'antimeter) e trovare processi con DLL riflessivamente iniettate.

Se sei interessato a capire come funziona l'iniezione riflessiva di DLL, c'è qualche codice open source scritto in Delphi che mostra come fare questo.

UPDATE : ho testato e posso in modo riflessivo iniettare DLL senza diritti di amministratore (e come utente normale), ma naturalmente come utente posso solo iniettare in processi eseguiti allo stesso livello di integrità ( e nella mia sessione) ... ma copre ancora applicazioni come la suite Office, Internet Explorer, ecc.

windows malware antimalware injection metasploit

posta Mick 28.09.2012 - 17:25

fonte

4 risposte

Leggi altre domande sui tag windows malware antimalware injection metasploit

Crittografia dei dati utente tramite password e password dimenticata Best practice nell'autenticazione della sicurezza delle applicazioni Web per evitare attacchi bruteforce

score 8 · Answer 1

Considera cosa è l'iniezione riflessiva della DLL: si sfrutta un'applicazione per ottenere l'esecuzione di codice arbitrario e questo codice shell carica una DLL in memoria come un blob di dati (tutto il codice di shell standard fino ad ora ...) e poi dà esegue tale che la DLL si carica correttamente come una DLL tramite un caricatore PE. Lo scopo di questa intera idea: Permette di scrivere un'applicazione completa che può compilare una DLL in una lingua a tua scelta invece di scrivere l'intero malware come codice assembly con offset di memoria fissi.

Quindi, per rilevare, si desidera cercare un file PE che esiste solo in memoria e non sul disco e che contiene codice in esso. Quindi scannerizza i BLOB di memoria eseguibili per cose che sembrano file PE, ma non sono associati a nessun file su disco. Questo può essere fatto come una scientifica post-sfruttamento. Oppure, se si desidera rilevare chiamate hook in tempo reale normalmente associate a Reflective DLL Injection, ad esempio LoadLibrary, GetProcAddress e VirtualAlloc, ed eseguire il passaggio precedente con più intelligenza. Vedi ambuships.com

score 2 · Answer 2

So che è piuttosto vecchio, ma lo aggiungo ad altri che potrebbero trovarlo in futuro.

Le tecniche, come camminare sull'albero VAD, possono essere utili per trovare le DLL riflessivamente iniettate, purché non abbiano usato tecniche anti-forensi specifiche per coprire le loro tracce in quest'area. C'è un documento forense su questo dal 2007 ( PDF ) che potrebbe essere utile per il futuro cerca di individuarli.

Il rilevamento non è così semplice come per esempio guardare l'elenco dei moduli caricati in un processo 'PEB (Process Environment Block, con cui la DLL riflettente non viene registrata); tuttavia, con un buon riferimento incrociato e tali strumenti potrebbero invece effettuare un rilevamento utilizzando l'albero VAD. L'albero VAD può essere trovato nel blocco EPROCESS del processo (memorizzato nello spazio di sistema).

score 0 · Answer 3

Ho scritto uno strumento (in C # e PowerShell utilizzando la reflection) che gestisce gli stack di thread e segnala dove vengono caricati i richiami di funzioni da GetMappedFile. Mostra da dove vengono eseguite tutte le funzioni (cioè quale DLL e dove sul disco) se la proprietà MappedFile è vuota, molto probabilmente caricata in modo riflessivo;) link

score 0 · Answer 4

Ho fatto parte di un grande prodotto per la sicurezza. Con VAD che cammina nella modalità kernel ma anche con l'aiuto di una funzione per rilevare il thread remoto.

In primo luogo si rileva il thread remoto per ottenere la posizione di memoria. Il thread inserito avrà per lo più un indirizzo iniziale che non è in alcun modulo caricato dall'applicazione. Non è detto che ciò accada, dopo di che puoi andare indietro nella memoria e rilevare l'intestazione PE o la sezione IAT / EAT, questo può aiutare a localizzare dove viene iniettato il codice malvagio