Sliver, Mythic, Realm (C2 Frameworks)

Nota da subpasta 03 - Ferramentas de Emulação e Purple Team, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata dos frameworks de comando e controle usados em emulação autorizada: Sliver, Mythic e Realm, com foco em características de tráfego, detecção e validação de NDR.
Dialoga com Caldera, Atomic Red Team e Temperance da mesma pasta, com a nota de Sliver e Mythic do Capítulo 19 e com o hunting de C2 do Capítulo 08.

1. Contexto e Posicionamento na Biblioteca

O canal de comando e controle é o único componente da emulação que o atomic e o plano Temperance não simulam: para validar detecções de C2, beaconing, fingerprinting de TLS e comportamento de implante, é preciso um framework real operado dentro das regras de engajamento. Esta nota cobre os três nomes que dominam essa faixa de uso: Sliver, o framework open source em Go com suporte a multiplayer; Mythic, a plataforma modular multiagente; e Realm, entrada recente da categoria com abordagem agêntica. A nota de Sliver e Mythic do Capítulo 19 cobre os fundamentos, e aqui o aprofundamento é de operação e detecção.

A advertência de escopo abre a nota por obrigação: frameworks de C2 são ferramentas de ofensiva, e seu uso fora de ambiente autorizado é crime. No contexto desta biblioteca, eles operam em laboratório ou em exercícios com autorização formal, infraestrutura dedicada e regras de engajamento assinadas, e o objetivo é sempre defensivo, medir o que a defesa vê.

2. Papel do C2 na Emulação Autorizada

Dentro de um exercício autorizado, o C2 cumpre três funções que nenhuma simulação substitui. Primeira, gerar tráfego realista de beaconing com jitter, criptografia e profiles configuráveis, matéria prima para testar detecções de rede do Capítulo 08. Segunda, exercer o ciclo completo de resposta, desde a detecção do canal até a contenção, porque caçar a sessão e isolar o host é parte do treino. Terceira, medir o NDR e o proxy em condições reais, com protocolos e timing que simuladores estáticos não reproduzem.

A infraestrutura de exercício segue um desenho padrão: servidor de C2 em segmento de teste ou em infraestrutura de nuvem dedicada ao laboratório, domínios de teste controlados, certificados de exercício e registro integral de sessões. O desenho de rede importa mais que a escolha do framework: um C2 excelente em rede mal desenhada ensina pouco, e um framework simples em rede bem instrumentada com Zeek, Suricata e logs de proxy gera o resultado que o programa precisa.

A janela de exercício também tem desenho de telemetria: os relógios dos sensores, proxies e hosts devem estar sincronizados, porque a correlação temporal entre o registro do operador e o evento no sensor é a base da ficha de resultado. Vinte minutos de dessincronia bastam para transformar uma validação em discussão sobre horários, e a checagem de relógio entra no checklist de abertura do exercício junto com a validação de isolamento do segmento.

3. Sliver

O Sliver é o framework open source de referência em Go, com server multiusuário, múltiplos listeners por protocolo, geração dinâmica de implantes e armory de extensões. Os protocolos de listener cobertos incluem mTLS, WireGuard, HTTP e HTTPS com suporte a domínios frontáveis, e DNS, o que permite desenhar exercícios de detecção por protocolo. O modo multiplayer permite que dois operadores dividam a sessão do server com funções e escopos, útil em exercícios com time red e time blue simultâneos.

Na operação, o desenho do exercício passa por três escolhas declaradas: protocolo do listener, perfil de beacon e geração do implante. O listener define o canal a testar, o perfil de beacon define o intervalo e o jitter que a detecção de periodicidade vai encontrar, e a geração define ofuscação e artefatos que o EDR vai ver, com cada escolha registrada na ficha para que o resultado seja reproduzível. Sessão interativa e modo beacon não são intercambiáveis: a sessão interativa simplifica o teste funcional, e o beacon é o que gera telemetria de cadência para o NDR.

A operação típica em exercício de validação de NDR segue o fluxo abaixo, com listener HTTPS dedicado e implante gerado para o host de teste.

1. Subir o server do Sliver no host de exercicio
2. Configurar listener HTTPS com dominio de teste e certificado do exercicio
3. Gerar implante para o alvo com beacon e jitter definidos
4. Executar o implante no host de teste autorizado
5. Registrar sessao, executar comandos de emulacao e manter log
6. Encerrar sessao, remover implante e auditar hosts

Os pontos fortes observados são a facilidade de deploy, o suporte nativo a WireGuard, que permite exercício de detecção de túnel, e a geração de implante com ofuscação configurável. O contraponto é que o projeto é público e muito adotado, o que significa que assinaturas e comportamentos do Sliver já constam de conteúdo de detecção comunitário, e o exercício deve compensar isso com profiles e infraestrutura próprios.

Os sinais de rede mais explorados na detecção do Sliver vêm de três origens combinadas. A pilha TLS do runtime em Go gera fingerprints JA3 e JA4 distintos das pilhas comuns do parque corporativo, a infraestrutura de exercício tende a registrar certificados e domínios recém-criados, e os modos de túnel, como DNS e WireGuard, produzem padrões de payload e handshake pouco frequentes no tráfego normal. Um exercício honesto parte desses sinais públicos para variar configuração, e o time azul valida exatamente a fronteira entre o que o conteúdo comunitário já cobre e o que precisa de regra própria.

4. Mythic

O Mythic organiza o C2 como plataforma colaborativa de agentes e perfis de C2 plugáveis, com arquitetura containerizada, interface de operação compartilhada, controle de tasks por operador e documentação de cada payload type. Essa modularidade é o diferencial central: o exercício pode trocar o agente mantendo a plataforma, testar múltiplos canais na mesma operação e treinar a equipe no padrão de trabalho de red team real, com tasks, callbacks e colaboração registradas.

A distinção entre payload type e C2 profile é o vocabulário que o Mythic impõe e que o programa adota. O payload type é o agente com suas capacidades e seu formato de implante; o perfil de C2 é a configuração do canal que o implante usa para chegar ao servidor; e a combinação dos dois é o que o exercício declara como caso de teste. Essa separação permite validar o mesmo agente sobre canais diferentes, e o resultado de detecção fica atribuído ao canal e não ao implante, o que é a pergunta certa para o NDR.

Para o programa de CTI-TH, o Mythic entrega o melhor ambiente de treino colaborativo: o analista de detecção participa da operação vendo as tasks executadas, correlaciona com a telemetria em tempo real e valida hipóteses de detecção durante o exercício, e não depois. O custo é operacional, com mais componentes para manter, e a recomendação é adotar quando o programa já roda exercícios recorrentes com mais de um operador.

5. Realm

O Realm representa a geração mais recente da categoria, posicionada entre o framework de C2 tradicional e a plataforma de red teaming agêntico, com orquestração assistida por agentes de IA para conduzir emulações e validar controles. O projeto evolui rapidamente, e o tratamento honesto para esta nota é o de categoria: trata-se de plataforma de emulação e validação adversária contínua, na mesma faixa de problema que o Capítulo 19 discute sob purple teaming autônomo, com capacidades de canal e implante no conjunto.

Para o programa, a entrada dessa geração muda o critério de compra: a pergunta deixa de ser qual framework operar manualmente e passa a ser qual nível de automação o time sustenta. Times com operadores experientes extraem mais do par Sliver e Mythic, com controle total; times que buscam validação contínua com equipe enxuta avaliam plataformas agênticas com o mesmo rigor de prova de conceito descrito na nota de TIPs da pasta 01, medindo o que a plataforma realmente detecta e reporta.

A prova de conceito com plataformas agênticas segue critérios declarados antes do teste: o que a plataforma executa sem intervenção humana, o que registra para auditoria, como o operador interrompe uma sequência indesejada e o que ela reporta de volta ao painel de cobertura. Plataforma que não responde essas quatro perguntas com evidência demonstrável está vendendo automação que o programa não pode sustentar, e a avaliação termina aí, sem depender de demonstração de marketing.

6. Características de Tráfego e Detecção

A tabela resume as características de tráfego e as frentes de caça associadas a cada ferramenta, e serve de roteiro para a validação de NDR descrita na seção seguinte.

As técnicas de caça de C2 do Capítulo 08 aplicam diretamente: análise de periodicidade com Fourier sobre timestamps de conexão, caça de JA3 e JA4 incomuns para a pilha da organização, detecção de domínios novos com TTL curto e monitoramento de volumes anômalos por destino. O exercício valida exatamente essas detecções, e a ficha de resultado usa o quadro de status canônico por ability e por canal.

A ponte entre sinal e método merece tabela própria, porque é ela que transforma a lista de características em plano de teste: cada sinal de canal abaixo tem um mecanismo de detecção e um método de caça concreto que o exercício exercita.

A consulta abaixo materializa a primeira linha da tabela em linguagem de detecção gerenciada: conexões por minuto por destino, com média estável e desvio baixo, que é a assinatura de beacon de um nó em cadência fixa. O limiar é propositalmente conservador para laboratório, e a versão de produção ajusta janela e limites pelo volume real do parque.

DeviceNetworkEvents
| where Timestamp > ago(24h)
| summarize conexoes = count() by RemoteUrl, DeviceName, bin(Timestamp, 1m)
| summarize media = avg(conexoes), desvio = stdev(conexoes), minutos = count() by RemoteUrl, DeviceName
| where minutos >= 20 and media between (0.5 .. 2.0) and desvio <= 0.8

O resultado da consulta entra na ficha como evidência positiva ou negativa por caso de teste, com os parâmetros declarados do beacon ao lado do que o sensor capturou. A comparação entre o parâmetro declarado e o metadado capturado é a medida de fidelidade da telemetria, e gap de fidelidade vira ajuste de sensor tanto quanto gap de detecção vira regra.

7. Red Team Interno e Validação de NDR

Para o red team interno, a escolha do framework segue o objetivo do exercício: Sliver quando o objetivo é canal simples e rápido com multiusuário, Mythic quando o objetivo é treinar colaboração e testar múltiplos perfis, plataformas agênticas quando o objetivo é cadência contínua com equipe enxuta. O que não muda é o conjunto de controles do exercício: autorização assinada com escopo e janela, inventário de implantes, registro de sessões, canal de comunicação com o time azul e critérios de parada imediata.

A validação de NDR é o caso de uso com maior retorno medido: o exercício executa beaconing com parâmetros conhecidos, e o time mede taxa de detecção, tempo de detecção e fidelidade dos metadados capturados. A tabela de tráfego da seção 6 define os casos de teste mínimos, e o resultado entra no painel de cobertura da mesma lógica do Capítulo 18, com gaps de rede virando ajustes de sensor, de política de proxy ou de regra de NDR.

As métricas da validação valem três números por caso de teste: taxa de detecção, tempo desde o primeiro beacon até o alerta e fidelidade dos metadados capturados, sempre medidos contra os parâmetros declarados do exercício. Um canal detectado com hora errada e domínio vazio ensina pouco, e a ficha registra a diferença entre ver a conexão e ser capaz de responder por ela.

8. Comparação e Critérios de Escolha

A leitura do critério por linha evita a discussão estéril de qual é o melhor: a pergunta correta é qual modelo de operação o time sustenta com os controles exigidos. Um framework poderoso sem disciplina de inventário e cleanup vira risco, e um framework simples com controles sólidos entrega resultado auditável.

9. Cenário de Teste Autorizado Ponta a Ponta

O cenário abaixo amarra as seções anteriores em um exercício completo de validação de NDR, no formato que o programa usa como gabarito. O objetivo é validar a detecção de três canais distintos com a mesma infraestrutura, e o desenho declara cada elemento do escopo antes de qualquer implante ser gerado.

A execução segue o roteiro abaixo, e cada passo produz registro que a ficha final consome.

1. Publicar autorizacao, escopo e contatos no canal do exercicio
2. Subir infraestrutura de C2 dedicada e validar isolamento
3. Sincronizar relogios de sensores, proxy e host de teste
4. Gerar e implantar o implante no host autorizado
5. Executar os casos de teste com registro por sessao
6. Coletar telemetria de NDR, proxy, DNS e EDR
7. Encerrar, remover implantes e auditar a limpeza
8. Preencher a ficha por caso e arquivar os logs

O fechamento do cenário é o mesmo contrato das rodadas de emulação desta pasta: cada caso de teste recebe status canônico, cada gap recebe dono no backlog, e a infraestrutura é desmontada com auditoria. O gabarito versionado do cenário é reexecutado após as correções de detecção, e a diferença entre rodadas entra no painel de cobertura do Capítulo 18 como evidência de eficácia dos controles de rede.

10. Erros Comuns e Pontos de Atenção

• Operar C2 fora das regras de engajamento, sem autorização, escopo ou janela; a infraestrutura só existe com o papel assinado.
• Reutilizar infraestrutura de exercício para outro fim, contaminando a linha de base de detecção; cada exercício tem domínio, certificado e segmento próprios.
• Esquecer implantes ativos após o exercício, o equivalente em ofensiva de deixar a porta aberta; inventário e remoção auditada fecham a operação.
• Usar configurações padrão de beacon que já constam de conteúdo público de detecção e concluir que a rede está cega; o exercício deve variar perfil e canal.
• Tratar a detecção de C2 como responsabilidade só do NDR; o EDR, o proxy, o DNS e o SIEM têm papéis no mesmo canal, e a ficha valida o conjunto.
• Avaliar plataformas agênticas por demonstração de marketing em vez de prova de conceito com métrica; o rigor da pasta 01 vale aqui integralmente.
• Medir sucesso do exercício pelo número de sessões mantidas e não pelo que a defesa aprendeu; o objetivo é defensivo, e o registro é do time azul.
• Declarar detecção validada sem medir tempo e fidelidade dos metadados; ver a conexão não é responder por ela, e a ficha separa as duas coisas.

11. Integração com o Restante da Biblioteca

Os exercícios de C2 alimentam o hunting de comando e controle do Capítulo 08 com telemetria conhecida e os controles de rede PRT.2 do Capítulo 15 com evidência de eficácia. O ciclo com o resto da subpasta é de escalonamento: atomic para técnica isolada, Temperance para plano curto, Caldera para operação agendada e C2 framework quando a validação exige canal realista, com a ficha de resultado unificando as ferramentas. A nota de Sliver e Mythic do Capítulo 19 permanece como referência de fundamentos, e esta nota cobre a camada de operação e de escolha.

Para a linha de maturidade do programa, a recomendação é começar por Sliver em exercício de NDR com casos de teste mínimos, evoluir para Mythic quando a colaboração se tornar o gargalo, e avaliar a geração agêntica quando a cadência contínua for requisito com equipe enxuta. O fechamento é o lembrete de escopo que abre a nota: essas ferramentas existem nesta biblioteca para medir a defesa, e o registro que elas geram pertence ao time azul, na forma de fichas, gaps com dono e detecções melhores.