Resumo executivo
Desde abril de 2026, um agente de ameaças rastreado como O-UNC-066, que opera um site DLS com o nome Pink (relatado como "CL-CRI-1147" pela Unidade 42 da Palo Alto Networks), implantou um kit de phishing controlado por painel, visando o processo de registro de chave de acesso para clientes do Microsoft 365.
A Okta observou que esse grupo de atividades tem como alvo organizações empresariais nos setores de alimentos e bebidas, tecnologia, saúde, automotivo, construção e aviação. A principal motivação dos agentes maliciosos é a extorsão de dados.
O agente malicioso registra domínios que incorporam a palavra "passkey" como parte de um esquema de phishing ativado por voz ("vishing"). O agente malicioso então liga para os usuários visados, tentando convencê-los de que precisam registrar uma nova passkey.
Os usuários são direcionados para um kit de phishing que imita de perto o processo de inscrição de chave de acesso da Microsoft. Aparentemente, o ataque foi projetado para convencer o usuário alvo de que ele está em processo de cadastro de uma chave de acesso na Microsoft, enquanto o invasor registra simultaneamente sua própria chave de acesso na conta Microsoft do usuário alvo.
Este pretexto é oportuno: desde maio de 2026, os administradores da Microsoft podem criar campanhas de registro de passkeys que lembram ou "incentivam" os usuários a se inscreverem para usar passkeys no momento do login, e em algumas circunstâncias esses incentivos estão ativados por padrão.
Atores maliciosos têm usado essa atualização de segurança bem-intencionada como pretexto para abusar do processo de inscrição e atingir seus objetivos.
Nossa análise do kit de phishing revelou que ele não tenta lidar com a federação com provedores de identidade de terceiros, como o Okta. Posteriormente, não observamos o comprometimento direto de contas da Microsoft.
Ainda assim, publicamos orientações em um post separado no blog sobre como aplicar resistência a phishing no cadastro e na recuperação de autenticadores.
Análise de Ameaças
Na atividade de ameaça que observamos, o agente malicioso cria subdomínios específicos para cada alvo, que imitam as páginas de login do Microsoft Entra ID. As páginas são personalizadas utilizando a identidade visual legítima de cada organização vítima. O estilo genérico da Microsoft é carregado da Rede de Distribuição de Conteúdo da Microsoft, enquanto os elementos de marca relevantes para cada organização vítima (logotipo e plano de fundo) são pré-configurados por subdomínio como parte da configuração para qualquer alvo específico e fornecidos pelo servidor do kit de phishing.
O kit não é um proxy Adversary-in-the-Middle (AitM) transparente, um dos tipos mais frequentes de kits de phishing projetados para coletar credenciais, tokens MFA e tokens de sessão. Trata-se de um painel PHP controlado por um operador, no qual um agente malicioso guia as vítimas por várias etapas de autenticação em tempo quase real, utilizando um mecanismo de verificação de pulsação a cada segundo. O operador pode usar o kit para adaptar a experiência do usuário aos requisitos de MFA de cada vítima (TOTP, notificação push com correspondência de número, OTP por SMS) durante a sessão. Este modelo operacional é consistente com as técnicas de vishing documentadas na postagem pública do blog da Okta de novembro de 2025, intitulada "Kits de phishing se adaptam ao roteiro dos chamadores". O chamador pode controlar e ajustar em tempo real quais páginas de phishing e notificações um usuário alvo vê.
É provável que o agente malicioso utilize o kit para assumir o controle da conta do usuário e enganá-lo para que aprove o registro de uma chave de acesso iniciado pelo atacante.
A Okta Threat Intelligence usou código derivado do kit de phishing para recriar o seguinte fluxo, que se assemelha bastante ao processo de registro de chave de acesso do Microsoft Entra.
A primeira página do kit de phishing (/gate) revela um ícone de carregamento de página enquanto o kit de phishing realiza verificações anti-análise. A segunda página (/identify) solicita um nome de usuário. No momento da nossa análise, o kit de phishing não redirecionava para um provedor de identidade federado.
Figura 1. A página de login da Microsoft O-UNC-066, regenerada usando código extraído do kit de phishing.
A próxima página (/password) solicita ao usuário uma senha. As credenciais capturadas são enviadas em uma solicitação POST com um carimbo de data/hora e um ID para um painel do operador em /backend.php.
Figura 2. A página de desafio de senha da Microsoft O-UNC-066, regenerada usando código extraído do kit de phishing.
Nossa hipótese é que um operador de kit de phishing (que pode ser uma pessoa diferente do chamador ao telefone) captura as credenciais do usuário-alvo em poucos segundos e as insere na página de login legítima da Microsoft para o locatário-alvo.
O usuário visado vê então uma página (/processing) que apresenta outra tela de carregamento enquanto o kit de phishing aguarda a próxima instrução do operador. Nossa hipótese é que esse pequeno atraso seja necessário para que um agente malicioso se autentique na conta legítima da Microsoft do usuário usando as credenciais roubadas, observe quais desafios de autenticação multifator (MFA) são apresentados e selecione a próxima página do kit de phishing a ser apresentada ao usuário.
Próxima página do kit de phishing a ser apresentada ao usuário.
- Se o operador optar por concluir um desafio OTP por SMS ou for obrigado a fazê-lo, o usuário será direcionado para uma página chamada /submit-otp. O OTP capturado é enviado em uma solicitação POST para o painel do operador em /backend.php.
- Se o operador escolher ou for obrigado a concluir um desafio TOTP, o usuário será direcionado para uma página chamada /submit-authenticator. O OTP capturado é enviado em uma solicitação POST para o painel do operador em /backend.php.
- Se o operador optar por concluir um desafio Push MFA ou for obrigado a fazê-lo, o usuário será direcionado para uma página chamada /approve-authenticator (veja a imagem abaixo) e solicitado a inserir o número fornecido pelo operador em seu aplicativo autenticador.
Figura 3. A página de desafio MFA O-UNC-066, regenerada usando código extraído do kit de phishing.
Nessa fase do ataque, o usuário foi enganado por telefone e induzido a aprovar o acesso do invasor à sua conta do Microsoft 365.
Mantendo o pretexto da chave de acesso, os agentes maliciosos podem então direcionar os usuários para a página /passkey/register, que solicita ao usuário que crie uma chave de acesso.
Figura 4. A página de registro da chave de acesso O-UNC-066, regenerada usando código extraído do kit de phishing.
O kit de phishing parece explorar a falta de familiaridade do usuário com a autenticação por chave de acesso. Em uma cerimônia real de registro de chave de acesso, o usuário pode esperar que o sistema apresente uma caixa de diálogo para registrar uma chave de acesso em seu dispositivo. As páginas de chave de acesso neste kit de phishing parecem reproduzir esse processo sem registrar uma chave de acesso.
Na página /passkey , o usuário-alvo se depara com uma página da Microsoft que o incentiva a "salvar sua chave de recuperação" a partir de uma lista de frases BIP-39 controlada pelo invasor. Isso se assemelha bastante aos métodos usados em alguns aplicativos de criptomoedas para gerar frases-semente memoráveis.
Figura 5. A página opcional com a chave de acesso O-UNC-066, usando código extraído do kit de phishing.
Uma página subsequente /passkey/check solicita ao usuário que verifique a palavra final usada na frase mnemônica.
Não temos conhecimento de nenhuma aplicabilidade direta das frases-semente BIP-39 ao Microsoft Entra ou ao seu processo de registro de chaves de acesso. Um invasor que já tenha obtido acesso não autorizado a uma conta de usuário pode criar seus próprios códigos de recuperação usando um processo que não requer nenhuma intervenção do verdadeiro titular da conta.
É provável que essas páginas com tema de chave de acesso estejam disponíveis para o operador do kit de phishing como um artifício. É uma distração manter o usuário ocupado com uma tarefa enquanto o invasor inscreve sua própria chave de acesso na conta legítima do usuário da Microsoft.
A página /done confirma que o registro da chave de acesso foi bem-sucedido. Um usuário desavisado que não entende completamente como uma chave de acesso é cadastrada pode realmente acreditar que registrou uma na Microsoft simplesmente concluindo essas tarefas, que de outra forma seriam insignificantes.
Figura 7. Página de confirmação da campanha O-UNC-066, usando código extraído do kit de phishing.
O operador pode escolher quando enviar a página /done para o usuário. No mínimo, isso ajuda a operação de phishing a manter o pretexto original. Sempre que um usuário cadastra uma chave de acesso na Microsoft, o proprietário da conta comprometida recebe um e-mail legítimo da Microsoft notificando-o de que uma nova chave de acesso foi registrada em sua conta. Durante um ataque, a chave de acesso foi registrada diretamente pelo agente da ameaça junto à Microsoft, e ele está em posição de nomear a chave com algo que o usuário alvo consideraria inofensivo (talvez até mesmo utilizando a frase inicial escolhida pelo usuário alvo). Em contrapartida, a configuração de inscrição com chave de acesso que o usuário-alvo experimentou no site de phishing provavelmente existe apenas para enganar o usuário, fazendo-o acreditar que a inscrição feita pelo atacante foi a sua própria.
Infraestrutura
Observou-se que agentes de ameaça criaram subdomínios para qualquer entidade-alvo nos seguintes domínios:
- assignpasskey[.]com (2026-06-14, Internet Domain Service BS Corp., DDoS-Guard)
- deploypasskey[.]com (2026-04-21, Tucows, DDoS-Guard)
- passkeydeploy[.]com (2026-04-23, Internet Domain Service BS Corp, DDoS-Guard)
- passkeyadd[.]com (2026-05-08, Tucows, DDoS-Guard)
- setpasskey[.]com (2026-05-23, IQWeb FZ-LLC)
Assim, uma campanha direcionada à "entidade de exemplo" poderia ser algo como:
exampleentity[.]setpasskey[.]com
A infraestrutura de phishing observada pelo Okta Threat Intelligence estava hospedada no DDoS-Guard (AS57724, Rússia) e no IQWeb FZ-LLC (AS59692, EUA).
Impacto
Desde abril de 2026, um agente malicioso ligado ao O-UNC-066 opera um site de vazamento de dados com o nome Pink (relatado como "CL-CRI-1147" pela Unidade 42 da Palo Alto Networks).
Figura 7. O site Pink DLS (extorsão de dados)
Recomendações
Embora este conjunto de atividades de ameaça não tenha sido observado se passando pela Okta, campanhas semelhantes combinaram engenharia social baseada em voz e kits de phishing controlados por operadores:
Postagem Pública no Blog (disponível publicamente)
Aviso Rápido (Somente para clientes Okta)
Aviso de ameaça (somente para clientes Okta)
As recomendações abaixo são específicas para a defesa dos clientes da Okta.
ATT&CK
|
Tática
|
Recomendação de controle
|
T1566
|
phishing
|
Inscreva os usuários em sistemas de autenticação robustos, como Okta FastPass, chaves de acesso ou cartões inteligentes, e implemente medidas de proteção contra phishing nas políticas da empresa.
Estabelecer, comunicar e divulgar métodos para verificar a identidade dos colaboradores do suporte técnico quando estes entrarem em contato com os usuários.
|
T1078
|
phishing
|
Negue solicitações de locais onde sua organização não oferece serviços. as zonas de rede do Okta permitem que os administradores definam políticas que negam o acesso a aplicativos protegidos pelo Okta com base em geolocalização (país), ASN, IP ou outros critérios.
|
T1078
|
Contas válidas
|
As políticas de autenticação do Okta podem ser usadas para restringir o acesso a contas de usuário com base em uma série de pré-requisitos configuráveis pelo cliente. Recomendamos que os administradores restrinjam o acesso a aplicativos confidenciais a dispositivos gerenciados por ferramentas de gerenciamento de endpoints e protegidos por ferramentas de segurança de endpoints. |
T1078
|
Contas válidas
|
Solicita-se que os usuários sejam notificados sobre cada evento do ciclo de vida do autenticador (fator) por meio de notificações ao usuário final.
|
T1098
|
Manipulação de conta (registro de dispositivo)
|
Aplique as Políticas de Gerenciamento de Contas do Okta que restringem a capacidade de adicionar ou modificar autenticadores com base no contexto da rede, no status de gerenciamento do dispositivo e nos autenticadores registrados. Orientações específicas são fornecidas na seguinte postagem do blog: |
