Sliver e Mythic (Frameworks de C2 para Emulação)

Nota da pasta 02 - Ferramentas de Emulação, no Capítulo 19 (Purple Teaming Contínuo).
Trata do Sliver e do Mythic como frameworks open source de comando e controle usados em red team interno autorizado e na validação de detecções de C2, incluindo beaconing, DNS e HTTPS.
Dialoga com a nota de Caldera da mesma pasta, com o hunting de comando e controle do Capítulo 08 e com os limites éticos de escopo do Capítulo 12.

1. Contexto e Posicionamento na Biblioteca

Validar a detecção de comando e controle com tráfego simulado demais produz uma falsa sensação de cobertura. Regras de beaconing, detecção de DNS anômalo e análise de certificados só podem ser testadas de verdade quando um canal real de C2 opera contra a rede observada, com timing, criptografia e volume parecidos com os de um adversário. Os frameworks Sliver e Mythic, ambos open source e mantidos publicamente, são os instrumentos consagrados para esse tipo de emulação controlada em red team interno autorizado e em exercícios purple team.

Esta nota delimita o papel dos dois frameworks dentro do capítulo: eles fornecem o canal de C2 realista que o Caldera não entrega nativamente, e consomem, na prática, a mesma disciplina de escopo, autorização e limpeza. A nota dialoga com o hunting de comando e controle do Capítulo 08, que descreve o que caçar, e com a pasta 03 deste capítulo, que mede se as detecções correspondentes alertaram. O conteúdo é descritivo e defensivo: a ênfase está nas características de tráfego que esses frameworks produzem e em como transformá-las em testes de detecção, não em receitas de ataque.

2. Por Que Frameworks de C2 Reais na Emulação Controlada

Um canal de C2 real exercita a pilha inteira de detecção de rede e endpoint. No endpoint, o implantante gera processos, carregamento em memória e comportamento de pós-exploração que testam as regras de EDR. Na rede, o beacon periódico sobre HTTPS, DNS ou mTLS exercita o NDR, o Zeek, o Suricata e as regras de correlação de proxy. Nenhuma simulação sintética reproduz essa combinação com fidelidade suficiente para validar detecções de produção, porque os detalhes que importam, jitter, tamanho de pacotes, renovação de sessão e handshake TLS, estão justamente no canal real.

Há, por outro lado, um custo de risco que precisa ser reconhecido antes de qualquer implantação. Um framework de C2 rodando dentro da rede é funcionalmente indistinguível de uma intrusão para todos os efeitos operacionais, e um erro de configuração pode transformar um exercício em incidente. Por isso, a premissa desta nota é red team interno autorizado, com ambiente de teste dedicado ou escopo rigidamente delimitado, e a parte de limites éticos é tratada em seção própria mais adiante.

3. Sliver: Características e Papel na Emulação

O Sliver é um framework de C2 escrito em Go, mantido como projeto open source, que se destaca pela facilidade de gerar implantes multiplataforma e pela variedade de canais de comunicação. Ele suporta listeners de mTLS, HTTP e HTTPS, e ainda túneis sobre WireGuard, com geração de certificados próprios por sessão. O modo multiplayer permite que vários operadores compartilhem a mesma sessão de servidor, o que se encaixa bem em exercícios purple com observadores de defesa acompanhando em tempo real. A tabela resume os aspectos operacionais relevantes para validação de detecção.

Para o purple team, o Sliver é a escolha natural quando o objetivo é testar detecções de rede contra um C2 moderno, com canais criptografados e perfil de tráfego configurável. A configuração de beacon e jitter permite reproduzir perfis documentados de atores reais, aproximando o teste das características que as regras de produção deveriam capturar.

4. Mythic: Arquitetura de Containers e Ecossistema de Agentes

O Mythic organiza cada componente como contêiner: servidor central, agentes, payload types e tradutores rodam isolados e conversam via filas de mensagens, o que dá ao framework modularidade acima da média. O catálogo de payload types inclui agentes consolidados para Windows, Linux e macOS, e a arquitetura aberta permite que a equipe desenvolva um agente próprio quando o cenário exige. A interface web centraliza tarefas, saídas e colaboração entre operadores, com histórico completo de cada ação, que é exatamente o registro que o time roxo precisa para cruzar com a telemetria do SIEM.

A arquitetura de contêineres do Mythic vale um mapa rápido de componentes, porque é ela que define onde cada peça do teste de canal vive e o que precisa estar isolado.

Para o time roxo, a combinação de c2 profile e parâmetros de canal é o principal dial de controle do experimento. Variar protocolo, intervalo e jitter mantendo o mesmo agente isola a variável testada, e o histórico do banco de dados fornece a linha do tempo exata de cada tarefa para o cruzamento com o SIEM.

5. Características de Tráfego que Geram e Como Testá-las

Os dois frameworks produzem padrões de tráfego com assinaturas observáveis, e é sobre essas assinaturas que as detecções devem ser construídas e testadas. A tabela consolida as principais oportunidades por canal, servindo de roteiro para desenhar os cenários de validação.

A validação segue a lógica do ciclo purple: executar o cenário, observar se a regra dispara e registrar o resultado. Para beaconing HTTPS, a consulta KQL a seguir exemplifica a verificação no SIEM de periodicidade de conexões a um destino fixo na janela do teste, considerando um implantante com beacon de aproximadamente 30 segundos.

// Periodicidade de conexões de saída na janela do teste de C2
DeviceNetworkEvents
| where Timestamp between (datetime(2025-10-07 09:00) .. datetime(2025-10-07 10:00))
| where RemotePort == 443 and InitiatingProcessFileName =~ "svchost.exe"
| summarize Sessoes = count(), Primeira = min(Timestamp), Ultima = max(Timestamp)
  by DeviceName, RemoteIpAddress, InitiatingProcessFileName
| where Sessoes >= 40
| extend Janela = Ultima - Primeira

Se a consulta revela o padrão do implantante, mas nenhuma regra de beaconing disparou, o resultado é só telemetria e a regra vai para o backlog. Se nem a telemetria de rede chegou, o gap é de coleta. O mesmo raciocínio se aplica às regras de DNS, com consultas agregadas por domínio e medida de entropia, e às regras de certificado, com o inventário de JA3 da rede.

Para a detecção do canal DNS, o exemplo a seguir mostra uma regra Sigma simplificada que a emulação deve disparar em laboratório antes de a regra entrar em produção.

title: Consultas DNS com rótulos longos em dominio interno raro
status: experimental
logsource:
  category: dns
detection:
  selection:
    query|re: '^[a-z0-9]{40,}\..*'
  filter_lab:
    query|endswith: '.lab.local'
  condition: selection and not filter_lab
fields:
  - client_ip
  - query
falsepositives:
  - servicos de telemetria com identificadores longos
level: high

O filtro de laboratório é deliberado e didático: em produção o domínio do laboratório não existe, mas a regra precisa ser validada em ambiente que inclua o tráfego normal do parque, e não apenas o tráfego do teste. É por isso que os cenários de C2 rodam em rede espelhada com sensores reais, e não em um laboratório estéril que gera resultado otimista.

6. Cenário de Teste: Validação de Detecção de Beaconing

O cenário de referência roda em rede de laboratório conectada a um sensor de rede espelhado, com um host Windows de teste e o servidor de C2 em uma sub-rede controlada. O passo a passo ilustra como a emulação se organiza sem jamais tocar a produção.

Cenário pt-c2-beaconing-01
Objetivo: validar regra de beaconing HTTPS do SIEM e regra Suricata de canal anômalo
Escopo: host LAB-PT-WIN-01, rede 10.30.0.0/24, janela 09:00 às 11:00, autorização PT-2025-18
Passos:
  1. Subir listener HTTPS do Sliver na sub-rede de teste, com beacon de 30s e jitter de 20%
  2. Gerar implantante com perfil de processo de atualização e registrar hash no repositório
  3. Executar implantante no host de teste e manter sessão por 60 minutos
  4. Verificar no SIEM a regra de beaconing e no NDR os alertas de canal anômalo
  5. Repetir com canal DNS, 60 minutos, para validar a regra de DNS anômalo
Resultados esperados: alerta de beaconing em até 10 minutos de sessão; alerta DNS em até 15
Regras de engajamento: nenhum acesso à produção, sem execução de comandos destrutivos,
limpeza do implantante e do listener registrada na ata da rodada

A leitura dos resultados segue a ficha de resultado padrão do capítulo, com a classificação detectado, só telemetria e não detectado por regra avaliada. O cenário DNS é particularmente instrutivo, porque as regras de DNS anômalo costumam depender de agregações por domínio que precisam de volume suficiente, e o teste de 60 minutos existe justamente para gerar esse volume de forma controlada.

A consolidação da rodada cabe em uma tabela pequena, e é ela que entra no painel de cobertura.

Esse formato fecha o ciclo da mesma forma para qualquer framework de C2 usado, o que permite comparar rodadas de Sliver e de Mythic na mesma régua. A régua comum é o que transforma a emulação de canal em métrica de programa, e não em anedota de exercício.

7. Limites Éticos e de Escopo

Frameworks de C2 são ferramentas de duplo uso por definição, e a fronteira entre validação defensiva e ataque é puramente organizacional e jurídica. A emulação descrita nesta nota pressupõe autorização formal por escrito, com escopo de ativos, janela temporal, contatos de emergência e critérios de abortagem definidos antes do primeiro listener subir. Sem esse envelope, a execução não acontece, independentemente da sofisticação da equipe.

Os limites operacionais específicos de C2 merecem itemização, porque são diferentes dos limites de teste de técnica isolada.

• Nunca apontar listeners ou implantantes para ativos fora do escopo autorizado, incluindo estações de analistas e redes administrativas.
• Não usar credenciais reais de usuários de produção em teste; crie contas de laboratório dedicadas e revogue ao final.
• Não exfiltrar dados reais; use arquivos armadilha com conteúdo sintético e marcado, para que o volume seja testável sem risco.
• Manter inventário de implantantes com hash, host e horário, e remover todos ao fim da rodada, verificando a ausência de comunicação residual.
• Tratar o servidor de C2 como ativo crítico: rede isolada, autenticação forte, backup mínimo e monitoramento do próprio servidor.
• Registrar tudo no relatório da rodada, incluindo desvios de escopo, para que o exercício seja auditável meses depois.

8. Erros Comuns e Pontos de Atenção

• Testar detecções de C2 apenas com tráfego sintético gerado por script, que nunca reproduz handshake TLS, timing e volume de um canal real; use os frameworks, em escopo controlado, para esse tipo de validação.
• Esquecer de combinar a janela com o SOC, gerando alertas reais de possível intrusão; a confusão entre exercício e incidente custa confiança e tempo de triagem.
• Configurar jitter e intervalos de beacon irreais, como 1 segundo fixo, e validar regras contra um padrão que nenhum adversário moderno usa; desenhe o teste a partir dos perfis de ator prioritários.
• Avaliar somente regras de rede e ignorar as de endpoint, ou vice-versa; o canal real exercita as duas camadas, e o cenário deve medir as duas.
• Deixar o servidor de C2 acessível de redes amplas após o exercício, transformando infraestrutura de teste em superfície de risco; desligue listeners ao fim da janela.
• Reproduzir cenários públicos de abuso sem adaptação, executando cargas que o laboratório não suporta; adapte cada passo ao ambiente e leia a documentação do framework antes.

9. Integração com o Restante da Biblioteca

Os resultados dos cenários de C2 alimentam o mesmo índice de resultados do painel de cobertura da pasta 03, e as lacunas de detecção de beaconing, DNS e TLS retornam como backlog de regras para a engenharia de detecção. As técnicas de hunting de comando e controle do Capítulo 08 são o referencial do que as regras devem capturar, e as notas de hunting de DNS, HTTP e TLS do mesmo capítulo descrevem os campos exatos que o cenário precisa gerar para ser útil.

Na direção da inteligência, os perfis de atores prioritários definem os parâmetros dos canais emulados, de intervalo de beacon a protocolo preferido, e o resultado do teste informa o relatório de maturidade de detecção por ator. Em conjunto com Caldera e Atomic Red Team, o Sliver e o Mythic completam o arsenal de emulação do capítulo: técnicas isoladas, cadeias encadeadas e canais de C2 realistas, todos medidos pelo mesmo painel.