Atores de ameaça fazem varredura em massa de Salesforce Experience Cloud com AuraInspector modificado

Campanha explora configurações permissivas de usuários convidados em sites públicos do Experience Cloud para consultar objetos do CRM e coletar dados que podem alimentar vishing e abuso de identidade.

Componente	Sites públicos do Salesforce Experience Cloud, perfil de usuário convidado e objetos CRM expostos por configurações excessivamente permissivas.
Vetor	Varredura em massa de instâncias públicas usando uma versão modificada do AuraInspector, com sondagem do endpoint /s/sfsites/aura e tentativa de extração quando permissões de convidado permitem consulta indevida.
Impacto	Consulta direta a objetos do Salesforce CRM sem autenticação quando o ambiente usa perfil de convidado e não segue as recomendações de configuração; dados como nomes e telefones podem apoiar engenharia social e vishing.
Prioridade	Revisar imediatamente permissões de usuários convidados no Experience Cloud, definir acesso externo padrão como privado, bloquear APIs públicas para convidados e monitorar consultas incomuns.
Atribuição	A atividade foi vinculada a um grupo conhecido não nomeado pela Salesforce; há possibilidade de relação com ShinyHunters, também chamado UNC6240, mas essa atribuição não foi confirmada nominalmente no alerta da empresa.
Técnicas associadas	Vishing estratégico, phishing adversary-in-the-middle, registro fraudulento de novo fator de MFA, uso de SaaS legítimo para movimentação e exportação de dados.

Resumo técnico

A atividade observada contra Salesforce Experience Cloud envolve varredura em massa de sites públicos em busca de configurações fracas no perfil de usuário convidado. O ponto central não é uma vulnerabilidade intrínseca da plataforma Salesforce, mas a combinação de páginas acessíveis publicamente, objetos de CRM com permissões excessivas e uso de interfaces expostas pelo framework Aura. Quando essas condições coexistem, um usuário não autenticado pode consultar dados além do necessário para páginas públicas como portais, bases de conhecimento, FAQs e áreas de autoatendimento.

O operador usa uma versão personalizada do AuraInspector, ferramenta aberta criada para apoiar auditorias defensivas de controle de acesso no Salesforce Aura. A versão original identifica objetos vulneráveis por meio de sondagens em endpoints expostos, especialmente /s/sfsites/aura. A modificação atribuída aos atores amplia esse comportamento: em vez de apenas identificar exposição, ela tenta extrair dados quando a configuração do perfil convidado permite acesso indevido. Isso transforma uma checagem de postura em uma cadeia de coleta automatizada contra múltiplas instâncias públicas.

A campanha se encaixa em uma tendência de abuso baseado em identidade. Dados colhidos em consultas contra CRM, como nomes e números de telefone, não precisam representar comprometimento completo do ambiente para gerar risco operacional. Eles podem servir como matéria-prima para ataques posteriores de engenharia social, sobretudo vishing, nos quais operadores se passam por equipes internas de TI, conduzem vítimas a domínios de phishing visualmente semelhantes e tentam capturar credenciais e códigos de autenticação em tempo real. A defesa deve tratar a exposição de dados de contato e organização como evento de segurança, não apenas como erro de privacidade isolado.

Fluxo técnico

O fluxo começa com enumeração de sites públicos do Salesforce Experience Cloud. Esses sites podem operar com um perfil dedicado de usuário convidado para permitir navegação sem login. Esse modelo é legítimo quando limitado a conteúdo público, mas se torna perigoso quando permissões de objeto, configurações de visibilidade ou acesso por API permitem que o convidado consulte registros internos. A condição necessária para exploração é dupla: o cliente precisa usar perfil de convidado e deixar de aplicar a orientação recomendada de configuração segura para o Experience Cloud.

A versão modificada do AuraInspector sonda interfaces Aura expostas publicamente e avalia se objetos acessíveis por API podem ser consultados a partir do contexto de convidado. Quando a instância permite a operação, o ator passa da descoberta para a coleta. O impacto confirmado fica restrito ao que a configuração permite acessar: objetos e campos do CRM disponíveis para o perfil público. O contexto não sustenta tratar a atividade como falha de execução remota, zero-day ou comprometimento automático de conta; a exposição depende de permissões configuradas pelo cliente.

Em paralelo, incidentes de vishing associados a atividades contra ambientes SaaS mostram como dados coletados podem ser operacionalizados. Operadores obtêm detalhes de funcionários em redes profissionais, fazem contato se passando por equipe interna de TI e pressionam a vítima a configurar uma suposta passkey de SSO dentro de um prazo obrigatório. A vítima é conduzida por celular a um domínio de phishing visualmente semelhante, o que pode reduzir a efetividade de inspeção corporativa de URL e controles aplicados no navegador gerenciado. A página usa estrutura adversary-in-the-middle para retransmitir a autenticação ao portal legítimo enquanto captura credenciais e códigos.

Após acesso bem-sucedido, os operadores registram um novo fator de MFA, incluindo instância em emulador Android, com nome apresentado como "Passkey" para reforçar a narrativa usada na chamada. Em alguns casos, a primeira ação após o login é apagar alertas de novo dispositivo ou novo login da caixa de entrada da vítima para atrasar descoberta. Quando recursos internos são necessários, credenciais comprometidas podem ser usadas em clientes VPN corporativos. Dentro de SaaS, a técnica descrita como living-off-the-SaaS prioriza funcionalidades nativas de exportação, como relatórios amplos de contatos e contas em CRMs, além de arquivos marcados como confidenciais ou sensíveis em outras plataformas.

Superfície afetada

A superfície primária é composta por instâncias Salesforce Experience Cloud publicamente acessíveis que mantêm usuário convidado ativo e permitem permissões além do necessário. Ambientes com páginas públicas, portais de atendimento, bases de conhecimento e recursos de autoatendimento precisam ser revisados porque o mecanismo de acesso anônimo é esperado nessas implementações. O risco aparece quando a fronteira entre conteúdo público e objetos internos do CRM não está rigidamente definida.

Também entram na superfície de risco os controles de identidade e SaaS conectados à organização. O material coletado em CRM pode apoiar vishing contra funcionários, enquanto credenciais capturadas em fluxo AitM podem abrir sessões em SSO, registrar novo MFA e permitir movimentação entre aplicações em dashboards SaaS. Setores citados em incidentes relacionados incluem serviços financeiros, manufatura, serviços profissionais e jurídicos, além de varejo, mas a condição técnica não é setorial: qualquer organização com CRM exposto, identidade federada e permissões SaaS amplas pode ter impacto relevante.

• Sites Experience Cloud acessíveis pela internet com perfil de usuário convidado habilitado.
• Objetos Salesforce CRM cujo acesso externo padrão não esteja configurado como privado.
• APIs públicas disponíveis para usuários convidados em portais e páginas Aura.
• Configurações que permitam enumeração de membros internos da organização por usuários não autenticados.
• Fluxos de SSO e MFA vulneráveis a engenharia social por telefone e phishing AitM.

Hunting e telemetria

A investigação deve começar pela telemetria do Experience Cloud e do Salesforce CRM. O objetivo é identificar consultas anômalas originadas de contexto convidado, especialmente padrões repetitivos de enumeração contra objetos, campos e endpoints Aura. Como a atividade descrita faz varredura em massa, defensores devem correlacionar volume, diversidade de objetos consultados, sequência de requisições e origem de tráfego. A ausência de login não reduz a gravidade: eventos associados ao usuário convidado podem indicar tentativa de extração por configuração permissiva.

Em identidade, a busca deve cobrir eventos de SSO, registro de MFA, uso de novos dispositivos e alterações suspeitas logo após contato telefônico relatado por usuários. O nome de dispositivo "Passkey" em um novo fator não prova comprometimento isoladamente, mas ganha relevância quando aparece após acesso incomum, troca de localização, uso de emulador ou exclusão de mensagens de alerta. Em SaaS, a telemetria deve destacar exportações amplas, relatórios sem filtros, aumento súbito de campos exportados e downloads de arquivos com rótulos ou nomes associados a conteúdo confidencial.

Na rede e no endpoint, o foco defensivo deve ficar em acessos a domínios de phishing defangados ou desconhecidos a partir de dispositivos móveis, lacunas de inspeção quando a vítima sai do navegador corporativo e autenticações que terminam rapidamente em ações de administração de MFA. Para evitar publicação de indicadores ativos, qualquer domínio suspeito deve ser tratado internamente como hxxp://dominio[.]suspeito ou mantido apenas em ferramentas de detecção. A caça deve priorizar padrões comportamentais, pois a infraestrutura de phishing pode mudar mais rápido que os controles baseados em lista.

• Requisições incomuns ao endpoint /s/sfsites/aura com enumeração repetitiva de objetos.
• Consultas a objetos CRM executadas por contexto de usuário convidado em sites públicos.
• Picos de exportação em relatórios de Contacts & Accounts ou relatórios equivalentes com muitos campos.
• Registro recente de novo fator MFA, especialmente dispositivo nomeado como "Passkey" após chamada suspeita.
• Exclusão de alertas de novo login ou novo dispositivo na caixa de entrada da vítima.
• Autenticação em VPN corporativa logo após evento suspeito de SSO ou MFA.
• Downloads de arquivos com rótulos como confidencial ou sensível em plataformas SaaS.

Mitigação

A resposta deve priorizar a configuração do Experience Cloud antes de ações genéricas de bloqueio. O primeiro passo é revisar todos os sites públicos, perfis de usuário convidado e permissões de objeto associadas. O acesso externo padrão de todos os objetos deve ser definido como privado, e permissões explícitas para convidados precisam ser removidas quando não forem estritamente necessárias para a função pública do portal. Acesso de convidados a APIs públicas deve ser desabilitado, e configurações de visibilidade devem impedir enumeração de membros internos da organização.

A organização também deve desabilitar auto-registro quando ele não for necessário e revisar trilhas de auditoria para consultas incomuns. Quando houver suspeita de coleta, a investigação precisa mapear quais objetos e campos foram acessados pelo perfil convidado, quais registros podem ter sido expostos e se os dados coletados seriam úteis para engenharia social. Esse escopo é essencial para orientar notificação interna, reforço de controles de identidade e monitoramento de vishing direcionado contra funcionários.

Para reduzir o risco de sequência pós-coleta, equipes de identidade devem endurecer fluxos de MFA e passkeys contra registro fraudulento. Mudanças de fator, inclusão de novos dispositivos e autenticações de alto risco devem exigir validação fora do canal iniciado pelo atacante. Usuários devem ter um caminho claro para reportar ligações de suposto suporte interno, mas a mitigação técnica precisa incluir detecção de AitM, bloqueio de domínios recém-criados, inspeção consistente em dispositivos móveis gerenciados e alertas para exportações massivas em SaaS. A contenção de contas suspeitas deve incluir revogação de sessões, remoção de fatores MFA não reconhecidos, rotação de credenciais e revisão de acessos VPN e SaaS no período da atividade.

• Inventariar todos os sites Salesforce Experience Cloud públicos e seus perfis de convidado.
• Definir Default External Access como privado para objetos e revisar exceções uma a uma.
• Desabilitar acesso de usuários convidados a APIs públicas quando não houver necessidade comprovada.
• Impedir que usuários convidados enumerem membros internos ou metadados sensíveis da organização.
• Desativar auto-registro em portais onde a funcionalidade não seja requerida.
• Monitorar e investigar consultas incomuns, exportações amplas e acesso anônimo a objetos CRM.
• Rever eventos de SSO, MFA, VPN e SaaS após qualquer suspeita de vishing ou phishing AitM.