Operações de SOC para detecção de ameaças entregam resultado quando transformam inteligência técnica sobre adversários reais em regras, consultas de caça e procedimentos de triagem que qualquer analista do turno consegue executar e auditar. O alerta conjunto #StopRansomware divulgado pela CISA e pelo FBI em 10 de agosto de 2026 sobre o ransomware Gunra é matéria-prima exata para esse ciclo: descreve táticas, técnicas e procedimentos mapeados na matriz MITRE ATT&CK, lista indicações de comprometimento e prioriza mitigações. Segundo o advisory AA26-222A, o Gunra passou a operar como ransomware-as-a-service em 2026, combinando criptografia dos dados com a ameaça de publicar informações exfiltradas em um site de vazamentos dedicado caso o resgate não seja pago. Vítimas já expostas pelos atacantes incluem governo, saúde, finanças, manufatura, transporte, utilities e varejo em múltiplos continentes.
Para a operação de segurança, o documento funciona como pacote de trabalho imediato: cada técnica citada corresponde a eventos pesquisáveis em logs de VPN, Active Directory, EDR e proxies. Este guia resume o que monitorar, como responder e como medir a cobertura resultante sem depender de compra de ferramenta nova.
Da inteligência ao playbook de detecção
O ponto de partida é converter o advisory em itens rastreáveis de cobertura. O MITRE organiza avaliações de SOC em módulos que analisam componentes da operação antes de sintetizar as recomendações finais, método que o centro de operações pode replicar alerta a alerta usando a matriz ATT&CK como referência. Na prática, isso significa uma linha por técnica: gerar o evento em laboratório, conferir se a regra existente dispara, registrar a lacuna quando ela não dispara e abrir demanda com prazo e dono definidos.
A tabela abaixo resume o mapeamento prioritário do Gunra para um SOC médio, com o sinal acionável que cada comportamento deve gerar:
| Técnica na matriz | Comportamento observado no Gunra | Sinal que o SOC deve alertar |
|---|---|---|
| Exploração de aplicativo público | Bypass de autenticação em firewall e VPN expostos | Login administrativo bem-sucedido sem sessão prévia no appliance |
| Contas padrão | Credenciais padrão em console de SSL-VPN sem bloqueio | Uso de conta de appliance nunca vista na autenticação normal |
| SMB em sistemas remotos | psexec.py e smbclient.py do Impacket para movimento lateral | Execução remota via SMB originada fora das estações de administração |
| Dump de credenciais do domínio | secretsdump.py contra controladores de domínio | Leitura do arquivo NTDS fora da janela de backup |
| Pass-the-hash | Reuso de hashes extraídos para acessar sistemas privilegiados | Autenticação NTLM com o mesmo hash em vários hosts |
| Bypass de MFA | Alteração de arquivos de autenticação do portal VDI | Mudança de integridade em binários do serviço de autenticação |
| Sequestro de sessão | Reuso de cookies roubados do tráfego do SSL-VPN | Dispositivo ou país novo mantendo cookie de sessão válido |
O próprio advisory declara usar a matriz MITRE ATT&CK for Enterprise na versão 19.1 como referência de mapeamento. No dia a dia, isso importa porque a verificação de cobertura precisa apontar para a versão vigente da matriz, evitando regras que referenciam técnicas renomeadas ou descontinuadas.
Pontos de entrada que exigem monitoração
A superfície inicial descrita pelo FBI é o equipamento voltado para a internet. O acesso inicial do grupo se apoia na exploração das vulnerabilidades CVE-2024-55591 e CVE-2025-24472, dois bypasses de autenticação que afetam versões específicas de FortiOS e FortiProxy, somados a credenciais expostas e falhas de controle de acesso SSH em gateways VPN. O inventário de appliances expostos é, portanto, o primeiro artefato que a operação precisa manter vivo, com dono, versão instalada e data da última correção.
A polícia nacional da Coreia do Sul observou um caso em que os atores assumiram a conta de administrador de um appliance SSL-VPN explorando credenciais padrão justamente quando o bloqueio após tentativas falhas não estava ativo. Em seguida, baixaram o OpenSSH de um servidor externo controlado por eles para estabelecer túneis entre sistemas comprometidos e manter persistência. Dois alertas saem direto desse relato: alteração de configuração em conta privilegiada de VPN e download de binário SSH iniciado por servidor interno.
Há ainda o caminho pela estação de trabalho do administrador: em uma vítima, o grupo acessou o console administrativo do SSL-VPN a partir de um computador usado por administrador de rede, identificou uma conta sem uso com acesso simultâneo à rede voltada para a internet e à rede corporativa interna e modificou a configuração dela para escapar da troca obrigatória de senha. Correlacione eventos de modificação de conta com sessões administrativas de VPN e com contas inativas que voltam a autenticar.
Movimento lateral e roubo de credenciais
Dentro da rede, o Gunra usa ferramentas legítimas de administração como veículo: as bibliotecas Impacket psexec.py e smbclient.py para executar e mover arquivos via SMB, RDP para alcançar a infraestrutura de desktops virtuais e o secretsdump.py para extrair hashes de contas do arquivo NTDS em controladores de domínio. Com os hashes em mãos, o passo seguinte é pass-the-hash ou pass-the-ticket rumo a sistemas privilegiados; já detalhamos como detectar esse movimento lateral no SOC com regras de correlação de autenticação NTLM.
Sessões roubadas completam o quadro. O grupo manipulou a funcionalidade de controle de tráfego de rede do SSL-VPN para capturar credenciais e informações de sessão de usuários que autenticavam no portal corporativo de VDI e, com os cookies roubados, conduziu sequestro de sessão personificando usuários legítimos. Alertas de viagem impossível e de novo dispositivo mantendo cookie válido são a resposta operacional mínima para esse comportamento.
O bypass de MFA no VDI
O episódio mais instrutivo do advisory envolve autenticação multifator. Em uma das vítimas, arquivos de processamento de autenticação no servidor do portal VDI foram modificados para aceitar um valor de senha única designado pelo próprio grupo, habilitando o bypass contínuo da MFA sem que o usuário percebesse a alteração. O log de autenticação seguia registrando sucesso, então o tráfego parecia normal para qualquer painel que observa apenas falhas de login. Detalhamos os sinais específicos desse ataque no guia sobre bypass de MFA pelo ransomware Gunra no SOC.
A defesa passa a ser verificação de integridade dos binários e scripts do serviço de autenticação, alerta de alteração fora da janela de mudança e correlação de valores de senha única repetidos em janelas longas. Nenhum desses controles exige aquisição: exigem regra escrita, teste e responsável nomeado.
Procedimento de resposta no SOC
A triagem ganha disciplina quando ancorada em processo formal. A revisão mais recente do guia de resposta a incidentes do NIST, a SP 800-61 Rev. 3, trata detecção e resposta como componentes contínuos do gerenciamento de risco descrito no CSF 2.0, o que na prática significa medir a operação pelo ciclo completo: preparação, detecção, análise, contenção, recuperação e aprendizado. O procedimento abaixo ordena o trabalho do SOC diante do Gunra e de variantes com comportamento equivalente:
- Inventariar FortiOS, FortiProxy e demais appliances expostos, aplicar as correções das duas CVEs citadas e revisar histórico de sessões administrativas anômalas desde abril de 2025, quando o Gunra surgiu.
- Auditar contas de administração de SSL-VPN: eliminar credenciais padrão, habilitar bloqueio após tentativas falhas e desativar contas inativas com acesso às duas redes.
- Criar alertas para execuções de Impacket, incluindo psexec.py, smbclient.py e secretsdump.py, e para leitura do arquivo NTDS fora da janela de backup.
- Monitorar integridade dos arquivos do serviço de autenticação do VDI e investigar valores de senha única repetidos com o mesmo conteúdo.
- Correlacionar cookies de sessão com geovelocidade e identificação de dispositivo, investigando sessões que trocam de país sem nova autenticação.
- Segmentar a rede para restringir movimento lateral a partir do primeiro equipamento comprometido e validar a segmentação com teste de rota.
- Manter backups offline e imutáveis em local fisicamente segregado, com restauração testada e tempo de recuperação medido, não apenas declarado.
Métricas fecham o ciclo: percentual de técnicas do advisory com regra correspondente em produção, tempo médio entre publicação do alerta e regra ativa, taxa de falsos positivos das novas detecções e tempo médio de detecção em exercício simulado. Sem métrica, a cobertura existe apenas na apresentação de status.
O Gunra não inventou mecanismos novos; combinou bypass de autenticação em appliance, ferramenta legítima de administração e manipulação do serviço de MFA em sequência testada. Um SOC que mantém inventário vivo, alerta sobre as técnicas mapeadas acima e ensaia restauração de backup encurta a janela de oportunidade desse encadeamento.
