Enquanto muita empresa ainda discute se deve exigir troca de senha a cada 90 dias, o jogo real já mudou. O risco que mais vem crescendo não é apenas o phishing clássico, nem o ransomware em si: é o roubo de sessão, de cookies e de tokens por infostealers e fluxos legítimos de autenticação abusados por criminosos. Em fóruns como o Reddit, esse tema aparece cada vez mais como “o risco subestimado” que pega times de surpresa. E o problema é simples de resumir: se o atacante entra com uma sessão válida, boa parte dos controles pensados para barrar “login suspeito” chega tarde demais.

Esse ponto importa porque o discurso de segurança em muitas organizações ainda está preso a uma ideia confortável: ativar MFA resolveria quase tudo. MFA continua essencial, mas sozinho já não basta. O que os casos recentes mostram é uma mudança de foco do invasor. Em vez de insistir em quebrar a porta, ele prefere sequestrar a credencial já autenticada. Para quem opera Microsoft 365, ambientes SaaS, acesso remoto, contas de desenvolvedor e painéis administrativos, isso tem impacto direto na superfície de risco.

O gatilho da pauta: o “risco subestimado” que voltou a aparecer

Uma discussão recente no Reddit sobre os riscos de cibersegurança que as empresas ainda subestimam chamou atenção por um padrão: muita gente experiente deixou de apontar apenas ransomware ou zero-day e passou a destacar infostealers, roubo de cookie, abuso de OAuth e sequestro de sessão. Isso não é só papo de fórum. O valor do Reddit, aqui, é funcionar como radar de percepção operacional: aquilo que administradores e analistas começam a relatar com insistência geralmente vira incidente recorrente pouco depois.

O mérito dessa leitura é que ela foge do sensacionalismo. Não se trata de dizer que senhas morreram ou que o MFA é inútil. O ponto é outro: os ataques mais eficientes hoje exploram o intervalo entre “usuário autenticado” e “sessão confiável”. Quando a organização protege apenas o momento do login e ignora o que acontece depois, fica exposta.

Por que o MFA deixou de ser resposta suficiente quando usado sozinho

A recomendação da CISA segue correta: adotar MFA resistente a phishing é melhor do que depender de push simples ou códigos fáceis de interceptar. O problema é que muitas empresas ouviram apenas a metade da mensagem. Implementaram MFA, marcaram a caixa de conformidade e seguiram em frente sem revisar sessão, consentimento OAuth, postura do endpoint e monitoramento de tokens.

Na prática, o criminoso não precisa mais roubar a senha se conseguir:

  • capturar cookie de sessão no navegador;
  • coletar token em endpoint já comprometido;
  • induzir o usuário a autorizar um fluxo legítimo;
  • abusar de device code, consentimento OAuth ou reautenticação enganosa.

É por isso que tanta organização “com MFA em tudo” ainda sofre takeover. O login até foi protegido. A sessão, não.

Infostealers mudaram a economia do crime digital

O avanço dos infostealers não é só técnico; ele é econômico. A Microsoft descreveu em 2026 como essas campanhas passaram a atingir também macOS, usar linguagens cross-platform como Python e abusar de plataformas confiáveis para distribuição. O que isso muda? Escala, adaptabilidade e acesso a dados mais valiosos: senhas salvas, cookies, sessões autenticadas, segredos de desenvolvimento, carteiras, credenciais corporativas e tokens.

Esse detalhe é decisivo. Um infostealer não precisa “invadir” o tenant com uma técnica sofisticada de pós-exploração se o próprio endpoint já entregar ao atacante o que ele precisa para entrar como usuário legítimo. Em ambientes com BYOD, equipes remotas e desenvolvedores usando múltiplas contas em navegadores, a combinação fica especialmente perigosa.

Há também um efeito colateral importante: o infostealer vira abastecedor de outras etapas do crime. Credenciais roubadas alimentam fraude, BEC, extorsão, movimento lateral e, mais tarde, ransomware. Em outras palavras, o malware que muita empresa ainda trata como “roubo de navegador” pode ser apenas a primeira peça de uma cadeia bem mais cara.

O caso do device code phishing mostra a sofisticação do problema

Se alguém ainda acha que esse tema é teórico, basta olhar para o crescimento do device code phishing. Microsoft e Proofpoint documentaram campanhas em que o atacante usa um fluxo legítimo de autorização para induzir a vítima a autenticar uma aplicação ou dispositivo. Não há site falso tosco, não há página obviamente clonada, e muitas vezes a vítima interage com telas reais da Microsoft.

Esse modelo é perigoso por três motivos:

  • ele reduz sinais clássicos de phishing para o usuário;
  • ele entrega tokens válidos ao invasor;
  • ele aproveita a confiança que a vítima já deposita no provedor de identidade.

No caso relatado pela Microsoft sobre a campanha atribuída ao grupo Storm-2372, a técnica foi usada contra governos, ONGs e setores sensíveis, com persistência viável enquanto os tokens permaneciam válidos. É o tipo de ataque que desmonta a visão simplista de que “se tem MFA, está resolvido”. O usuário pode completar o MFA corretamente e ainda assim entregar acesso.

Roubo de sessão é pior do que parece porque contorna a lógica de vários controles

Boa parte das defesas corporativas foi desenhada para responder a anomalias no momento da autenticação: senha errada, origem suspeita, falha de MFA, geolocalização incomum, tentativa em massa. Mas quando o atacante usa um cookie ou token já emitido, ele entra por uma trilha mais limpa.

Isso afeta inclusive times maduros, porque o incidente tende a parecer atividade normal no começo. A conta continua autenticando, às vezes a partir de infraestrutura legítima, com permissões legítimas e APIs legítimas. O resultado é atraso na detecção. E em segurança, atraso costuma ser o que separa “alerta controlado” de “crise com impacto operacional”.

Outro erro comum é delegar todo o problema ao time de identidade. Sessão roubada é tema de identidade, sim, mas também de endpoint, navegador, awareness, governança de aplicações, revogação, telemetria e resposta. Quando a defesa fica compartimentada demais, o atacante agradece.

Os sinais que muitas equipes ignoram até virar incidente

Os indícios raramente aparecem como um grande alarme único. Em geral, o problema começa com sinais pequenos e dispersos:

  • aplicações OAuth novas ou pouco conhecidas sendo autorizadas sem revisão;
  • crescimento de logins válidos em dispositivos não gerenciados;
  • alertas de navegador, extensões suspeitas ou download de suposto utilitário “urgente”;
  • usuários recebendo códigos, QR codes ou pedidos de autenticação fora de contexto;
  • sessões persistentes demais para contas privilegiadas;
  • acessos legítimos a SaaS seguidos de exportação incomum de dados.

O problema é cultural: como esses sinais não lembram o “ataque clássico”, acabam tratados como ruído operacional. Só depois, na investigação, percebe-se que o ruído era o ataque.

O que fazer na prática: cinco decisões que reduzem risco de verdade

Não existe bala de prata, mas há um conjunto de decisões que reduz bastante a exposição. E quase todas são mais sobre disciplina operacional do que sobre comprar mais ferramenta.

  1. Suba o nível do MFA
    Onde for possível, priorize métodos resistentes a phishing, como passkeys e chaves FIDO2. Se ainda estiver em push, use number matching e reduza aprovações automáticas.
  2. Trate endpoint como peça central da identidade
    Se o dispositivo está comprometido, a identidade também está. Endpoints sem gestão, EDR fraco ou navegador fora de política viram fonte de tokens e cookies para o atacante.
  3. Revise consentimento OAuth e device code
    Restrinja quem pode consentir aplicações, monitore novos grants e avalie limitar ou controlar fluxos de device code em perfis onde ele não faz sentido.
  4. Encurte a vida útil e aumente a vigilância sobre sessões
    Reautenticação contextual, revogação rápida, checagem de risco e atenção a refresh tokens importam tanto quanto a política de senha.
  5. Caçe credenciais e sessões expostas antes do atacante monetizar
    Monitorar vazamentos, stealer logs e indícios de credenciais corporativas em dispositivos não gerenciados deixou de ser luxo. Hoje é higiene básica.

Checklist prático para a próxima semana

  • Mapear quais grupos ainda usam MFA por push sem number matching.
  • Levantar aplicações OAuth com consentimento amplo e revisão fraca.
  • Verificar se contas privilegiadas têm sessão excessivamente longa.
  • Auditar acessos SaaS originados de dispositivos não gerenciados.
  • Confirmar se há telemetria para revogação de token e anomalias de sessão.
  • Revisar campanhas internas de awareness para incluir QR code, device code e falso pedido de reautenticação.
  • Validar proteção de navegadores e cofre de senhas em endpoints críticos.
  • Criar procedimento rápido para “usuário autorizou algo estranho” com revogação imediata.

O erro estratégico: continuar defendendo 2022 em vez de 2026

Muitas empresas ainda montam seu programa de defesa pensando no atacante que tenta adivinhar senha ou mandar um e-mail mal escrito. Esse atacante ainda existe, claro. Mas os casos mais eficientes hoje são mais silenciosos: enganam o usuário com fluxo legítimo, extraem sessão do endpoint e se movem com identidade válida.

O erro estratégico é continuar investindo quase tudo em barreira de entrada e pouco em proteção da sessão autenticada. É como instalar uma porta blindada e deixar a cópia da chave com quem pegar seu notebook.

O mercado já dá sinais claros de para onde o risco foi. O Reddit captou a mudança de percepção. Microsoft e Proofpoint documentaram campanhas reais. A CISA já vinha insistindo que nem todo MFA oferece a mesma proteção. Ignorar esse conjunto porque “nunca aconteceu aqui” é precisamente o comportamento que faz um risco subestimado virar manchete interna.

FAQ

MFA não vale mais a pena?
Vale, e continua sendo obrigatório. O problema é tratá-lo como solução única. Sem proteção de sessão, endpoint e autorização de aplicações, ele perde parte do efeito.

Passkey resolve tudo?
Não. Passkeys ajudam muito contra phishing tradicional e AiTM, mas não eliminam riscos de endpoint comprometido, roubo de sessão já estabelecida ou consentimento indevido.

Device code phishing é relevante só para grandes empresas?
Não. O alvo pode ser qualquer organização que dependa de Microsoft 365 e fluxos de identidade em nuvem. Empresas menores costumam sofrer ainda mais por terem menos revisão de grants e menos telemetria.

Infostealer é problema só de usuário desatento?
Também não. O vetor pode começar com usuário enganado, mas a exposição real depende de arquitetura, políticas de navegador, gestão de endpoint, privilégio e monitoramento.

Qual a prioridade número um?
Se for preciso escolher uma sequência: fortalecer MFA com resistência a phishing, revisar OAuth/device code e elevar o controle sobre endpoints e sessões. Os três pontos se reforçam.

Conclusão

O risco mais subestimado hoje não é apenas “phishing”, mas o que vem depois dele: a transformação de uma autenticação legítima em acesso ilegítimo. Quem continuar medindo maturidade só por senha forte e MFA habilitado vai descobrir tarde que segurança de identidade virou segurança de sessão, de dispositivo e de contexto. A boa notícia é que dá para reagir. A má notícia é que isso exige sair do piloto automático.

Referências

  • Reddit r/cybersecurity — discussão sobre riscos subestimados em cibersegurança.
  • CISA — Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication.
  • Microsoft Security Blog — Storm-2372 conducts device code phishing campaign.
  • Microsoft Security Blog — Infostealers without borders: macOS, Python stealers, and platform abuse.
  • Proofpoint — Access granted: phishing with device code authorization for account takeover.
  • BleepingComputer — Hackers target Microsoft Entra accounts in device code vishing attacks.