Wiki per raccogliere risorse sull'hardening delle infrastrutture Red Team
Questa wiki è pensata per fornire una risorsa per l'impostazione di un'infrastruttura Red Team resiliente. È stata creata per integrare il talk di Steve Borosh (@424f424f) e Jeff Dimmock (@bluscreenofjeff) al BSides NoVa 2017 "Doomsday Preppers: Fortifying Your Red Team Infrastructure" (slides)
Se hai un'aggiunta che desideri apportare, invia una Pull Request o apri un issue sul repository.
GRAZIE a tutti gli autori dei contenuti citati in questa wiki e a tutti coloro che hanno contribuito!
Quando si progetta un'infrastruttura Red Team che deve resistere a una risposta attiva o durare per un impegno a lungo termine (settimane, mesi, anni), è importante segregare ogni asset in base alla funzione. Questo fornisce resilienza e agilità contro la Blue Team quando gli asset della campagna iniziano a essere rilevati. Ad esempio, se l'email di phishing di una valutazione viene identificata, il Red Team dovrebbe solo creare un nuovo server SMTP e un server di hosting dei payload, piuttosto che l'intera configurazione di un team server.
Considera di segregare queste funzioni su asset diversi:
Ognuna di queste funzioni sarà probabilmente richiesta per ogni campagna di social engineering. Poiché la risposta attiva agli incidenti è tipica in una valutazione Red Team, per ogni campagna dovrebbe essere implementato un nuovo set di infrastrutture.
Per aumentare la resilienza e l'occultamento, ogni asset back-end (cioè il team server) dovrebbe avere un redirector posizionato davanti. L'obiettivo è avere sempre un host tra il nostro target e i nostri server back-end. Impostare l'infrastruttura in questo modo rende il rinnovo dell'infrastruttura molto più rapido e semplice: non è necessario creare un nuovo team server, migrare le sessioni e riconnettere gli asset non bruciati sul back-end.
Tipi comuni di redirector:
Ogni tipo di redirector ha molteplici opzioni di implementazione che si adattano meglio a diversi scenari. Queste opzioni sono discusse in dettaglio nella sezione Redirector della wiki. I redirector possono essere host VPS, server dedicati o persino app eseguite su un'istanza Platform-as-a-Service.
Ecco un esempio di progettazione, tenendo a mente la segregazione funzionale e l'uso dei redirector:
A Vision for Distributed Red Team Operations - Raphael Mudge (@armitagehacker)
Infrastructure for Ongoing Red Team Operations - Raphael Mudge
Advanced Threat Tactics (2 of 9): Infrastructure - Raphael Mudge
Cloud-based Redirectors for Distributed Hacking - Raphael Mudge
How to Build a C2 Infrastructure with Digital Ocean – Part 1 - Lee Kagan (@invokethreatguy)
Automated Red Team Infrastructure Deployment with Terraform - Part 1 - Rasta Mouse (@_RastaMouse)
La reputazione percepita di un dominio varierà notevolmente a seconda dei prodotti utilizzati dal tuo target e della loro configurazione. Pertanto, scegliere un dominio che funzioni sul tuo target non è una scienza esatta. La raccolta di intelligence a fonte aperta (OSINT) sarà fondamentale per fare una stima migliore dello stato dei controlli e di quali risorse utilizzare per verificare i domini. Fortunatamente, gli inserzionisti online affrontano gli stessi problemi e hanno creato alcune soluzioni che possiamo sfruttare.
expireddomains.net è un motore di ricerca per domini scaduti o rilasciati di recente. Fornisce ricerca e filtri avanzati, come l'età della scadenza, il numero di backlink, il numero di snapshot su Archive.org, il punteggio SimilarWeb. Usando il sito, possiamo registrare domini già utilizzati, che avranno un'età di dominio, che sembrano simili al nostro target, simili alla nostra impersonificazione, o semplicemente è probabile che si integrino bene nella rete del nostro target.
Quando scegli un dominio per C2 o esfiltrazione di dati, considera di scegliere un dominio categorizzato come Finance o Healthcare. Molte organizzazioni non eseguiranno SSL middling su quelle categorie a causa della possibilità di problemi legali o di sensibilità dei dati. È anche importante assicurarsi che il dominio scelto non sia associato a precedenti campagne di malware o phishing.
Lo strumento CatMyFish di Charles Hamilton(@MrUn1k0d3r) automatizza le ricerche e la verifica della categorizzazione web con expireddomains.net e BlueCoat. Può essere modificato per applicare più filtri alle ricerche o persino eseguire un monitoraggio a lungo termine degli asset che registri.
Un altro strumento, DomainHunter di Joe Vest (@joevest) e Andrew Chiles (@andrewchiles), restituisce la categorizzazione BlueCoat/WebPulse, IBM X-Force e Cisco Talos, l'età del dominio, TLD alternativi disponibili, link Archive.org e un report HTML. Inoltre, esegue controlli per l'uso in campagne note di malware e phishing utilizzando Malwaredomains.com e MXToolBox. Questo strumento include anche il supporto OCR per bypassare i captcha BlueCoat/WebPulse. Dai un'occhiata al post del blog sulla versione iniziale dello strumento per maggiori dettagli.
Ancora un altro strumento, AIRMASTER di Max Harley (@Max_68) usa expireddomains.net e Bluecoat per trovare domini categorizzati. Questo strumento usa l'OCR per bypassare il captcha BlueCoat, aumentando la velocità di ricerca.
Se un dominio precedentemente registrato non è disponibile o preferisci un dominio auto-registrato, è possibile categorizzare i domini da soli. Usando i link diretti qui sotto o uno strumento come Chameleon di Dominic Chell (@domchell). La maggior parte dei prodotti di categorizzazione ignorerà i redirect o i contenuti clonati quando determina la categorizzazione del dominio. Per maggiori informazioni sull'uso di Chameleon, dai un'occhiata al post di Dominic Categorisation is not a security boundary.
Infine, assicurati che le tue impostazioni DNS si siano propagate correttamente.
Le parole facile e phishing non sembrano mai andare d'accordo. Impostare un'infrastruttura di phishing adeguata può essere un vero problema. Il seguente tutorial ti fornirà le conoscenze e gli strumenti per configurare rapidamente un server di phishing che supera "la maggior parte" dei filtri antispam attuali e ti fornisce un'interfaccia RoundCube per un'esperienza di phishing semplice, inclusa la comunicazione bidirezionale con il tuo target. Ci sono molte configurazioni e post là fuori riguardanti il phishing. Questo è solo un metodo.
Una volta che hai un dominio che supera i controlli appropriati elencati nella sezione precedente e hai avviato il tuo server di phishing, dovrai creare un paio di record "A" per il tuo dominio come mostrato.
Successivamente, accedi via ssh al tuo server di phishing e assicurati di avere un hostname FQDN corretto elencato nel tuo /etc/hosts. Esempio "127.0.0.1 email.yourphishingserver.com email localhost"
Ora installerai il front-end web per fare phishing in pochi semplici passaggi. Inizia scaricando l'ultima versione "BETA" di iRedMail sul tuo server di phishing. Il modo semplice è fare clic con il tasto destro sul pulsante di download, copiare l'indirizzo del link, usare wget per scaricarlo direttamente sul tuo server di phishing. Successivamente, estrai il file "tar -xvf iRedMail-0.9.8-beta2.tar.bz2". Naviga nella cartella estratta e rendi eseguibile lo script iRedMail.sh (chmod +x iRedMail.sh). Esegui lo script come root, segui le istruzioni e dovrai riavviare per completare tutto.
Dovrai assicurarti di avere tutti i record DNS corretti che puntano al tuo server di posta. (https://docs.iredmail.org/setup.dns.html). Per DKIM, il nuovo comando dovrebbe essere "amavisd-new showkeys" per elencare la tua chiave DKIM.
Per DMARC possiamo usare (https://www.unlocktheinbox.com/dmarcwizard/) per generare la nostra voce dmarc.
Ora, crea un utente con cui fare phishing.
Accedi all'interfaccia RoundCube con il tuo nuovo utente e fai phishing in modo responsabile!
Cobalt Strike fornisce funzionalità di spearphishing personalizzabili per supportare il phishing via email in pentest o red team. Supporta modelli in formato HTML e/o testo semplice, allegati, un indirizzo di rimbalzo, incorporamento di URL, uso di server SMTP remoti e ritardi di invio per messaggio. Un'altra caratteristica interessante è la possibilità di aggiungere un token univoco all'URL incorporato di ogni utente per il monitoraggio dei clic.
Per informazioni più dettagliate, dai un'occhiata a queste risorse:
Per esercitazioni di red-team e phishing in cui la fiducia del cliente e l'OPSEC contano, mantenere i dati del cliente catturati e l'infrastruttura primaria sui server del cliente stesso (on-premises) offre vantaggi significativi rispetto alle soluzioni solo cloud. Questo approccio usa asset cloud solo per redirector e front sottili, mantenendo le operazioni sensibili internamente.
Una configurazione on-premises robusta di Evilginx consiste tipicamente in:
Il gating tramite cookie riduce i colpi dei bot e la scansione automatizzata richiedendo un cookie specifico per accedere al portale di phishing:``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
Questa regola reindirizza le richieste al dominio del portale che non contengono il cookie richiesto, esentando le richieste di favicon per prevenire loop di reindirizzamento.
### Configurazione Caddy di Esempio```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
Esegui Evilginx sul nodo interno con i flag appropriati:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**Importante:** Evilginx dovrebbe essere raggiungibile solo dall'interno della rete privata; non pubblicare mai il suo IP nel DNS pubblico.
### Checklist OPSEC e di Hardening
1. **Non esporre mai gli IP di Evilginx nel DNS pubblico** - Utilizzare solo reti private
2. **Mantenere i dati sensibili solo sui server client** - I redirector non devono memorizzare le credenziali catturate
3. **Hardening dei redirector** - Ruotare i domini, utilizzare TTL brevi, distribuire più redirector effimeri
4. **Implementare regole WAF/firewall** - Utilizzare controlli sui cookie, allowlist IP o validazione dello User-Agent
5. **Separare logging e conservazione** - Mantenere i log di accesso su Caddy e i log di cattura sull'host Evilginx
6. **Evitare impronte digitali** - Non utilizzare pattern prevedibili o impronte TLS identiche
Questo approccio ibrido (redirector pubblico/cattura privata) offre la resilienza del cloud fronting mantenendo al contempo i vantaggi di sicurezza e legali di tenere le operazioni sensibili on-premises.
## Framework di Phishing
Oltre a creare una configurazione di phishing personalizzata o a utilizzare un framework di pentest o red teaming, come Cobalt Strike, esistono numerosi strumenti e framework dedicati al phishing via email. Sebbene questa wiki non entri nel dettaglio di ciascun framework, di seguito sono raccolte alcune risorse per ciascuno:
### Gophish
* [Sito ufficiale Gophish](https://getgophish.com/)
* [Repository GitHub Gophish](https://github.com/gophish/gophish)
* [Guida utente Gophish](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Sito ufficiale Phishing Frenzy](https://www.phishingfrenzy.com/)
* [Repository GitHub Phishing Frenzy](https://github.com/pentestgeek/phishing-frenzy)
* [Presentazione di Phishing Frenzy - Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### The Social-Engineer Toolkit
* [Repository GitHub The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit)
* [Manuale utente The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (ex FirePhish)
* [Repository GitHub FiercePhish](https://github.com/Raikia/FiercePhish)
* [Wiki FiercePhish](https://github.com/Raikia/FiercePhish/wiki)
# Redirector
## SMTP
"Redirector" potrebbe non essere la parola migliore per descrivere ciò che realizzeremo, ma l'obiettivo è lo stesso della nostra altra redirezione. Vogliamo rimuovere qualsiasi traccia dell'origine del nostro phishing dalle intestazioni finali delle email e fornire un buffer tra la vittima e il nostro server backend. Idealmente, il redirector SMTP dovrebbe essere rapido da configurare e facile da dismettere.
Ci sono due azioni chiave che vogliamo configurare per un redirector SMTP:
### Sendmail
#### Rimuovere le intestazioni precedenti del server
Aggiungere la seguente riga alla fine di `/etc/mail/sendmail.mc`:```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
Add alla fine di /etc/mail/access:```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[Removing Sender’s IP Address From Email’s Received From Header](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Removing Headers from Postfix setup](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### Configurare un indirizzo catch-all
Questo inoltrerà qualsiasi email ricevuta su *@phishdomain.com a un indirizzo email scelto. È molto utile per ricevere eventuali risposte o messaggi di rimbalzo a un'email di phishing.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
Aggiungi la seguente riga subito prima di //Mailer Definitions// (verso la fine) di /etc/mail/sendmail.mc:```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
Aggiungi la seguente riga alla fine di `/etc/mail/virtusertable`:```bash
@phishdomain.com external-relay-address
Nota: I due campi devono essere separati da tabulazione
Postfix offre un'alternativa più semplice a sendmail con una compatibilità più ampia. Postfix offre anche pieno supporto IMAP con Dovecot. Questo consente ai tester di corrispondere in tempo reale con i target di phishing che rispondono al messaggio originale, piuttosto che fare affidamento sull'indirizzo catch-all e dover creare un nuovo messaggio usando il proprio strumento di phishing.
Una guida completa alla configurazione di un server di posta Postfix per il phishing è disponibile nel post di Julian Catrambone (@n0pe_sled) Mail Servers Made Easy.
Nota: Quando si usano redirector C2, un listener esterno dovrebbe essere configurato sul proprio framework post-exploitation per inviare il traffico di staging attraverso il dominio del redirector. Questo farà sì che l'host compromesso esegua lo staging attraverso il redirector come il traffico C2 stesso.
socat può essere usato per reindirizzare i pacchetti DNS in ingresso sulla porta 53 al nostro team server. Sebbene questo metodo funzioni, alcuni utenti hanno segnalato problemi di staging con Cobalt Strike e/o problemi di latenza usando questo metodo. Modifica del 21/04/2017: Il seguente comando socat sembra funzionare bene grazie ai test di @xorrior:``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### iptables per DNS
Le regole di inoltro DNS con iptables hanno dimostrato di funzionare bene con Cobalt Strike. Non sembrano esserci i problemi che socat ha nel gestire questo tipo di traffico.
Di seguito è riportato un esempio di set di regole di reindirizzamento DNS.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
Anche, imposta la policy della catena "FORWARD" su "ACCEPT"
Alcuni potrebbero avere l'esigenza o la necessità di ospitare un server c2 su una rete interna. Utilizzando una combinazione di IPTABLES, SOCAT e tunnel SSH inversi, possiamo certamente ottenere questo risultato nel modo seguente.
In questo scenario abbiamo il nostro redirector volatile che utilizza IPTables per inoltrare tutto il traffico DNS utilizzando la regola di esempio descritta in precedenza in questa sezione. Successivamente, creiamo un tunnel SSH con port forwarding inverso dal nostro server c2 interno al nostro redirector principale. Questo inoltrerà qualsiasi traffico che il redirector principale riceve sulla porta 6667 al server c2 interno sulla porta 6667. Ora, avvia socat sul nostro team server per fare il fork di qualsiasi traffico TCP in entrata sulla porta 6667 verso la porta UDP 53, che è ciò su cui il nostro c2 DNS deve rimanere in ascolto. Infine, configuriamo allo stesso modo un'istanza di socat sul redirector principale per reindirizzare qualsiasi traffico UDP in entrata sulla porta 53 nel nostro tunnel SSH sulla porta 6667.
Nota: Quando si utilizzano redirector C2, un listener esterno dovrebbe essere configurato sul tuo framework di post-exploitation per inviare il traffico di staging attraverso il dominio del redirector. Questo farà sì che l'host compromesso esegua lo staging attraverso il redirector come il traffico C2 stesso.
socat fornisce un reindirizzamento a 'tubo stupido' (dumb pipe). Qualsiasi richiesta che socat riceve sull'interfaccia/porta di origine specificata viene reindirizzata all'IP/porta di destinazione. Non c'è filtro o reindirizzamento condizionale. Apache mod_rewrite, d'altra parte, fornisce una serie di metodi per rafforzare il tuo phishing e aumentare la resilienza della tua infrastruttura di test. mod_rewrite ha la capacità di eseguire reindirizzamenti condizionali basati su attributi della richiesta, come URI, user agent, query string, sistema operativo e IP. Apache mod_rewrite utilizza file htaccess per configurare set di regole su come Apache dovrebbe gestire ogni richiesta in entrata. Utilizzando queste regole, potresti, ad esempio, reindirizzare le richieste al tuo server con lo user agent predefinito di wget a una pagina legittima sul sito web del tuo target.
In breve, se il tuo redirector deve eseguire reindirizzamenti condizionali o filtri avanzati, usa Apache mod_rewrite. Altrimenti, il reindirizzamento con socat con filtro iptables opzionale sarà sufficiente.
socat può essere utilizzato per reindirizzare qualsiasi pacchetto TCP in entrata su una porta specificata al nostro team server.
La sintassi di base per reindirizzare la porta TCP 80 su localhost alla porta 80 su un altro host è:``` socat TCP4-LISTEN:80,fork TCP4::80
Se il tuo redirector è configurato con più di un'interfaccia di rete, socat può essere associato a un'interfaccia specifica, tramite indirizzo IP, con la seguente sintassi:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
In questo esempio, 10.0.0.2 è uno degli indirizzi IP locali del redirector e 1.2.3.4 è l'indirizzo IP del team server remoto.
Oltre a socat, iptables può eseguire la redirezione 'dumb pipe' tramite NAT. Per inoltrare la porta locale 80 del redirector a un host remoto, usa la seguente sintassi:``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### SSH per HTTP
In precedenza abbiamo trattato l'uso di SSH per i tunnel DNS. SSH funziona come un mezzo solido e robusto per superare il NAT e ottenere un modo per l'impianto di connettersi a un redirector e al tuo ambiente server. Prima di configurare un redirector SSH, devi aggiungere le seguenti righe a `/etc/ssh/sshd_config`:```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
Per inoltrare la porta locale 80 del redirector al tuo server interno, usa la seguente sintassi sul server interno:``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
Puoi anche inoltrare più di una porta, ad esempio se vuoi che 443 e 80 siano aperte contemporaneamente:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
Quando si servono payload e risorse web, vogliamo ridurre al minimo la capacità dei responder agli incidenti di esaminare i file e aumentare le possibilità di eseguire con successo il payload, sia per stabilire un C2 che per raccogliere intelligence.
Utilizzo ed esempi di Apache Mod_Rewrite di Jeff Dimmock:
Altri utilizzi ed esempi di Apache mod_rewrite:
Per configurare automaticamente Apache Mod_Rewrite su un server redirector, consulta il post del blog di Julain Catrambone (@n0pe_sled) Configurazione automatica Mod_Rewrite e il tool associato.
L'intenzione dietro il reindirizzamento del traffico C2 è duplice: oscurare il server del team backend e apparire come un sito web legittimo se visitato da un responder agli incidenti. Attraverso l'uso di Apache mod_rewrite e profili C2 personalizzati o altri proxy (come con Flask), possiamo filtrare in modo affidabile il traffico C2 reale dal traffico investigativo.
Basandosi su "Reindirizzamento C2" sopra, un altro metodo è far utilizzare al tuo server redirector il motore SSL Proxy di Apache per accettare richieste SSL in ingresso e inoltrarle come richieste a un listener reverse-HTTPS. La crittografia viene utilizzata in tutte le fasi e puoi ruotare i certificati SSL sul tuo redirector secondo necessità.
Per far funzionare questo con le tue regole mod_rewrite, devi inserire le tue regole in "/etc/apache2/sites-available/000-default-le-ssl.conf" supponendo che tu abbia utilizzato LetsEncrypt (noto anche come CertBot) per installare il tuo certificato. Inoltre, per abilitare il motore SSL ProxyPass, avrai bisogno delle seguenti righe nello stesso file di configurazione:```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### Altre risorse su Apache mod_rewrite
* [Automazione di Apache mod_rewrite e dei profili Cobalt Strike](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [Documentazione ufficiale di Apache 2.4 mod_rewrite](http://httpd.apache.org/docs/current/rewrite/)
* [Introduzione ad Apache mod_rewrite](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [Guida approfondita a mod_rewrite per Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod_rewrite-for-apache--net-6708)
* [Controllo sintassi Mod_Rewrite/.htaccess](http://www.htaccesscheck.com/)
# Modifica del traffico C2
## Cobalt Strike
Cobalt Strike modifica il proprio traffico tramite i profili Malleable C2. I profili offrono opzioni altamente personalizzabili per modificare l'aspetto del traffico C2 del tuo server sulla rete. I profili Malleable C2 possono essere utilizzati per rafforzare l'evasione durante l'incident response, impersonare avversari noti o mascherarsi da applicazioni interne legittime utilizzate dal target.
* [Profili Malleable C2 ufficiali - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Documentazione Malleable Command and Control - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - Un percorso per l'escalation dei privilegi - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [Un nuovo mondo: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [Come scrivere profili Malleable C2 per Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [Evasione in memoria (serie di video) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
Quando inizi a creare o modificare profili Malleable C2, è importante tenere presenti i limiti di dimensione dei dati per il posizionamento delle informazioni Beacon. Ad esempio, configurare il profilo per inviare grandi quantità di dati in un parametro URL richiederà molte richieste. Per maggiori informazioni su questo argomento, consulta il post del blog di Raphael Mudge [Beware of Slow Downloads](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/).
Se riscontri problemi con il tuo profilo Malleable C2 e noti che la console del teamserver genera errori, fai riferimento al post del blog di Raphael Mudge [Broken Promises and Malleable C2 Profiles](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/) per suggerimenti sulla risoluzione dei problemi.
## Empire
Empire utilizza i Communication Profiles, che offrono opzioni di personalizzazione per gli URI delle richieste GET, lo user agent e le intestazioni. Il profilo è composto da ciascun elemento, separato dal carattere pipe, e viene impostato con l'opzione `set DefaultProfile` nel menu contestuale `listeners`.
Ecco un esempio di profilo predefinito:```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
In alternativa, il valore DefaultProfile può essere impostato modificando il file /setup/setup_database.py prima della configurazione iniziale di Empire. Questo cambierà il profilo di comunicazione predefinito che Empire utilizzerà.
Oltre al profilo di comunicazione, considera di personalizzare gli URI di staging del server Empire, gli header del server e il contenuto predefinito della pagina web seguendo i passaggi presentati nel post di Joe Vest (@joevest) Empire - Modifying Server C2 Indicators.
Sfruttare servizi web legittimi e affidabili per il C2 può fornire un vantaggio prezioso rispetto all'uso di domini e infrastrutture configurati da te. Il tempo e la complessità di configurazione variano in base alla tecnica e al servizio utilizzato. Un esempio popolare di sfruttamento di servizi di terze parti per il reindirizzamento C2 è il Domain Fronting.
Il Domain Fronting è una tecnica utilizzata da servizi e app di elusione della censura per instradare il traffico attraverso domini legittimi e altamente affidabili. I servizi popolari che supportano il Domain Fronting includono Google App Engine, Amazon CloudFront e Microsoft Azure. È importante notare che molti provider, come Google e Amazon, hanno implementato mitigazioni contro il Domain Fronting, quindi alcune risorse collegate o informazioni fornite in questo wiki potrebbero essere obsolete quando proverai a utilizzarle.
In poche parole, il traffico utilizza il nome DNS e SNI del provider di servizi affidabile; Google viene utilizzato nell'esempio seguente. Quando il traffico viene ricevuto dal server perimetrale (ad es. situato su gmail.com), il pacchetto viene inoltrato al server di origine (ad es. phish.appspot.com) specificato nell'header Host del pacchetto. A seconda del provider di servizi, il server di origine inoltrerà direttamente il traffico a un dominio specificato, che punteremo al nostro team server, oppure sarà necessaria un'app proxy per eseguire il salto finale di inoltro.
Per informazioni più dettagliate su come funziona il Domain Fronting, consulta il whitepaper Blocking-resistant communication through domain fronting e la documentazione di meek del progetto TOR.
Oltre ai domini frontabili standard, come qualsiasi dominio google.com, è possibile sfruttare altri domini legittimi per il fronting.
Per maggiori informazioni sulla ricerca di domini frontabili, consulta:
Molti provider PaaS e SaaS forniscono un sottodominio o un URL statico da utilizzare con un'istanza provisionata. Se il dominio associato è generalmente altamente affidabile, le istanze potrebbero fornire fiducia extra alla tua infrastruttura C2 rispetto a un dominio acquistato e a un VPS.
Per configurare il reindirizzamento, dovrai identificare un servizio che emette un sottodominio o un URL statico come parte di un'istanza. Quindi, l'istanza dovrà essere configurata con reindirizzamento basato su rete o su applicazione. L'istanza agirà come un proxy, simile agli altri redirector discussi in questo wiki.
Un'altra tecnica interessante che merita ulteriori ricerche è l'uso di bucket Amazon S3 eccessivamente permissivi per il C2. Consulta il post S3 Buckets for Good and Evil di Andrew Luke (@Sw4mp_f0x) per maggiori dettagli su come i bucket S3 potrebbero essere utilizzati per il C2. Questa tecnica potrebbe essere combinata con le capacità C2 di terze parti di Empire per utilizzare i bucket S3 legittimi del target contro di esso.
Per un altro esempio di utilizzo di PaaS per il C2, consulta Databases and Clouds: SQL Server as a C2 di Scott Sutherland (@_nullbind).
Altri servizi di terze parti sono stati utilizzati in natura per il C2 in passato. Sfruttare siti web di terze parti che consentono la pubblicazione o la modifica rapida di contenuti generati dagli utenti può aiutarti a eludere i controlli basati sulla reputazione, soprattutto se il sito di terze parti è generalmente affidabile.
Consulta queste risorse per altre opzioni C2 di terze parti:
L'infrastruttura di attacco è spesso facile da identificare, apparendo come un guscio di un server legittimo. Dovremo adottare ulteriori passaggi con la nostra infrastruttura per aumentare la probabilità di mimetizzarci con server reali, sia tra l'organizzazione target sia tra i servizi che il target potrebbe ragionevolmente utilizzare.
I redirector possono aiutare a mimetizzarsi reindirizzando URI non validi, facendo scadere i link dei payload di phishing o bloccando le tecniche comuni degli incident responder; tuttavia, si dovrebbe prestare attenzione anche all'host sottostante e ai suoi indicatori.
Ad esempio, nel post Fall of an Empire, John Menerick (@Lord_SQL) copre i metodi per rilevare i server Empire su internet.
Per contrastare questi e indicatori simili, è una buona idea modificare i modelli di traffico C2, modificare le pagine di destinazione del server, limitare le porte aperte e modificare gli header di risposta predefiniti.
Per maggiori dettagli su come eseguire queste e altre tattiche per più framework di attacco, consulta questi post:
L'infrastruttura di attacco può essere attaccata proprio come qualsiasi altro host connesso a internet e dovrebbe essere considerata ALTAMENTE sensibile a causa dei dati in uso e delle connessioni negli ambienti target.
Nel 2016, sono state divulgate vulnerabilità di esecuzione remota di codice sugli strumenti di attacco più comuni:
iptables dovrebbe essere utilizzato per filtrare il traffico indesiderato e limitare il traffico tra gli elementi infrastrutturali richiesti. Ad esempio, se un team server Cobalt Strike servirà asset solo a un redirector Apache, le regole iptables dovrebbero consentire solo la porta 80 dall'IP sorgente del redirector. Questo è particolarmente importante per qualsiasi interfaccia di gestione, come SSH o la porta predefinita 50050 di Cobalt Strike. Considera anche di bloccare gli IP di paesi non target. In alternativa, considera l'uso dei firewall dell'hypervisor forniti dai tuoi provider VPS. Ad esempio, Digital Ocean offre Cloud Firewalls che possono proteggere uno o più droplet.
chattr può essere utilizzato sui team server per impedire la modifica delle directory cron. Usando chattr, puoi limitare qualsiasi utente, incluso root, dalla modifica di un file finché l'attributo chattr non viene rimosso.
SSH dovrebbe essere limitato alla sola autenticazione con chiave pubblica e configurato per utilizzare utenti con diritti limitati per il login iniziale. Per una maggiore sicurezza, considera l'aggiunta dell'autenticazione multi-fattore a SSH.
Aggiornamento! Nessuna lista di protezione è completa senza un promemoria per aggiornare regolarmente i sistemi e applicare hot-fix come necessario per rimediare alle vulnerabilità.
Naturalmente, questa lista non è esaustiva di ciò che puoi fare per proteggere un team server. Segui le pratiche comuni di hardening su tutta l'infrastruttura:
Esistono numerose risorse disponibili online che discutono la configurazione e la progettazione sicure delle infrastrutture. Non ogni considerazione di progettazione sarà appropriata per ogni infrastruttura di attacco, ma è utile sapere quali opzioni sono disponibili e cosa stanno facendo gli altri tester.
Ecco alcune di queste risorse:
Gli argomenti trattati in questo wiki rafforzano le infrastrutture di attacco, ma generalmente richiedono molto tempo per la progettazione e l'implementazione. L'automazione può essere utilizzata per ridurre notevolmente i tempi di distribuzione, consentendoti di distribuire configurazioni più complesse in meno tempo.
Consulta queste risorse sull'automazione dell'infrastruttura di attacco:
Documenta tutto - Gestire un'infrastruttura Red Team complessa significa molte parti mobili. Assicurati di documentare la funzione di ogni asset e dove viene inviato il suo traffico.
Dividi gli asset tra diversi provider di servizi e regioni - Gli asset infrastrutturali dovrebbero essere distribuiti su più provider di servizi e regioni geografiche. I membri del Blue Team potrebbero alzare le soglie di monitoraggio contro i provider identificati come attivamente impegnati in un attacco e potrebbero persino bloccare del tutto un determinato provider di servizi. Nota: tieni a mente le leggi internazionali sulla privacy se invii dati crittografati o sensibili oltre i confini.
Non esagerare - È facile entusiasmarsi per tecniche avanzate e voler lanciare tutto contro un target. Se stai emulando una specifica minaccia avversaria, sfrutta solo le tecniche utilizzate dal vero attore della minaccia o tecniche all'interno delle competenze dell'attore della minaccia. Se il tuo test red team attaccherà lo stesso target a lungo termine, considera di iniziare "facile" e di lavorare attraverso le tecniche più avanzate man mano che le tue valutazioni procedono. Evolvere la tecnica del red team insieme a quella del blue team spingerà costantemente l'organizzazione in avanti, mentre colpire il blue team con tutto in una volta potrebbe sopraffarlo e rallentare il processo di apprendimento.
Monitora i log - Tutti i log dovrebbero essere monitorati durante l'impegno: log SMTP, log Apache, tcpdump sui redirector socat, log iptables (specifici per l'inoltro del traffico o il filtraggio mirato), weblog, log Cobalt Strike/Empire/MSF. Inoltra i log a una posizione centrale, ad esempio con rsyslog, per un monitoraggio più semplice. La conservazione dei dati del terminale dell'operatore può tornare utile per rivedere l'uso storico dei comandi durante un'operazione. @Killswitch_GUI ha creato un programma facile da usare chiamato lTerm che registrerà tutti i comandi del terminale bash in una posizione centrale. Registra tutto l'output del terminale con lTerm. Consulta il post di Vincent Yiu CobaltSplunk per un esempio di come inviare i log di Cobalt Strike a Splunk per il monitoraggio e l'analisi avanzata dell'infrastruttura.* Implementare l'alerting per eventi ad alto valore - Configurare l'infrastruttura di attacco per generare alert per eventi ad alto valore, come nuove sessioni C2 o rilevamenti di credenziali catturate. Un modo popolare per implementare l'alerting è tramite l'API di una piattaforma di chat, come Slack. Dai un'occhiata ai seguenti post sull'alerting con Slack: Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g), Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles), Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
Fingerprint dell'incident response - Se possibile, cerca di fare un fingerprint passivo o attivo delle azioni di IR prima che inizi la valutazione. Ad esempio, invia un'email di phishing mediocre al target (usando infrastrutture non correlate) e monitora il traffico che quell'infrastruttura riceve. Le indagini del team di IR possono rivelare molte informazioni su come opera il team e su quale infrastruttura utilizza. Se questo può essere determinato in anticipo rispetto alla valutazione, può essere filtrato o reindirizzato del tutto.
UN GRANDE GRAZIE a tutte le seguenti persone (elencate in ordine alfabetico) che hanno contribuito con strumenti, suggerimenti o link da includere nella wiki, e un altro GRAZIE a chiunque abbia scritto uno strumento o un post citato in questa wiki!