Campanhas rastreadas como UNC6661, UNC6671 e UNC6240 usam engenharia social contra SSO e autenticação multifator para acessar Okta, Microsoft 365, Salesforce, DocuSign, Google Workspace e outros ambientes SaaS antes de extorsão.
| Componente | Contas corporativas federadas por SSO, provedores de identidade e aplicações SaaS como Okta, SharePoint, OneDrive, Salesforce, DocuSign, Google Workspace e possivelmente Slack. |
| Vetor | Phishing por voz com falsa atualização de autenticação multifator, coleta de credenciais SSO e códigos MFA em sites com aparência da vítima, seguido de registro de novo dispositivo MFA pelo invasor. |
| Impacto | Exfiltração de documentos, dados pessoais, comunicações internas e amostras usadas em extorsão, além de possível envio de phishing a partir de contas de e-mail comprometidas. |
| Prioridade | Migrar contas críticas para MFA resistente a phishing, revisar novos fatores MFA registrados, auditar OAuth em SaaS e correlacionar downloads em massa com acessos vindos de VPNs comerciais ou proxies residenciais. |
| Artefatos | Atividade associada a UNC6661, UNC6671 e UNC6240; uso observado de PowerShell em acessos ao SharePoint; autorização do aplicativo ToogleBox Recall; pesquisas por termos como poc, confidential, internal, proposal, salesforce e vpn. |
| IoCs | Endereços observados incluem 24.242.93[.]122, 23.234.100[.]107, 23.234.100[.]235, 73.135.228[.]98, 157.131.172[.]74, 149.50.97[.]144, 67.21.178[.]234, 142.127.171[.]133, 76.64.54[.]159, 76.70.74[.]63, 206.170.208[.]23, 68.73.213[.]196, 37.15.73[.]132, 104.32.172[.]247, 85.238.66[.]242, 199.127.61[.]200, 209.222.98[.]200, 38.190.138[.]239 e 198.52.166[.]197. |
A atividade observada no início e em meados de janeiro de 2026 mostra uma expansão operacional de campanhas de extorsão associadas à marca ShinyHunters. O acesso inicial não depende de exploração de falha em produto ou infraestrutura dos fornecedores de SaaS. A cadeia começa com engenharia social: operadores ligam para funcionários, se passam por equipe de TI e afirmam que a organização está atualizando configurações de autenticação multifator. A vítima é conduzida a um portal falso com aparência corporativa, onde insere credenciais de SSO e códigos MFA. Com esses dados, o invasor autentica a sessão e registra um dispositivo próprio como novo fator de autenticação, reduzindo a dependência de nova interação com a vítima.
Nos incidentes atribuídos a UNC6661, os domínios de coleta de credenciais seguiram padrões que imitam portais internos, SSO, suporte técnico, identidade ou acesso remoto. Exemplos de iscas incluem variações de nomes corporativos com termos como sso, internal, support, okta, azure, zendesk e access. Parte da infraestrutura foi registrada com NICENIC, enquanto atividade semelhante atribuída a UNC6671 usou estrutura de domínio parecida, mas com maior presença de registros via Tucows. Essa diferença operacional, combinada com estilos distintos de extorsão e identificadores de contato separados, sustenta a hipótese de participação de operadores diferentes ou de agrupamentos parcialmente independentes.
Depois que a sessão SSO é comprometida, o acesso às aplicações SaaS depende das permissões já concedidas ao usuário invadido. A movimentação posterior não exige privilégio administrativo em todos os casos; uma conta comum com acesso a documentos, registros de CRM, envelopes de assinatura eletrônica ou mensagens internas pode ser suficiente para coleta de dados sensíveis. Foram observados eventos de FileDownloaded e FileAccessed no SharePoint, downloads em DocuSign, acessos ao Salesforce e consultas em aplicações de nuvem buscando termos associados a propriedade intelectual, rede, propostas comerciais e dados internos. Em pelo menos uma ocorrência, PowerShell apareceu no User-Agent durante acesso programático a arquivos do SharePoint, o que indica automação para varredura ou extração em volume.
Um ponto relevante da cadeia é a tentativa de esconder alterações de autenticação. Em um incidente envolvendo conta de cliente Okta, os operadores autorizaram o complemento ToogleBox Recall no Google Workspace. O aplicativo tem capacidade relacionada a leitura contextual e execução de ações no Gmail e em Apps Script, e foi usado para apagar a mensagem de notificação de inscrição de método de segurança enviada pelo Okta. Esse comportamento reduz a chance de o usuário perceber rapidamente que um novo método MFA foi associado à sua identidade. Em outra ocorrência, uma conta de e-mail comprometida foi usada para enviar phishing a contatos ligados a empresas de criptomoedas; as mensagens enviadas foram removidas depois, indicando tentativa de reduzir rastros nos itens enviados e nos fluxos de resposta a incidente.
A fase de extorsão ligada a UNC6240 envolve mensagens com alegações sobre dados roubados, prazo de pagamento de 72 horas, endereço BTC de destino e amostras hospedadas no Limewire como prova de posse. Também houve relatos de mensagens de texto enviadas a funcionários e ataques de negação de serviço distribuída contra sites de vítimas. No fim de janeiro de 2026, surgiu um site de vazamento de dados com a marca SHINYHUNTERS, contendo supostas vítimas e contatos shinycorp@tutanota[.]com e shinygroup@onionmail[.]com, endereços já associados à atividade de extorsão rastreada nesse conjunto de operações.
A superfície exposta concentra-se em organizações que usam SSO para acesso a múltiplos SaaS e ainda dependem de MFA suscetível a engenharia social, como códigos de uso único, SMS, notificações push aprovadas manualmente ou fluxos em que o usuário consegue repassar um desafio em tempo real. O risco aumenta quando uma mesma identidade concede acesso a repositórios de documentos, CRM, assinatura eletrônica, e-mail, colaboração corporativa e diretórios de clientes. Nessa configuração, o comprometimento de uma conta pode atravessar várias aplicações sem exploração técnica adicional.
Ambientes com Okta devem tratar inscrições recentes de fatores MFA, alterações de política, acesso ao console administrativo e eventos executados de redes anônimas como sinais de alta prioridade. Em Microsoft 365, a atenção deve recair sobre SharePoint, OneDrive e Exchange, especialmente quando a sessão apresenta User-Agent incomum, sequência de downloads de documentos ou deleção de notificações sobre MFA. Em Google Workspace, autorizações OAuth de aplicativos não usuais, principalmente ToogleBox Recall, precisam ser analisadas junto com escopos concedidos, usuário autorizador, endereço IP e data do evento. Em Salesforce e DocuSign, downloads de registros, documentos anexos e envelopes arquivados devem ser correlacionados com origem de rede, dispositivo, país, horário e histórico normal do usuário.
- Contas com acesso SSO a múltiplos SaaS e MFA não resistente a phishing.
- Usuários de negócio com acesso a
Salesforce, propostas, documentos internos, dados pessoais e comunicações com clientes. - Sessões autenticadas vindas de VPNs comerciais ou proxies residenciais associados a serviços como
Mullvad,Oxylabs,NetNut,9Proxy,Infaticaensocks. - Ambientes que permitem autorização OAuth por usuário final sem revisão administrativa ou sem alerta contextual.
A investigação deve começar pelo provedor de identidade, pois a cadeia depende da captura e reutilização de credenciais. Procure inscrições de novo método MFA, redefinições de fator, acesso ao painel administrativo, concessão de papéis administrativos e eventos permitidos a partir de endereços marcados como anonimizados. O valor defensivo está na correlação: um novo fator MFA registrado por um usuário, seguido de acesso a SharePoint, Salesforce, DocuSign ou Google Workspace em curto intervalo, é mais forte do que qualquer indicador isolado.
Em Microsoft 365, priorize eventos FileDownloaded, FileAccessed e SearchQueryPerformed em SharePoint e OneDrive. Sinais consistentes incluem grande número de documentos acessados em poucos minutos, múltiplas extensões de arquivo como .docx, .xlsx, .pptx e .pdf, User-Agent contendo PowerShell e pesquisas por termos como poc, proposal, confidential, internal, salesforce e vpn. Em Exchange, busque SoftDelete, HardDelete e MoveToDeletedItems envolvendo assuntos relacionados a novo método, dispositivo, MFA, 2FA ou configuração de segurança, filtrando eventos simples de login para reduzir ruído.
Em Google Workspace, eventos de autorização OAuth com ToogleBox Recall devem ser revisados mesmo quando o usuário parece legítimo. Escopos como https://www.googleapis.com/auth/gmail.addons.current.message.readonly, https://www.googleapis.com/auth/gmail.addons.execute, https://www.googleapis.com/auth/script.external_request, https://www.googleapis.com/auth/script.locale e https://www.googleapis.com/auth/userinfo.email exigem análise de finalidade, aprovação administrativa e necessidade de negócio. Em Salesforce e DocuSign, anomalias de login, downloads arquivados e acessos fora do padrão precisam ser comparados ao histórico de dispositivo e localização do usuário.
- Novo fator MFA registrado logo antes de acessos a várias aplicações SaaS.
- Eventos
FileDownloadedouFileAccessedem massa noSharePointcomUser-AgentcontendoPowerShell. - Pesquisas em repositórios por
poc,confidential,internal,proposal,salesforceouvpn. - Autorização OAuth para
ToogleBox RecallemGoogle Workspace. - Deleção de e-mails de notificação sobre inscrição, alteração ou configuração de MFA.
- Tráfego autenticado originado de VPNs comerciais, proxies residenciais ou endereços como
149.50.97.144,76.64.54[.]159e73.135.228[.]98quando incompatível com o perfil do usuário.
A resposta deve separar contenção de correção estrutural. Na contenção, desative sessões ativas do usuário comprometido, remova fatores MFA recém-inscritos que não sejam reconhecidos, redefina credenciais, revogue tokens OAuth e valide regras de encaminhamento, aplicativos autorizados, permissões concedidas e mensagens apagadas. Em paralelo, preserve logs do IdP, Microsoft 365, Google Workspace, Salesforce, DocuSign, VPN corporativa e ferramentas de EDR antes que retenções curtas eliminem evidências de movimentação entre SaaS.
A correção estrutural passa por MFA resistente a phishing para contas críticas e, sempre que possível, para toda a força de trabalho. Chaves FIDO2 e passkeys vinculadas ao domínio reduzem a viabilidade do fluxo de vishing porque o segredo não é transferível para um portal falso da mesma maneira que códigos, prompts push ou senhas. Políticas de acesso condicional também devem exigir dispositivo gerenciado, postura de segurança, risco de sessão e localização coerente para aplicações de alto impacto. Para SaaS com dados sensíveis, limite consentimento OAuth por usuário final, aplique revisão administrativa a novos aplicativos, reduza permissões permanentes e monitore exportações em volume.
A validação final precisa confirmar se houve exfiltração e se a identidade foi usada para novas tentativas de acesso. Revise mensagens enviadas e apagadas, contatos externos abordados, downloads por arquivo, consultas realizadas, envelopes de assinatura baixados e registros de CRM acessados. Quando houver evidência de dados retirados, preserve a linha do tempo técnica, escopo de informação exposta, usuários afetados, aplicações envolvidas e mecanismos usados para apagar rastros. Bloqueios amplos por IP devem ser usados com cautela porque vários indicadores pertencem a serviços legítimos de VPN ou proxy; a abordagem mais robusta é usar esses endereços como pivôs de caça combinados com identidade, novo MFA, OAuth anômalo e acesso incomum a dados.
- Invalidar sessões e tokens, redefinir senha e remover fatores MFA não reconhecidos.
- Revogar autorizações OAuth suspeitas, incluindo
ToogleBox Recall, e revisar escopos concedidos. - Migrar contas privilegiadas e usuários com acesso a dados sensíveis para
FIDO2ou passkeys. - Habilitar alertas para registro de novo MFA, deleção de notificações de segurança e downloads em massa em SaaS.
- Restringir consentimento OAuth por usuário final e exigir aprovação administrativa para aplicativos com acesso a e-mail, documentos ou automação.
- Correlacionar IoCs com comportamento de conta antes de aplicar bloqueios amplos por IP.
0 Comentários