A Microsoft publicou a 9 de setembro de 2026 uma análise de intrusões em ambientes cloud que começam com um telefonema ou uma SMS a fingir ser do help desk interno e terminam com roubo massivo de ficheiros e correio eletrónico em contas Microsoft 365. O pretexto é sempre o mesmo — “tem de atualizar a sua passkey” — mas o objetivo real quase nunca é registar uma passkey: é levar o utilizador a percorrer um fluxo de autenticação manipulado que entrega ao atacante credenciais, tokens de sessão ou autorização direta sobre a conta. A campanha chega num momento particularmente sensível, porque a própria Microsoft começou a 1 de setembro de 2026 a tornar as passkeys a experiência de autenticação por omissão no Entra ID, o que normaliza exatamente o tipo de pedido que os atacantes estão a imitar.
Resposta rápida: A Microsoft Threat Intelligence documentou intrusões em que criminosos se fazem passar pelo help desk, por chamada ou SMS para o telemóvel pessoal, e usam a desculpa de “atualizar a passkey” para conduzir o utilizador a páginas de adversary-in-the-middle ou ao fluxo de device code. Depois registam métodos de MFA próprios, fazem reconhecimento via Microsoft Graph e recolhem dados do SharePoint, OneDrive e Exchange. A ação recomendada é bloquear o fluxo de device code onde não for necessário, restringir e monitorizar o registo de métodos de autenticação e nunca aprovar códigos ou alterações de MFA pedidos por telefone.
O que a Microsoft observou
O relatório publicado a 9 de setembro de 2026 descreve intrusões cloud ativas em múltiplas contas, em que autenticações anómalas são seguidas de métodos de autenticação adicionados pelo atacante, atividade elevada no Microsoft Graph, descarregamentos de SharePoint e OneDrive e recolha de correio eletrónico através de APIs REST, começando por engenharia social focada na identidade e infraestrutura de personificação. A atividade é observada desde maio de 2026 e arranca com a personificação de técnicos de help desk, por chamada telefónica ou SMS, que encaminham as vítimas para sites que imitam páginas de início de sessão da Microsoft.
Antes do contacto, os atacantes investigam a organização e os colaboradores, e depois dizem à vítima que tem de atualizar com urgência uma passkey, a autenticação multifator (MFA) ou a configuração de single sign-on para não perder o acesso aos sistemas corporativos. É uma variante de vishing com um detalhe eficaz: o pedido é tecnicamente plausível e coincide com mudanças reais que muitas organizações estão mesmo a fazer.
Porque é que a isca da passkey funciona tão bem
O ponto central da análise é contraintuitivo. Apesar do uso frequente de iscas temáticas de passkeys, o registo de uma passkey não é normalmente o verdadeiro objetivo: a narrativa serve de pretexto convincente para conduzir as vítimas por fluxos de phishing adversary-in-the-middle (AiTM) ou de autenticação por device code; no primeiro caso o atacante captura credenciais e tokens de sessão, no segundo a vítima autoriza o acesso sem saber, em nome do atacante.
No phishing de device code, o utilizador é persuadido a introduzir um código na página legítima de autenticação da Microsoft; essa aprovação emite um token para um cliente controlado pelo atacante, que passa a aceder aos recursos permitidos sem roubar qualquer cookie do browser — e o token foi depois reutilizado para contornar a MFA e prosseguir a enumeração. Ou seja: a passkey pode continuar intacta e criptograficamente sólida, porque o ataque não incide sobre a autenticação, mas sobre a camada de autorização e sobre o utilizador.
Há ainda um problema de visibilidade forense. O contacto inicial deixa muito pouca evidência: se a vítima abrir o link de phishing num telemóvel pessoal que não está integrado no Microsoft Defender for Endpoint, a atividade pode simplesmente não existir na telemetria de endpoint, e em muitas investigações a recordação da chamada ou da mensagem pelo colaborador é a primeira — e às vezes a única — prova de como o comprometimento começou.
Cronologia típica da intrusão
| Fase | O que acontece |
|---|---|
| Preparação | Investigação da organização e dos colaboradores antes do contacto |
| Contacto | Chamada ou SMS para o número pessoal, a fingir ser o help desk interno |
| Acesso inicial | Página falsa de início de sessão Microsoft, com fluxo AiTM ou de device code |
| Persistência | Registo de métodos de MFA não autorizados na conta da vítima |
| Reconhecimento | Uso intensivo do Microsoft Graph para mapear utilizadores, grupos, permissões e recursos |
| Recolha e exfiltração | Extração em volume de SharePoint, OneDrive e Exchange, a ritmo controlado ao longo de horas ou dias |
Depois de obter acesso, os atacantes estabelecem persistência adicionando métodos de MFA não autorizados, conduzem reconhecimento extensivo com a API do Microsoft Graph e culminam com recolha de dados em volume a partir do SharePoint, OneDrive e Exchange, com exfiltração a taxas controladas para evitar deteção. Num terceiro padrão observado, o atacante autenticou-se com credenciais comprometidas e aprovou a MFA através de um método PhoneAppOTP previamente registado, o que sugere que a aplicação autenticadora tinha sido registada dias antes do lançamento da campanha.
Quem está por trás
A Microsoft Threat Intelligence avalia que a atividade de acesso inicial observada nesta campanha é usada por vários agentes de ameaça, incluindo os grupos que designa por Storm-3121 e Storm-3032, entre outros. Estes clusters aparecem associados a grupos de extorsão como o ShinyHunters e o Helix, que exploram o acesso para roubo de dados a partir de serviços Microsoft 365. Não se trata, portanto, de um único operador, mas de um modo de operação partilhado entre vários grupos com motivação financeira.
Mitigações concretas
A recomendação mais direta é antiga e continua por aplicar em muitos tenants: permitir o fluxo de device code apenas onde for necessário — a Microsoft recomenda bloqueá-lo sempre que possível. Perante suspeitas, a orientação é investigar a sequência de forma transversal nos sinais de identidade, Microsoft Graph, SharePoint, OneDrive e Exchange, revogar sessões e remover métodos de autenticação não autorizados.
- Bloquear o
device code flowpor política de Acesso Condicional, com exceções documentadas e limitadas. - Restringir e auditar o registo de novos métodos de autenticação (passkeys, apps OTP, telefone), exigindo rede ou dispositivo de confiança.
- Alertar sempre que um método de MFA for adicionado fora do processo normal de onboarding.
- Monitorizar volumes anómalos de chamadas ao Microsoft Graph e descarregamentos em massa de SharePoint e OneDrive.
- Definir e comunicar um procedimento oficial de help desk: nunca pedir códigos, aprovações ou alterações de MFA por chamada não solicitada.
- Formar as equipas para iscas específicas de passkeys e SSO, e não apenas para páginas falsas que pedem palavras-passe.
O contexto: passkeys por omissão no Entra ID
A Microsoft anunciou que o Entra ID passa a ter as passkeys como método de autenticação resistente a phishing por omissão, com o arranque da distribuição a partir de 1 de setembro de 2026, para reduzir a dependência de métodos passíveis de phishing como SMS e voz. Os utilizadores que hoje usam SMS ou chamada de voz serão automaticamente ativados para passkeys, com esses métodos a serem descontinuados em fevereiro de 2027 em todos os tenants. A transição é positiva em termos de segurança, mas cria uma janela de oportunidade: milhares de colaboradores vão receber, legitimamente, pedidos para registar uma passkey — e é exatamente essa expectativa que a campanha explora.
Porque é que isto importa em Portugal
Para as organizações nacionais, o impacto é duplo: operacional e legal. O Decreto-Lei n.º 125/2025, que transpõe a Diretiva NIS2 e aprova o Regime Jurídico da Cibersegurança, entrou em vigor a 3 de abril de 2026 e impõe às entidades essenciais, importantes e públicas relevantes prazos de notificação de incidentes com impacto significativo: alerta em 24 horas, atualização em 72 horas e relatório final em 30 dias úteis. Um comprometimento de identidade que resulte em exfiltração de ficheiros e correio eletrónico pode facilmente cair nesse enquadramento.
O Regulamento do Regime Jurídico da Cibersegurança entrou em vigor a 23 de junho de 2026 e deu início à contagem do prazo legal de 24 meses para a produção de efeitos das medidas de cibersegurança e da obrigatoriedade do relatório anual pelas entidades essenciais. Em paralelo, se os dados recolhidos do SharePoint, OneDrive ou Exchange incluírem dados pessoais — e quase sempre incluem —, aplica-se o RGPD, com avaliação de risco e eventual notificação à CNPD e aos titulares dos dados.
Para as PME, a lição prática é simples e barata de aplicar: rever no tenant Microsoft 365 quem pode registar métodos de autenticação, desligar o fluxo de device code, e estabelecer por escrito que o suporte informático nunca liga a pedir aprovações. O CNCS e o CERT.PT mantêm canais de reporte e alerta para incidentes desta natureza, e a notificação atempada é hoje uma obrigação legal, não uma cortesia.
Não foi a única campanha divulgada
A Microsoft divulgou na mesma semana uma segunda investigação, sobre fraude financeira por personificação de executivos, com recurso a infraestrutura de entrega de correio de terceiros e a conteúdos gerados com inteligência artificial. As duas divulgações partilham um sinal comum: os atacantes estão a alinhar as suas iscas com processos de negócio e mudanças tecnológicas que as vítimas já esperam — seja um pedido de pagamento do diretor-geral, seja um aviso para atualizar a autenticação.
Perguntas frequentes
As passkeys deixaram de ser seguras?
Não. Nesta campanha o alvo não é a criptografia da passkey, mas o utilizador e os fluxos alternativos de autorização. A passkey continua a ser um método resistente a phishing e muito superior a SMS ou códigos OTP; o que falha é a cadeia à volta dela, como o registo de novos métodos de MFA e o fluxo de device code.
O que é o phishing de device code?
É uma técnica em que a vítima é convencida a introduzir um código na página legítima de autenticação da Microsoft. Ao aprovar, emite um token de acesso para uma aplicação controlada pelo atacante, que passa a aceder aos recursos permitidos sem precisar de roubar a palavra-passe nem cookies do browser.
Como é que uma PME se protege rapidamente?
Bloqueando o fluxo de device code por Acesso Condicional onde não for necessário, restringindo quem pode registar métodos de autenticação, criando alertas para métodos de MFA adicionados fora do processo normal e comunicando a todos os colaboradores que o suporte informático nunca pede códigos nem aprovações por telefone.
Se houver exfiltração de dados, tenho de notificar alguma entidade?
Depende do enquadramento. Entidades abrangidas pelo Regime Jurídico da Cibersegurança têm prazos de notificação ao CNCS de 24 horas, 72 horas e relatório final em 30 dias úteis para incidentes com impacto significativo. Se estiverem envolvidos dados pessoais, aplica-se ainda o RGPD, com avaliação de risco e eventual notificação à CNPD.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft Threat Intelligence, pelo Microsoft Security Blog, pelo RH-ISAC, pelo CNCS e em legislação publicada em Diário da República.