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

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)

Poiché Sliver genera URI casualmente da combinazioni path × file × estensione, il matcher path generato utilizza glob di prefisso (path /api* /public* /resources* /services* /static*) anziché path esatti. Il matcher dello User-Agent utilizza una sottostringa del numero di build di Chrome (ad esempio 3921.146), che Sliver preserva nelle sue riscritture dello UA per piattaforma.

Test rapidi dopo la distribuzione

# HTTP semplice dovrebbe ricevere 403 (se hai usato --forbid-http)
curl -I http://redirector.0xtb.sh/

# Solo hostname dovrebbe reindirizzare all'esca
curl -kI https://redirector.0xtb.sh/

# Un UA cattivo dovrebbe anch'esso reindirizzare
curl -kI -A "curl/8.4.0" https://redirector.0xtb.sh/broadcast

# Una richiesta con UA corretto + percorso dovrebbe passare attraverso il proxy (200)
# In modalità strict devi anche inviare tutti gli header client del profilo.

Limitazioni note

• Le regole di staging non vengono generate (Cobalt Strike). Se il tuo profilo CS ha set host_stage "true" (o non lo imposta affatto), lo script avviserà e salterà gli URI di staging. Aggiungi set host_stage "false"; al tuo profilo, oppure passa gli URI di staging esplicitamente tramite --extra-uri.
• La corrispondenza per prefisso di Sliver è più ampia della corrispondenza esatta di CS. Con Sliver, la route del proxy rivendica qualsiasi URL che inizia con /api, /static, ecc. Le sonde degli scanner che usano questi prefissi (es. /api/.env) verranno inviate al team server anziché essere bloccate localmente — ma il trasporto HTTP di Sliver autentica tramite ID implant, quindi le richieste non autorizzate vengono respinte a livello C2. Il filtro UA continua comunque a tenere fuori la maggior parte degli scanner.
• Un backend per esecuzione. Ogni route passa dallo stesso --backend. Se hai bisogno di più team server, esegui lo script più volte e unisci manualmente.
• L'analisi degli URI del profilo è basata sulle righe (Cobalt Strike). set uri "/path1 /path2"; funziona (path multipli su una riga), ma una formattazione insolita potrebbe far inceppare il parser. Controlla l'elenco delle route nel riepilogo per verificare.
• La verifica del certificato del backend HTTPS è disabilitata di default. I team server di solito hanno certificati autofirmati, quindi la configurazione generata include . Se il tuo backend ha un certificato reale, cancella quella riga dal file generato.

Crediti

Il Malleable-Redirector basato su Apache è stato il punto di partenza per ciò che questo script genera: lo stesso modello a tre vie (URI del profilo / URI extra / URI lax), le stesse modalità di policy, la stessa struttura generale. CaddySmith si limita a tradurre l'output in sintassi Caddy invece di Apache .htaccess.

Licenza

MIT