For over seventeen months, a single server has been quietly pulling sensitive records from Salesforce Experience Cloud sites and ServiceNow Service Portals across the globe. The attacker didn’t breach firewalls, exploit zero-day vulnerabilities, or crack complex passwords. They simply logged in as a guest.
Cybersecurity firm Reco has uncovered an ongoing campaign they’ve dubbed “City-Forum,” named after a domain tied to the threat actor’s infrastructure. What makes this campaign particularly alarming isn’t just its duration it’s the sophistication of the techniques employed. The attacker has developed custom tooling to exploit guest access points that many security teams don’t even know exist.
“The fix hasn’t changed at all,” Reco’s researchers note in their analysis. “In every case here – Aura, LWR, and the ServiceNow portal alike – the exposure is a guest identity that was granted more than it needed.”
Anatomy of a Multi-Platform Attack
The Infrastructure
The campaign traces back to a single indicator: IP address 158.220.87.79, hosted on a Contabo VPS in Germany (ASN 51167). Passive DNS records show the domain city-forum.com resolving to this IP since March 2025, meaning the infrastructure has been standing for well over a year unusually static for sophisticated threat actors.
The attacker’s toolset is equally distinctive. Every request carries the default Go HTTP client user agent (Go-http-client/1.1) a clear signature of a compiled, purpose-built scanning tool rather than a browser-based attack. This single binary has been systematically probing both Salesforce and ServiceNow instances across multiple organizations worldwide.
The Targets
The victim list reads like a who’s who of critical infrastructure:
- Telecommunications providers
- Banks and financial services firms
- Enterprise software vendors
- Security and data privacy companies
- Public sector portals
The attacker has focused exclusively on guest user activities – never authenticated users – making detection particularly challenging for security teams.
Behind the Techniques: Three Attack Vectors
1. Salesforce Aura Framework Enumeration
Aura, Salesforce’s older Experience Cloud framework, has been the primary target. The attacker sends high-volume getItems and getConfigData requests through the /aura endpoint, essentially asking Salesforce: “What data can I see as a guest?”
The answer, all too often, is “everything.” Misconfigured guest sharing rules have exposed Accounts, Contacts, Cases, and other sensitive objects to anonymous reading.
2. Salesforce LWR (Lightning Web Runtime) Exploitation
This is where the campaign breaks new ground. LWR is Salesforce’s newer framework, where the /aura endpoint is disabled. Many security teams incorrectly assume this means guest access is controlled.
The attacker discovered otherwise, leveraging LWR’s UI-API a data layer that has no public documentation and no known open-source tools. Through endpoints like /webruntime/api/services/data/{version}/graphql, the attacker systematically swept through API versions v56.0 through v66.0, querying the GraphQL schema and extracting record data.
“The /webruntime/ pattern is the piece nobody looks for today,” Reco’s researchers explain, “and it’s what makes LWR activity visible at all.”
3. ServiceNow Service Portal Search Abuse
ServiceNow instances face a similar threat. The attacker targets /api/now/sp/search, a native endpoint that lacks published API documentation. This endpoint processes search queries from Service Portals, including those accessible to anonymous users.
The critical issue: the endpoint does not gate on authentication at the transport layer. Both authenticated and anonymous POST requests return HTTP 201. What differs is the response body and that’s determined entirely by the search sources (Knowledge Base, Catalog, etc.) configured for each portal.
When configured with Knowledge Base sources that lack proper access controls, guest users can search and retrieve sensitive articles. The attacker sends escalating volumes of search queries to map what information is accessible anonymously.
The Self-Registration Threat
Beyond data enumeration, the attacker consistently probes for self-registration vulnerabilities. By appending /SiteRegister and /CommunitiesSelfReg to discovered experience site paths, they test whether anonymous visitors can create accounts.
If self-registration is enabled, an attacker can promote themselves from guest to authenticated external user typically gaining access to significantly more data than the guest profile alone.
Why This Matters Now
For Security Teams
This campaign represents a shift in offensive strategy. The attacker:
- Developed custom tooling rather than using existing frameworks like AuraInspector
- Researched undocumented APIs in both Salesforce and ServiceNow
- Maintained persistent infrastructure for over 17 months without rotating IPs
- Targeted multiple platforms from a single point of control
“The operator’s tool walked v56.0 through v66.0 against the GraphQL endpoint in sequence,” Reco’s analysis reveals. “It leaves an unmistakable burst. Proportionally, the LWR traffic was light next to the Aura flood. The operator isn’t leaning on LWR as its primary technique… it’s to be expected Aura sites are still more common.”
This suggests the attacker is methodically mapping the attack surface rather than simply maximizing data extraction speed.
The Attribution Question
Reco declined to attribute the campaign to any known group, noting that confident attribution can lead to dangerous assumptions.
“None of that means it isn’t ShinyHunters, and none of it means it’s anyone else,” the researchers caution. “A campaign that doesn’t match a group’s last known fingerprint tells you nothing on its own actors rewrite tooling, rent new boxes, and add techniques constantly.”
One operational pattern stands out: the single IP address with no rotation since March 2025. This differs from typical campaigns, which often rotate through multiple machines and IP ranges. Whether this indicates a smaller operation, a deliberate stealth strategy, or simply a different threat actor remains unclear.
10 Recommended Actions for Security Teams
For Salesforce Experience Cloud
- Audit guest sharing rules immediately. Review every sharing rule that grants access to the Guest User profile. Remove any rule that shares records beyond what the site genuinely needs to serve publicly.
- Strip object- and field-level permissions from the guest profile. For every object the site doesn’t need to render for anonymous visitors, remove read access. Hide sensitive fields with field-level security.
- Disable “Access Activities” permission on the guest profile. This exposes Tasks and Events that guests almost never need.
- Turn off guest file access and member visibility. Prevent guests from retrieving ContentDocument files or enumerating other site members.
- For LWR sites, disable guest access to UI-API. In Experience Builder, go to Workspaces → Administration → Preferences and uncheck “Allow guest users to access public APIs.” This closes GraphQL and UI-API REST endpoints in one move.
- Disable self-registration unless the site truly requires it. If enabled, ensure new accounts receive minimal permissions.
- Don’t mistake “API Enabled” for security. Removing this permission does NOT close UI-API access—they’re unrelated controls.
For ServiceNow Service Portals
- Map guest-facing portals to their search sources. Review
sp_portal,m2m_sp_portal_search_source, andsp_search_sourcetables. Detach any search source a public portal doesn’t need. - Audit Knowledge Base read criteria. Review
kb_knowledge_base,kb_uc_can_read_mtom, anduser_criteriatables. Remove unconstrained “Any User” criteria and replace with properly scoped controls (by role, group, or company). - For custom scripted sources, add
gs.isLoggedIn()gates and switch fromGlideRecordtoGlideRecordSecureto enforce ACLs.
The Bottom Line: Least Privilege Matters
This isn’t a platform vulnerability. Every byte the attacker retrieved was something a site owner had exposed to anonymous users. The guest user profile, its permissions, its sharing rules, and any code running in its context all still exist even if you require login.
“Every Salesforce Experience Cloud site has its own Guest User,” Reco emphasizes. “You cannot delete those guest users, and requiring login doesn’t remove them. If the guest can read a record, so can anyone on the internet.”
Conclusion
The City-Forum campaign serves as a stark reminder that security visibility must extend beyond traditional attack surfaces. When attackers develop custom tooling for undocumented APIs and maintain persistent infrastructure over seventeen months, reactive defenses are insufficient.
For CISOs and security teams, the message is clear: audit what your guests can see. The threat actor behind this campaign has demonstrated both patience and sophistication. Without proactive guest access review, your organization could be the next target and you might not know it for months.
If you haven’t audited your guest sharing rules, your LWR UI-API exposure, and your ServiceNow portal search access lately, this campaign is a good reason to do it now.
