A tecnologia que a indústria apresenta como a mais resistente ao phishing transformou-se, ironicamente, no pretexto preferido de vários grupos de extorsão. Desde a primavera de 2026 que investigadores da Microsoft, do Google Threat Intelligence Group (GTIG), da Arctic Wolf e da Okta descrevem campanhas em que criminosos telefonam a colaboradores, fingem ser o suporte informático interno e insistem que é urgente “atualizar a passkey” ou a configuração de MFA/SSO. O objetivo não é criptográfico: é levar a vítima a autenticar-se num fluxo controlado pelos atacantes, entregando a sessão do Microsoft 365 e, com ela, o acesso a correio eletrónico, SharePoint e OneDrive.
Resposta rápida: A Microsoft publicou a 9 de setembro de 2026 uma investigação sobre intrusões na cloud que começam com chamadas ou SMS para o telemóvel pessoal de colaboradores, com o pretexto de atualizar uma passkey, MFA ou SSO. Não existe falha de software nem CVE associado: os atacantes abusam de fluxos legítimos de autenticação, através de adversary-in-the-middle ou de device code phishing, e seguem-se recolha de dados em SharePoint, OneDrive e Exchange e tentativas de extorsão. Ação recomendada: bloquear o fluxo de device code no Acesso Condicional, restringir o registo de novos métodos de autenticação, adotar MFA resistente a phishing e criar um procedimento formal de verificação de identidade para contactos do help desk.
O isco chama-se “passkey”, mas nenhuma passkey é registada
O padrão descrito pela Microsoft é consistente entre vítimas. A atividade é observada desde maio de 2026 e começa com investigação prévia sobre a organização e os colaboradores, seguida de chamadas ou mensagens em que os atacantes se fazem passar pelo help desk interno, dizendo ser urgente atualizar uma passkey, a autenticação multifator ou a configuração de SSO para não perder acesso aos sistemas; as vítimas são depois encaminhadas para páginas que imitam o ecrã de início de sessão da Microsoft, por vezes através de links enviados por SMS para o telemóvel pessoal. A Microsoft sublinha que, apesar de o tema recorrente ser a passkey, os atacantes não tentam efetivamente registar uma.
Há aqui uma divergência relevante entre relatórios que convém não apagar. A Okta descreve um comportamento diferente num outro conjunto de atividade: desde abril de 2026, um agente que a empresa segue como O-UNC-066, associado ao site de fugas com o nome Pink, usa um kit de phishing controlado por painel dirigido ao processo de registo de passkeys de clientes Microsoft 365, registando domínios com a palavra passkey e telefonando aos utilizadores para os convencer a registar uma nova chave. Segundo a Okta, o fluxo parece desenhado para convencer o utilizador de que está a inscrever uma passkey junto da Microsoft enquanto o atacante regista, em simultâneo, a sua própria chave na conta da vítima. Ou seja: em alguns casos o tema é apenas pretexto; noutros, há tentativa real de inscrição de um método de autenticação controlado pelo criminoso.
Dois caminhos técnicos: proxy em tempo real ou código de dispositivo
Depois da chamada, o desfecho é quase sempre o mesmo — uma sessão autenticada nas mãos do atacante —, mas o percurso varia. Num dos cenários documentados pela Microsoft, um isco relacionado com passkeys serviu para lançar um ataque de device code phishing e tomar controlo da conta sem sequer roubar credenciais ou cookies, contornando na prática a proteção de MFA. No outro, funciona um proxy adversary-in-the-middle: o GTIG descreve o UNC6671 a usar técnicas AiTM para ultrapassar defesas de perímetro e MFA, visando sobretudo infraestruturas Microsoft 365 e Okta e recorrendo a scripts Python e PowerShell para exfiltrar dados corporativos.
A fase pós-compromisso é o que distingue estes grupos de um phishing vulgar. A investigação da Microsoft descreve início de sessão anómalo, adição de métodos de autenticação pelo atacante, atividade intensa na Microsoft Graph, descargas de SharePoint e OneDrive e recolha de correio através de APIs REST. Num dos casos analisados, houve uma autenticação anómala no Microsoft Office Home a partir de um equipamento não gerido, com posterior expansão para SharePoint Online e OneDrive via Graph API e enumeração de ficheiros sensíveis e serviços internos.
A Arctic Wolf, que segue um agrupamento sobreposto, acrescenta detalhe operacional: os operadores telefonam a diretores, vice-presidentes, executivos e pessoal de TI fazendo-se passar pelas equipas de suporte, encaminham-nos para subdomínios AiTM específicos de cada vítima com palavras como passkey, oskey, passkeydeploy, setpasskey, oskeyconnect ou secure-passkey, capturam credenciais e tokens de MFA e reutilizam a sessão a partir de infraestrutura residencial estática NodeMaven, mantendo um IP fixo por sessão para reduzir sinais de rotação de IP. A empresa não observou implantação de malware em endpoints nem movimento lateral na rede: os dados saíram de SharePoint, OneDrive, Exchange e Box e seguiram-se pedidos de extorsão.
Quem está por trás
A Microsoft Threat Intelligence considera que o acesso inicial observado nesta campanha é usado por vários agentes, incluindo o Storm-3121 — cuja atividade conduz a extorsão sob as marcas ShinyHunters e Falcon — e o Storm-3032, um conjunto de atores que se separou do grupo BlackFile e opera agora sob a marca de extorsão Helix. O GTIG avalia que um grupo comum de atores está associado às marcas BlackFile, Redact, Pink, Helix e Falcon, admitindo em alternativa afiliados dissidentes ou infraestrutura de phishing-as-a-service partilhada. A Arctic Wolf segue esta atividade como PREY-0058, nota sobreposição substancial com o reporte do GTIG sobre o UNC6671 e com trabalho público da ReliaQuest, Unit 42, Okta e CrowdStrike, e avisa que estas etiquetas podem representar afiliados ou mudanças de marca e não uma identidade única comprovada.
Cronologia pública do caso
| Data | Acontecimento |
|---|---|
| Abril de 2026 | Início da atividade do agrupamento O-UNC-066/Pink contra o registo de passkeys no Microsoft 365, segundo a Okta |
| Abril–maio de 2026 | Domínios dirigidos a grandes empresas de indústria, imobiliário, saúde e seguros, segundo o GTIG |
| Maio de 2026 | Microsoft Security Research começa a observar a atividade em múltiplas contas comprometidas |
| Início de agosto de 2026 | GTIG documenta a mudança de marca do UNC6671, de BlackFile para REDACT, com diversificação por FALCON, HELIX e PINK |
| Início de setembro de 2026 | Arctic Wolf divulga o agrupamento PREY-0058 e as semelhanças com o UNC6671 |
| 9 de setembro de 2026 | Microsoft publica a análise das intrusões na cloud iniciadas por engenharia social temática de passkeys |
Indicadores e sinais de alerta
Os domínios mudam depressa e servem sobretudo para caracterizar o padrão. A própria Microsoft nota que domínios, endereços IP e alojamentos podem mudar rapidamente, mas a sequência recorrente — compromisso de identidade, persistência, reconhecimento, descoberta de conteúdos e exfiltração — é uma base de deteção mais durável.
| Tipo | Indicador | Fonte |
|---|---|---|
| Domínios de raiz | passkeyhelpdesk[.]com, portalpasskey[.]com, addssopasskey[.]com, passkeydeploy[.]com, setupsso[.]com, passkeyuser[.]com | GTIG |
| Padrão de subdomínio | Nome da empresa combinado com termos como passkey, SSO ou verificação de identidade | Microsoft |
| Infraestrutura de proxy | NodeMaven (predominante), além de DataImpulse, Luminati, Massive, ProxyRack, Shifter, Soax e Yilu | Arctic Wolf |
| Eventos de identidade | Acessos iniciais a mysignins.microsoft.com e myaccount.microsoft.com e eventos User registered security info | Arctic Wolf |
Um pormenor que dificulta a deteção: a sessão capturada é reutilizada a partir de um IP residencial na mesma cidade e rede da vítima, pelo que as verificações de “viagem impossível” não disparam e o antivírus nunca vê qualquer ficheiro malicioso.
Mitigações concretas
- Bloquear o fluxo de device code no Acesso Condicional do Microsoft Entra, permitindo-o apenas para ferramentas legadas documentadas.
- Restringir e vigiar o registo de métodos de autenticação: a Microsoft recomenda escrutinar alterações de registo de MFA, investigar eventos de autenticação por código de dispositivo, revogar sessões ativas após compromisso e remover métodos de autenticação não autorizados como parte da resposta a incidentes.
- Adotar MFA verdadeiramente resistente a phishing: chaves FIDO2, passkeys, Windows Hello for Business ou Okta FastPass, cujo origin binding WebAuthn derrota domínios sósia e proxies AiTM.
- Endurecer o Acesso Condicional e limitar o alcance dos dados: a Arctic Wolf aconselha bloquear ou desafiar tráfego de proxies e alojamentos, reduzir o volume de SharePoint acessível por uma única conta e treinar o help desk para reconhecer chamadas de vishing.
- Criar um canal de verificação fora de banda: nenhuma equipa de TI legítima deve pedir a um colaborador que conclua uma inscrição de passkey a partir de um link recebido por SMS no telemóvel pessoal.
- Encurtar sessões e centralizar aplicações no SSO: o Google recomenda integrar as aplicações críticas no SSO central e reduzir a duração das sessões para forçar reautenticação regular.
Porque é que isto importa em Portugal
Nenhum destes ataques depende de uma vulnerabilidade de software, o que os torna transversais: qualquer organização portuguesa com Microsoft 365 ou Okta está tecnicamente exposta, independentemente do nível de atualização dos sistemas. A defesa é organizacional — processos de help desk, política de registo de credenciais, monitorização de identidade — e é exatamente esse tipo de medida que o Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2) exige às entidades abrangidas, incluindo autenticação multifator, gestão de incidentes e formação. As entidades no âmbito devem ainda notificar incidentes significativos ao CNCS/CERT.PT nos prazos legalmente previstos.
Há também uma dimensão de proteção de dados: quando o desfecho é a cópia massiva de caixas de correio e de repositórios documentais, o incidente configura quase sempre uma violação de dados pessoais, com as obrigações de notificação à CNPD e, quando aplicável, aos titulares, previstas no RGPD. Para PME, a lição prática é barata de aplicar: assumir que uma chamada inesperada sobre autenticação é um ataque em curso até prova em contrário, e verificar sempre por um canal interno conhecido.
Perguntas frequentes
As passkeys deixaram de ser seguras?
Não. Não existe falha na tecnologia: os criminosos usam a palavra “passkey” como pretexto de engenharia social e desviam a vítima para fluxos de autenticação alternativos. A autenticação baseada em WebAuthn continua a ser das defesas mais eficazes contra phishing, por estar ligada ao domínio legítimo.
Existe algum CVE ou patch a aplicar?
Não foi divulgado qualquer identificador CVE associado a esta atividade, porque não há exploração de vulnerabilidade de software. A mitigação passa por configuração de identidade, políticas de Acesso Condicional, monitorização e formação dos utilizadores.
Como sei se a minha organização foi afetada?
Procure inícios de sessão a partir de equipamentos não geridos ou de IP residenciais invulgares, métodos de autenticação adicionados sem pedido do utilizador, consultas intensas à Microsoft Graph e descargas anómalas em SharePoint e OneDrive. Em caso de suspeita, revogue sessões e remova métodos de autenticação não autorizados.
O que deve fazer um colaborador que recebe uma chamada destas?
Deve desligar, não clicar em qualquer link recebido por SMS e contactar a equipa de TI pelo canal interno habitual. Depois, deve reportar a tentativa, mesmo que não tenha introduzido dados, para que a equipa de segurança possa procurar outros alvos na mesma organização.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft Security Research, pelo Google Threat Intelligence Group, pela Arctic Wolf e pela Okta Threat Intelligence.