Salesforce and ServiceNow Portals: City-Forum Guest Data Harvesting Campaign

A single threat actor has spent well over a year systematically pulling data out of Salesforce Experience Cloud sites and ServiceNow Service Portals belonging to organizations worldwide, using a custom-built Go toolset and nothing more exotic than the anonymous guest access both platforms ship by default. SaaS security firm Reco, which disclosed the research this week, named the operation "City-Forum" after a domain tied to the attacker's infrastructure. Every observed request traces to one IP address, 158.220.87.79, a Contabo VPS in Germany, carrying the default Go-http-client/1.1 user agent. The associated domain city-forum.com has resolved to that server since at least March 2025. Reco says the campaign is still running and the volume is climbing. There is no CVE, no vendor patch, and no exploited vulnerability.

What Happened

Reco's researchers traced a long-running data theft campaign to a single server that has been probing and harvesting from both Salesforce and ServiceNow tenants across multiple sectors: telecommunications carriers, banks and financial services firms, enterprise software vendors, security and data-privacy companies, and public-sector portals. Reco has not named victims.

On the timeline, accounts differ slightly in framing rather than substance. BleepingComputer, The Register and Dark Reading all anchor the campaign to "at least March 2025," when the city-forum.com domain began resolving to the attacker's server, and describe the activity as running for more than a year. The Register notes explicitly that the actual start date of the campaign is unclear and that the domain resolution is the earliest hard marker. A write-up from Duggan (OTHER tier) puts the figure at seventeen months, which is consistent with counting from March 2025 to disclosure, but that specific number is that outlet's arithmetic rather than a Reco finding.

On scale, The Register reports that the busiest single Salesforce target logged more than 560,000 events. That figure appears in only one outlet and should be treated as a data point from Reco's telemetry on one victim, not a campaign-wide total.

There is one source that reads against the grain. The OffSeq threat radar entry, an automated aggregator, rates the item "medium" severity and states there is "no indication of active exploitation in the wild." That conclusion is an artifact of CVE-centric automated triage: it is looking for a vulnerability identifier and finding none. Every human-reported source, and Reco itself, describes confirmed, ongoing, in-the-wild data theft. Weight the researcher findings and the security press over the aggregator here.

What Was Taken

This is where defenders should be careful about what is actually established. None of the available sources publish record counts, data categories, or a victim list. Reco has not named affected organizations and has not quantified stolen records.

What is confirmed is the shape of the exposure. The attacker retrieved whatever data each organization had made readable to its unauthenticated guest user through overly permissive sharing rules, object permissions, or portal configuration. In practice, on Salesforce Experience Cloud and ServiceNow Service Portals, that class of accidental exposure typically covers Case and Contact records, knowledge base articles, account details, and support ticket contents. The affected sectors reported by Reco, telecoms, banking, enterprise software, security vendors, and government portals, indicate the exposed data is customer and constituent records rather than internal infrastructure.

Reco's own scoping note matters: "So far, we have only seen guest user activities, never an authenticated user, but we cannot rule it out." Treat unauthenticated harvesting as confirmed and authenticated access as unproven but not excluded.

Why It Matters

The central point, made most sharply by the Duggan analysis and echoed in the technical detail across BleepingComputer, Dark Reading and The Register, is that nothing was exploited. Salesforce and ServiceNow both behaved exactly as designed. Every affected organization was running correctly patched software with no known vulnerability. The vulnerability scanner reports clean, patch compliance sits at 100 percent, KEV remediation is current, and a stranger reads your customer data anyway.

That has three practical consequences. First, no CVE means no advisory-driven trigger for your remediation process: this exposure will never appear in a feed you already subscribe to. Second, the detection signal is not malware or exploitation but anomalous read volume from an unauthenticated identity, which most SaaS monitoring does not baseline. Third, the entry point cannot be removed. As Reco puts it, you cannot delete guest users, and requiring login does not remove them. The profile, its permissions, its sharing rules, and any code running in its context all still exist. If the guest can read a record, so can anyone on the internet.

The persistence is the other alarm. One unrotated IP address, one default user agent, one hosting provider, and no operational security to speak of, sustained across more than a year against enterprise and government targets. This actor did not evade detection. Nobody was looking.

The Attack Technique

Reco characterizes the tooling as custom and multi-platform, not off-the-shelf. "One Go binary hit Salesforce over both Aura and LWR and hit ServiceNow, from the same box," the researchers wrote, contrasting this with commodity tools like AuraInspector.

Three technical elements stand out across the reporting:

Salesforce LWR via the UI API. On newer Lightning Web Runtime sites, the actor interacts directly with the runtime's underlying data-access layer through the UI API's GraphQL surface. SecurityWeek and NCIJ describe this as the first observed in-the-wild exploitation of Salesforce's UI-API guest surface. The Register and Dark Reading add that Reco found no public research documenting the technique and no publicly available tooling implementing it.

Aura enumeration, integrated. Legacy Aura sites are also targeted, necessarily so, since Aura deployments still outnumber LWR. The distinguishing feature is that Aura and LWR attacks are unified in one toolset rather than run as separate campaigns.

An obscure ServiceNow endpoint. The same binary hammers a native ServiceNow Service Portal search endpoint that, per Reco, has almost no online documentation and no well-known open source tooling.

The toolset also probes whether Salesforce sites permit self-registration, which would offer a path from anonymous guest access to an authenticated external account with visibility into considerably more data. Reco reported seeing these checks against most of the Salesforce targets it examined.

On attribution, accounts differ and no one has named the actor. CSO Online frames the campaign as resembling ShinyHunters operations and raises the possibility that the group has found a new target. SecurityWeek and NCIJ draw the comparison in order to distinguish the two: ShinyHunters' Salesforce Aura campaign, disclosed in March 2026, hit Aura only, showed no known ServiceNow targeting, and used a modified AuraInspector. The Register and Dark Reading simply call this a mystery or unknown actor. The honest read is that the tradecraft overlaps at a high level and diverges at every technical detail that matters. Nitay Bachrach, senior security researcher at Reco, put it this way: "The threat actor created their own toolset, based on research and techniques which are not well documented online. They studied the services to map different common data leak vectors. This is an advanced actor."

What Organizations Should Do

1. Block and hunt the known IOCs immediately. Search Salesforce Event Monitoring and ServiceNow transaction logs for 158.220.87.79, for the Go-http-client/1.1 user agent, and for the domain city-forum.com. Reco reports these appearing together across nearly all observed attacks. Search backwards to March 2025, not just the last 90 days, and note that a retention window shorter than that will not answer the question.

2. Audit every guest user profile in every Experience Cloud site and Service Portal. Enumerate object permissions, field-level security, sharing rules, and any Apex or server-side code executing in guest context. The controlling question is not "is this site public" but "what can the guest user read." Assume any org unit that stood up a portal did so without a security review.

3. Turn off self-registration unless it is a deliberate business requirement. The toolset actively checks for it. Where self-registration must stay on, verify that the resulting authenticated external profile is scoped tighter than you assume, and that approval or email verification gates it.

4. Do not rely on requiring login. Enabling authentication on a portal does not decommission the guest user or revoke its sharing rules. Explicitly strip the guest profile's record access rather than assuming a login wall covers it.

5. Baseline and alert on unauthenticated read volume. The detection signal here is a guest identity pulling records at a rate no human visitor produces. The Register's report of one Salesforce target logging over 560,000 events illustrates how visible this is when someone is actually watching. Alert on guest-context record retrieval rate and on GraphQL or UI API traffic from non-browser user agents.

6. Add SaaS exposure review to your vulnerability management cycle as a standing item. This campaign generates no CVE, no vendor advisory, and no scanner finding. If guest-access configuration review is not a recurring calendar item with a named owner, it will not happen.

Given the campaign is ongoing and the actor is still operating from unchanged infrastructure, organizations running public Salesforce or ServiceNow portals should treat this as active hunting work this week, not a backlog item.

Sources: "City-Forum" data-theft attacks target Salesforce, ServiceNow portals | Stealthy 'City-Forum' Attacks Target Salesforce and ... | Salesforce, ServiceNow data targeted in 'City-Forum' attacks | Mystery attacker spent a year raiding Salesforce and ServiceNow por... | Long-running Data Theft Campaign Targets Salesforce, ... | Stealthy ‘City-Forum’ Attacks Target Salesforce and ServiceNow With... | "City-Forum" data-theft attacks target Salesforce, ServiceNow porta... | Somebody Read Salesforce and ServiceNow Portals Worldwide for 17 Mo...