City-Forum: o ataque silencioso que explora acesso de convidados no Salesforce e ServiceNow

Por pelo menos 17 meses, um ator de ameaça desconhecido vem extraindo registros de sites Salesforce Experience Cloud e ServiceNow Service Portals ao redor do mundo — sem explorar nenhuma vulnerabilidade de software, roubar credenciais ou burlar autenticação. O invasor simplesmente usou o que as organizações já haviam tornado acessível ao público por meio do acesso convidado (anônimo) integrado das plataformas.

A empresa de segurança Reco batizou essa campanha contínua de City-Forum, em referência ao domínio city-forum.com registrado na infraestrutura do invasor. Desde pelo menos março de 2025, um único servidor alugado na Alemanha coleta sistematicamente dados de operadoras de telecomunicações, bancos, instituições financeiras, empresas de software empresarial e portais do setor público.

Como a Exploração Funciona: Nenhuma Vulnerabilidade é Necessária

Tanto o Salesforce quanto o ServiceNow possuem contas de usuário convidado permanentes para visitantes não autenticados. Esses usuários convidados não podem ser excluídos. As permissões deles — quais registros e objetos podem ler — são configuradas por cada organização. Se o perfil de convidado tiver acesso de leitura a um registro, qualquer pessoa na internet pode recuperá-lo por meio de endpoints de API totalmente legítimos.

No Salesforce (framework Aura):

• A ferramenta envia requisições POST para o endpoint /aura ou /s/sfsites/aura.
• Primeiro, chama HostConfigController.getConfigData para enumerar quais objetos (Account, Contact, Case, Lead, User, ContentDocument, etc.) estão acessíveis ao convidado.
• Em seguida, usa SelectableListDataProviderController.getItems para percorrer todas as páginas de registros em cada objeto acessível.
• O alvo individual mais movimentado registrou mais de 560.000 eventos do IP do invasor, quase todos de enumeração Aura de convidados.

No Salesforce (framework LWR — Lightning Web Runtime):

• Esta é a primeira exploração observada em ambiente real da superfície de convidados da UI-API do Salesforce em sites LWR.
• A ferramenta tem como alvo um endpoint GraphQL em

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  , primeiro enumerando o esquema via EntityDefinition e depois lendo registros com paginação baseada em cursor.
• Ela varre as versões de API v56.0 a v66.0 em sequência contra cada site LWR descoberto.

No ServiceNow:

• A ferramenta tem como alvo o endpoint /api/now/sp/search — uma API de busca nativa do Service Portal que é amplamente não documentada e tem quase nenhuma documentação online ou ferramentas de código aberto que a referenciem.
• Este endpoint é público por design. Quais dados ele retorna depende inteiramente de quais fontes de busca estão associadas a um portal voltado para convidados e se essas fontes impõem controles de acesso.

Sondagem de auto-registro (Salesforce):

• A ferramenta anexa /SiteRegister e /CommunitiesSelfReg a cada caminho de site de experiência descoberto para testar se o auto-registro está habilitado. Se estiver, um convidado pode se promover a um usuário externo autenticado, ganhando acesso a muito mais dados.

O Conjunto de Ferramentas Personalizado e a Infraestrutura

• IP de origem: 158.220.87.79, hospedado em um VPS da Contabo (provedor de hospedagem alemão), resolvendo para o domínio city-forum.com (um domínio registrado em 2002, abandonado e depois reaproveitado).
• O mesmo IP carrega o mesmo domínio desde março de 2025 sem rotação — pelo menos 17 meses em um único endereço.
• Binário Go personalizado: Uma única ferramenta compilada em Go que ataca o Salesforce tanto pelos frameworks Aura quanto LWR e também ataca o ServiceNow — tudo a partir do mesmo servidor. Este é um conjunto de ferramentas multiplataforma personalizado, não uma ferramenta pronta como AuraInspector.
• A ferramenta usa a string User-Agent padrão Go-http-client, facilitando a identificação em logs.

Organizações Visadas

A Reco relata que os principais alvos incluem:

• Operadoras de telecomunicações
• Bancos e instituições financeiras
• Fornecedores de software empresarial (incluindo empresas de segurança e privacidade de dados)
• Portais do setor público

Por que os Logs de Auditoria Padrão Não Revelam Quais Dados Foram Levados

Para o ServiceNow: Os logs de transação da plataforma (syslog_transaction) não gravam o corpo da requisição POST de chamadas para /api/now/sp/search. Os defensores podem ver que buscas automatizadas ocorreram e quantos dados foram retornados (através da coluna de tamanho de saída), mas não conseguem determinar os termos de busca exatos ou quais registros específicos foram recuperados.

Para o Salesforce: O tráfego de enumeração de convidados consiste em chamadas de API legítimas e compatíveis com o protocolo que se parecem com tráfego normal do site. Embora o Event Monitoring possa mostrar o volume de eventos AuraRequest e Sites de usuários convidados, os logs mostram que os dados foram solicitados, mas não o conteúdo específico do que foi retornado nas respostas GraphQL ou Aura.

Em outras palavras, você pode ver que o invasor esteve lá e quanto puxou, mas não consegue reconstruir exatamente quais registros ou campos foram extraídos.

Passos de Remediação Recomendados

Para Salesforce (recomendações da Reco):

1. Aperte as regras de compartilhamento de convidados — o controle de maior impacto. Remova qualquer regra de compartilhamento que compartilhe registros com o Usuário Convidado além do que o site realmente precisa para servir publicamente.
2. Remova permissões de objetos e campos do perfil de convidado. Remova o acesso de leitura em objetos que o site não precisa para visitantes anônimos.
3. Remova a permissão "Access Activities" do perfil de convidado (expõe Tasks e Events).
4. Desabilite "API Enabled" no usuário convidado.
5. Desabilite o auto-registro a menos que o site realmente exija.
6. Desabilite o acesso a arquivos e a visibilidade de membros por convidados para que convidados não possam recuperar arquivos ContentDocument ou enumerar outros membros do site.
7. Para sites LWR apenas: Em Experience Builder → Workspaces → Administration → Preferences, desmarque "Allow guest users to access public APIs." Isso fecha os endpoints GraphQL e UI-API REST em um só movimento.

Para ServiceNow (recomendações da Reco):

1. Mapeie os portais voltados para convidados para suas fontes de busca. Verifique as tabelas sp_portal, m2m_sp_portal_search_source e sp_search_source. Desassocie qualquer fonte de busca que um portal público não precise.
2. Revise a lógica de cada fonte de busca — especialmente is_scripted_source, data_fetch_script e se ela usa GlideRecordSecure (que impõe ACLs) vs. GlideRecord simples (que não impõe).
3. Revise os critérios de usuário "Can Read" da base de conhecimento — procure por acesso irrestrito "Any User" que exponha KBs sensíveis através da busca de convidados.
4. Desassocie links kb_uc_can_read_mtom incorretos em vez de editar regras de compartilhamento às cegas.

Orientação de Detecção:

• Salesforce Event Monitoring: Procure por altos volumes de getItems e getConfigData de

  USER_TYPE = 'Guest'

  , varreduras de versão /webruntime/.../vNN.0/graphql e acessos a /SiteRegister e /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Procure por requisições /api/now/sp/search feitas como convidado. Ordene por tamanho de saída — linhas retornando significativamente mais do que a pequena linha de base de resultado vazio indicam buscas que retornaram conteúdo.