# The Patient Scraper: One Server Has Been Draining Salesforce and ServiceNow for Fifteen Months
The attacker didn't bother rotating their infrastructure. Same IP. Same user agent. Same Contabo VPS in Germany. For over a year, a single compiled tool running on 158.220.87.79 has been methodically pulling records out of Salesforce Experience Cloud and ServiceNow customer portals across telecoms, banks, enterprise software vendors, and public sector organizations — and nobody flagged it until Reco published their analysis this week.
That operational detail is either stunning confidence or stunning carelessness. Probably both.
## Fifteen Months, One Server
Passive DNS ties the domain "City Forum" — the name Reco gave the campaign — to that IP as far back as March 2025. The server hasn't moved. Every request carries the same fingerprint: Go's default net/http user agent, Go-http-client/1.x, which means whoever wrote this didn't bother spoofing a browser string. It's a compiled binary, purpose-built, and they either didn't care about being fingerprinted or figured nobody was watching closely enough to notice.
That assumption has largely held. One target accumulated over 560,000 events originating from the same IP before anyone pulled together the pattern. That's not a smash-and-grab. That's a long-running harvest operation, and the infrastructure is reportedly still active with volume climbing.
## Two Platforms, One Problem
What makes City Forum notable beyond its longevity is the breadth. Most known abusers of Salesforce guest access — including campaigns attributed to ShinyHunters — stick to Salesforce's Aura framework, blasting high-volume requests to enumerate objects and walk through records. The older framework is well-documented, the scanning behavior is understood, and defenders who've been paying attention have hunting queries for it.
This actor does that too. But then it goes further in two directions that haven't been publicly documented.
On Salesforce, the tool also targets Lightning Web Runtime sites through the UI-API — a data layer built for the platform's newer architecture. According to Reco, there are no public write-ups on this surface and no known scanning tools that target it. The tool walks API versions v56.0 through v66.0 sequentially, probing each endpoint systematically. That's not opportunistic scanning. That's someone who mapped the attack surface deliberately.
On ServiceNow, the same infrastructure hammers POST /api/now/sp/search — a native Service Portal search endpoint that carries almost no public documentation. The attacker found a way to enumerate what Service Portal exposes to unauthenticated users, and apparently found enough of value to keep hitting it for months.
The common thread across both platforms isn't a zero-day. It's the same boring misconfiguration dressed up in two different enterprise SaaS flavors.
## The Guest User You Cannot Delete
Both Salesforce Experience Cloud and ServiceNow maintain a persistent guest identity. Every unauthenticated visitor to a portal executes as this guest user. You cannot remove it — only restrict it.
That design decision is reasonable in isolation. The problem is that organizations routinely stand up customer-facing portals, self-service sites, and partner hubs with guest profiles that carry far more access than the public-facing use case actually requires. A guest user that can read an Account object, a case record, or a knowledge base article might not display that data to a logged-out browser visitor — but if you ask the API directly, you'll get it. The portal UI enforces login. The underlying API endpoints often don't.
City Forum doesn't exploit a vulnerability. It reads what the guest profile is allowed to read, at scale, faster than any human, with no authentication required. Both platforms are working exactly as designed. The attack surface is the configuration debt that accumulated while organizations shipped portals without locking down the identity that underpins them.
## What Defenders Can Actually Do
Reco published concrete detection steps for both platforms, and they're worth operationalizing now rather than waiting for this to land in an incident debrief.
On Salesforce, pull Event Monitoring or Shield logs for AuraRequest and Sites events. Filter on the Go-http-client user agent, flag the known IP (158.220.87.79), and watch for request paths containing /webruntime/api/services/data — that's the LWR UI-API surface. Self-registration spikes at /SiteRegister and /CommunitiesSelfReg are also a tell. On the remediation side: audit guest sharing rules, strip object and field-level access from the guest profile to the minimum required, disable self-registration where it isn't needed, and turn off the Experience Builder setting that lets guest users reach public APIs.
On ServiceNow, filter syslog_transaction by the same IP and by URLs starting with /api/now/sp/search. Rows created by the guest user with unusual output length are the clearest signal. Remediation means auditing which search sources are exposed to your public portal and tightening the Knowledge Base read criteria that govern anonymous search results.
Neither fix requires renegotiating a vendor contract or waiting for a patch. Both require someone to actually sit down with the guest profile settings and make deliberate choices — which is exactly the work that didn't happen when these portals were first deployed.
---
## HackWire Analysis
City Forum exposes something the enterprise security industry would rather not talk about directly: SaaS portal misconfiguration has become its own attack category, and the detection and response muscle for it is years behind where it needs to be.
The ShinyHunters Salesforce incidents drew coverage because the name was recognizable and the data was splashy. City Forum hasn't made the same headlines yet — no named victims, no data dump posted — but it's arguably more methodical and more dangerous precisely because it's operating quietly across multiple industries on infrastructure that hasn't changed in fifteen months.
The LWR UI-API angle deserves particular attention. When an attacker is mapping and systematically scanning a Salesforce API surface that has *no public documentation and no known tooling*, it suggests either proprietary research or access to information that isn't public. That's not a script kiddie running a known scanner. That's someone who invested time understanding the platform's internals. The fact that they're also running ServiceNow enumeration from the same infrastructure suggests this is a professional operation with a specific goal — building comprehensive data sets about enterprise customers, probably for sale.
The industries targeted make the likely end-use obvious. Telecom customers, financial services clients, enterprise software users. That's either credential harvesting for follow-on attacks or data brokering. Either way, the organizations whose portals were scraped likely don't know it happened.
For defenders, the immediate priority is the guest profile audit. Not next quarter. This week. If you run a Salesforce Experience Cloud site or a ServiceNow Service Portal, run Reco's detection queries against your logs today and find out whether that IP has ever touched you. The answer might be uncomfortable.
— HackWire Editorial
---
## Related Coverage