Cordial Spider e Snarky Spider usam engenharia social por voz, páginas AiTM, abuso de IdP e movimentação dentro de aplicações SaaS para roubo de dados e extorsão com baixa presença em endpoints.
| Componente | Ambientes SaaS integrados a SSO e IdP, incluindo Google Workspace, HubSpot, Microsoft SharePoint e Salesforce |
| Vetor | Chamadas de vishing com impersonação de suporte de TI direcionam usuários a páginas AiTM com tema de SSO para capturar credenciais, códigos de MFA e sessões autenticadas |
| Impacto | Roubo de dados em aplicações SaaS, acesso lateral por relação de confiança do IdP e extorsão baseada em arquivos e relatórios corporativos |
| Prioridade | Revisar eventos de autenticação SSO, registros de dispositivos MFA, regras de caixa de entrada e acessos anômalos a repositórios SaaS de alto valor |
| Artefatos | Cordial Spider, BlackFile, CL-CRI-1116, O-UNC-045, UNC6671, Snarky Spider, O-UNC-025, UNC6661, páginas AiTM, proxies residenciais e técnicas LotL |
| Alvos | Organizações de varejo e hospitalidade aparecem como foco observado para CL-CRI-1116 desde fevereiro de 2026 |
Dois agrupamentos de cibercrime, rastreados como Cordial Spider e Snarky Spider, vêm conduzindo campanhas de roubo de dados e extorsão com operação concentrada em ambientes SaaS. A atividade é relevante porque desloca boa parte da intrusão para serviços confiáveis já integrados ao SSO corporativo, reduzindo a dependência de malware em endpoint, cargas persistentes locais ou exploração tradicional de vulnerabilidades. O ponto inicial observado é a engenharia social por voz: operadores se passam por equipe de TI, conduzem a vítima para páginas AiTM que imitam fluxos de autenticação SSO e coletam credenciais, códigos de MFA ou material de sessão suficiente para entrar no provedor de identidade.
A característica operacional mais crítica é o uso do IdP como ponto único de entrada para múltiplas aplicações SaaS. Quando a conta comprometida possui acesso a serviços conectados por SSO, os invasores não precisam comprometer cada aplicação separadamente. Eles aproveitam a relação de confiança entre o IdP e os serviços integrados para acessar Google Workspace, HubSpot, Microsoft SharePoint, Salesforce e outros sistemas onde dados comerciais, relatórios internos e arquivos de alto valor ficam armazenados. Essa abordagem acelera o tempo entre a coleta de credenciais e a exfiltração, ao mesmo tempo em que produz menos sinais clássicos de comprometimento em estáções de trabalho.
Cordial Spider, também associado aos nomes BlackFile, CL-CRI-1116, O-UNC-045 e UNC6671, e Snarky Spider, também rastreado como O-UNC-025 e UNC6661, apresentam sobreposição de táticas e objetivos. Ambos são avaliados como ativos desde pelo menos outubro de 2025. Snarky Spider é descrito como um grupo de falantes nativos de inglês com vínculos ao ecossistema de e-crime conhecido como The Com. Para CL-CRI-1116, há avaliação de confiança moderada de associação provável com The Com, com atividade voltada principalmente ao setor de varejo e hospitalidade desde fevereiro de 2026.
A cadeia começa com seleção de usuários e contato por vishing. O operador assume o papel de suporte, central de TI ou função equivalente, criando uma justificativa para que a vítima acesse uma página de autenticação controlada pelo adversário. A página AiTM replica a experiência visual e o fluxo de SSO, encaminhando ou intermediando a autenticação real para capturar credenciais e fatores adicionais. Quando o processo envolve MFA, o objetivo não é apenas obter senha, mas induzir a vítima a aprovar o acesso, informar códigos temporários ou completar um fluxo que permita ao atacante estabelecer uma sessão autenticada no IdP.
Após a entrada inicial, os operadores manipulam mecanismos de confiança do ambiente de identidade. Um comportamento observado é o registro de um novo dispositivo para manter acesso e contornar verificações de MFA, acompanhado da remoção de dispositivos previamente cadastrados em alguns casos. Em seguida, os invasores configuram regras de caixa de entrada para apagar notificações automáticas relacionadas a registro de dispositivo ou atividade não autorizada. Essa etapa é importante para reduzir a chance de o usuário perceber alertas gerados pelo próprio IdP ou serviço de e-mail, principalmente quando a organização depende de notificações ao usuário como camada de detecção.
Com a sessão válida, a operação passa para reconhecimento interno e escalada social. Os invasores consultam diretórios de funcionários, organogramas, catálogos internos ou listas acessíveis por SaaS para identificar contas com privilégios maiores. A partir dessa enumeração, eles executam novas interações de engenharia social contra usuários com acesso ampliado, buscando credenciais, aprovações MFA ou sessões com autorização mais ampla. A atividade usa técnicas LotL, ou seja, recursos nativos das plataformas e permissões legítimas da conta comprometida, em vez de ferramentas ruidosas implantadas em máquinas locais.
A fase de coleta se concentra em arquivos, relatórios e bases de negócio disponíveis em aplicações SaaS. Em Google Workspace e SharePoint, a busca tende a priorizar documentos compartilhados, unidades corporativas e conteúdo com nomes sensíveis a finanças, clientes, operações, contratos ou incidentes. Em Salesforce e HubSpot, o interesse recai sobre dados comerciais, registros de clientes, histórico de relacionamento e relatórios exportáveis. A exfiltração ocorre para infraestrutura controlada pelo adversário, com uso de proxies residenciais para mascarar a origem geográfica e reduzir bloqueios baseados apenas em reputação de IP.
A superfície exposta inclui qualquer organização que use SSO para centralizar acesso a aplicações SaaS sem controles fortes de contexto, revisão de dispositivos MFA e telemetria integrada entre identidade, e-mail e aplicações. O risco aumenta quando usuários comuns conseguem registrar novos dispositivos sem aprovação adicional, quando regras de caixa de entrada podem ser criadas sem monitoramento, e quando sessões válidas do IdP concedem acesso amplo a múltiplos serviços críticos. Contas de suporte, administração de SaaS, vendas, finanças, operações e liderança executiva merecem atenção porque combinam alto valor de dados com grande superfície de interação social.
A atividade observada contra varejo e hospitalidade indica interesse em setores com grande volume de dados operacionais e comerciais, múltiplas unidades, dependência de atendimento interno e pressão por continuidade. Esses ambientes frequentemente usam plataformas de CRM, colaboração e gestão documental para coordenar lojas, reservas, fornecedores, campanhas e atendimento. A presença de muitos usuários distribuídos favorece pretextos de suporte remoto e dificulta validação presencial de chamadas. Ainda assim, o padrão técnico não é limitado a esses setores: qualquer ambiente SaaS federado por IdP pode ser explorado se o adversário conseguir completar a autenticação inicial e manter uma sessão confiável.
O impacto não depende de execução de código em servidor próprio. A conta autenticada já carrega permissões suficientes para busca, leitura, exportação e compartilhamento de dados. Por isso, controles tradicionais focados em antivírus, EDR isolado ou bloqueio de binários podem não enxergar o núcleo da intrusão. A defesa precisa correlacionar identidade, dispositivos MFA, regras de e-mail, acesso a arquivos, exportações em massa, criação de tokens ou sessões, e uso de endereços IP residenciais incomuns para o perfil do usuário.
- Contas autenticadas via SSO com acesso a Google Workspace, HubSpot, Microsoft SharePoint, Salesforce e serviços conectados ao IdP
- Usuários com permissões para registrar dispositivos MFA, aprovar sessões ou criar regras de caixa de entrada
- Diretórios internos, listas de funcionários e dados de organograma usados para identificar alvos de maior privilégio
- Ambientes de varejo e hospitalidade expostos a vishing com impersonação de help desk desde fevereiro de 2026 no caso de
CL-CRI-1116
A investigação deve começar pelo plano de identidade. Eventos de autenticação bem-sucedida após chamadas suspeitas, alterações de MFA, registro de novos dispositivos, remoção de dispositivos existentes e criação de sessões a partir de ASN, geolocalização ou proxy residencial incomum são sinais de alto valor. A análise precisa considerar que o tráfego pode vir de endereços residenciais e não necessariamente de infraestrutura maliciosa já classificada. Portanto, regras baseadas apenas em reputação de IP tendem a falhar quando não combinadas com contexto de usuário, histórico de dispositivo, localização usual, horário e aplicação acessada.
No e-mail, a criação de regras automáticas deve receber prioridade. Regras que apagam, arquivam ou movem mensagens contendo termos relacionados a MFA, dispositivo, segurança, login, alerta, autenticação ou registro podem indicar tentativa de ocultar notificações. O mesmo vale para alterações feitas logo após uma autenticação anômala ou antes de exportações em SaaS. Em aplicações de colaboração e CRM, a telemetria deve procurar consultas incomuns, acesso a muitos arquivos em curto período, downloads de relatórios, exportações, compartilhamento externo, enumeração de pastas e acesso a dados fora do padrão funcional do usuário.
Como os operadores usam recursos legítimos, a caça deve privilegiar sequências de eventos e não apenas indicadores estáticos. Um encadeamento típico combina vishing relatado ou suspeito, login SSO incomum, mudança em MFA, regra de e-mail para suprimir alerta, enumeração de diretório, acesso a arquivos de alto valor e exfiltração. Cada evento isolado pode parecer administrativo; a correlação temporal revela a intrusão. Equipes de SOC e DFIR devem manter consultas que cruzem logs do IdP, auditoria de e-mail, auditoria de SaaS, DLP, CASB e EDR para verificar se houve execução local auxiliar ou se a operação permaneceu dentro das plataformas SaaS.
- Registro ou remoção de dispositivo MFA seguido de login SSO a partir de localização, ASN ou proxy residencial incomum
- Criação de regra de caixa de entrada que exclui ou move notificações de segurança, autenticação, MFA ou dispositivo
- Acesso rápido a múltiplos repositórios SaaS após autenticação inicial, especialmente em Google Workspace, SharePoint, HubSpot ou Salesforce
- Consultas a diretórios internos antes de tentativas de acesso ou engenharia social contra contas privilegiadas
- Downloads, exportações ou compartilhamentos externos incompatíveis com o perfil do usuário e próximos a alterações de identidade
A resposta deve tratar o incidente como comprometimento de identidade e SaaS, não apenas como phishing de senha. A primeira ação é revogar sessões ativas do usuário afetado, redefinir credenciais, remover dispositivos MFA não reconhecidos e revisar todos os métodos de autenticação cadastrados. Em paralelo, é necessário inspecionar regras de caixa de entrada e restaurar notificações suprimidas. Se houver evidência de acesso a aplicações SaaS, a equipe deve preservar logs de auditoria, identificar arquivos e relatórios acessados, verificar exportações e mapear compartilhamentos externos criados durante a janela de atividade.
A mitigação preventiva exige endurecimento do IdP e dos controles de SaaS. Registro de novos dispositivos MFA deve exigir verificação adicional, aprovação administrativa ou política baseada em risco. A organização deve restringir métodos MFA suscetíveis a engenharia social quando houver alternativas resistentes a phishing, como chaves de segurança compatíveis com FIDO2 ou autenticação vinculada ao dispositivo. Políticas de acesso condicional precisam considerar dispositivo gerenciado, localização esperada, risco de sessão, sensibilidade da aplicação e comportamento histórico do usuário. Para contas privilegiadas, o acesso a SaaS crítico deve ser limitado por privilégio mínimo e revisado continuamente.
Treinamento operacional também precisa mudar: usuários devem ter um canal oficial para validar chamadas de suporte antes de seguir instruções de login, troca de MFA ou acesso a páginas enviadas durante a ligação. No SOC, alertas devem ser construídos para sequências de identidade e SaaS, pois a intrusão pode não gerar malware, hash, beacon clássico ou exploração de CVE. A validação final deve confirmar que não restaram sessões persistentes, regras maliciosas, dispositivos desconhecidos, permissões excessivas, compartilhamentos externos ou dados exportados sem autorização.
- Revogar sessões SSO, redefinir credenciais e remover dispositivos MFA não reconhecidos em contas suspeitas
- Auditar regras de caixa de entrada criadas ou alteradas após logins anômalos e remover regras que ocultem alertas de segurança
- Habilitar MFA resistente a phishing para contas privilegiadas e aplicações SaaS críticas
- Correlacionar logs de IdP, e-mail, CASB, DLP e auditoria de SaaS para reconstruir o fluxo de acesso e exfiltração
- Revisar exportações, downloads em massa, compartilhamentos externos e acessos a relatórios sensíveis durante a janela do incidente
0 Comentários