Se você já habilitou MFA e “dormiu tranquilo”, 2026 trouxe um choque de realidade: muitos ataques hoje não tentam “quebrar” MFA — eles roubam o token de sessão (ou cookies) depois que o usuário autentica corretamente. A partir daí, o invasor reaproveita a sessão e acessa e-mail, arquivos e chats como se fosse o usuário, frequentemente sem novo desafio de MFA. É por isso que o hardening moderno precisa atacar token replay, sessão e dispositivo, não só credencial.
A própria Microsoft publica um playbook específico para investigação e resposta a token theft e reforça que é uma ameaça comum em cadeias de ataque modernas. (Microsoft Learn) E a documentação de segurança do Microsoft Entra ID descreve uma estratégia “defense-in-depth” para reduzir exfiltração e replay de tokens. (Microsoft Learn)
A seguir, um artigo prático com checklist de hardening focado em Microsoft Teams e Microsoft 365 — com foco em evitar que um token roubado vire acesso persistente.
Como o roubo de token acontece (em alto nível)
Sem entrar em “como fazer”, os vetores mais comuns são:
- Phishing Adversary-in-the-Middle (AiTM): a vítima autentica em uma página falsa que proxyfica o login real; o atacante captura a sessão já autenticada. A Microsoft descreve esse tipo de ameaça e como “phishing-resistant MFA” ajuda a reduzir o risco. (TECHCOMMUNITY.MICROSOFT.COM)
- Infostealers no endpoint: malware no dispositivo extrai artefatos de sessão e permite replay. A orientação oficial enfatiza endurecimento do endpoint e controles de acesso baseados em dispositivo. (Microsoft Learn)
- Consentimento OAuth malicioso: o usuário concede permissões a um app e o atacante ganha acesso duradouro a dados (muitas vezes sem “barulho” de login). A Microsoft detalha o padrão de “OAuth consent phishing” e recomenda controles de consentimento e governança. (TECHCOMMUNITY.MICROSOFT.COM)
Checklist de hardening (mínimo viável e eficaz)
1) Suba o nível do MFA: “phishing-resistant” para contas de alto valor
MFA por código/sms/push ainda ajuda, mas não é a camada final contra AiTM. O que muda o jogo é exigir métodos resistentes a phishing (como passkeys/FIDO2/Windows Hello), pelo menos para administradores e perfis privilegiados. A Microsoft recomenda políticas específicas para isso e alerta para evitar lockout (habilite com cuidado e piloto). (Microsoft Learn)
Ação prática
- Crie uma política exigindo phishing-resistant MFA para admins e grupos “high value”.
- Use acesso privilegiado sob demanda (PIM) e reduza admins permanentes.
2) Pare de aceitar login “de qualquer lugar”: exija dispositivo gerenciado
Token roubado costuma ser reusado em outro dispositivo. Uma barreira extremamente efetiva é exigir dispositivo em conformidade (Intune) para acessar apps críticos. A Microsoft descreve como aplicar isso via Conditional Access e compliance. (Microsoft Learn)
Ação prática
- Para usuários: exigir dispositivo compliant para Exchange/SharePoint/Teams (ou, no mínimo, para o conjunto “Office 365”).
- Para admins: exigir compliant + phishing-resistant MFA.
3) Restrinja o “cliente”: somente apps aprovados / App Protection Policy
Se o atacante tenta usar um cliente “genérico” ou fluxo alternativo, você pode bloquear exigindo cliente aprovado ou políticas de proteção de app (especialmente em mobile). A documentação mostra como isso funciona em Conditional Access. (Microsoft Learn)
Ação prática
- Habilite “Require approved client app” onde fizer sentido (principalmente mobile).
- Combine com MAM/APP para dados corporativos.
4) Ative Token Protection (quando aplicável) para bloquear replay
O controle mais direto contra replay é exigir Token Protection em Conditional Access: tokens passam a ser vinculados ao dispositivo, reduzindo o valor de um token roubado fora do endpoint original. A Microsoft documenta o recurso e recomenda começar por um piloto e modo “report-only”. (Microsoft Learn)
Atenção importante
- Há limitações de plataforma/escopo (por exemplo, requisitos e suportes específicos), então trate como camada para usuários e dados de maior risco, não como “liga e esquece”. (Microsoft Learn)
5) Reduza tempo útil da sessão e “revalide” risco com controles de sessão
Para encurtar a janela de abuso, use session controls como “sign-in frequency” e “persistent browser session”. A Microsoft descreve esses controles e como aplicá-los. (Microsoft Learn)
Ação prática
- Para apps sensíveis: reduza frequência de login e evite sessão persistente em navegadores não gerenciados.
- Para perfis de risco: reautenticação mais frequente.
6) Use CAE + risco (Identity Protection) para derrubar sessão em tempo real
A Microsoft explica que Continuous Access Evaluation (CAE) pode invalidar tokens quando risco muda (ex.: sinalização de risco pelo Identity Protection), forçando reautenticação e mitigação automática. (TECHCOMMUNITY.MICROSOFT.COM)
Ação prática
- Ative políticas de risco (sign-in risk/user risk) e alinhe resposta: exigir MFA forte, troca de senha ou bloquear.
7) Governe OAuth e apps conectados (o “atalho” que vira backdoor)
Se o atacante obtém permissões via OAuth, o problema não é “sessão” e sim autorização persistente. Use governança e auditoria para apps OAuth. A Microsoft detalha monitoramento/auditoria e controles em Defender for Cloud Apps/App Governance. (Microsoft Learn)
Ação prática
- Reduza/controle consentimento do usuário.
- Crie workflow de admin consent e monitore apps com permissões de alto impacto (mail, arquivos, diretórios).
8) Endureça endpoint e detecção (porque token sai do device)
Token theft frequentemente depende do endpoint. A orientação oficial enfatiza hardening com EDR e gestão. (Microsoft Learn)
Ação prática
- Padronize EDR, patching, bloqueio de execução suspeita e proteção do navegador.
- Remova admin local e controle extensões.
9) Tenha playbook de resposta pronto (revogar sessão rápido)
Quando suspeitar de token theft, velocidade importa. O playbook da Microsoft ajuda analistas a identificar, conter e remediar. (Microsoft Learn)
Ação prática
- Automatize: revogar sessões/tokens, reset de credenciais, quarentena do dispositivo, revisão de consentimentos OAuth e regras suspeitas.
