Phishing com código de dispositivo: o domínio certo pode autorizar a ação errada

Uma campanha analisada pela Push Security usa convites falsos atribuídos a OpenAI, SpaceX e Anthropic para comprometer contas Microsoft e Google.[2] Segundo a reportagem, os caminhos combinam autorização por código de dispositivo e páginas de autenticação intermediadas por proxy.[2] A lição para quem desenvolve sistemas com identidade federada é separar três perguntas: onde o usuário entrou, qual solicitação aprovou e quem recebeu a autorização.

O que muda para quem desenvolve

No caminho Microsoft, a vítima recebe um código criado para uma solicitação controlada pelo atacante e é orientada a inseri-lo no site verdadeiro da Microsoft.[2] Assim, conferir apenas o domínio não basta: o usuário pode autenticar no lugar correto e autorizar o contexto errado.[2]

A campanha ainda acrescenta uma etapa com VoidProxy para capturar senha e cookie de sessão.[2] Para Google, a reportagem descreve um proxy adversário no meio da conexão, que tenta capturar credenciais, respostas de MFA e cookies enquanto repassa a autenticação.[2]

Isso muda a forma de escrever requisitos de segurança. Em vez de aceitar “tem MFA” como resposta completa, peça a descrição dos fluxos permitidos, dos tokens emitidos e do mecanismo usado para recuperar o controle após um incidente. A superfície relevante é a cadeia de autorização, não apenas o formulário de login.

Como aplicar

Comece por mapear usos legítimos do fluxo de dispositivo. Para cada integração, registre finalidade, responsável e alternativa disponível. A recomendação citada na matéria é restringir esse fluxo onde ele não é necessário e adotar MFA resistente a phishing, como chaves FIDO2.[2] Bloquear sem inventário pode trocar um risco de identidade por uma indisponibilidade evitável.

Um exercício interno pode apresentar um convite fictício, sem coleta de credenciais, e pedir que a equipe identifique quem iniciou a autorização. O resultado esperado não é memorizar uma marca de evento, mas reconhecer que códigos recebidos de terceiros não devem ser aprovados por reflexo.

No produto, torne explícitos o recurso solicitado e a ação autorizada. Para resposta a incidente, proponha um roteiro que examine sessões, consentimentos e aplicações conectadas, em vez de encerrar o atendimento na troca de senha.

Cuidados e limites

A matéria registra uso de intermediários conhecidos e de CAPTCHA da Cloudflare nas páginas falsas.[2] Reputação do serviço intermediário não deve funcionar como aprovação automática do destino.

A distribuição inicial de todos os links ainda não estava esclarecida, e o alcance posterior depende das permissões e integrações da conta.[2] Portanto, não atribua a toda visita o mesmo impacto. Separe exposição, autenticação realizada, autorização concedida e evidência de uso indevido. Cada etapa exige uma resposta proporcional e verificável.

Fonte

[2] Fonte: BleepingComputer