O phishing de código de dispositivo tenta convencer uma pessoa a autorizar, em outro aparelho, uma sessão iniciada pelo invasor. Organizações que usam Microsoft Entra ou outros provedores compatíveis com esse fluxo são afetadas; a prioridade é restringir a autorização de dispositivos não gerenciados, alertar sobre pedidos inesperados e revogar imediatamente sessões suspeitas.
O método merece tratamento diferente do phishing tradicional. A vítima pode não entregar uma senha, clicar em um anexo ou instalar um programa. Em vez disso, recebe uma mensagem com um código e uma instrução para acessar uma página legítima de autenticação. Se concluir o processo, o usuário pode estar aprovando uma sessão que não iniciou. O atacante aproveita a confiança no domínio verdadeiro e desloca a decisão crítica para uma tela que parece normal.
Como o golpe funciona
O fluxo legítimo de autorização de dispositivo foi criado para aparelhos nos quais digitar credenciais é difícil, como televisores, consoles e alguns terminais. O cliente apresenta um código, o usuário abre a página indicada em outro dispositivo, autentica-se e confirma a solicitação. A documentação da Microsoft descreve esse processo como uma forma de obter autorização para um aplicativo em um dispositivo com limitações de entrada.
No abuso, o criminoso inicia o fluxo para o próprio cliente e envia o código à vítima por e-mail, mensagem instantânea, ligação ou conversa em uma plataforma corporativa. A narrativa pode mencionar uma reunião, uma atualização, uma validação de acesso ou uma atividade de suporte. O endereço visitado pode ser legítimo, mas a solicitação exibida depois do login pertence ao atacante.
A diferença operacional é decisiva: o domínio pode ser autêntico e a autenticação pode ser concluída com sucesso, enquanto a intenção da transação é fraudulenta. Por isso, bloquear apenas páginas falsas ou indicadores de URL não encerra o risco.
O que fica exposto
Depois da aprovação, o invasor pode receber tokens associados ao recurso autorizado. O alcance depende das permissões solicitadas, das políticas de consentimento e dos controles aplicados à sessão. Uma autorização limitada ainda pode fornecer acesso suficiente para consultar mensagens, recolher informações de diretório, procurar documentos ou preparar uma fraude posterior.
O evento também pode parecer um login normal nos primeiros minutos. O registro pode mostrar um usuário válido, uma autenticação multifator concluída e um cliente que não é imediatamente reconhecido como malicioso. A investigação precisa correlacionar o início do fluxo, o código ou a solicitação de dispositivo, o endereço de origem, o agente do cliente, a localização, o recurso acessado e as alterações posteriores na conta.
Não presuma que a troca de senha encerra o incidente. Tokens já emitidos podem continuar úteis conforme a política do provedor, e o atacante pode ter criado consentimentos, sessões persistentes, regras de caixa postal ou novos métodos de autenticação. A contenção deve tratar a identidade como comprometida até que as sessões e permissões relacionadas sejam revisadas.
Decisão para o SOC
A equipe deve decidir entre bloquear o fluxo de autorização de dispositivo para todos ou mantê-lo apenas onde houver uma necessidade operacional documentada. Em ambientes corporativos, a opção mais segura costuma ser desativar o fluxo quando ele não é indispensável. Quando a função precisa permanecer ativa, a exceção deve ser limitada por aplicativo, grupo, dispositivo gerenciado e condição de acesso.
O guia da Microsoft para o fluxo de dispositivo deve ser usado para identificar onde a capacidade está habilitada e quais clientes podem solicitá-la. A orientação do CISA sobre engenharia social ajuda a complementar o controle técnico com treinamento e procedimento de verificação fora da mensagem. A equipe não deve pedir ao usuário que envie o código ao suporte; deve confirmar a solicitação por um canal conhecido e registrar quem iniciou a transação.
| Prioridade | Ação | Evidência a preservar |
|---|---|---|
| P1 | Revogar sessões, tokens e consentimentos associados à conta suspeita; bloquear a solicitação de dispositivo e isolar alterações recentes. | Registros de autenticação, auditoria de consentimento, IP, agente do cliente e horário da solicitação. |
| P1 | Verificar regras de encaminhamento, métodos de autenticação, aplicativos empresariais e membros privilegiados. | Estado anterior e posterior da conta, objetos alterados e identidade que executou cada mudança. |
| P2 | Restringir autorização de dispositivos a grupos e aplicações aprovados; exigir dispositivo compatível e sinais de risco. | Políticas de acesso, exceções, grupos abrangidos e resultado dos testes de bloqueio. |
| P2 | Criar detecções para solicitações de dispositivo fora do padrão e para acessos logo após uma aprovação inesperada. | Consulta, limiar, amostras benignas e alertas produzidos no período de validação. |
Sinais para investigar
Comece pelos registros de auditoria de identidade. Procure solicitações de autorização em horários atípicos, de redes residenciais quando o usuário trabalha no escritório, de países incompatíveis com o histórico e de clientes que não fazem parte do inventário corporativo. Um único indicador não prova comprometimento; a combinação de solicitação inesperada, autenticação válida e atividade posterior incomum é mais relevante.
Compare também o momento em que o usuário recebeu a mensagem com a criação da sessão. Se a organização conserva telemetria de e-mail e colaboração, pesquise por textos que pedem a leitura de um código, imagens de telas de login, links encurtados e mensagens que pressionam por urgência. O conteúdo deve ser tratado como evidência, não como instrução de resposta.
Em seguida, examine o que a conta fez depois da aprovação. Busque leitura em massa, pesquisa de caixas postais, downloads atípicos, criação de regras, inclusão em grupos, consentimento de aplicações e acesso a recursos que não fazem parte da função do usuário. Se houver sinais de uso de privilégio, a contenção precisa abranger as contas administrativas que interagiram com o caso.
Controles que reduzem risco
O primeiro controle é eliminar a autorização de dispositivo onde ela não tem função empresarial. O segundo é impor políticas que avaliem o estado do dispositivo, a localização, o risco da sessão e a sensibilidade do recurso. O terceiro é controlar o consentimento de aplicações: usuários comuns não devem aprovar livremente aplicações desconhecidas, sobretudo quando pedem permissões de correio, arquivos ou diretório.
As equipes também precisam separar o canal de instrução do canal de autorização. Uma solicitação recebida por mensagem deve ser confirmada em um contato já conhecido, sem usar o número, o link ou a conversa fornecidos pelo remetente. O suporte deve ter um roteiro que pergunte qual aplicação solicitou a autorização, qual aparelho deveria ser conectado e quem abriu o pedido.
O treinamento deve mostrar a situação concreta: uma página verdadeira não torna legítima toda solicitação que aparece depois do login. Exercícios internos podem medir se os usuários reportam códigos inesperados sem concluir o fluxo. O objetivo não é transformar cada funcionário em analista, mas criar uma interrupção confiável antes da aprovação.
Resposta após a aprovação
Quando houver confirmação, preserve primeiro os registros necessários para reconstruir a cadeia. Depois revogue as sessões e os consentimentos, redefina credenciais conforme o procedimento de resposta, remova métodos de autenticação não reconhecidos e revise regras e delegações. O SOC deve procurar reutilização de tokens e atividade semelhante em outras contas, especialmente quando a mensagem foi enviada a um grupo.
Comunique o usuário sem culpabilização. Ele pode ter seguido uma instrução em um domínio oficial e ainda assim ter autorizado o cliente errado. A comunicação precisa explicar que a senha pode não ser o único elemento comprometido e que qualquer novo pedido de código deve ser reportado.
O incidente só deve ser encerrado depois de uma busca retroativa pelos indicadores, da validação das políticas de bloqueio e da confirmação de que não existem consentimentos ou sessões residuais. O resultado mais útil não é apenas registrar que uma conta foi recuperada, mas provar que o próximo pedido equivalente será impedido ou detectado antes da autorização.
Para estruturar a decisão de contenção, consulte também o plano de resposta e a autoridade para iniciar um incidente. Se a investigação envolver múltiplas contas, a orientação sobre decisões prévias na resposta a incidentes ajuda a definir responsáveis, evidências e critérios de escalonamento.
Fontes
Microsoft: OAuth 2.0 device authorization grant