Reco Links Salesforce and ServiceNow Scraping to One Server

Security platform Reco has linked record-scraping activity against Salesforce and ServiceNow customer portals to a single server, 158.220.87.79. The firm calls the operation the City Forum campaign, after a domain associated with the attacker’s IP address, and says the infrastructure has been active since at least March 2025.

The server is hosted through German VPS provider Contabo and sends requests with the default user agent of Go’s net/http library. Reco says that consistent fingerprint indicates a compiled, purpose-built tool rather than browser-based activity. The company has not attributed the campaign to a named group.

One infrastructure set, several public portal surfaces

Targets identified by Reco include telecommunications companies, banks and other financial-services firms, enterprise software vendors, security and data-privacy companies, and public-sector portals. Reco did not identify the affected organizations by name.

Salesforce Aura requests made up most of the observed traffic. At one target, Reco recorded more than 560,000 events from the same IP address. Aura has featured in earlier abuse of Salesforce guest access, but Reco found that this actor also queried newer Salesforce Lightning Web Runtime sites through the UI-API.

The tool moved sequentially through UI-API versions v56.0 to v66.0. Reco said it was not aware of public write-ups or scanning tools associated with this data layer. The same server also sent requests to the native ServiceNow Service Portal endpoint POST /api/now/sp/search, which has little public documentation.

Guest privileges determine the exposure

The techniques rely on a shared condition: a guest identity has permission to access records beyond what a public site needs to serve anonymous visitors. Salesforce Experience Cloud sites and ServiceNow portals retain guest users through which unauthenticated visitors operate. These identities cannot be deleted, but their access can be restricted.

If a guest profile can read a record, that record is effectively public even when the browser interface appears to require a login. This distinction is important for organisations reviewing wider SaaS and DNS exposure after Chrome fixes and SonicWall SaaS attacks reported Chrome fixes and attacks affecting SonicWall: public-facing application permissions can create a separate path to sensitive data.

Detection and remediation steps

For Salesforce, Reco recommends using Event Monitoring or Shield to examine AuraRequest and Sites logs for the Go-http-client user agent, the IP address 158.220.87.79 and paths containing /webruntime/api/services/data. Teams should also investigate spikes in self-registration requests to /SiteRegister and /CommunitiesSelfReg.

For ServiceNow, defenders can filter the syslog_transaction table by source IP and URLs beginning with /api/now/sp/search. Guest-created rows and unusual output length are the clearest indicators of an active sweep, Reco said.

Remediation focuses on permissions rather than blocking endpoints that are functioning as designed. Salesforce administrators should review guest sharing rules, remove unnecessary object- and field-level access, disable self-registration where it is not needed, and disable the Experience Builder option that exposes public APIs to guests. ServiceNow teams should map public portal search sources and audit Knowledge Base read criteria. For businesses, the practical priority is to treat anonymous portal access as a data-access control review, not merely a web-interface setting.