One VPS, Two SaaS Platforms: A Portal Scraper That Has Not Moved Since March 2025

One server has been pulling records out of public-facing Salesforce and ServiceNow portals across multiple industries for more than a year, according to research published this week by the agent security firm Reco ^[1][19]. That reframes an exposure many teams closed out as a one-off Salesforce incident: what Reco describes is a persistent, cross-SaaS misconfiguration problem with an indicator defenders can search for today ^[18][11].

Reco calls the activity the City Forum campaign, after a domain tied to the attacker's IP ^[1]. The infrastructure is unglamorous: a single commodity VPS at 158.220.87.79, rented from the German provider Contabo ^[2]. Passive DNS puts the same domain on that address as far back as March 2025, and the server has not moved since ^[4]. Every request carries the default user agent of Go's net/http library, which tells Reco the client is a compiled, purpose-built program rather than anything driven from a browser ^[3]. Reco says targets so far include telecoms, banks and other financial services firms, enterprise software vendors including security and data privacy companies, and public sector portals, though it has not named individual organizations ^[5].

The volumes are not subtle. Most known abuse in this space leans on Salesforce's older Aura framework, sending high volumes of guest requests to enumerate objects and page through records ^[6]. This actor does that too, and Aura accounts for the bulk of the traffic Reco observed, with one target logging more than 560,000 events from that single IP ^[7]. What is new is the reach. The same tool queries Salesforce's newer Lightning Web Runtime sites through the UI-API, a data layer Reco says has no public write-ups or known scanning tools attached to it, stepping through API versions v56.0 to v66.0 in sequence ^[8] - eleven versions walked one after another ^[17]. It also hits a native ServiceNow Service Portal search endpoint, POST /api/now/sp/search, which similarly carries almost no public documentation ^[9].

The underlying fault is the same in both products. Salesforce Experience Cloud sites and ServiceNow portals both keep a persistent guest user that unauthenticated visitors execute as, and that identity cannot be deleted, only restricted ^[10]. If the guest profile can read a record, the record is public in practice, whether or not the browser experience asks for a login ^[20]. Reco's position is that the endpoints are working as designed, so remediation belongs at the profile, not the URL ^[13].

The checkable part is worth acting on before the attribution question resolves. On Salesforce, teams with Event Monitoring or Shield can pull AuraRequest and Sites log events and look for the Go-http-client user agent, the IP itself, and request paths containing /webruntime/api/services/data, alongside spikes in self-registration at /SiteRegister and /CommunitiesSelfReg ^[11]. On ServiceNow, the syslog_transaction table can be filtered by source IP and by URLs starting with /api/now/sp/search, with guest-created rows and unusual output length as the clearest sign of a live sweep ^[12]. Fixes follow: review guest sharing rules, strip unneeded object and field access from the guest profile, disable self-registration where it is not required, and turn off the Experience Builder setting that lets guests reach public APIs ^[14]. On ServiceNow, map which search sources are exposed to public portals and audit the Knowledge Base read criteria that decide what an anonymous query returns ^[15].