One Server Has Spent Over a Year Scraping Data from Salesforce and ServiceNow Portals

Analysts at the Reco platform have published a report on a campaign they named City Forum — after a domain tied to the attacker's IP address. Behind all the activity stands a single server: 158.220.87.79, hosted on a cheap VPS with the German provider Contabo. According to passive DNS, that same domain pointed to this address as far back as March 2025, and the infrastructure hasn't changed since.

The server's telltale marker is the default user agent of Go's net/http library. This indicates that the requests aren't coming from a browser but from a compiled program written for a specific purpose. Among the targets are telecom operators, banks and other financial companies, enterprise software developers (including firms in the security and data-privacy space), and public-sector portals. Reco does not name the specific organizations.

What Sets This Campaign Apart

Earlier cases of guest-access abuse in Salesforce — including the widely covered activity of ShinyHunters — typically relied on the legacy Aura framework: mass guest requests, enumerating objects, and reading records page by page. Here Aura is used too, and it accounts for the bulk of the traffic — with one victim more than 560,000 events were logged from this IP. But the same tool also reaches new sites built on Lightning Web Runtime through the UI API, working sequentially through API versions from v56.0 to v66.0 — a mechanism for which there are neither public write-ups nor known scanners. On top of that, the server hammers ServiceNow Service Portal's native search endpoint POST /api/now/sp/search, which has almost no public documentation.

The Root of the Problem Is the Guest

In Reco's view, all of these techniques share a single cause: a guest account granted more privileges than a public site requires. Both Salesforce Experience Cloud and ServiceNow portals have a permanent guest user under whose identity unauthenticated visitors operate; it can't be deleted, only restricted. If the guest profile can read a record, that record is effectively public — regardless of whether the browser interface asks for a login.

The report offers concrete steps for detection. In Salesforce (given Event Monitoring or Shield), it advises searching the AuraRequest and Sites logs for the aforementioned Go-http-client user agent, that same IP, and paths containing /webruntime/api/services/data, as well as spikes in self-registration attempts. In ServiceNow — filtering the syslog_transaction table by source IP and by URLs beginning with /api/now/sp/search.

The fix, it suggests, lies not at the endpoint level (both the UI API and ServiceNow search work as designed) but in hardening the guest profile: reviewing access rules, stripping excessive object and field permissions, disabling self-registration, and barring guests from public APIs. In ServiceNow — auditing which search sources and knowledge-base articles are available to an anonymous request.

Reco stresses that the campaign's infrastructure is still active and that the request volume is growing. The researchers do not attribute it to any specific group.

Source: The Hacker News