Beaconing C2 é o pulso periódico com que um servidor de comando e controle mantém contato com uma máquina comprometida — e é um dos sinais de intrusão mais confiáveis que os logs de rede conseguem revelar. Para detectá-lo, o SOC não precisa inspecionar conteúdo criptografado: basta medir a regularidade estatística das conexões entre cada origem e um mesmo destino, usando os logs de firewall, proxy ou fluxos de rede que a equipe já coleta. Na prática, o canal de comando e controle quase sempre atravessa protocolos comuns como HTTP e HTTPS, misturando-se ao tráfego legítimo da empresa e embutindo os comandos dentro do próprio tráfego do protocolo — comportamento catalogado como T1071 (Application Layer Protocol) no MITRE ATT&CK. O primeiro passo prático é simples: agregue as conexões por origem, destino e porta e compare a variação dos intervalos com a do restante do tráfego.
O pulso que denuncia o invasor
Depois de comprometer um host, o invasor precisa de um canal estável para receber comandos e devolver resultados. Esse canal quase nunca é um serviço exótico: o implante estabelece sessões HTTP ou HTTPS para um servidor externo e repete o pedido de checagem dezenas de vezes por dia. Cada sessão é curta, com pouco tráfego, e o conjunto se estende por horas ou dias — um padrão que a navegação humana raramente produz. A estratégia de detecção da própria página da técnica no MITRE ATT&CK recomenda procurar processos anômalos usando protocolos comuns, com alto volume de bytes de saída ou intervalos semelhantes aos de um beacon, em vez de depender apenas de assinaturas de conteúdo. É essa pista comportamental, e não uma assinatura, que sustenta a caça a beacons em redes de qualquer tamanho.
Por que o jitter engana
Um compasso perfeitamente fixo seria fácil de flagrar. Por isso, frameworks modernos de C2 — como Cobalt Strike, Sliver, Mythic e Brute Ratel — oferecem perfis malleable com um intervalo de sleep somado a uma porcentagem de jitter, que faz os check-ins variarem o suficiente para escapar de detecções de intervalo fixo sem perder a cadência regular que mantém o invasor conectado. Em um cálculo ilustrativo próprio: com sleep de 60 segundos e jitter de 20%, as checagens caem em qualquer ponto entre 48 e 72 segundos. O destino costuma ser um domínio recém-registrado ou de vida curta, sem reputação estabelecida, e o TLS esconde o conteúdo — razão pela qual inspeção de conteúdo e reputação de domínio, isoladas, não sustentam a detecção. O que o atacante não consegue disfarçar por completo é a regularidade estatística do conjunto.
O método do coeficiente de variação
A abordagem estatística que funciona sobre logs de sessão, publicada como detecção pronta pela DF00 Tech, calcula o coeficiente de variação dos intervalos entre as conexões e o coeficiente de variação dos bytes enviados por sessão para cada tupla de origem, destino e porta. O coeficiente de variação é o desvio padrão dividido pela média: quanto mais baixo, mais regular a sequência. Na proposta, cada tupla precisa acumular pelo menos 20 sessões em uma janela de 24 horas, e o alerta dispara quando o CV dos intervalos fica em até 0,15 — com confiança alta quando cai para 0,05 ou menos, acompanhado de CV baixo também no tamanho das requisições.
| Perfil de tráfego | CV dos intervalos | CV dos bytes | Leitura no SOC |
|---|---|---|---|
| Navegação humana interativa | Alto | Alto | Descartar |
| Beacon com sleep e jitter baixo | Baixo | Baixo | Investigar com prioridade |
| Agente de monitoramento legítimo | Baixo | Baixo | Falso positivo típico — allowlist |
| Backup agendado noturno | Variável | Variável | Descartar após baseline |
O procedimento para reproduzir a análise no seu ambiente:
- Exporte as sessões de firewall, proxy ou registros de conexão do Zeek da janela de análise, com carimbo de tempo e contagem de bytes.
- Agrupe por origem, destino e porta; descarte tuplas com poucas sessões para evitar ruído estatístico.
- Calcule média e desvio padrão dos intervalos e dos bytes enviados; derive os dois coeficientes de variação.
- Classifique: CV baixo nos dois eixos eleva a prioridade; CV alto nos dois eixos descarta a tupla.
- Corrobore com idade do domínio, certificado TLS e telemetria do endpoint antes de escalar o alerta.
Consulta prática e Sigma
Antes de ligar o alerta em produção, faça um ciclo de caça: levante os destinos com maior volume de sessões e construa a allowlist de CDNs, APIs SaaS e serviços internos. Depois, transforme a lógica em regra versionada. Sigma é um formato aberto de regras de detecção em YAML que converte uma única regra em consultas para diferentes SIEMs, tornando as detecções portáteis e neutras de fornecedor; a documentação oficial do Sigma mostra o caminho do repositório de detecção como código até a consulta no backend escolhido. Para beaconing, a detecção da DF00 Tech aponta o logsource network_connection e distribui a mesma lógica em KQL, SPL, Elastic e outras plataformas — o time escolhe o idioma sem reescrever a regra.
Falsos positivos e triagem
Beaconing legítimo existe, e é a principal fonte de ruído: agentes de nuvem, clientes de telemetria, verificadores de atualização e health checks de balanceadores batem em intervalos fixos por design. Baselineie esses endpoints de fornecedor e coloque na allowlist antes de ativar o alerta como bloqueante. Na triagem de um alerta real, quatro perguntas resolvem a maioria dos casos: o destino tem relação de negócio com a empresa? O domínio é jovem ou está em hospedagem rotativa? Existe processo no host de origem explicando as conexões — e a ausência de agente EDR no host é, por si só, um sinal? O padrão se sustenta por dias, e não apenas na janela do alerta? Um beacon confirmado raramente vem sozinho: é o estágio que costuma anteceder o movimento lateral com pass the hash e a preparação de cargas de ransomware, como no caso do bypass de MFA pelo ransomware Gunra já analisado aqui — trate o host como comprometido até prova em contrário.
