Discussione Meterpreter evasion con Strong Microsoft Template + command Migrate AV Evasion (Python Dropper)

[Netcat]

Questa tecnica può essere impiegata in un attacco di spear-phishing, ma la parte del social engineering non viene trattata, per ragioni di sicurezza. Il thread delinea il metodo per ottenere una reverse shell che bypassa l'AV, assumendo che dietro all'end-point ci sia anche un user abbastanza sveglio da killare un processo infetto da Task Manager.

I processi infetti che hostano una reverse shell, sono un elemento critico per l'attaccante, e devono rimanere intatti. La loro chiusura, determinerà la fine della shell remota. windows/meterpreter, incorpora un comando chiamato migrate che performa l'iniezione di shellcode in un nuovo processo come workaround, supponendo che l'attaccante performi l'iniezione in un processo critico (che deve essere ON per forza) come explorer.exe o winlogon.exe. Tuttavia, quando proviamo a lanciare questo comando, si viene bullizzati, PESANTEMENTE, dalla maggior parte degli AV esistenti (anche se il payload di base aveva bypassato). Il comando migrate effettua un'injection sofisticata, ma ormai conosciuta dagli AV, a causa della sua natura open-source.

Nell'esperimento, sarà usato un file legittimo di MS Office, che hosta shellcode per windows/meterpreter/reverse_tcp. Questo file, che ha un nome arbitrario (scelta a piacere), spawnerà semplicemente nel Task Manager come "Microsoft Outlook Conflict Note", a prescindere da come viene rinominato. Questo rende difficile capire quale sia il vero nome dell'.exe che sta hostando metsvc.dll. Il punto, comunque, è che questo template può essere individuato risalendo alla descrizione del file da cui origina:

Per impedire di risalire al file originale, il deployment va eseguito attraverso un Dropper. Qui entrano in gioco le skill in Python:

Il seguente script usa urllib.request.urlretrieve, per scaricare il payload dal nostro server alla working directory del target. Sempre per ragioni di sicurezza, non viene neppure spiegato come creare un server che funziona in WAN, sperando che quelli che lanciano smbghost su Shodan si incartino qui.
Il comando os.system viene lanciato due volte:
- Nella prima istanza, os.system sposta rapidamente l'.exe infetto dalla working directory, a %TEMP%, usando "MOVE".
- Nella seconda istanza, lo script cerca l'exe spostato in %TEMP% e lo esegue, lo può eseguire indiscriminatamente sia coi privilegi dell'USER che as AUTHORITY/SYSTEM. Dipende da come il target ha eseguito lo script.

Operando in questo modo, il blue teamer di turno non può indovindare al volo cosa stia accadendo. Vedendo di aver aperto un file che non fa nulla, sospetterà di essere di fronte a un trojan, ma senza sapere che quello è solo un Dropper creato per il deployment. Il vero file è situato in %TEMP%, e presenta un nome fraintenditivo nel Task Manager, chiamandosi come un processo di MS Office. Oltre a %TEMP%, possono essere specificate altre working directories, sfruttando la variabile %USERPROFILE% in os.system. Bindando al Dropper un UAC bypass method, possono essere sfruttate in modo stealth anche altri path come C:/Windows/System32 Auguri a killarlo.

Questo metodo è un'alternativa funzionale al comando "Migrate", che usa un metodo d'injection antico come i dinosauri, e che richiede troppe rimanipolazioni per essere di nuovo funzionale all'evasion. Il metodo del dropper mette in sicurezza sia Meterpreter che la Shell di base. Oltre a urllib esistono altri metodi che potete sfruttare per il download, come curl e bitsadmin (presenti di default nelle versioni moderne di Windows, oppure Powershell Invoke-Webrequests). Quello che conta sempre e comunque, è sopprimere gli output, per evitare che dall'altra parte si insospettiscano.

Curiosità: nell'esperimento si verifica un piccolo bug di natura benevola (per l'attaccante). Il payload viene spostato dalla current working directory a %TEMP%, e così risulta. Tuttavia, usando i comandi ls e pwd, la sessione si interfaccia con la working directory dell'User, invece che con %TEMP%. Questo permette di risparmiare un pochino di tempo se la current working directory è il Desktop, dal momento che questa cartella contiene spesso sensitive-data, materiale bollente per uno shell-based trojan.

 

[JunkCoder]

Ottimo esempio di dll hijacking, il fatto che tu abbia censurato il nome dell'exe mi ha incuriosito e l'ho trovato. Questa tecnica è molto efficace anche grazie alla firma digitale originale microsoft, e lo continuerà ad essere finché l'exe in questione non diventa troppo popolare, a quel punto gli AV inizieranno a controllare la directory padre e se diversa da quella prevista dal software lanciare una detection. è anche possibile evitare la parte di dropper: nella dll malevola potresti copiare te stesso e l'exe vulnerabile, in questo modo anche il codice d'installazione risulterà firmato in processo trusted. Il contro è che non basterebbe più un file singolo, l'utente dovrà cliccare sull'exe avendo la dll nella stessa cartella.

 

[Netcat]

Sono un po' confuso sulla storia della firma digitale lo sai? L'injection ha rimosso completamente la sezione della "Digital signature" di Microsoft, tuttavia Windows quando vede questo file in particolare, si comporta ugualmente come se fosse firmato... Quando la firma non c'è più. Forse la firma è già hard-coded nel codice assembly del file?

 

[JunkCoder]

Avevo dato erroneamente per scontato usassi dll hijacking senza toccare l'exe (tramite AppV...dll), se hai inettato codice nell'exe allora si, invalidi la firma.