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

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)

Como o Sliver gera URIs aleatoriamente a partir de combinações de caminho × arquivo × extensão, o correspondente path gerado usa globs de prefixo (path /api* /public* /resources* /services* /static*) em vez de caminhos exatos. O correspondente de User-Agent usa uma substring do número de build do Chrome (ex.: 3921.146), que o Sliver preserva em suas reescritas de UA por plataforma.

Testes de fumaça após a implantação

# Plain HTTP should be 403'd (if you used --forbid-http)
curl -I http://redirector.0xtb.sh/

# Bare hostname should redirect to the decoy
curl -kI https://redirector.0xtb.sh/

# Bad UA should also redirect
curl -kI -A "curl/8.4.0" https://redirector.0xtb.sh/broadcast

# A request with the right UA + path should proxy through (200)
# You need to also send all the profile's client headers in strict mode.

Limitações conhecidas

• Regras de staging não são geradas (Cobalt Strike). Se o seu perfil CS tiver set host_stage "true" (ou não definir isso), o script avisará e pulará as URIs de stager. Adicione set host_stage "false"; ao seu perfil, ou passe as URIs de stager explicitamente via --extra-uri.
• A correspondência de prefixo do Sliver é mais ampla do que a correspondência exata do CS. Com o Sliver, a rota de proxy reivindica qualquer URL começando com /api, /static, etc. Sondas de scanner que por acaso usam esses prefixos (ex.: /api/.env) serão enviadas para o team server em vez de bloqueadas localmente — mas o próprio transporte HTTP do Sliver autentica via ID do implant, então requisições não autorizadas são rejeitadas na camada C2. A filtragem de UA ainda mantém a maioria dos scanners afastados.
• Um backend por execução. Cada rota faz proxy para o mesmo --backend. Se precisar de vários team servers, execute o script várias vezes e mescle manualmente.
• A análise de URI do perfil é baseada em linhas (Cobalt Strike). set uri "/path1 /path2"; funciona (vários caminhos em uma linha), mas formatações incomuns podem atrapalhar o analisador. Verifique a lista de rotas no resumo para confirmar.
• Verificação de certificado do backend HTTPS está desligada por padrão. Team servers geralmente têm certificados autoassinados, então a configuração gerada inclui . Se o seu backend tiver um certificado real, remova essa linha do arquivo gerado.

Créditos

O Malleable-Redirector baseado em Apache foi o ponto de partida para o que este script gera, mesmo modelo de três trilhas de URI (URIs do perfil / URIs extras / URIs lax), mesmos modos de política, mesma estrutura geral. O CaddySmith apenas traduz a saída para a sintaxe do Caddy em vez do .htaccess do Apache.

Licença

MIT