Discussione Come usare al 100% il potere di Metasploit contro ogni AV esistente [Meterpreter ft. VNC]

[Netcat]

Questo thread delinea il metodo per prendere il controllo totale di un'infrastruttura informatica, ma non come attuarlo per davvero (ciò che spiego in questo thread è fattibile solo in lab). Molti AV moderni per Microsoft Windows, possiedono una feature anti-tempering, che impedisce all'end-user di spegnerli o chiuderli tramite Task Manager, o da Terminal. Questa feature di sicurezza è molto importante, perché previene l'arresto anomalo dell'AV anche da parte di un hacker. Questo thread enumera i passi da compiere per mettere a tacere ogni AV esistente, ma mi concentrerò maggiormente su Avast:

1. Meterpreter payload con msfvenom (msfvenom -p windows/meterpreter/reverse_tcp);
2. Carica il payload sul target device e ottieni la sessione;
   
   
3. Crea con msfvenom un payload che ti restituisce una sessione di VNC (GUI access con write/read permissions), caricalo sul target device tramite il comando "upload" ed eseguilo. Questo tipo di payload vi permetterà di ottenere una sessione VNC illegale sul target device (illegale perché le sessioni VNC regolari prevedono lo scambio di chiavi crittografate, e altre conferme fra i due utenti interconnessi);
   
   
4. Prepara VNC Viewer sul tuo terminal per ricevere la sessione;
   
   
5. Avast, nel momento in cui si tenta di disabilitarlo, presenta all'user un'overlay anti-VNC. Significa che da una sessione VNC non è possibile visualizzare il banner in cui chiede la conferma per disattivarsi. Se si tenta di farlo, la sessione VNC si blocca, e bisognerà farla ripartire;
   
   
6. Apri le impostazioni di Avast dalla sessione VNC "illegale", e aggiungi alle eccezioni tutti gli ".exe" e i ".dll", presentandoli come una stringa scritta nel seguente modo "C:\*.exe" e "C:\*.dll". In questo modo, tutti gli .exe e i .dll saranno aggiunti alle eccezioni.

Si tratta di una tecnica di "tampering" e non di evasione. In uno scenario reale, tuttavia, è difficilmente attuabile per i seguenti motivi:

1. Le Shell VNC ti rendono "Dio" (su Microsoft Windows) a causa della strafalcioneria dei developers, che lo centralizzano su una maledetta GUI.
   Tuttavia, lanciare quest'attacco senza farsi scoprire è molto difficile, perché chiunque è dall'altra parte vedrà le finestre aprirsi "da sole", con tanto di cursore "automatico";
   
   
2. Gli AV si arrabbiano moltissimo (soprattutto al runtime) se vedono un file che da un click fa partire una connessione VNC. Rendere "FUD" un payload che hosta VNC, è stato molto più difficile rispetto a quando lavoravo con i payload che hostano una semplice shell;

FINE

 

[☣ᴋɪʟʟ ꜰᴏʀ ᴛʜᴇ ᴛʜʀɪʟʟ☣]

Ho notato svariate sessioni di ignari Windows user su Shodan, affetti da questo tipo di RAT artigianali che sfruttano il protocollo VNC e sono anche mediamente persistenti. Non quanto un APT ben strutturato, con molte linee di codice, varie intersezioni, uso complesso di librerie avanzate, etc., ma insomma, ho visto gli stessi host online per quasi una settimana.

Il punto che trovo geniale e li rende veri e propri Remote Administration Tools è che gli altri users possono solo collegarsi in VNC ed osservare tutto ciò che avviene sull'endpoint affetto, ma assolutamente NON inviare comandi neanche base del VNC client e nemmeno di altro tipo per amministrazione remota.