CaddySmith

CaddySmith è un piccolo script Python che legge un profilo C2 di Cobalt Strike o Sliver e genera una configurazione per il server web Caddy. Il Caddyfile generato trasforma un normale server Linux in un redirector: il traffico legittimo dei beacon viene inoltrato tramite proxy inverso al team server, mentre tutto il resto (scanner, bot di ricerca, sonde blu team, curl casuali) viene reindirizzato a un URL esca.

L'ho scritto perché Caddy è un server web molto più semplice da configurare rapidamente rispetto ad Apache: è un singolo binario statico, ha certificati Let's Encrypt automatici e non richiede il ballo di a2enmod.

Solo per engagement autorizzati. Si tratta di strumentazione offensiva di sicurezza. Eseguila solo su ambienti per i quali hai un'autorizzazione scritta per i test.

Formati di profilo supportati

CaddySmith rileva automaticamente il formato dal contenuto del file:

• Cobalt Strike — il classico formato testuale con direttive set uri "/foo". Ogni URI di HTTP-GET / HTTP-POST diventa una route esatta con gli header client del profilo applicati.
• Sliver — la configurazione JSON dell'impianto esportata da Sliver. Sliver non ha URI fissi; li genera al momento della creazione del beacon a partire da liste di path/file/estensione. CaddySmith gestisce questa situazione confrontando i prefissi di path di primo livello come glob (es. path /api* /static* /resources*) ed effettuando una corrispondenza parziale sul numero di build di Chrome presente nello User-Agent (che sopravvive alle riscritture dello UA specifiche per piattaforma di Sliver).

Puoi anche forzare un parser specifico con --profile-type cobaltstrike o --profile-type sliver.

Cosa fa

Dato un file di profilo, lo script estrae:

• La stringa User-Agent
• URI (CS) o prefissi di path (Sliver)
• Header lato client (solo CS — Sliver non specifica header particolari)
• L'header Host (usato come nome di dominio del redirector se non passi --server-name)
• Se lo staging è abilitato (solo CS — set host_stage)

Poi costruisce un Caddyfile che:

1. (Opzionale) Restituisce 403 al traffico HTTP semplice
2. Blocca circa 15 user agent noti come dannosi (curl, nmap, sqlmap, Googlebot, ecc.)
3. Blocca l'accesso diretto tramite IP e qualsiasi metodo HTTP che non sia GET/POST
4. Inoltra tramite proxy inverso solo gli URI del profilo (o i prefissi per Sliver), vincolati allo User-Agent corrispondente
5. Blocca i path comuni di scanner (.env, /wp-admin, .php, ecc.)
6. Reindirizza tutto il resto all'URL esca

Requisiti

• Python 3.7+ (usa solo la libreria standard, non serve pip install)
• Caddy 2.x sul redirector stesso (guida all'installazione)

Avvio rapido

python3 caddysmith.py my.profile \
    --backend https://teamserver.internal:443 \
    --decoy   https://www.example.com/ \
    --server-name redirector.example.com \
    --email   [email protected] \
    --forbid-http \
    -o redirector.caddy

Scrive la configurazione generata in redirector.caddy e stampa un riepilogo di ciò che ha fatto su stderr.

Distribuzione della configurazione generata

Opzione A: Eseguire direttamente il Caddyfile

Copia il file generato sul redirector ed esegui Caddy su di esso. È necessario il flag --adapter caddyfile perché Caddy di default usa la configurazione in JSON:

caddy run --config /etc/caddy/redirector.caddy --adapter caddyfile

Per ricaricare un'istanza in esecuzione con una configurazione aggiornata:

caddy reload --config /etc/caddy/redirector.caddy --adapter caddyfile

Se Caddy segnala problemi di formattazione, pulisci con:

caddy fmt --overwrite /etc/caddy/redirector.caddy

Opzione B: Importare da un Caddyfile principale

Metti il file in /etc/caddy/ e importalo dal tuo Caddyfile principale:

# /etc/caddy/Caddyfile
import /etc/caddy/redirector.caddy

Se hai passato --email (consigliato), il frammento generato contiene già il blocco delle opzioni globali, quindi il Caddyfile principale necessita solo della riga import. Se non lo hai fatto, aggiungi l'email manualmente in un blocco { } sopra l'import.

Poi convalida e ricarica:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Caddy fornirà automaticamente un certificato Let's Encrypt per il dominio specificato in --server-name fintanto che il record A punti al redirector.

Tutti i flag

Flag	Default	Cosa fa
profile	(obbligatorio)	Percorso del file .profile
--backend	https://teamserver.local:443	Dove inoltrare il traffico corrispondente
--decoy	https://www.example.com/	Dove reindirizzare il traffico non corrispondente
--server-name	c2.example.com	Nome di dominio del tuo redirector
--policy	strict	strict, lax o none
--profile-type	auto	Forza cobaltstrike o sliver (default: auto-rilevamento)
--extra-uri PATH	—	URI extra da inoltrare (con controllo UA). Ripetibile.
--lax-uri PATH	—	URI extra da inoltrare (senza controlli). Ripetibile.
--allow-ua STRING	—	UA extra consentiti sulle route --extra-uri. Ripetibile.
--forbid-http	off	Restituisce 403 su HTTP semplice
--email EMAIL	—	Email per la registrazione Let's Encrypt e notifiche di rinnovo
-o, --output FILE	stdout	Scrive la configurazione su file

Modalità di policy

• strict (default) — controlla User-Agent, tutti gli header client, IP diretto, metodo HTTP e path di sonda
• lax — blocca solo i cattivi user agent, nessuna corrispondenza di header per route
• none — inoltra qualsiasi richiesta a un URI del profilo, nessun filtro

Strict è ciò che di solito si vuole. Lax è utile quando stai debugando perché un vero beacon non si connette.

Un esempio pratico

Supponiamo che tu abbia un profilo che imita un endpoint di Amazon e che desideri distribuirlo su redirector.0xtb.sh:

python3 caddysmith.py amazon.profile \
    --backend https://10.1.1.10:443 \
    --decoy   https://www.amazon.com/ \
    --server-name redirector.0xtb.sh \
    --forbid-http \
    --policy strict \
    -o /etc/caddy/redirector.caddy

Il riepilogo mostra esattamente quali route sono state costruite, ad esempio:

Routes built:   2
  - [profile-get] /broadcast
  - [profile-post] /1/events/com.amazon.csm.csa.prod

Se rigeneri e non vedi nessuna route, probabilmente lo script non è riuscito a analizzare il tuo profilo: controlla gli avvisi su stderr.

Esempio con Sliver

Per una configurazione di impianto Sliver (JSON):

python3 caddysmith.py sliver-implant.json \
    --backend https://10.1.1.10:443 \
    --decoy   https://www.amazon.com/ \
    --server-name redirector.0xtb.sh \
    --email   [email protected] \
    --forbid-http \
    --policy strict \
    -o /etc/caddy/redirector.caddy

Il riepilogo ti dirà che Sliver è stato rilevato e mostrerà la route con prefisso:

Profile type:   sliver
Routes built:   1
  - [sliver] /api /public /resources /services /static (prefix)