CaddySmith

CaddySmith es un pequeño script en Python que lee un perfil C2 de Cobalt Strike o Sliver y genera una configuración de servidor web Caddy a partir de él. El Caddyfile generado convierte una máquina Linux normal en un redireccionador: el tráfico legítimo de balizas se redirige a tu servidor del equipo, y todo lo demás (escáneres, bots de búsqueda, sondas de equipos azules, curl aleatorio) se envía a una URL señuelo.

Lo escribí porque Caddy es un servidor web mucho más amigable para levantar rápidamente que Apache, un único binario estático, certificados automáticos de Let's Encrypt, sin el baile de a2enmod.

Solo para compromisos autorizados. Esto es una herramienta ofensiva de seguridad. Ejecútala solo contra entornos para los que tengas permiso por escrito para probar.

Formatos de perfil compatibles

CaddySmith detecta automáticamente el formato a partir del contenido del archivo:

• Cobalt Strike — el formato de texto clásico con directivas set uri "/foo". Cada URI de HTTP-GET / HTTP-POST se convierte en su propia ruta exacta con los encabezados del cliente definidos en el perfil.
• Sliver — la configuración del implante en JSON exportada desde Sliver. Sliver no tiene URIs fijas; las genera en tiempo de compilación de la baliza a partir de listas de rutas / archivos / extensiones. CaddySmith maneja esto haciendo coincidir los prefijos de ruta de nivel superior como globs (ej. path /api* /static* /resources*) y realizando una coincidencia de subcadena en el número de compilación de Chrome del UA (que sobrevive a las reescrituras de UA específicas de plataforma de Sliver).

También puedes forzar un analizador específico con --profile-type cobaltstrike o --profile-type sliver.

Qué hace

Dado un archivo de perfil, el script extrae:

• La cadena User-Agent
• URIs (CS) o prefijos de ruta (Sliver)
• Encabezados del lado del cliente (solo CS — Sliver no dicta encabezados específicos)
• El encabezado Host (se usa como nombre de dominio del redireccionador si no pasas --server-name)
• Si el staging está habilitado (solo CS — set host_stage)

Luego construye un Caddyfile que:

1. (Opcional) Devuelve 403 al tráfico HTTP plano
2. Bloquea ~15 agentes de usuario conocidos como malos (curl, nmap, sqlmap, Googlebot, etc.)
3. Bloquea el acceso por IP directa y cualquier método HTTP que no sea GET/POST
4. Redirige solo las URIs del perfil (o prefijos para Sliver), condicionado al User-Agent correspondiente
5. Bloquea rutas de sonda comunes de escáneres (.env, /wp-admin, .php, etc.)
6. Redirige todo lo demás a tu URL señuelo

Requisitos

• Python 3.7+ (usa solo la biblioteca estándar, no necesita pip install)
• Caddy 2.x en el redireccionador (guía de instalación)

Inicio rápido

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

Esto escribe la configuración generada en redirector.caddy e imprime un resumen de lo que hizo en stderr.

Desplegar la configuración generada

Opción A: Ejecutar el Caddyfile directamente

Copia el archivo generado al redireccionador y ejecuta Caddy con él. Necesitas la bandera --adapter caddyfile porque Caddy por defecto usa configuración JSON:

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

Para recargar una instancia en ejecución con una configuración actualizada:

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

Si Caddy advierte sobre inconsistencias de formato, límpialas con:

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

Opción B: Importar desde un Caddyfile principal

Coloca el archivo en /etc/caddy/ e impórtalo desde tu Caddyfile principal:

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

Si pasaste --email (recomendado), el fragmento generado ya contiene el bloque de opciones globales, por lo que el Caddyfile principal solo necesita la línea import. Si no lo hiciste, agrega el email manualmente en un bloque { } antes de la importación.

Luego valida y recarga:

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

Caddy aprovisionará automáticamente un certificado de Let's Encrypt para el dominio en --server-name siempre que el registro A apunte al redireccionador.

Todas las banderas

Modos de política

• strict (por defecto) — verifica User-Agent, todos los encabezados del cliente, IP directa, método HTTP y rutas de sonda
• lax — solo bloquea agentes de usuario malos, sin coincidencia de encabezados por ruta
• none — redirige cualquier solicitud a una URI del perfil, sin filtrado

Strict es lo que normalmente quieres. Lax es útil cuando estás depurando por qué una baliza real no se conecta.

Un ejemplo práctico

Supón que tienes un perfil que imita un endpoint de Amazon y quieres desplegarlo en 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

El resumen te muestra exactamente qué rutas se construyeron, por ejemplo:

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

Si regeneras y ves ninguna ruta, probablemente el script falló al analizar tu perfil — revisa las advertencias en stderr.

Ejemplo con Sliver

Para una configuración de implante de 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

El resumen te indicará que se detectó Sliver y mostrará la ruta de prefijo:

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

Debido a que Sliver genera URIs aleatoriamente a partir de combinaciones de ruta × archivo × extensión, el comparador path generado usa globs de prefijo (path /api* /public* /resources* /services* /static*) en lugar de rutas exactas. El comparador de User-Agent usa una subcadena del número de compilación de Chrome (ej. 3921.146), que Sliver conserva en sus reescrituras de UA específicas de plataforma.

Pruebas de humo después del despliegue

# HTTP plano debería devolver 403 (si usaste --forbid-http)
curl -I http://redirector.0xtb.sh/

# Solo el nombre de host debería redirigir al señuelo
curl -kI https://redirector.0xtb.sh/

# UA malo también debería redirigir
curl -kI -A "curl/8.4.0" https://redirector.0xtb.sh/broadcast

# Una solicitud con el UA correcto + ruta debería redirigir (200)
# También debes enviar todos los encabezados del cliente del perfil en modo strict.

Limitaciones conocidas

• No se generan reglas de staging (Cobalt Strike). Si tu perfil de CS tiene set host_stage "true" (o no lo establece), el script te advertirá y omitirá las URIs de stager. Agrega set host_stage "false"; a tu perfil, o pasa las URIs de stager explícitamente con --extra-uri.
• La coincidencia de prefijos de Sliver es más amplia que la coincidencia exacta de CS. Con Sliver, la ruta de redireccionamiento reclama cualquier URL que comience con /api, /static, etc. Las sondas de escáneres que casualmente usen esos prefijos (ej. /api/.env) se enviarán al servidor del equipo en lugar de bloquearse localmente — pero el transporte HTTP de Sliver autentica mediante el ID del implante, por lo que las solicitudes no autorizadas son rechazadas en la capa C2. El filtrado por UA aún mantiene fuera a la mayoría de los escáneres.
• Un backend por ejecución. Cada ruta redirige al mismo --backend. Si necesitas varios servidores de equipo, ejecuta el script varias veces y combínalos manualmente.
• El análisis de URIs del perfil está basado en líneas (Cobalt Strike). set uri "/path1 /path2"; funciona (múltiples rutas en una línea), pero un formato inusual podría hacer tropezar al analizador. Revisa la lista de rutas en el resumen para confirmar.
• La verificación del certificado del backend HTTPS está desactivada por defecto. Los servidores de equipo suelen tener certificados autofirmados, por lo que la configuración generada incluye . Si tu backend tiene un certificado real, elimina esa línea del archivo generado.

Créditos

El Malleable-Redirector basado en Apache fue el punto de partida para lo que genera este script, el mismo modelo de tres vías de URI (URIs de perfil / URIs extra / URIs lax), los mismos modos de política, la misma disposición general. CaddySmith simplemente traduce la salida a sintaxis de Caddy en lugar de .htaccess de Apache.

Licencia

MIT