noticias

Novo phishing não rouba sua senha: ele faz você autorizar o invasor mesmo com autenticação em duas etapas

**Categoria editorial:** Cibersegurança | Segurança Digital

**Linha fina:** Ataque explora um recurso legítimo de login da Microsoft para obter tokens de acesso depois que a própria vítima conclui a autenticação. O problema não é uma falha no 2FA, mas uma mudança na lógica do phishing.

**Meta description:** Novo phishing explora login legítimo da Microsoft para obter tokens mesmo com 2FA. Entenda o ataque e por que empresas precisam rever suas defesas.

**Slug amigável:** phishing-device-code-burlar-2fa-roubar-token-microsoft

**Editoria:** Cibersegurança

**Autor:** Redação PixBugTech

**Data:** 10 de agosto de 2026

Durante anos, a principal recomendação de segurança para contas importantes foi simples: ative a autenticação em duas etapas. A lógica continua correta, mas uma nova geração de ataques mostra que adicionar um segundo fator não resolve sozinho um problema muito mais difícil: convencer o usuário a autenticar uma sessão que pertence ao criminoso.

É exatamente isso que acontece em campanhas de *device code phishing*, técnica analisada recentemente por pesquisadores da Trend Micro e também acompanhada pela própria Microsoft. Em vez de criar uma página falsa destinada a capturar login e senha, os atacantes exploram um fluxo legítimo de autenticação criado para dispositivos nos quais digitar credenciais diretamente seria inconveniente ou impossível.

A vítima pode chegar a uma página verdadeira da Microsoft, usar suas credenciais verdadeiras e até confirmar corretamente o segundo fator de autenticação.

Nada precisa parecer quebrado.

O problema é que aquela autenticação pode estar liberando uma sessão iniciada pelo invasor.

Essa pequena inversão transforma uma ferramenta criada para facilitar logins em dispositivos limitados em uma arma particularmente incômoda contra ambientes corporativos.

O ataque não quebra o 2FA

Esse talvez seja o ponto mais importante para compreender a técnica.

Dizer simplesmente que criminosos “burlaram a autenticação em duas etapas” pode gerar a impressão de que descobriram uma forma matemática ou técnica de derrotar o segundo fator.

Não foi isso.

O 2FA funciona exatamente como deveria.

O usuário recebe a solicitação, autentica sua identidade e o serviço valida a operação.

O que está errado é a sessão sendo autorizada.

Em outras palavras, o criminoso não precisa necessariamente roubar a senha e depois tentar superar a segunda etapa. Ele manipula o processo para fazer com que o próprio usuário realize a autenticação necessária.

A proteção não foi arrombada.

A vítima abriu a porta porque acreditava estar entrando em outro lugar.

Para que existe o código de dispositivo?

O chamado *device code flow* nasceu para resolver um problema bastante legítimo.

Imagine uma televisão inteligente, uma sala de videoconferência, um dispositivo corporativo compartilhado ou outro equipamento sem teclado confortável para digitar endereço de e-mail, senha e códigos de autenticação.

Em vez de realizar todo o login naquele equipamento, o sistema apresenta um código.

O usuário abre uma página de autenticação em um computador ou celular, informa esse código e conclui o login por ali.

Depois da confirmação, o dispositivo original recebe autorização para acessar os serviços permitidos.

É uma solução elegante.

Também cria uma característica essencial para o ataque: **o equipamento que solicita acesso e o equipamento no qual o usuário confirma a identidade podem ser diferentes**.

Os criminosos perceberam que existe uma costura entre essas duas etapas.

E passaram a explorá-la.

O criminoso inicia o login; a vítima termina

Em uma campanha legítima, o dispositivo que precisa acessar determinada conta solicita um código e o apresenta ao proprietário.

No ataque, quem inicia esse processo é a infraestrutura controlada pelo criminoso.

A vítima recebe então uma história convincente: pode ser um documento compartilhado, uma proposta comercial, uma solicitação de assinatura, um arquivo protegido ou outra situação aparentemente normal dentro do cotidiano corporativo.

Depois de alguns redirecionamentos, o usuário recebe um código e é orientado a utilizá-lo na autenticação.

Até aqui, muita gente treinada para reconhecer phishing ainda poderia desconfiar.

O problema aparece na próxima etapa.

A página de login pode ser realmente da Microsoft.

O domínio pode ser legítimo.

O certificado pode estar correto.

O usuário pode utilizar sua senha verdadeira.

Pode confirmar a autenticação multifator.

E ainda assim entregar acesso ao atacante.

O golpe funciona justamente porque parte da operação ocorre dentro da infraestrutura legítima que normalmente ensinamos as pessoas a procurar como sinal de segurança.

O prêmio agora é o token, não a senha

Essa mudança também mostra como o phishing está evoluindo.

Durante muito tempo, credenciais eram o grande objetivo.

Login e senha eram capturados em uma página falsa, enviados ao criminoso e utilizados posteriormente para tentar acessar a conta real.

A autenticação multifator tornou esse modelo mais trabalhoso.

Mesmo possuindo a senha, o atacante ainda teria de superar um código, uma confirmação no aplicativo ou algum outro segundo fator.

Os criminosos responderam mudando o objeto do roubo.

Em vez de buscar somente a senha, passaram a mirar **tokens de autenticação**.

Um token funciona, simplificando bastante, como uma comprovação digital de que determinada sessão já foi autenticada.

Depois que o servidor confirma a identidade do usuário, aplicações não precisam solicitar senha a cada nova ação. Tokens passam a representar aquela autorização durante determinado período e dentro de determinadas permissões.

Se o invasor consegue um token válido, ele pode potencialmente acessar recursos sem precisar repetir exatamente o processo tradicional de login.

É por isso que roubar sessão se tornou tão importante quanto roubar senha.

O cadeado verde perdeu parte de seu poder psicológico

O ataque também desmonta uma recomendação de segurança que durante muitos anos foi repetida quase como mantra: “verifique se o site é verdadeiro”.

Continuamos devendo verificar.

Mas isso não basta.

No *device code phishing*, o criminoso pode conduzir a vítima até uma página oficial de autenticação.

Isso significa que procurar o domínio correto e o HTTPS já não resolve todo o problema.

A pergunta precisa mudar.

Além de perguntar **“este site é verdadeiro?”**, o usuário precisa perguntar **“por que estou autenticando isso?”**.

Essa diferença parece pequena, mas representa uma mudança profunda na educação digital.

Segurança deixou de depender apenas da autenticidade da página.

Passou a depender também da autenticidade da intenção.

Serviços confiáveis podem participar involuntariamente da cadeia

Pesquisadores observaram ainda o uso de plataformas legítimas durante a primeira parte do golpe.

Serviços confiáveis podem hospedar páginas ou participar de redirecionamentos utilizados para construir uma aparência de legitimidade.

Isso cria outra dificuldade para ferramentas tradicionais de proteção.

Filtros de phishing costumam observar reputação de domínio, padrões de URL, conteúdo da página e histórico de atividades maliciosas.

Quando parte da cadeia utiliza infraestrutura conhecida e a autenticação final acontece no serviço verdadeiro, alguns sinais clássicos ficam menos evidentes.

O ataque explora justamente essa mistura.

Há conteúdo malicioso.

Há engenharia social.

Há infraestrutura controlada pelo criminoso.

Mas também existem componentes perfeitamente legítimos no meio do caminho.

É uma espécie de Frankenstein digital montado com peças confiáveis.

A engenharia social continua sendo o exploit mais barato

A sofisticação técnica pode chamar atenção, mas o ataque ainda depende de uma peça bastante antiga: convencer alguém.

Pesquisadores observaram abordagens capazes de começar com conversas aparentemente comuns, construção de confiança, propostas profissionais ou envio de documentos.

Isso é importante porque existe uma tendência de imaginar ataques cibernéticos como sequências frenéticas de código atravessando firewalls.

Boa parte dos ataques modernos é muito menos cinematográfica.

O criminoso precisa criar uma situação plausível.

Se a vítima acredita estar recebendo um documento de um parceiro comercial ou convite legítimo, realizar uma autenticação adicional pode parecer absolutamente normal.

Quanto mais familiar a história, menor a chance de resistência.

Tecnologia avançada e psicologia básica continuam formando uma combinação extremamente eficiente.

O ataque pode permanecer depois que a vítima fecha o navegador

Outra característica preocupante é o que acontece após a autenticação.

Dependendo das permissões concedidas e dos tokens obtidos, o acesso não precisa terminar imediatamente quando a vítima fecha a página.

O invasor pode tentar acessar e-mails, arquivos e outros recursos associados à identidade comprometida.

Em cenários corporativos, isso abre uma segunda fase muito mais perigosa.

Uma conta de e-mail não contém apenas mensagens.

Ela contém relações de confiança.

Fornecedores.

Clientes.

Conversas financeiras.

Documentos internos.

Nomes de executivos.

Histórico de projetos.

Calendários.

E uma quantidade considerável de contexto necessário para produzir ataques seguintes muito mais convincentes.

A primeira vítima pode então virar a porta de entrada para a segunda.

Uma conta legítima é muito mais perigosa do que um e-mail falso

Imagine receber uma mensagem estranha de um endereço desconhecido pedindo a abertura de determinado documento.

A chance de desconfiança é razoável.

Agora imagine a mesma mensagem enviada pelo e-mail verdadeiro de um colega com quem você trabalha todos os dias.

A percepção muda completamente.

Esse é um dos efeitos mais graves da tomada de contas corporativas.

Quando um atacante consegue operar a partir de uma identidade legítima, ele herda parte da confiança acumulada por aquela pessoa dentro da organização.

O phishing deixa de vir de fora.

Ele começa a circular internamente.

É por isso que ataques contra identidade possuem potencial de propagação tão grande.

Um firewall pode bloquear uma máquina desconhecida.

É muito mais difícil para uma empresa desconfiar de um funcionário que aparentemente acabou de entrar normalmente no sistema.

MFA continua essencial — mas não pode ser a última defesa

Nada disso significa que empresas deveriam abandonar a autenticação multifator.

Seria exatamente a conclusão errada.

MFA continua eliminando uma quantidade enorme de ataques baseados apenas em senha comprometida.

O que muda é a expectativa.

Durante anos, muitas organizações trataram o segundo fator como uma espécie de linha final de defesa.

Senha roubada?

O MFA segura.

Esse raciocínio funciona contra muitos ataques, mas não contra todos.

Se a própria vítima autentica uma sessão maliciosa, o sistema precisa procurar outros sinais.

Localização incomum.

Dispositivo desconhecido.

Fluxo de autenticação inesperado.

Uso anormal de tokens.

Alterações suspeitas na conta.

Acesso a informações incompatíveis com o comportamento histórico daquele usuário.

Segurança moderna precisa observar o que acontece **antes, durante e depois do login**.

A Microsoft já considera esse fluxo de alto risco

A discussão ficou ainda mais interessante porque a própria Microsoft endureceu sua orientação sobre o recurso.

A empresa classifica o fluxo de código de dispositivo como um método de autenticação de alto risco e recomenda que organizações se aproximem, sempre que possível, de um bloqueio amplo da funcionalidade.

A lógica é simples.

Se a empresa não utiliza aquele mecanismo, não existe razão para manter uma porta aberta apenas porque ela faz parte do sistema.

Quando algum equipamento realmente depende dele, a recomendação passa a ser restringir a funcionalidade aos cenários documentados e necessários.

Esse princípio deveria valer para praticamente qualquer infraestrutura corporativa.

Funcionalidade que existe não precisa necessariamente estar habilitada.

Em cibersegurança, cada recurso também representa superfície de ataque.

O ataque já ultrapassou a fronteira do cibercrime comum

O *device code phishing* também não é apenas uma técnica teórica apresentada por pesquisadores.

A Microsoft já documentou seu uso contra governos, organizações não governamentais e empresas de setores como tecnologia, defesa, telecomunicações, saúde, educação superior e energia.

Uma das campanhas acompanhadas pela empresa foi associada a um grupo alinhado a interesses russos, posteriormente relacionado pela Microsoft ao conjunto de atividades do Midnight Blizzard.

Isso coloca a técnica em outra escala.

Um mecanismo suficientemente eficiente para espionagem patrocinada por Estado inevitavelmente merece atenção do mercado corporativo.

Ferramentas e métodos desenvolvidos ou aperfeiçoados em campanhas altamente direcionadas têm uma tendência desconfortável de aparecer posteriormente em operações muito mais amplas.

O que hoje atinge uma organização estratégica pode amanhã virar kit comercializado entre criminosos.

A IA pode tornar a primeira metade do golpe ainda melhor

Existe ainda uma variável que tende a aumentar o problema: inteligência artificial generativa.

O ponto fraco do ataque continua sendo fazer a história parecer plausível.

Modelos generativos reduzem dramaticamente o custo dessa etapa.

É possível produzir mensagens gramaticalmente corretas em vários idiomas, adaptar textos ao setor da empresa e construir abordagens muito menos caricatas do que os antigos e-mails de phishing.

A Microsoft já documentou em 2026 uma campanha de *device code phishing* com componentes auxiliados por inteligência artificial.

Isso não significa que a IA tenha descoberto alguma técnica revolucionária de invasão.

Significa algo talvez mais relevante: ela melhora a escala e a qualidade da engenharia social.

O criminoso continua precisando enganar alguém.

Agora pode fazer isso com textos melhores, mais rápidos e potencialmente mais personalizados.

O usuário comum também precisa mudar um hábito

Para quem não administra infraestrutura corporativa, existe uma regra prática importante.

Códigos de autenticação não devem ser tratados como simples burocracia.

Se apareceu uma tela pedindo que você informe um código, confirme um dispositivo ou autorize determinada conexão, é necessário entender de onde aquela solicitação surgiu.

Não basta reconhecer o logotipo.

Não basta ver HTTPS.

Não basta estar em um domínio conhecido.

E não basta o aplicativo autenticador dizer que alguém está tentando entrar.

A pergunta fundamental é outra:

**fui eu quem iniciou esse login?**

Se a resposta não for claramente sim, existe motivo para interromper o processo e investigar.

Essa lógica vale não apenas para a Microsoft, mas para qualquer ecossistema que utilize autorizações entre dispositivos, OAuth ou mecanismos semelhantes.

Para empresas, treinamento sozinho não resolve

Treinar funcionários continua necessário.

Mas depender exclusivamente de treinamento é transferir para o usuário uma responsabilidade que também pertence à arquitetura.

Uma empresa pode realizar campanhas de conscientização mensalmente e ainda encontrar alguém cansado, apressado ou distraído no momento certo.

É por isso que controles técnicos continuam indispensáveis.

Se determinado fluxo de autenticação não é necessário para a organização, bloquear sua utilização elimina uma classe inteira de risco.

Se é necessário, monitorá-lo permite procurar eventos incompatíveis com o uso esperado.

Também é fundamental investigar tokens e sessões, não apenas mudanças de senha.

Depois de um comprometimento baseado em identidade, simplesmente alterar a senha pode não resolver tudo se sessões existentes, dispositivos registrados ou outros mecanismos de persistência continuarem ativos.

A arquitetura de segurança precisa assumir que autenticação legítima também pode ser utilizada de maneira maliciosa.

O que quase ninguém discute: estamos entrando na era pós-senha antes de estarmos preparados para ela

A indústria de tecnologia trabalha há anos para diminuir a dependência de senhas.

Passkeys, biometria, aplicativos autenticadores, OAuth e tokens representam avanços importantes.

Mas existe uma consequência.

À medida que a senha perde protagonismo, criminosos passam a atacar aquilo que a substituiu.

O alvo deixa de ser apenas um segredo armazenado na memória do usuário.

Passa a ser a sessão.

A autorização.

O token.

O dispositivo confiável.

O consentimento.

O próprio fluxo de identidade.

Isso muda profundamente o modelo de ameaça.

Uma senha pode ser trocada.

Uma arquitetura inteira baseada em confiança é muito mais difícil de corrigir.

O phishing está deixando de falsificar portas para convencer você a abrir as verdadeiras

A característica mais reveladora desse ataque talvez seja justamente a ausência de uma grande vulnerabilidade.

Não existe necessariamente código secreto quebrando a criptografia.

Não existe uma falha mágica derrotando a autenticação multifator.

Não existe sequer a obrigação de criar uma cópia perfeita da página de login.

Existe um recurso legítimo.

Existe um usuário legítimo.

Existe uma autenticação legítima.

E existe um criminoso manipulando a relação entre essas três coisas.

Durante muito tempo, segurança digital ensinou usuários a desconfiar de páginas falsas.

A próxima fase será mais complicada.

Precisaremos aprender a desconfiar também de **ações verdadeiras realizadas no contexto errado**.

Porque o phishing mais perigoso talvez não seja aquele que constrói uma porta falsa.

É aquele que convence você a abrir a verdadeira para alguém que está esperando do outro lado.

---

👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis