CaddySmith

CaddySmith est un petit script Python qui lit un profil C2 Cobalt Strike ou Sliver et génère une configuration de serveur web Caddy à partir de celui-ci. Le Caddyfile généré transforme une boîte Linux standard en redirecteur : le trafic légitime des beacons est proxy inverse vers votre team server, et tout le reste (scanners, robots de recherche, sondes blue team, curl aléatoire) est redirigé vers une URL leurre.

J'ai écrit cet outil parce que Caddy est un serveur web bien plus facile à monter rapidement qu'Apache : binaire statique unique, certificats Let's Encrypt automatiques, pas de danse a2enmod.

Engagements autorisés uniquement. Il s'agit d'un outil de sécurité offensive. Ne l'utilisez que dans des environnements pour lesquels vous avez une autorisation écrite de test.

Formats de profil pris en charge

CaddySmith détecte automatiquement le format à partir du contenu du fichier :

• Cobalt Strike — le format texte classique avec des directives set uri "/foo". Chaque URI HTTP-GET / HTTP-POST devient sa propre route de chemin exact avec les en-têtes clients du profil appliqués.
• Sliver — la configuration JSON de l'implant exportée depuis Sliver. Sliver n'a pas d'URI fixes ; il les génère au moment de la construction du beacon à partir de listes de chemins / fichiers / extensions. CaddySmith gère cela en faisant correspondre les préfixes de chemin de haut niveau en tant que globs (par ex. path /api* /static* /resources*) et en effectuant une correspondance de sous-chaîne sur le numéro de build Chrome du UA (qui survit aux réécritures UA par plateforme de Sliver).

Vous pouvez aussi forcer un analyseur spécifique avec --profile-type cobaltstrike ou --profile-type sliver.

Ce qu'il fait

À partir d'un fichier de profil, le script extrait :

• La chaîne User-Agent
• Les URI (CS) ou les préfixes de chemin (Sliver)
• Les en-têtes côté client (CS uniquement — Sliver ne dicte pas d'en-têtes spécifiques)
• L'en-tête Host (utilisé comme nom de domaine du redirecteur si vous ne passez pas --server-name)
• Si le staging est activé (CS uniquement — set host_stage)

Ensuite, il construit un Caddyfile qui :

1. (Optionnel) Renvoie une 403 au trafic HTTP non chiffré
2. Bloque environ 15 user agents connus comme nuisibles (curl, nmap, sqlmap, Googlebot, etc.)
3. Bloque l'accès par IP directe et toute méthode HTTP qui n'est ni GET ni POST
4. Proxy inverse uniquement les URI du profil (ou les préfixes pour Sliver), filtrés par le User-Agent correspondant
5. Bloque les chemins courants de sondes de scanner (.env, /wp-admin, .php, etc.)
6. Redirige tout le reste vers votre URL leurre

Prérequis

• Python 3.7+ (utilise uniquement la bibliothèque standard, pas besoin de pip install)
• Caddy 2.x sur le redirecteur lui-même (guide d'installation)

Démarrage rapide

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

Ceci écrit la configuration générée dans redirector.caddy et affiche un résumé de ce qui a été fait sur stderr.

Déploiement de la configuration générée

Option A : Exécuter le Caddyfile directement

Copiez le fichier généré sur le redirecteur et exécutez Caddy avec. Vous avez besoin du drapeau --adapter caddyfile car Caddy utilise par défaut la configuration JSON :

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

Pour recharger une instance en cours avec une configuration mise à jour :

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

Si Caddy vous avertit d'incohérences de format, nettoyez-les avec :

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

Option B : Importer depuis un Caddyfile principal

Placez le fichier dans /etc/caddy/ et importez-le depuis votre Caddyfile principal :

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

Si vous avez passé --email (recommandé), l'extrait généré contient déjà le bloc d'options globales, donc le Caddyfile principal n'a besoin que de la ligne import. Sinon, ajoutez l'email manuellement dans un bloc { } avant l'import.

Validez et rechargez ensuite :

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

Caddy va automatiquement provisionner un certificat Let's Encrypt pour le domaine dans --server-name tant que l'enregistrement A pointe vers le redirecteur.

Tous les drapeaux

Modes de politique

• strict (défaut) — vérifie le User-Agent, tous les en-têtes clients, IP directe, méthode HTTP et chemins de sonde
• lax — bloque seulement les mauvais user agents, pas de correspondance d'en-têtes par route
• none — proxye toute requête vers une URI du profil, sans filtrage

Strict est ce que vous voulez en général. Lax est utile lorsque vous dépannez pourquoi un vrai beacon ne se connecte pas.

Exemple concret

Supposons que vous ayez un profil qui imite un point de terminaison Amazon et que vous souhaitiez le déployer sur 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

Le résumé montre exactement quelles routes ont été construites, par exemple :

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

Si vous régénérez et ne voyez aucune route, le script n'a probablement pas réussi à analyser votre profil — vérifiez les avertissements sur stderr.

Exemple Sliver

Pour une configuration d'implant 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

Le résumé vous indiquera que Sliver a été détecté et montrera la route de préfixe :

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

Parce que Sliver génère des URI aléatoirement à partir de combinaisons chemin × fichier × extension, le correspondant de chemin généré utilise des globs de préfixe (path /api* /public* /resources* /services* /static*) plutôt que des chemins exacts. Le correspondant User-Agent utilise une sous-chaîne du numéro de build Chrome (par ex. 3921.146), que Sliver conserve à travers ses réécritures UA par plateforme.

Tests de fumée après le déploiement

# Le HTTP non chiffré devrait renvoyer une 403 (si vous avez utilisé --forbid-http)
curl -I http://redirector.0xtb.sh/

# Le nom d'hôte nu devrait rediriger vers le leurre
curl -kI https://redirector.0xtb.sh/

# Un mauvais UA devrait aussi rediriger
curl -kI -A "curl/8.4.0" https://redirector.0xtb.sh/broadcast

# Une requête avec le bon UA et le bon chemin devrait passer par le proxy (200)
# Vous devez également envoyer tous les en-têtes clients du profil en mode strict.

Limitations connues

• Les règles de staging ne sont pas générées (Cobalt Strike). Si votre profil CS a set host_stage "true" (ou ne le définit pas du tout), le script vous avertira et ignorera les URI de stager. Ajoutez set host_stage "false"; à votre profil, ou passez les URI de stager explicitement via --extra-uri.
• La correspondance de préfixe Sliver est plus large que la correspondance exacte de CS. Avec Sliver, la route proxy prend en charge toute URL commençant par /api, /static, etc. Les sondes de scanner qui utilisent ces préfixes (par ex. /api/.env) seront envoyées au team server plutôt que bloquées localement — mais le transport HTTP de Sliver lui-même s'authentifie via l'ID d'implant, donc les requêtes non autorisées sont rejetées au niveau C2. Le filtrage UA empêche tout de même la plupart des scanners d'entrer.
• Un seul backend par exécution. Chaque route proxye vers le même --backend. Si vous avez besoin de plusieurs team servers, exécutez le script plusieurs fois et fusionnez manuellement.
• L'analyse des URI de profil est basée sur les lignes (Cobalt Strike). set uri "/path1 /path2"; fonctionne (plusieurs chemins sur une seule ligne), mais un formatage inhabituel pourrait faire planter l'analyseur. Vérifiez la liste des routes dans le résumé pour confirmer.
• La vérification du certificat du backend HTTPS est désactivée par défaut. Les team servers ont généralement des certificats auto-signés, donc la configuration générée inclut . Si votre backend a un vrai certificat, supprimez cette ligne du fichier généré.

Crédits

Le Malleable-Redirector basé sur Apache a été le point de départ de ce que ce script génère, même modèle d'URI à trois voies (URI de profil / URI supplémentaires / URI laxes), mêmes modes de politique, même disposition générale. CaddySmith traduit simplement la sortie en syntaxe Caddy au lieu d'Apache .htaccess.

Licence

MIT