Campanhas ligadas ao ShinyHunters miram SaaS com vishing e abuso de identidade

Intrusões usam credenciais válidas, manipulação de MFA, autorizações OAuth e exportações nativas para roubo de dados em ambientes SaaS, sem depender de exploração de vulnerabilidade em fornecedores.

Componente	Provedores de identidade, SSO, MFA, Google Workspace, Microsoft 365, Salesforce, DocuSign, Atlassian, consoles de nuvem e repositórios de código conectados ao ambiente corporativo.
Vetor	Vishing, coleta de credenciais em portais falsificados com marca da vítima, manipulação de suporte técnico, registro de novos fatores de MFA e uso de sessões, tokens OAuth ou contas legítimas.
Impacto	Acesso não autorizado a SaaS, exportação em massa de documentos e registros, alteração de configurações administrativas, exclusão de notificações de segurança e base para extorsão por roubo de dados.
Prioridade	Revogar sessões e autorizações OAuth, bloquear novos registros de MFA, restringir redefinições de senha, exigir dispositivos gerenciados e migrar contas críticas para MFA resistente a phishing.
Artefatos	Eventos de ciclo de vida de MFA no Okta, alterações de métodos no Entra ID, autorizações OAuth no Google Workspace, eventos FileDownloaded e FileAccessed no Microsoft 365, uso de Salesforce Data Loader, exportações do Google Takeout e atividade com agente de usuário contendo PowerShell.
Mitigação	Aplicar FIDO2, passkeys ou WebAuthn, políticas de acesso condicional, verificação manual forte no help desk, escopo mínimo para tokens e contas não humanas, segredos em gerenciador dedicado e alertas para exportação, download e alteração administrativa em SaaS.

Resumo técnico

Clusters de extorsão associados à marca ShinyHunters ampliaram operações contra ambientes SaaS usando identidade como ponto de entrada principal. A cadeia observada não depende de exploração de falha em produto, execução de malware em endpoint ou abuso de CVE. O acesso inicial ocorre quando operadores convencem usuários ou equipes de suporte a entregar credenciais, aprovar redefinições, registrar novos dispositivos ou aceitar mudanças em métodos de autenticação. Depois que uma conta passa pelo SSO, a atividade maliciosa se mistura a fluxos legítimos de administração, APIs, conectores e exportações nativas, o que reduz a utilidade de controles baseados apenas em binários, hashes ou tráfego de comando e controle tradicional.

O risco operacional está na combinação de credencial válida, MFA manipulável e alta dependência de aplicações SaaS para dados sensíveis. Um atacante que obtém acesso ao provedor de identidade pode pivotar para Salesforce, Google Workspace, Microsoft 365, Atlassian, DocuSign, consoles de nuvem e repositórios de código, preservando uma aparência de sessão normal. A investigação precisa começar pelo plano de controle de identidade: quem autenticou, de onde autenticou, qual fator foi registrado, qual dispositivo foi associado, quais autorizações OAuth foram concedidas e quais volumes de dados foram exportados. Sem esses registros, a primeira evidência pode aparecer apenas quando a organização recebe uma tentativa de extorsão.

A resposta defensiva exige contenção de identidade antes de análise de endpoint. Contas suspeitas devem ter sessões e tokens revogados em IdP e SaaS, autorizações OAuth devem ser revisadas, redefinições públicas de senha precisam ser restringidas e novos registros de MFA devem ser pausados temporariamente durante a contenção. Em paralelo, acessos administrativos e aplicações sensíveis devem aceitar apenas dispositivos gerenciados, conformes e vindos de redes ou saídas corporativas conhecidas. O objetivo imediato é interromper a continuidade de sessão e impedir que o invasor transforme uma credencial obtida por engenharia social em persistência operacional.

Fluxo técnico

O fluxo típico começa com vishing ou phishing direcionado. O operador usa informações pessoais ou corporativas já disponíveis em violações anteriores para aumentar credibilidade durante chamadas com usuários e help desk. Dados como matrícula, nome de gerente ou identificadores internos não devem ser tratados como prova suficiente de identidade, porque podem estar em bases já expostas. Em cenários de suporte, o atacante tenta induzir uma redefinição de senha, uma alteração de MFA ou a aprovação de um novo dispositivo. Em cenários contra usuário final, a abordagem força urgência fora do horário comercial ou orienta a vítima a acessar um portal de autenticação falsificado com aparência da organização.

Após obter credenciais ou modificar o MFA, o atacante autentica em SSO e usa recursos nativos das plataformas. Em Okta, eventos de inscrição, ativação, redefinição ou remoção de fatores de MFA são sinais importantes, especialmente quando ocorrem próximos de recuperação de conta ou de login a partir de geolocalização inédita. Em Entra ID, alterações de métodos de autenticação, mudanças em políticas de acesso condicional, locais nomeados e postura de segurança podem indicar preparação para persistência. Em Google Workspace, autorizações OAuth suspeitas, habilitação de aplicativos, exclusão de mensagens de notificação e exportações do Google Takeout indicam abuso do próprio ecossistema. Em Microsoft 365, downloads de SharePoint e OneDrive com user agent contendo PowerShell apontam para coleta automatizada.

A fase de exfiltração tende a usar exportações e APIs legítimas. Salesforce pode ser acessado por Data Loader, relatórios, API, eventos de bulk job e aplicativos conectados. Atlassian pode revelar acesso a espaços, páginas, exportações e tokens de API. DocuSign pode expor envelopes, documentos baixados, operações em lote e chaves de integração. Repositórios de código adicionam outra camada de risco porque podem conter segredos históricos, arquivos de configuração, tokens de CI/CD, chaves de serviço e permissões de deploy. A defesa precisa correlacionar login, mudança de fator, autorização de aplicativo e download em volume na mesma janela temporal, em vez de tratar cada SaaS como um silo isolado.

Superfície afetada

A superfície exposta inclui qualquer ambiente em que a identidade centralizada funcione como controle de acesso para dados, administração ou automação. Provedores de identidade e SSO são críticos porque uma alteração bem-sucedida de MFA pode liberar acesso para múltiplas aplicações sem interação adicional com o endpoint corporativo. SaaS com contas locais fora do IdP aumentam o risco, pois permitem persistência ou acesso paralelo que não segue o ciclo de vida centralizado. Contas administrativas, assistentes executivos, equipes financeiras, operadores de suporte, proprietários de integração e usuários com permissão de exportação em massa devem ser priorizados na revisão.

Contas não humanas elevam a gravidade quando possuem tokens longos, escopo amplo ou permissões privilegiadas. Chaves de API, tokens OAuth, service accounts e credenciais embutidas em repositórios, pipelines e arquivos de configuração podem ser usados depois da etapa inicial de engenharia social. O controle adequado envolve inventário de identidade programática, proprietário definido, escopo por recurso, restrição por IP, rotação e preferência por federação de identidade de workload com tokens temporários. Em nuvens públicas, políticas como bloqueio de criação de chaves de service account, restrição de regiões, proteção contra remoção de backups e perímetros de dados reduzem o impacto de uma credencial roubada.

• Provedores de identidade com autoatendimento de senha, registro de novos fatores ou aprovação fraca de MFA expõem o ponto de entrada mais provável.
• Ambientes Google Workspace, Microsoft 365 e Salesforce ficam em risco quando exportações, OAuth, APIs e eventos de download não são ingeridos no SIEM.
• Repositórios de código e CI/CD ampliam o impacto quando tokens amplos, chaves estáticas ou segredos antigos permanecem acessíveis após o comprometimento de SSO.
• Consoles AWS, Azure e GCP exigem políticas de organização, acesso condicional, bloqueio de chaves estáticas e alertas para comandos de reconhecimento, como GetCallerIdentity.

Hunting e telemetria

A investigação deve privilegiar eventos de identidade e SaaS. No Okta, procure okta.user.mfa.factor.enroll, okta.user.mfa.factor.activate, okta.user.mfa.factor.deactivate, okta.user.mfa.factor.reset_all, redefinições de senha e início de recuperação de conta próximos de sessões iniciadas fora do padrão do usuário. Também é relevante identificar ações administrativas feitas a partir de ASNs de datacenter, VPN, proxy ou origem sem histórico corporativo. No Entra ID, eventos de método de autenticação, políticas de acesso condicional, alterações de locais confiáveis e registros de aplicativo devem ser correlacionados com login recente e alteração de dispositivo.

Em Google Workspace, a telemetria necessária inclui autorização OAuth, escopos concedidos, aplicação autorizada, usuário que concedeu acesso, IP de origem e geolocalização. Eventos de Gmail devem revelar exclusão ou remoção permanente de notificações de segurança, principalmente mensagens relacionadas a novo método, novo dispositivo ou autenticação. Atividade do Google Takeout deve ser tratada como evento de alto valor, porque exportações corporativas desse tipo tendem a ser raras e indicam caminho direto de extração. Também há valor em detectar autorização do aplicativo ToogleBox Recall ou nomes equivalentes quando associados a manipulação de caixa postal.

Em Microsoft 365, colete o Unified Audit Log com operações de SharePoint e OneDrive, incluindo FileDownloaded, FileAccessed, recurso alvo, usuário, IP, geolocalização e user agent. Downloads em volume por sessão, sequência de arquivos .doc, .docx, .xls, .xlsx, .ppt, .pptx e .pdf, ou user agent com PowerShell devem ser investigados. Em Exchange, exclusões SoftDelete, HardDelete ou MoveToDeletedItems com assunto ligado a MFA, método de segurança ou registro de dispositivo podem indicar tentativa de apagar alertas enviados ao usuário.

• Mudança de MFA ou método de autenticação até 30 minutos após redefinição de senha, recuperação de conta ou login de local inédito.
• Três ou mais usuários com eventos de MFA originados do mesmo IP em janela curta, especialmente se o endereço não pertence à rede corporativa.
• Autorização OAuth com escopos amplos, aplicativo desconhecido, origem incomum ou vínculo com exclusão de mensagens de segurança.
• Exportação do Google Takeout iniciada e concluída pela mesma conta, fora de fluxos aprovados de jurídico, RH ou desligamento.
• Eventos FileDownloaded ou FileAccessed em SharePoint e OneDrive com PowerShell, grande soma de bytes ou contagem elevada em poucos minutos.
• Consultas no SharePoint por termos como confidential, internal, vpn, salesforce, proposal ou poc, quando incompatíveis com o perfil normal da conta.

Mitigação

A contenção deve começar com a retirada de capacidade operacional do invasor. Contas suspeitas precisam ser desabilitadas ou bloqueadas temporariamente, todas as sessões ativas devem ser encerradas, tokens OAuth e autorizações de aplicativos precisam ser revogados, e registros recentes de MFA devem ser revisados para remover dispositivos não reconhecidos. Durante a resposta, portais públicos de redefinição de senha devem ser limitados, contas administrativas não devem usar autoatendimento para recuperação e novos registros de MFA devem ficar bloqueados até que a equipe valide a extensão do incidente. VPN, VDI e aplicações SaaS sensíveis devem exigir dispositivo gerenciado, conformidade de postura e origem em egressos confiáveis.

O help desk deve operar com verificação de alta confiança para qualquer solicitação de senha, MFA, dispositivo ou aplicativo. Chamadas recebidas não devem resultar em acesso imediato quando envolvem fornecedores ou suporte externo; a validação precisa ocorrer por contato independente com o responsável registrado do fornecedor. Para usuários internos, a organização deve usar retorno para número confiável, aprovação fora de banda por gerente conhecido e conferência visual quando aplicável. Identificadores como documento parcial, número de funcionário ou nome de gestor não bastam, pois podem estar disponíveis em vazamentos prévios.

No médio prazo, a arquitetura de identidade precisa reduzir a dependência de MFA passível de engenharia social. SMS, chamada telefônica, push simples e e-mail são controles frágeis contra esse padrão de intrusão. Contas privilegiadas e perfis de alto risco devem usar FIDO2, passkeys ou WebAuthn, com políticas que considerem identidade, dispositivo, localização, risco e contexto da aplicação. Contas não humanas devem migrar de credenciais estáticas para federação de workload baseada em OIDC quando possível, com tokens curtos, escopo mínimo e restrição por recurso. A validação final deve confirmar que os logs chegam ao SIEM com campos suficientes para responder quem autenticou, qual fator mudou, qual aplicativo foi autorizado e quais dados foram exportados.

• Revogar sessões, refresh tokens, autorizações OAuth, chaves de API suspeitas e tokens de acesso emitidos antes da contenção.
• Bloquear criação ou alteração de MFA até concluir revisão de usuários afetados, dispositivos registrados e métodos de autenticação recém-adicionados.
• Exigir MFA resistente a phishing para administradores, contas de alto impacto e acesso a IdP, repositórios de código, consoles de nuvem e SaaS críticos.
• Aplicar políticas de acesso condicional por dispositivo gerenciado, conformidade, IP confiável, geolocalização e risco de autenticação.
• Inventariar contas não humanas, mover segredos para gerenciador dedicado, remover credenciais de código e pipelines, e rotacionar qualquer segredo exposto.
• Criar detecções para exportações SaaS, downloads em volume, exclusão de notificações de segurança, aplicativos OAuth desconhecidos e alterações administrativas fora do padrão.