Intruder Quietly Harvests Global Salesforce and ServiceNow Records Without Exploiting a Single Vulnerability

A quietly persistent intruder has spent more than a year pulling data from Salesforce and ServiceNow portals worldwide — without exploiting a vulnerability, stealing credentials, or bypassing authentication. Instead, the attacker relied entirely on what organizations had already made accessible to the public through their built‑in guest user accounts.

The City-Forum Campaign

Researchers at Reco have been tracking the activity, which they call City‑Forum, after a long‑abandoned domain now pointing to a rented server in Germany. From that single IP address, the operator accessed customer portals belonging to telecom providers, banks, financial‑services firms, enterprise software vendors, and public‑sector organizations. Passive DNS shows the infrastructure has been stable since at least March 2025.

No Exploit, No Credentials — Just Misconfigured Guest Access

What makes the campaign notable is what did not happen. No software was exploited. No authentication was bypassed. The attacker simply visited public Salesforce Experience Cloud and ServiceNow portals as an anonymous guest user and repeatedly requested their contents. The portals responded with whatever they had been configured to expose.

Both platforms assign every public portal a built‑in guest user — a real account with a profile, permissions, and access rules. It cannot be deleted. It is the identity used whenever an unauthenticated visitor loads a support site or knowledge base. “The core issue is that ‘what is public’ and ‘what should be public’ are two different things,” said Nitay Bachrach, Security Researcher at Reco.

Custom Toolkit Targets Overlooked Surfaces

While attackers have abused over‑permissioned Salesforce guest users before, this operator built custom tooling. Most traffic targeted Salesforce’s older Aura framework, a long‑documented weak point. One portal logged more than 560,000 events from the intruder’s IP, almost all Aura enumeration.

The rest of the toolkit is what stands out. Reco observed probes against Salesforce’s newer LWR/GraphQL data layer — an offensive blind spot ignored by existing tools — and heavy use of a ServiceNow search endpoint so undocumented that the vendor publishes no reference for it. The endpoint is public by design, and its responses depend entirely on how each knowledge base is configured.

Attribution Remains Unclear

Reco will not attribute the campaign, noting similarities to ShinyHunters’ Experience Cloud activity but cautioning that tooling changes frequently. One soft signal stands out: the operator has used the same IP address for at least seventeen months, with no rotation.

Logs Reveal Attempts — Not What Was Taken

Organizations reviewing logs will find limited clarity. ServiceNow records that a search occurred and how large the response was, but not the search terms. Salesforce logs show which actions were attempted — Aura calls, GraphQL sweeps, self‑registration probes — but not which records or fields were returned.

“It is not possible to determine what was leaked based on the audit logs,” Bachrach said. “An organization would need to simulate the requests internally and analyze the responses.”

The Root Cause Across Both Platforms

The most common misconfiguration Reco observed was simple: guest or anonymous users had been granted excessive read permissions. On Salesforce, guest sharing rules are the highest‑impact fix. On ServiceNow, knowledge bases often allowed “Any User” to read content without restriction.

How Organizations Should Investigate

Salesforce:
– Review Event Monitoring for AuraRequest and Sites entries with USER_TYPE = Guest
– Look for high volumes of getItems, getConfigData, GraphQL version sweeps, and self‑registration probes

ServiceNow:
– Review sys