Como detectar Mythic no tráfego de rede: regras e limites
Uma análise técnica publicada pela Kaspersky detalha padrões de tráfego usados por agentes do framework Mythic e propõe assinaturas (Suricata) e técnicas comportamentais para Network Detection and Response (NDR). O trabalho descreve múltiplos canais de comunicação e pontos fracos de detecção.
Descoberta e escopo / O que mudou agora
O artigo documenta em detalhe como o Mythic, um framework de pós‑exploração de código aberto, emprega diversos transportes — SMB, TCP, HTTP(S), WebSocket, Discord e GitHub — para estabelecer C2. A análise inclui exemplos de pacotes e regras direcionadas a padrões estáveis, como a presença de um UUID no início dos blocos Base64 que carregam a carga útil (formato: base64(UUID+AES256(JSON))).
Vetor e exploração / Mitigações
Mythic opera em dois modos principais: P2P (agentes comunicam‑se entre si via SMB/TCP) e egress direto (agentes falam com o servidor C2 via HTTP/S, WebSocket, ou serviços de terceiros). A análise identificou vários indicadores aproveitáveis por NDR/IDS:
- Nome de pipe SMB tipicamente igual ao UUID do agente (padrão regex para UUID);
- Blocos com payloads Base64 que, após decodificação, iniciam com UUID seguido por payload cifrado AES‑256;
- Padrões HTTP/Discord/GitHub nos endpoints de API usados para publicar mensagens, comentários ou arquivos com conteúdo codificado em Base64 contendo o UUID do agente.
Kaspersky propõe assinaturas Suricata para detecção em SMB, TCP, HTTP e WebSocket que buscam especificamente o padrão UUID dentro de dados Base64, além de regras comportamentais para identificar conexões frequentes a serviços como discord.com e api.github.com vindas de segmentos de rede atípicos.
Como mitigações práticas, a publicação recomenda uso de NDR com regras adaptadas ao ambiente e inspeção de tráfego TLS quando possível (TLS inspection) para permitir análise de conteúdo em transportes que usam HTTPS. Onde a descriptografia não for viável, a sugestão é afinar regras comportamentais (freqüência de conexões, padrões DNS) e combinar telemetria de rede com logs de endpoint para correlação.
Impacto e alcance / Setores afetados
Mythic é usado por diversos atores maliciosos, inclusive em operações APT e campanhas de penetração que requerem pivoting e exfiltração. O uso de transportes legítimos (Discord, GitHub) dificulta distinção entre tráfego benigno e malicioso, elevando a necessidade de ajustes finos em ambientes empresariais. Organizações com políticas frouxas de egress (acesso irrestrito a APIs públicas) e infraestruturas que não monitoram detalhadamente tráfego DNS/TLS são as mais expostas.
Limites das informações / O que falta saber
O relatório fornece regras e amostras de tráfego, mas ressalta limitações: assinatura estática falha quando tráfego é totalmente criptografado (SMBv3 com criptografia, HTTPS sem TLS inspection) ou quando operadores do Mythic alteram padrões (mudar nome de pipe, alterar formato do payload). As regras propostas exigem ajuste conforme contexto de rede e podem gerar falsos positivos, especialmente em ambientes com uso legítimo intensivo de GitHub/Discord.
Repercussão / Próximos passos
Para equipes de defesa, os próximos passos indicados no material são:
- Implementar as regras-padrão disponibilizadas e testá‑las em modo de detecção sem bloqueio para calibrar thresholds;
- Habilitar TLS inspection em pontos críticos para permitir análise de conteúdo das comunicações covertas; quando não for possível, empregar detecção comportamental baseada em frequência de conexões e padrões DNS;
- Correlacionar alertas de NDR com EDR/telemetria de endpoints para reduzir falsos positivos e facilitar caça a ameaças;
- Avaliar uso de listas de bloqueio e segmentação de rede para limitar acessos a serviços de terceiros usados como canais C2.
O trabalho inclui exemplos práticos de regras Suricata (SMB, TCP, HTTP, WebSocket) e referencia perfis de transporte Mythic no GitHub para auxiliar integração em soluções NDR. Fonte: Securelist / Kaspersky. Consulte o relatório original para as regras completas e os exemplos de pacotes antes de implantá‑las em produção.