Ataques via OAuth: tokens roubados podem driblar MFA e sobreviver à troca de senha

O ponto central da análise da Unit 42 é que o ataque acontece na camada de autorização, depois da autenticação. A vítima entra no provedor de identidade legítimo e conclui o MFA. Só então o token vai parar na mão do atacante. Por isso access tokens e refresh tokens roubados driblam o MFA e sobrevivem à troca de senha: o token não é uma senha e vale até ser revogado explicitamente. Refresh tokens ainda geram novos access tokens por dias ou meses.

O texto separa as campanhas em três categorias: sequestro de conta (abuso do fluxo de device authorization e roubo de código de autorização via redirect_uri de apps legítimos), sequestro de permissão (consentimento a apps com nome vago ou que imitam marcas) e redirecionamento malicioso (uso do fluxo OAuth como vetor de entrega, inclusive com erros provocados de propósito, campanha documentada pela Microsoft em março de 2026). Arquiteturas de OAuth como serviço também ficam expostas a falhas como Cross-Tenant Client ID Confusion. Entre as defesas citadas: desabilitar consentimento de usuário para apps suspeitos, exigir aprovação de administrador, monitorar eventos de clipboard com código de autorização e auditar continuamente os redirect_uri registrados. O estudo também cita que 18,53% dos sites OAuth analisados pedem permissões além do mínimo.

O tema vem sendo acompanhado pelo CEVIU ao longo de 2026. Em 6 de abril de 2026, o CEVIU noticiou "Phishing está migrando para OAuth", e em 8 de abril de 2026 veio o caso do phishing com código de dispositivo da Microsoft. Em 7 de maio de 2026, a matéria sobre proteção de concessões OAuth empresariais citou o incidente da Drift, que afetou mais de 700 organizações. Em 14 de julho de 2026, o CEVIU tratou de um ataque com redirecionamentos legítimos. Em 28 de setembro de 2026 e 23 de outubro de 2026, as matérias reforçaram a persistência após redefinição de senha e o levantamento da Unit 42. A abordagem atual consolida essas frentes numa taxonomia única (sequestro de conta, de permissão e redirecionamento) e detalha as defesas.

Para quem opera identidade corporativa, a leitura é direta: MFA sozinho não fecha a conta. Resposta a incidente que pare na troca de senha deixa a porta aberta. Isso sugere incluir revogação de tokens e concessões no playbook, restringir consentimento de usuários e tratar a lista de apps autorizados e seus redirect_uri como ativo auditável, com revisão periódica.