Hai messo a punto un attacco perfetto, che localmente funziona tutto liscio (AV sconfitto, l'exploit è stabile ecc.) ma al momento cruciale, fallisce. Semplicemente fallisce.
Forse il target ha un firewall, e dovevi istruire il tuo payload a usare una porta ritenuta notoriamente sicura, da queste applicazioni.
So che sembro un russo, ma io sono più interessato all'attacco che alla difesa (a differenza di molti), e non per ragioni nefaste.
In questa guida, ti dirò come risolvere tutti gli intoppi legati alla creazione del listener perfetto. Non dovrai più preoccuparti di un firewall, o di un tizio che vede un IP connesso ad una porta strana, e decide di scollegarsi da internet, iniziando scansioni con Avast & company. Basta che lo attacchi legalmente, senza prendere decisioni sconsiderate.
La soluzione più "umile" che viene in mente, è quella di dire al payload di sfruttare la porta 443. Questa porta, mai censurata, è la risposta a tutte le domande, il problema è che sia in Windows che nei sistemi Unix, è possibile mettere in ascolto questa porta solamente con i privilegi dell'amministratore/o di root. Mentre è facile lanciare il server con i permessi di root, non è così semplice indovinare un modo per riuscire a "bypassare" i privilegi, e mettere in ascolto la porta 443 sotto l'user corrente.
Sia nei sistemi Unix (ma anche su Windows, se non erro), ciascuna porta di valore inferiore a 1024, per ragioni di sicurezza, non può essere messa in ascolto da qualsiasi user, eccetto che "root". Per bypassare questa regola, su Unix, si usa il seguente comando:
Questa stringa, che sfrutta un tool chiamato "iptables", consente di impostare un listener sulla porta 8443 (ma si può scegliere anche un'altra porta volendo), e il traffico ricevuto sulla suddetta porta, verrà reindirizzato alla porta 443, bypassando le restrizioni, e creando un dirottamento di traffico. A questo punto, noi possiamo scrivere nel codice del nostro payload, di puntare alla porta 443 del nostro server, anche se noi tecnicamente abbiamo in ascolto la 8443. Cliccando sul PE, riceveremo una call back perfettamente funzionante, apparendo come se la connessione sia diretta effettivamente ad un canale sicuro.
Parte finale: IP whitelist bypass
Una seconda tecnica di rilevamento, è quella di trovare la presenza di un IP che ha una cattiva reputazione connesso alla propria rete. Sfruttare un IP in whitelist è fondamentale in questi casi. Anche il solo fare "esperimenti" in locale può danneggiare il proprio IP, cosa di cui non si accorgono tutti, specialmente coloro che sfruttano la propria rete di casa per "giocare" con Metasploit.
Iniziando un test anche solo con i sample di Metasploit, inserendo il nostro IP di casa nel payload, e inviandolo successivamente a Virus Total, rischiamo di compromettere la reputazione dell'IP. Infatti le detection che VT individuerà, non si limiteranno al rilevamento delle azioni fatte dal payload, ma prima o poi inizieranno a far caso anche l'indirizzo IP a cui si andrà a connettere, e in caso di rilevamento di troppi file malevoli che comunicano con quell'IP, la reputazione di quell'IP calerà. Chi ha un IP dinamico ovviamente può disinteressarsi a questo, ma comunque non raccomando di fare esperimenti con un IP dinamico, altrimenti i payload dovranno essere modificati continuamente, ogni volta che l'IP cambia.
Un secondo effetto indesiderato, dell'IP flaggato su VT, è l'impossibilità di fare AV bypass. Non importa in quanti blob di XOR poliformico vai a criptare il payload, dato che l'IP è messo male, terminerai sempre con una detection, perché il payload semplicemente comunica con un "cattivo IP". Avevo parlato più specificataente di quest'ultima parte in un vecchio thread, ma la riesumiamo.
Il metodo migliore per fare esperimenti con i sample, è l'uso di servizi esterni, come VPS. In tale modo, il nostro IP di casa non rischierà mai. Packetriot e Ngrok, ad esempio, sono due noti servizi di traffic routing che sono stati sfruttati per anni da attaccanti allo scopo di creare TCP relay con i trojan. Come risultato, questi due servizi hanno subito enormi danni reputazionali su VirusTotal, con multiple detection, e vari ricercatori di sicurezza che commentano i risultati dei report.
Forse il target ha un firewall, e dovevi istruire il tuo payload a usare una porta ritenuta notoriamente sicura, da queste applicazioni.
So che sembro un russo, ma io sono più interessato all'attacco che alla difesa (a differenza di molti), e non per ragioni nefaste.
In questa guida, ti dirò come risolvere tutti gli intoppi legati alla creazione del listener perfetto. Non dovrai più preoccuparti di un firewall, o di un tizio che vede un IP connesso ad una porta strana, e decide di scollegarsi da internet, iniziando scansioni con Avast & company. Basta che lo attacchi legalmente, senza prendere decisioni sconsiderate.
La soluzione più "umile" che viene in mente, è quella di dire al payload di sfruttare la porta 443. Questa porta, mai censurata, è la risposta a tutte le domande, il problema è che sia in Windows che nei sistemi Unix, è possibile mettere in ascolto questa porta solamente con i privilegi dell'amministratore/o di root. Mentre è facile lanciare il server con i permessi di root, non è così semplice indovinare un modo per riuscire a "bypassare" i privilegi, e mettere in ascolto la porta 443 sotto l'user corrente.
Sia nei sistemi Unix (ma anche su Windows, se non erro), ciascuna porta di valore inferiore a 1024, per ragioni di sicurezza, non può essere messa in ascolto da qualsiasi user, eccetto che "root". Per bypassare questa regola, su Unix, si usa il seguente comando:
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443Questa stringa, che sfrutta un tool chiamato "iptables", consente di impostare un listener sulla porta 8443 (ma si può scegliere anche un'altra porta volendo), e il traffico ricevuto sulla suddetta porta, verrà reindirizzato alla porta 443, bypassando le restrizioni, e creando un dirottamento di traffico. A questo punto, noi possiamo scrivere nel codice del nostro payload, di puntare alla porta 443 del nostro server, anche se noi tecnicamente abbiamo in ascolto la 8443. Cliccando sul PE, riceveremo una call back perfettamente funzionante, apparendo come se la connessione sia diretta effettivamente ad un canale sicuro.
Parte finale: IP whitelist bypass
Una seconda tecnica di rilevamento, è quella di trovare la presenza di un IP che ha una cattiva reputazione connesso alla propria rete. Sfruttare un IP in whitelist è fondamentale in questi casi. Anche il solo fare "esperimenti" in locale può danneggiare il proprio IP, cosa di cui non si accorgono tutti, specialmente coloro che sfruttano la propria rete di casa per "giocare" con Metasploit.
Iniziando un test anche solo con i sample di Metasploit, inserendo il nostro IP di casa nel payload, e inviandolo successivamente a Virus Total, rischiamo di compromettere la reputazione dell'IP. Infatti le detection che VT individuerà, non si limiteranno al rilevamento delle azioni fatte dal payload, ma prima o poi inizieranno a far caso anche l'indirizzo IP a cui si andrà a connettere, e in caso di rilevamento di troppi file malevoli che comunicano con quell'IP, la reputazione di quell'IP calerà. Chi ha un IP dinamico ovviamente può disinteressarsi a questo, ma comunque non raccomando di fare esperimenti con un IP dinamico, altrimenti i payload dovranno essere modificati continuamente, ogni volta che l'IP cambia.
Un secondo effetto indesiderato, dell'IP flaggato su VT, è l'impossibilità di fare AV bypass. Non importa in quanti blob di XOR poliformico vai a criptare il payload, dato che l'IP è messo male, terminerai sempre con una detection, perché il payload semplicemente comunica con un "cattivo IP". Avevo parlato più specificataente di quest'ultima parte in un vecchio thread, ma la riesumiamo.
Il metodo migliore per fare esperimenti con i sample, è l'uso di servizi esterni, come VPS. In tale modo, il nostro IP di casa non rischierà mai. Packetriot e Ngrok, ad esempio, sono due noti servizi di traffic routing che sono stati sfruttati per anni da attaccanti allo scopo di creare TCP relay con i trojan. Come risultato, questi due servizi hanno subito enormi danni reputazionali su VirusTotal, con multiple detection, e vari ricercatori di sicurezza che commentano i risultati dei report.