Grupos rastreados como UNC6661, UNC6671 e UNC6240 usam engenharia social por voz, sites falsos de credenciais e registro indevido de MFA para acessar aplicações em nuvem, coletar dados sensíveis e pressionar vítimas com extorsão.
| Componente | Provedores de identidade, fluxos de SSO e MFA, contas Okta, e aplicações SaaS como e-mail corporativo, SharePoint e OneDrive. |
| Vetor | Chamadas de vishing com falsa identidade de equipe de TI direcionam usuários para páginas de coleta de credenciais e códigos MFA com aparência da organização alvo. |
| Impacto | Acesso não autorizado a ambientes SaaS, registro de dispositivo MFA controlado pelo invasor, coleta de dados sensíveis e comunicações internas, uso de e-mail comprometido para phishing adicional e extorsão. |
| Prioridade | Reforçar verificação de help desk, migrar para MFA resistente a phishing, auditar eventos de ciclo de vida de MFA e monitorar exportações ou downloads anômalos em SaaS. |
| Atores | A atividade é acompanhada em múltiplos agrupamentos, incluindo UNC6661, UNC6671 e UNC6240, com separação operacional em relação a UNC6040 no material analisado. |
| Artefatos | Os domínios de coleta foram registrados por meios distintos: NICENIC aparece associado a UNC6661 e Tucows aparece associado a UNC6671. |
Uma expansão recente de atividade financeira motivada está explorando a camada de identidade corporativa, e não uma falha de software em produtos ou infraestrutura de fornecedores. O padrão observado combina vishing avançado, personificação de equipes internas de TI, páginas falsas com identidade visual da empresa alvo e captura de credenciais SSO junto com códigos de autenticação multifator. O objetivo operacional é obter acesso inicial a contas legítimas, registrar um novo fator de MFA sob controle do invasor e usar essa sessão para alcançar aplicações SaaS que concentram dados sensíveis e comunicações internas.
A atividade foi registrada entre o início e meados de janeiro de 2026 e é acompanhada em diferentes agrupamentos, incluindo UNC6661, UNC6671 e UNC6240, também associado ao nome ShinyHunters. A separação em clusters reflete incerteza operacional relevante: parte da atividade pode representar evolução de táticas já conhecidas, enquanto outra parte pode envolver grupos copiando métodos anteriores. Há também distinção explícita em relação a UNC6040, grupo anteriormente vinculado a vishing contra instâncias Salesforce, sem sobreposição observada com a campanha mais recente descrita aqui.
O impacto confirmado concentra-se em comprometimento de identidade e abuso de aplicações SaaS. Em um caso, o acesso a contas de e-mail comprometidas foi usado para enviar mensagens de phishing a contatos ligados a empresas focadas em criptomoedas, com exclusão posterior dos e-mails para reduzir rastros visíveis. Em outras instâncias, houve acesso a contas Okta e uso de PowerShell para baixar dados sensíveis armazenados no SharePoint e no OneDrive. A fase final inclui extorsão, com relatos de escalada para assédio contra pessoas ligadas às organizações afetadas.
O fluxo começa com uma chamada de voz em que o operador se apresenta como integrante de TI da organização alvo. A vítima é induzida a acreditar que precisa atualizar ou ajustar suas configurações de MFA. Em vez de conduzir a pessoa por um processo legítimo, o operador encaminha para um link de coleta de credenciais com aparência alinhada à marca da empresa. A página coleta credenciais SSO e códigos MFA, permitindo que o invasor use a janela de autenticação para entrar como o usuário legítimo.
Depois da captura, as credenciais são usadas para registrar um dispositivo MFA controlado pelo invasor. Esse passo altera a persistência no plano de identidade: a conta deixa de depender apenas do código capturado durante a chamada e passa a aceitar um fator que o operador consegue satisfazer em tentativas futuras. A partir desse ponto, a atividade se desloca para plataformas SaaS e serviços de colaboração, com busca por informações sensíveis, comunicações internas e dados úteis para pressão extorsiva.
UNC6661 foi observado usando essa abordagem com falsa equipe de TI e links de coleta sob o pretexto de atualização de MFA. UNC6671 também personificou suporte interno para obter credenciais e códigos MFA em sites de coleta com identidade da vítima. As diferenças técnicas descritas incluem registradores de domínio distintos para infraestrutura de phishing: NICENIC para domínios ligados a UNC6661 e Tucows para domínios ligados a UNC6671. Além disso, um e-mail de extorsão após atividade UNC6671 não coincidiu com indicadores conhecidos de UNC6240, o que sugere participação de conjuntos diferentes de operadores ou uma estrutura criminosa menos rígida.
O uso de PowerShell aparece no material como mecanismo para baixar dados sensíveis de SharePoint e OneDrive. Não há indicação de vulnerabilidade explorada nos produtos SaaS citados; o ponto central é a quebra do processo humano e do controle de autenticação. Por isso, a defesa precisa tratar o problema como abuso de identidade, alteração de fatores de autenticação, sessão legítima desviada e exportação anômala de dados, não como exploração de RCE ou falha de patch em um servidor específico.
A superfície exposta envolve organizações que dependem de SSO, MFA por push, SMS, chamada telefônica ou e-mail, processos de help desk baseados em confirmação fraca de identidade e plataformas SaaS com dados corporativos sensíveis. O risco cresce quando usuários conseguem alterar métodos de autenticação sem validação robusta fora de banda, quando o suporte aceita confirmação apenas por voz ou quando administradores não têm visibilidade suficiente sobre eventos de inscrição de novos fatores.
Ambientes com Okta, e-mail corporativo, SharePoint, OneDrive e outras aplicações SaaS precisam ser avaliados como parte de uma única cadeia de identidade. O invasor não precisa comprometer o provedor em si se conseguir convencer um usuário a entregar credenciais e aprovar ou informar o fator temporário. Uma vez dentro, a coleta pode mirar mensagens internas, arquivos compartilhados, dados de clientes, listas de contatos e informações úteis para chantagem. O caso envolvendo contatos de empresas de criptomoedas indica também interesse em ampliar monetização a partir de contas já comprometidas.
- Usuários com permissão para registrar, redefinir ou alterar dispositivos MFA sem validação forte de identidade.
- Contas federadas por SSO com acesso a e-mail, repositórios de arquivos e aplicações SaaS com exportação de dados.
- Tenants com autenticação por SMS, chamada telefônica, e-mail ou push suscetível a engenharia social.
- Processos de suporte que aceitam solicitações sensíveis sem chamada de vídeo ao vivo ou verificação independente da identidade.
- Ambientes Okta em que eventos de ciclo de vida de MFA e autorizações OAuth não são revisados de forma contínua.
A investigação deve começar pela linha do tempo de identidade. Eventos de inscrição de novo dispositivo MFA, redefinição de fatores, alteração de método de autenticação e autenticações fora do horário normal devem ser correlacionados com chamadas ao help desk, tickets de suporte e acessos a páginas externas de credenciais. O sinal mais importante não é apenas uma tentativa de login falha, mas a combinação entre contato social, mudança de MFA e acesso subsequente a dados SaaS.
Em plataformas de colaboração, a defesa deve procurar downloads incomuns, exportações volumosas, acesso a bibliotecas sensíveis, leitura de comunicações internas e uso de automação para coleta. No e-mail, eventos de autorização OAuth, manipulação de caixa postal e exclusão de mensagens enviadas podem indicar uso da conta comprometida para phishing adicional e limpeza de rastros. A referência a utilitários como ToogleBox Email Recall aponta para a necessidade de monitorar comportamentos de recall, exclusão ou manipulação de mensagens após envio.
Na infraestrutura de rede e DNS, domínios de coleta recém-registrados com aparência da marca da vítima devem ser tratados como alerta, principalmente quando associados a registradores citados na atividade. A recomendação defensiva é defangar indicadores ao compartilhá-los internamente e priorizar classes de comportamento: domínios parecidos com a marca, páginas de login falsas, acessos originados de egressos não confiáveis e mudanças de autenticação feitas logo após contato de voz suspeito.
- Evento de cadastro de novo fator MFA seguido por acesso a SaaS de alto valor na mesma janela temporal.
- Autenticações de identidade fora do padrão de localização, horário, dispositivo ou ponto de saída confiável.
- Downloads ou exportações incomuns em SharePoint, OneDrive e outros repositórios SaaS sensíveis.
- Autorizações OAuth ou atividades de caixa postal que indiquem manipulação, recall ou exclusão de mensagens.
- Mensagens de phishing enviadas a partir de contas internas e removidas pouco depois do envio.
- Tickets ou chamadas ao help desk vinculados a redefinições de MFA, especialmente quando a verificação de identidade foi fraca.
A resposta deve priorizar a camada de identidade. Organizações expostas precisam revisar todos os registros recentes de MFA, invalidar fatores suspeitos, revogar sessões ativas de contas potencialmente comprometidas e forçar reautenticação segura. Quando houver indício de coleta em SaaS, a contenção deve incluir revisão de downloads, permissões, tokens OAuth, regras de e-mail, mensagens enviadas e dados acessados. A rotação de credenciais deve ser acompanhada de limpeza de dispositivos MFA não reconhecidos, pois trocar apenas a senha pode não remover a persistência obtida pelo invasor.
O endurecimento estrutural passa por MFA resistente a phishing, como chaves FIDO2 ou passkeys, em substituição a SMS, chamada telefônica, e-mail e fluxos push facilmente manipuláveis por engenharia social. O help desk precisa exigir validação mais forte para qualquer alteração sensível de autenticação, incluindo chamada de vídeo ao vivo quando aplicável e checagens independentes que não dependam apenas da conversa iniciada pelo solicitante. Acesso ao plano de gestão deve ser limitado a pontos de saída e locais físicos confiáveis, com controles de dispositivo e senhas fortes.
A prevenção também exige visibilidade. Logs de ações de identidade, autorizações, ciclo de vida de MFA e exportações SaaS devem ser preservados e consultáveis por tempo suficiente para reconstruir a cadeia completa. Detecções devem combinar eventos de autenticação, mudanças administrativas, acessos a arquivos, comportamento de e-mail e sinais de engenharia social. Como a atividade não depende de uma vulnerabilidade de fornecedor, a mitigação efetiva depende de processo, telemetria, autenticação resistente a phishing e resposta rápida a alterações anômalas de identidade.
- Migrar contas críticas para FIDO2 ou passkeys e remover SMS, chamada telefônica e e-mail como métodos de autenticação.
- Exigir verificação forte do usuário antes de redefinir MFA, registrar dispositivo ou alterar métodos de autenticação.
- Restringir acesso administrativo a pontos de saída confiáveis, dispositivos gerenciados e locais esperados.
- Auditar inscrições recentes de MFA, autorizações OAuth, sessões ativas e alterações de conta em provedores de identidade.
- Revisar downloads, exportações e acessos a SharePoint, OneDrive, e-mail e demais aplicações SaaS após qualquer suspeita.
- Treinar help desk e usuários para tratar chamadas de atualização de MFA como evento de alto risco que exige validação independente.
0 Comentários