City-Forum: How a Single Server Stole Data from Salesforce and ServiceNow for 17 Months Without a Vulnerability

How the Exploitation Works: No Vulnerability Required

Both Salesforce and ServiceNow ship with permanent guest user accounts for unauthenticated visitors. These guest users cannot be deleted. Their permissions — what records and objects they can read — are configured by each organization. If the guest profile has read access to a record, anyone on the internet can retrieve it through entirely legitimate API endpoints.

On Salesforce (Aura framework):

• The tool sends POST requests to the /aura or /s/sfsites/aura endpoint.
• It first calls HostConfigController.getConfigData to enumerate which objects (Account, Contact, Case, Lead, User, ContentDocument, etc.) are accessible to the guest.
• It then uses SelectableListDataProviderController.getItems to page through all records on each accessible object.
• The busiest single target logged over 560,000 events from the attacker's IP, nearly all guest Aura enumeration.

On Salesforce (LWR framework — Lightning Web Runtime):

• This is the first observed in-the-wild exploitation of Salesforce's UI-API guest surface on LWR sites.
• The tool targets a GraphQL endpoint at

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

  , first enumerating the schema via EntityDefinition, then reading records with cursor-based pagination.
• It sweeps API versions v56.0 through v66.0 in sequence against each discovered LWR site.

On ServiceNow:

• The tool targets the /api/now/sp/search endpoint — a native Service Portal search API that is largely undocumented and has almost no online documentation or open-source tools referencing it.
• This endpoint is public by design. What data it returns depends entirely on which search sources are attached to a guest-facing portal and whether those sources enforce access controls.

Self-registration probing (Salesforce):

• The tool appends /SiteRegister and /CommunitiesSelfReg to every discovered experience site path to test whether self-registration is enabled. If it is, a guest can promote itself to an authenticated external user, gaining access to far more data.

The Custom Toolset and Infrastructure

• Source IP: 158.220.87.79, hosted on a Contabo VPS (German hosting provider), resolving to the domain city-forum.com (a domain registered in 2002, abandoned, then re-purposed).
• The same IP has carried the same domain since March 2025 with no rotation — at least 17 months on one address.
• Custom Go binary: A single Go-compiled tool that hits Salesforce over both Aura and LWR frameworks and also hits ServiceNow — all from the same server. This is a custom multi-platform toolset, not an off-the-shelf tool like AuraInspector.
• The tool uses Go's default Go-http-client User-Agent string, making it easy to identify in logs.

Organizations Targeted

Reco reports that the primary targets include:

• Telecom operators
• Banks and financial-services firms
• Enterprise software vendors (including security and data-privacy companies)
• Public-sector portals

Why Standard Audit Logs Cannot Reveal What Data Was Taken

For ServiceNow: The platform's transaction logs (syslog_transaction) do not record the POST body of /api/now/sp/search requests. Defenders can see that automated searches occurred and how much data was returned (via the output length column), but cannot determine the exact search terms or which specific records were retrieved.

For Salesforce: The guest enumeration traffic consists of legitimate, protocol-compliant API calls that look like normal site traffic. While Event Monitoring can show the volume of AuraRequest and Sites events from guest users, the logs show that data was requested but not the specific content of what was returned in the GraphQL or Aura responses.

In other words, you can see the attacker was there and how much they pulled, but you cannot reconstruct exactly which records or fields they extracted.

Recommended Remediation Steps

For Salesforce (Reco recommendations):

1. Tighten guest sharing rules — the single highest-impact control. Remove any sharing rule that shares records with the Guest User beyond what the site genuinely needs to serve publicly.
2. Strip object- and field-level permissions from the guest profile. Remove read access on objects the site doesn't need for anonymous visitors.
3. Remove the "Access Activities" permission from the guest profile (exposes Tasks and Events).
4. Disable "API Enabled" on the guest user.
5. Disable self-registration unless the site truly requires it.
6. Disable guest file access and member visibility so guests cannot retrieve ContentDocument files or enumerate other site members.
7. For LWR sites only: In Experience Builder → Workspaces → Administration → Preferences, uncheck "Allow guest users to access public APIs." This closes GraphQL and the UI-API REST endpoints in one move.

For ServiceNow (Reco recommendations):

1. Map guest-facing portals to their search sources. Check the sp_portal, m2m_sp_portal_search_source, and sp_search_source tables. Detach any search source a public portal doesn't need.
2. Review each search source's logic — especially is_scripted_source, data_fetch_script, and whether it uses GlideRecordSecure (ACL-enforcing) vs. plain GlideRecord (which is not).
3. Review knowledge base "Can Read" user criteria — look for unconstrained "Any User" access that exposes sensitive KBs through guest search.
4. Detach bad kb_uc_can_read_mtom links rather than editing sharing rules blindly.

Detection Guidance:

• Salesforce Event Monitoring: Look for high volumes of getItems and getConfigData from

  USER_TYPE = 'Guest'

  , /webruntime/.../vNN.0/graphql version sweeps, and hits on /SiteRegister and /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Look for /api/now/sp/search requests made as guest. Sort by output length — rows returning significantly more than the small empty-result baseline indicate searches that returned content.