CaddySmith

CaddySmith é um pequeno script em Python que lê um perfil C2 do Cobalt Strike ou Sliver e gera uma configuração do servidor web Caddy a partir dele. O Caddyfile gerado transforma uma máquina Linux comum em um redirecionador: o tráfego legítimo de beacons é proxy reverso para o team server, e qualquer outra coisa (scanners, bots de busca, sondagens da blue team, curl aleatório) é redirecionada para uma URL isca.

Escrevi isso porque o Caddy é um servidor web muito mais amigável para levantar rapidamente do que o Apache, binário estático único, certificados automáticos Let's Encrypt, sem a dança do a2enmod.

Somente engajamentos autorizados. Esta é uma ferramenta de segurança ofensiva. Execute-a apenas contra ambientes para os quais você tenha permissão por escrito para testar.

Formatos de perfil suportados

O CaddySmith detecta automaticamente o formato a partir do conteúdo do arquivo:

• Cobalt Strike — o formato de texto clássico com diretivas set uri "/foo". Cada URI HTTP-GET / HTTP-POST se torna sua própria rota de caminho exato com os cabeçalhos do cliente do perfil aplicados.
• Sliver — a configuração JSON do implant exportada do Sliver. O Sliver não possui URIs fixas; elas são geradas no momento da construção do beacon a partir de listas de caminhos / arquivos / extensões. O CaddySmith lida com isso combinando os prefixos de caminho de nível superior como globs (ex.: path /api* /static* /resources*) e fazendo uma correspondência de substring no número de build do Chrome no UA (que sobrevive às reescritas de UA por plataforma do Sliver).

Você também pode forçar um analisador específico com --profile-type cobaltstrike ou --profile-type sliver.

O que ele faz

Dado um arquivo de perfil, o script extrai:

• A string User-Agent
• URIs (CS) ou prefixos de caminho (Sliver)
• Cabeçalhos do lado do cliente (CS apenas — Sliver não dita cabeçalhos específicos)
• O cabeçalho Host (usado como nome de domínio do redirecionador se você não passar --server-name)
• Se o staging está habilitado (CS apenas — set host_stage)

Em seguida, ele constrói um Caddyfile que:

1. (Opcional) Retorna 403 para tráfego HTTP simples
2. Bloqueia cerca de 15 user agents conhecidos como ruins (curl, nmap, sqlmap, Googlebot, etc.)
3. Bloqueia acesso por IP direto e qualquer método HTTP que não seja GET/POST
4. Faz proxy reverso apenas das URIs do perfil (ou prefixos para Sliver), condicionado ao User-Agent correspondente
5. Bloqueia caminhos comuns de sondagem de scanners (.env, /wp-admin, .php, etc.)
6. Redireciona todo o resto para sua URL isca

Requisitos

• Python 3.7+ (usa apenas a biblioteca padrão, sem necessidade de pip install)
• Caddy 2.x no próprio redirecionador (guia de instalação)

Início 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

Isso escreve a configuração gerada em redirector.caddy e exibe um resumo do que foi feito no stderr.

Implantando a configuração gerada

Opção A: Execute o Caddyfile diretamente

Copie o arquivo gerado para o redirecionador e execute o Caddy com ele. Você precisa da flag --adapter caddyfile porque o Caddy usa JSON como configuração padrão:

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

Para recarregar uma instância em execução com uma configuração atualizada:

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

Se o Caddy avisar sobre inconsistências de formatação, corrija-as com:

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

Opção B: Importar de um Caddyfile principal

Coloque o arquivo em /etc/caddy/ e importe-o do seu Caddyfile principal:

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

Se você passou --email (recomendado), o snippet gerado já contém o bloco de opções globais, então o Caddyfile principal só precisa da linha import. Se não passou, adicione o e-mail manualmente em um bloco { } acima do import.

Em seguida, valide e recarregue:

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

O Caddy provisionará automaticamente um certificado Let's Encrypt para o domínio em --server-name desde que o registro A aponte para o redirecionador.

Todas as flags

Flag	Padrão	O que faz
profile	(obrigatório)	Caminho para o arquivo .profile
--backend	https://teamserver.local:443	Para onde o tráfego correspondido será proxy reverso
--decoy	https://www.example.com/	Para onde o tráfego não correspondido será redirecionado
--server-name	c2.example.com	Nome de domínio do seu redirecionador
--policy	strict	strict, lax ou none
--profile-type	auto	Forçar cobaltstrike ou sliver (padrão: detecção automática)
--extra-uri PATH	—	URI extra para proxy (com verificação de UA). Pode repetir.
--lax-uri PATH	—	URI extra para proxy (sem verificações). Pode repetir.
--allow-ua STRING	—	UA extra permitida nas rotas --extra-uri. Pode repetir.
--forbid-http	off	Retornar 403 para HTTP simples
--email EMAIL	—	E-mail para registro e notificações de renovação do Let's Encrypt
-o, --output FILE	stdout	Escrever a configuração em um arquivo

Modos de política

• strict (padrão) — verifica User-Agent, todos os cabeçalhos do cliente, IP direto, método HTTP e caminhos de sonda
• lax — apenas bloqueia user agents ruins, sem correspondência de cabeçalhos por rota
• none — faz proxy de qualquer requisição para uma URI do perfil, sem filtragem

Strict é o que você normalmente quer. Lax é útil quando você está depurando por que um beacon real não está se conectando.

Um exemplo prático

Digamos que você tenha um perfil que imita um endpoint da Amazon e queira implantá-lo em 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

O resumo mostra exatamente quais rotas foram construídas, ex.:

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

Se você regenerar e ver nenhuma rota, o provavelmente falhou ao analisar seu perfil — verifique os avisos no stderr.

Exemplo com Sliver

Para uma configuração de implant do 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

O resumo informará que o Sliver foi detectado e mostrará a rota de prefixo:

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