Vendor Access · SaaS Security

One Attacker Has Been Scraping Salesforce and ServiceNow Portals Since Early 2025

August 19, 2026 · 5 min read

A single, unattributed threat actor has been quietly scraping sensitive data from Salesforce Experience Cloud sites and ServiceNow Service Portals since at least March 2025, running a purpose-built automated tool against guest-user interfaces that were never meant to be a front door. The campaign, which researchers at Reco named City-Forum after infrastructure the attacker left sitting on the same IP address for over 17 months, targets telecoms, banks, enterprise software vendors, security firms, and public-sector portals. Every request in this campaign originates from one server, carries one Go user agent, and has never required a password.

What actually happened

Reco's research team identified and tracked the campaign, attributing all activity to a single server at IP address 158.220.87.79, hosted by German VPS provider Contabo (ASN 51167). The domain city-forum.com, registered in 2002 and long abandoned, resolves to that server and has done so continuously since at least March 2025, with no infrastructure rotation at any point through the publication of the research in August 2026. Every HTTP request in the campaign carries the default Go net/http user agent string, Go-http-client/1.1, indicating a compiled, purpose-built tool rather than a browser or an off-the-shelf scanner.

The campaign covers two distinct platforms with platform-specific techniques for each. Against Salesforce Experience Cloud, the tool targets both the older Aura framework and the newer Lightning Web Runtime (LWR) framework. On Aura sites, the attacker posts to /aura and /s/sfsites/aura endpoints, calling HostConfigController.getConfigData to map available objects and SelectableListDataProviderController.getItems to pull record sets. Against LWR sites, the attacker uses Salesforce's UI API through GraphQL requests to /webruntime/api/services/data/{version}/graphql, sweeping API versions v56.0 through v66.0. Reco says that LWR GraphQL technique has not appeared in any public attack tool or prior write-up, including tools associated with the ShinyHunters group. The attacker also appended /SiteRegister and /CommunitiesSelfReg paths to nearly every discovered Experience site to probe whether self-registration is enabled. A site with self-registration open would allow the tool to promote itself from a guest into an authenticated external user with broader data access.

Against ServiceNow Service Portals, the attacker targets a native POST endpoint at /api/now/sp/search?sysparm_cancelable=true. Reco says this endpoint had almost no online documentation and had not previously been seen abused in public attack tooling. As with the Salesforce techniques, the attacker relies entirely on misconfigured access controls, with no software vulnerability in ServiceNow itself involved.

The root cause across both platforms is the same: guest-user sharing rules and configurations that permit unauthenticated access to data objects that should require authentication. No CVE identifiers are associated with this campaign. The busiest targeted organization logged over 560,000 events across the campaign window, essentially all of it guest Aura enumeration. As of publication, the campaign is ongoing and activity volume is increasing.

Reco notes similarity to the ShinyHunters Salesforce Aura campaign disclosed in March 2026, which involved data theft from around 100 high-profile companies and nearly 400 websites, but explicitly states there is no evidence tying City-Forum to that group. The infrastructure is generic hosting absent from public threat-intelligence feeds, and the actor remains unattributed.

Why this should matter to you even if you don’t run Salesforce or ServiceNow

If your organization runs Salesforce Experience Cloud or ServiceNow with any public-facing portal, this campaign is directly relevant to you, regardless of whether you operate in the sectors Reco identified. The attack surface here is the guest-user configuration, and that configuration is almost never something a security team audits with the same frequency as firewall rules or endpoint controls. It tends to get set once during implementation and then drift as features get added, portals get extended, and the people who understood the original intent move on.

The broader pattern matters more than the specific campaign. The ShinyHunters Aura campaign from March 2026 and the City-Forum campaign from at least March 2025 target the same misconfiguration class. Two separate actors, running separate infrastructure, have independently built tooling to sweep Salesforce and ServiceNow guest interfaces at scale. That convergence tells you the opportunity is well understood in the attacker community, and the defender community has been slower to respond.

There is also an insurance implication worth flagging. Cyber insurers are increasingly asking about SaaS configuration controls during underwriting and renewals, particularly around guest and external user access. A data exfiltration event driven by a misconfigured guest-user sharing rule is unlikely to be treated the same way as an unavoidable zero-day by a claims team reviewing whether reasonable controls were in place. The absence of a vulnerability here cuts both ways: it confirms that no patch will fix this, and it also confirms that the exposure was within your control to address.

The control that would have blunted it

The primary control here is least-privilege guest-user configuration, enforced and audited on a defined schedule. Reco's specific advice for Salesforce is to work the guest user down to the minimum permissions required for the portal's stated purpose, and then review that baseline whenever new objects or features are added. For ServiceNow, the guidance is to remove search sources that do not need public exposure and enforce appropriate authentication for each remaining search source, including custom scripted sources. Neither of those actions is technically complex, but both require someone to own the task on a recurring basis, which is where most organizations fall short.

On the detection side, Salesforce customers with Event Monitoring or Shield enabled should build alerts on the Go-http-client/1.1 user agent string, requests from 158.220.87.79, and request paths containing /webruntime/api/services/data in AuraRequest and Sites log events. That covers the current campaign's known fingerprint. The harder problem is that a more careful attacker would rotate user agents and IP addresses, so the durable detection posture has to include anomaly-based alerting on guest-user request volume and data access patterns, not just IOC matching.

From an insurance standpoint, guest-user access configuration falls squarely within the vendor access controls that underwriters are looking for evidence of. The specific controls they tend to want to see are periodic access reviews, documented permission baselines for external and unauthenticated users, and alerting on anomalous unauthenticated activity. A vendor risk program that includes SaaS configuration review, with documented review cycles, is the most straightforward way to demonstrate that posture. The operational cost of maintaining this is real: it requires someone with both Salesforce or ServiceNow admin knowledge and an understanding of what data is sensitive enough to warrant restriction. That person is often the same person responsible for platform administration, and the security review gets deprioritized. Building it into a formal review cadence, with a checklist and an owner, is the only way to make it stick.

Strondex's Vendor Risk product includes SaaS configuration review workflows and access control auditing to help teams maintain documented permission baselines for platforms like Salesforce and ServiceNow.