O bypass de MFA descrito no advisory conjunto AA26-222A, publicado em 10 de agosto de 2026 pelo FBI, CISA, NSA e parceiros internacionais, mostra que o ransomware Gunra não quebra o fator adicional de autenticação: ele reescreve o processo que o valida. Em ao menos uma vítima, o grupo Gunra modificou arquivos de processamento de autenticação em um portal VDI para aceitar um OTP específico escolhido pelos atacantes, mantendo o bypass de autenticação multifator de forma contínua. Para o SOC, a consequência é direta: logins comprometidos continuam aparecendo como autenticações legítimas com segundo fator válido, então a triagem precisa migrar de “houve segundo fator?” para “o segundo fator se comporta como variável aleatória?”.
Como o Gunra contorna o MFA
Segundo o advisory, a cadeia de ataque começa na borda: os atores exploram CVEs de bypass de autenticação em firewalls e VPNs expostos, como CVE-2024-55591 e CVE-2025-24472, ou aproveitam contas com credenciais padrão em appliances SSL-VPN sem controle de bloqueio de conta. Dentro da rede, eles manipularam a funcionalidade de controle de tráfego do SSL-VPN para coletar credenciais e informações de sessão de usuários que autenticavam em um portal corporativo de VDI; em seguida, os atacantes usaram cookies de sessão roubados para realizar sequestro de sessão e se passar por usuários legítimos. O passo final é o mais insidioso: a alteração dos arquivos de processamento de autenticação no servidor do portal para que um valor de OTP escolhido pelo grupo sempre autentique com sucesso, além da remoção da exigência de troca de senha em uma conta com acesso às duas redes. O guia de detecção e resposta ao Gunra já cobria a visão geral da operação; este texto foca no elo que a maioria dos playbooks de SOC ainda não cobre. Vale lembrar a escala do grupo: o Gunra surgiu em abril de 2025 como variante de dupla extorsão derivada do código-fonte vazado do Conti e passou a operar como ransomware-as-a-service no início de 2026, com vítimas publicadas em leak site abrangendo saúde, finanças, manufatura, transporte e governo.
Sinais para o SOC priorizar
O coração da detecção está em tratar o MFA como dado observável, não como caixa marcada. O advisory mapeia a alteração do processo de autenticação à sub-técnica T1556.006, Modify Authentication Process: Multi-Factor Authentication, documentada no MITRE ATT&CK. A tabela abaixo resume os sinais com maior valor de triagem e onde hunt por eles.
| Sinal | Onde caçar | Técnica ATT&CK |
|---|---|---|
| Mesmo valor de OTP repetido em logins distintos | Logs de autenticação do portal VDI | T1556.006 |
| Cookie de sessão reutilizado de novo IP ou dispositivo | Telemetria do SSL-VPN e do proxy | T1539 |
| Login sem bloqueio após várias falhas | Console do appliance VPN | T1078 |
| Troca obrigatória de senha desativada em conta | Auditoria do Active Directory | T1098 |
| Execução de secretsdump.py em controlador de domínio | EDR e Sysmon | T1003.003 |
O primeiro sinal é o mais específico: um OTP legítimo muda a cada autenticação, portanto repetição de valor entre sessões diferentes é indicador forte de manipulação do processo. Os demais servem como pivô de investigação quando o primeiro não está disponível no repositório de logs.
Procedimento de resposta ao bypass
Após confirmar um caso suspeito, execute a resposta em ordem para não destruir evidência antes de conter o acesso:
- Exporte os logs de autenticação do portal VDI e do SSL-VPN dos últimos 30 dias e agrupe os valores de OTP por conta de usuário.
- Marque as contas cujo valor de OTP se repetiu entre sessões distintas; esse é o indicador central da manipulação de autenticação.
- Compare o IP e o fingerprint de dispositivo associados a cada cookie de sessão e invalide todas as sessões ativas das contas afetadas.
- Verifique a integridade dos arquivos de processamento de autenticação no servidor do portal: hash conhecido, data de modificação e eventos de reinício de serviço na janela suspeita.
- Audite contas sem política de bloqueio ou com exigência de troca de senha removida e corrija a configuração.
- Hunte por uso de psexec.py, smbclient.py e secretsdump.py via EDR; o secretsdump alimenta ataques de pass-the-hash descritos em detalhe no artigo sobre detecção de movimento lateral com Pass the Hash.
- Reemita credenciais, cookies e segredos de MFA das contas afetadas e mantenha monitoração reforçada por 14 dias.
Comparação das técnicas de evasão
As três rotas de evasão do Gunra exigem detecções diferentes e complementares. O sequestro de sessão com cookies roubados é visível em telemetria de rede e de proxy, porque o mesmo token aparece em contextos de dispositivo distintos. A alteração do processo de autenticação só aparece em logs de aplicação e verificação de integridade de arquivo no servidor de autenticação, o que exige que o SOC tenha essa fonte ingerida no SIEM. Já o abuso de credenciais padrão sem bloqueio de conta é um defeito de configuração do appliance, detectável com auditoria contínua de hardening. Um playbook maduro contra o Gunra cobre as três camadas em paralelo, porque o advisory mostra os atores combinando as técnicas na mesma intrusão.
