What’s going on (short version)

If you run a Salesforce Experience Cloud site or a ServiceNow customer portal, some sneaky actor has been poking around and quietly scooping up stuff that was accidentally left open to the internet. The campaign—tracked back to a single server and cheekily nicknamed “City-Forum”—looks for data that any unauthenticated visitor can reach and downloads it with automated requests.

Researchers tied most of the traffic to the IP address 158.220.87.79 and a domain called city-forum.com. The requests often use the default Go-http-client/1.1 user agent, which is a dead giveaway that this is automated scraping rather than a helpful human browsing your portal.

How they work and what they hit

The attacker doesn’t exploit a zero-day. Instead, they take advantage of anything your configuration accidentally left public. In plain terms: if your portal lets a guest see records, the attacker will happily enumerate and pull them.

  • On older Salesforce sites built with Aura, the bot probes endpoints like /aura or /s/sfsites/aura to list which objects (Accounts, Contacts, Cases, etc.) are visible to a guest. It calls HostConfigController.getConfigData to find objects and SelectableListDataProviderController.getItems to harvest records.
  • On newer Lightning Web Runtime (LWR) sites, the actor uses Salesforce’s UI API through the webruntime API endpoint and fires off GraphQL-style queries to extract data exposed to guest visitors.
  • For Experience Cloud portals the bot also checks self-registration endpoints to see whether anonymous users can sign themselves up—because if they can, it might get even more access.
  • ServiceNow Service Portals are targeted via the portal search endpoint (POST /api/now/sp/search?sysparm_cancelable=true). If a search source is configured to allow guest access, those anonymous search requests can return sensitive information. ServiceNow logs show that searches happened and how much data was returned, but not the exact search terms, which makes forensics awkward.

Some victims saw staggering volumes: one environment recorded over 560,000 events tied to the attacker’s IP, mostly from Aura enumeration. The campaign has been active and increasing, and the actor generally uses only unauthenticated guest access—at least as far as observers can tell.

Quick, what should admins do?

No, you don’t need to panic, but you should absolutely yank any accidental public access off the table. Here’s a practical checklist to harden portals fast:

  • Review guest-user sharing rules and permissions. If the guest account can read or list objects it shouldn’t, lock it down.
  • Audit object and field-level permissions—especially for Accounts, Contacts, Cases and files.
  • Check file access and member visibility settings; remove public file links and limit visibility where possible.
  • Disable or tighten self-registration unless you absolutely need it; if you must allow it, require verification and strict role assignment.
  • For LWR sites, consider disabling the Experience Builder option that lets guest users access public APIs unless it’s required—this will block the webruntime API paths attackers use.
  • On ServiceNow, review which search sources are exposed to portals and lock sensitive sources behind authentication.
  • Monitor logs for repeated anonymous requests from the same IPs and user agents like Go-http-client/1.1 and block or rate-limit suspicious traffic.

If you’ve already been hit, treat the guest account as the likely vector: search for exported records, rotate any affected credentials, and inform impacted teams so they can handle any privacy or compliance fallout.

Short takeaway: this isn’t rocket science—just a reminder that the internet will cheerfully grab whatever you accidentally leave unlocked. Tighten guest access and stop leaving the keys under the doormat.