SLH recruta mulheres para campanhas de vishing contra help desks de TI

O grupo oferece pagamentos por chamada e scripts prontos para ampliar fraudes de suporte, resets de identidade e acesso inicial a ambientes corporativos e SaaS.

Componente	Fluxos de atendimento de help desk, redefinição de senha, MFA, SSO corporativo, contas privilegiadas, ambientes SaaS, Microsoft Azure e infraestrutura de suporte remoto.
Vetor	Vishing com personas de suporte ou funcionário, scripts pré-escritos, chamadas guiadas, resets de senha e MFA, possível uso de domínios de impersonação em subdomínios no padrão *.sso-verify[.]com e iscas móveis.
Impacto	Acesso inicial por identidade válida, criação de usuário ou máquina virtual, enumeração de Active Directory, tentativa de coleta de arquivos de caixa postal do Outlook, acesso a dados em Snowflake e possível progressão para extorsão ou ransomware quando a intrusão avança.
Prioridade	Endurecer verificação de identidade no help desk, revisar resets após chamadas, auditar criação de usuários e elevação administrativa, reduzir dependência de SMS para MFA e correlacionar eventos de suporte com autenticação, SaaS e cloud.
Artefatos	Uso observado de serviços legítimos e infraestrutura comum, incluindo redes de proxy residencial, túneis como Ngrok, Teleport e Pinggy, ferramentas de enumeração como ADRecon e serviços de compartilhamento de arquivos como file[.]io, gofile[.]io, mega.nz e transfer.sh.
Atribuição	A atividade envolve sobreposição entre SLH, Scattered Spider, LAPSUS$, ShinyHunters e operações descritas como Muddled Libra; a atribuição do uso de subdomínios foi associada com alta confiança a ShinyHunters dentro da visibilidade relatada.

Resumo técnico

O coletivo Scattered LAPSUS$ Hunters, tratado como SLH, foi observado ampliando sua operação de engenharia social com recrutamento pago de mulheres para chamadas de vishing contra help desks de TI. A proposta operacional descrita envolve pagamentos entre US$ 500 e US$ 1.000 por chamada, além do fornecimento de scripts previamente preparados para conduzir a conversa. O objetivo técnico não é explorar diretamente uma vulnerabilidade de software, mas manipular processos humanos de suporte para obter redefinição de senha, alteração de MFA, instalação de ferramenta de monitoramento e gerenciamento remoto ou outro caminho que entregue acesso com identidade legítima.

A escolha de vozes femininas aparece como adaptação de persona para reduzir suspeitas em equipes treinadas para perfis tradicionais de fraude. Esse detalhe muda a defesa porque desloca o controle de segurança do reconhecimento subjetivo do interlocutor para validações formais e rastreáveis. Em um fluxo de help desk vulnerável, uma chamada bem conduzida pode acionar reset de conta, troca de dispositivo MFA ou liberação de acesso sem que malware, exploit público ou infraestrutura incomum apareçam nos primeiros minutos da intrusão.

A campanha também se conecta a padrões já associados a Scattered Spider, ShinyHunters e ao agrupamento SLH: abuso de MFA por fadiga de prompts, SIM swapping, uso de serviços legítimos, proxies residenciais e ferramentas de tunelamento. Em casos avançados, após a obtenção de credenciais privilegiadas, operadores criaram máquina virtual, executaram reconhecimento de Active Directory e tentaram coletar arquivos de caixa postal do Outlook e dados baixados de Snowflake. O impacto, portanto, deve ser analisado como comprometimento de identidade e operação de acesso, não apenas como chamada fraudulenta isolada.

Fluxo técnico

O fluxo começa com seleção de alvo e preparação de pretexto. A operação usa scripts para padronizar a interação com o help desk ou com o usuário final, reduzindo improvisação do operador e aumentando consistência entre chamadas. A pessoa recrutada atua como voz da persona, enquanto o roteiro conduz o atendimento para ações de alto risco: validar identidade com informações parciais, pedir redefinição de senha, pressionar por reset de MFA, orientar aprovação de login ou persuadir a instalação de ferramenta RMM. O uso de pagamentos por chamada indica uma tentativa de escalar volume sem depender apenas de operadores centrais do grupo.

Em intrusões atribuídas ao ecossistema Scattered Spider, a fase pós-acesso tende a privilegiar recursos já presentes no ambiente. Em vez de depender de malware customizado desde o início, os operadores usam credenciais válidas, APIs, console cloud, ferramentas administrativas e serviços amplamente permitidos. Isso dificulta detecção baseada apenas em binários desconhecidos. A atividade descrita inclui uso de redes de proxy residencial, serviços legítimos e túneis como Ngrok, Teleport e Pinggy para reduzir contraste no tráfego. Serviços de compartilhamento de arquivos como file[.]io, gofile[.]io, mega.nz e transfer.sh também aparecem como canais auxiliares para movimentação ou staging de dados.

Uma extensão da atividade envolve ShinyHunters usando subdomínios com aparência de marca, phishing adversary-in-the-middle guiado por telefone e iscas desenhadas para usuários móveis. O padrão de domínio citado usa subdomínios no formato *.sso-verify[.]com, com o domínio defangado para evitar link ativo. A lógica é reduzir a eficácia de controles focados apenas em domínios recém-registrados ou lookalikes simples, enquanto o telefonema orienta a vítima em tempo real. Se o usuário entrega uma sessão SSO válida ou se o help desk realiza um reset, o operador pode acessar aplicações SaaS sensíveis sem implantar código malicioso personalizado.

Há limites importantes de atribuição. As táticas lembram Scattered Spider, mas a atividade de impersonação por subdomínio foi associada a ShinyHunters com base em vitimologia, uso prático dos subdomínios durante vishing contra organizações e sequências de intrusão consistentes. Também há indicação de colaboração parcial entre grupos em operações específicas de engenharia social, sem evidência pública suficiente para tratar todo o conjunto como uma estrutura única e estável. Para defesa, a distinção importa menos que o padrão operacional: chamadas, pressão sobre suporte, abuso de identidade, sessão SSO e acesso rápido a SaaS.

Superfície afetada

A superfície principal está nos processos de identidade operados por pessoas: help desks, call centers, fluxos de recuperação de conta, redefinição de MFA, validação por telefone e exceções emergenciais para usuários. Ambientes que aceitam SMS como fator forte, permitem alteração de MFA sem verificação fora de banda robusta ou autorizam instalação de RMM por solicitação verbal ficam mais expostos. O risco aumenta quando atendentes conseguem criar usuários, alterar grupos, redefinir fatores ou liberar acesso remoto sem validação independente e registro de caso suficientemente detalhado.

A superfície técnica posterior inclui Microsoft Azure, recursos acessíveis via Graph API, Active Directory, ambientes virtualizados, caixas de correio Outlook, bases Snowflake e demais aplicações SaaS conectadas ao SSO corporativo. Em pelo menos um caso investigado, após credenciais privilegiadas obtidas por chamada ao help desk, houve criação e uso de máquina virtual para reconhecimento e tentativa de coleta de dados. Esse caminho mostra que a fronteira crítica não está apenas no endpoint da vítima, mas no encadeamento entre suporte, identidade, cloud, virtualização e dados corporativos.

• Help desks com autorização para reset de senha, troca de MFA, criação de usuário ou alteração de privilégio com base em validação telefônica.
• Usuários com acesso a SaaS sensível, SSO corporativo, Outlook, Snowflake, Azure ou grupos administrativos de Active Directory.
• Ambientes que permitem ferramentas RMM, túneis ou serviços de compartilhamento de arquivos sem justificativa operacional registrada.
• Dispositivos móveis onde o usuário tem menor visibilidade de URL, certificado, contexto de rede e alertas de segurança corporativa.

Hunting e telemetria

A caça deve correlacionar eventos humanos e técnicos. Uma chamada ao help desk seguida por reset de senha, alteração de MFA, criação de conta, login de origem incomum ou acesso a SaaS de alto valor deve gerar investigação, mesmo que cada evento isolado pareça legítimo. A telemetria mais útil envolve tickets de suporte, gravações ou metadados de chamada quando disponíveis, logs de identidade, alterações em métodos MFA, criação de sessões SSO, consentimentos de aplicação, uso de Graph API, eventos de Azure e consultas de enumeração em Active Directory.

No endpoint e na rede, a defesa deve procurar sinais compatíveis com abuso de ferramentas legítimas. Isso inclui execução ou instalação de RMM não aprovado, túneis para serviços conhecidos, conexões via proxies residenciais, tráfego para serviços de compartilhamento incomuns e transferência de arquivos após atividade de suporte. Em cloud e SaaS, indicadores relevantes incluem download incomum de caixas postais, exportação ou consulta anômala em Snowflake, enumeração de diretórios, criação de máquina virtual fora do padrão do usuário e elevação administrativa logo depois de uma interação com suporte.

Para phishing guiado por telefone e AiTM, logs de proxy e identidade podem mostrar sessões com características móveis, autenticação recente seguida por uso de token em outro contexto, domínios de verificação de SSO defangados semelhantes a sso-verify[.]com e alterações rápidas em dispositivos confiáveis. Como a operação busca usar infraestrutura aceitável, a detecção deve valorizar sequência, proximidade temporal e divergência comportamental, não apenas reputação de domínio ou assinatura de arquivo.

• Ticket de help desk seguido por reset de senha, troca de MFA, criação de usuário, nova sessão SSO ou privilégio administrativo.
• Login bem-sucedido após chamada com origem, dispositivo, ASN, proxy residencial ou geografia incompatíveis com o histórico do usuário.
• Uso de Graph API, enumeração de Azure ou Active Directory e execução de ferramenta como ADRecon após obtenção de credenciais.
• Criação de máquina virtual, acesso a Outlook, consultas ou exportações de Snowflake e tráfego para serviços de compartilhamento de arquivos em janela curta.
• Instalação de RMM, uso de túneis como Ngrok, Teleport ou Pinggy e conexões externas sem mudança aprovada.

Mitigação

A resposta deve começar pelo processo de identidade. Help desks precisam de verificação resistente a engenharia social para qualquer reset de senha, alteração de MFA, mudança de dispositivo, criação de conta ou instalação remota. Isso inclui validação fora do canal da chamada, aprovação por fluxo interno, registro detalhado do motivo e bloqueio de exceções baseadas apenas em urgência. Treinamento ajuda, mas não substitui controles: a campanha explora confiança, pressão e persona, portanto o atendente não deve carregar sozinho a decisão de segurança.

A configuração de MFA também deve ser revista. SMS deve ser tratado como fator fraco para contas críticas, e resets precisam invalidar sessões antigas, exigir reautenticação forte e gerar alerta para o time de segurança. Contas privilegiadas devem ter políticas separadas, sem recuperação simplificada por telefone. Em Azure e SaaS, revisar permissões de Graph API, consentimentos de aplicativos, grupos administrativos e logs de auditoria é essencial quando uma interação suspeita de help desk antecede qualquer mudança de identidade.

Para contenção, a organização deve congelar alterações recentes na conta afetada, revogar sessões, remover métodos MFA adicionados, revisar dispositivos confiáveis, verificar uso de RMM e investigar acessos a Outlook, Snowflake, diretórios e ambientes virtualizados. A resposta não deve se limitar ao usuário que atendeu a chamada: o operador pode ter usado a primeira conta para localizar o próximo alvo, criar VM, enumerar diretório ou preparar extorsão. A validação final precisa confirmar ausência de novas contas, privilégios, túneis, chaves de acesso e exportações de dados.

• Exigir validação fora de banda e aprovação rastreável para reset de senha, troca de MFA, criação de usuário e concessão de privilégio.
• Migrar contas sensíveis para MFA resistente a phishing e reduzir dependência de SMS, especialmente em administradores e usuários com acesso a SaaS crítico.
• Correlacionar tickets de suporte com logs de identidade, Azure, Graph API, Active Directory, Outlook, Snowflake e virtualização.
• Bloquear ou restringir RMM não aprovado, túneis e serviços de compartilhamento de arquivos que não tenham justificativa operacional.
• Revogar sessões, remover métodos MFA não reconhecidos, auditar grupos administrativos e revisar contas criadas após chamadas suspeitas.