An ongoing data-theft campaign has been quietly extracting corporate records from misconfigured Salesforce Experience Cloud and ServiceNow customer portals, using custom-crafted tools to turn anonymous guest access into a high-volume data pipeline. Tracked as City-Forum by SaaS security firm Reco, the operation has been traced to a single server that has targeted organizations across telecommunications, banking, financial services, enterprise software, security, data privacy, and the public sector. The City-Forum campaign does not exploit a vulnerability in either platform. Instead, it methodically pulls records that administrators have unintentionally exposed to unauthenticated users — and it has been doing so with increasing intensity for more than a year.
The attacker’s footprint is unusually stable. The same IP address, 158.220.87.79, hosted by German VPS provider Contabo, has been associated with the domain city-forum.com since at least March 2025. The campaigns observed by Reco almost always use the default Go-http-client/1.1 user agent when downloading data, creating a consistent fingerprint across Salesforce and ServiceNow environments worldwide. That combination of indicators has been present in nearly every attack tied to the campaign.
What Is the City-Forum Campaign?
The City-Forum campaign is a sustained data-theft operation that abuses guest accounts in Salesforce Experience Cloud and ServiceNow Service Portals to retrieve data exposed to anonymous users. Reco identified the campaign through repeated, high-volume requests originating from a single IP address against multiple organizations. The campaign is not a zero-day exploit chain or a piece of malware; it is an organized effort to find and extract data that should never have been made publicly accessible.
Because the attacker is deliberately targeting portal configurations rather than platform vulnerabilities, the threat applies to any organization using Salesforce Experience Cloud or ServiceNow customer-facing portals with permissive guest settings. The campaign remains active, and Reco has observed the volume of attacks climbing over time. So far, the activity appears to be entirely guest-user behavior, but Reco notes that authenticated-user misuse cannot be ruled out.
How Does the City-Forum Campaign Steal Data?
The attacker harvests data through normal API and framework endpoints that are designed to serve content to anonymous visitors. Both Salesforce Experience Cloud and ServiceNow rely on guest accounts to manage unauthenticated access. When those guest accounts are granted access to records, shared objects, or search sources, anyone on the internet can query the same endpoints that the portals themselves use.
In Salesforce, the attacker targets the legacy Aura framework and, more recently, the Lightning Web Runtime (LWR). In ServiceNow, the attacker abuses the native Service Portal search API. The underlying weakness is the same in every case: overly permissive sharing rules, insecure object and field permissions, and portal configurations that allow guest users to see records they should not see.
One Server, One Domain, One Persistent Operator
The City-Forum campaign’s infrastructure is remarkably simple. All observed attacks originate from IP address 158.220.87.79, a server operated by Contabo, a German VPS provider. The domain city-forum.com has resolved to that IP address since at least March 2025, indicating the attacker has not needed to rotate infrastructure or evade detection.
Reco found the same fingerprint across nearly all of the organizations targeted in the campaign. The requests consistently use the default Go HTTP client user agent, Go-http-client/1.1, which is a common default for Go-based tooling. Although using a default user agent is not inherently suspicious in isolation, the combination of the IP address, the domain resolution, and the repeated request patterns creates a clear indicator of activity tied to City-Forum.
The decision to keep the same server online for more than a year suggests a low perceived risk of interruption. It also gives defenders a durable detection signal: any anomalous guest-user traffic to Salesforce or ServiceNow originating from 158.220.87.79 should be treated as a possible sign of this campaign.
Salesforce Experience Cloud: The Aura Attack Path
On Salesforce, most of the observed City-Forum traffic targets the older Aura framework, which still powers many Experience Cloud sites. The attacker sends crafted requests to the /aura or /s/sfsites/aura endpoints to determine which standard and custom objects are available to the guest account. This initial enumeration is critical because it allows the attacker to map an organization’s publicly exposed data before making any bulk extraction.
The attacker’s first step is invoking HostConfigController.getConfigData, a controller method that returns configuration data about the objects available to the current user, including guest users. With that information in hand, the attacker moves to SelectableListDataProviderController.getItems, a controller used to retrieve records from objects that are accessible to the guest session. This two-stage approach is a common technique for Azure? No, Aura-based enumeration, but City-Forum executes it with custom tooling at a scale far beyond manual testing.
The attack volume against a single environment can be enormous. Reco recorded one organization where the attacker’s IP address generated more than 560,000 events, with nearly all of them related to guest Aura enumeration. That kind of activity is hard to miss in platform logs, yet it often goes unnoticed because many organizations do not monitor guest-user requests, API endpoint usage, or controller-level events.
Why Aura Guest Access Is So Dangerous
Aura controllers are designed to execute server-side actions on behalf of components in the page. When a guest account has read access to an object, those same controllers will happily return records to an anonymous user. Attackers do not need to exploit the platform; they simply need to ask the right questions through the right endpoints. The City-Forum attacker appears to have automated this process, using the Aura endpoints as a discovery and extraction engine.
This exact pattern was seen previously in data-theft campaigns attributed to ShinyHunters. That group used a modified version of the open-source tool AuraInspector to abuse guest users in misconfigured Experience Cloud portals. City-Forum is not identical to ShinyHunters, but the technical overlap reflects how well-known the guest-user abuse problem has become in the Salesforce ecosystem.
A New Frontier: Salesforce LWR and GraphQL
What distinguishes the City-Forum campaign is its expansion beyond older Aura-based attack paths. The same attacker is also targeting Salesforce sites built on the newer Lightning Web Runtime (LWR) framework. LWR is the modern runtime for Experience Cloud, and it handles data retrieval through a different architecture.
On LWR sites, the attacker uses Salesforce’s UI API to steal data exposed to guest accounts. The requests are GraphQL-based and are sent to the /webruntime/api/services/data/{version}/graphql endpoint. Reco says it has not observed any public attack tool that uses this technique. Existing tools such as AuraInspector, S-RET, and CirrusGo do not target the webruntime interface, which means the City-Forum operator is either using a custom tool or a tool that has not been publicly disclosed.
This is a significant development for organizations that have migrated their Experience Cloud sites to LWR. Many administrators assume that modern frameworks are safer by default, but the same guest-access misconfigurations can be exploited through the UI API and GraphQL layer. The City-Forum attacker appears to have built tooling around Salesforce’s own API surface, making the attack difficult to distinguish from legitimate portal activity without careful auditing.
The attacker also probes Experience Cloud sites for the /SiteRegister and /CommunitiesSelfReg endpoints to determine whether self-registration is enabled. If self-registration is open, a guest can create an authenticated external account. That new account may inherit broader permissions or membership in public groups, expanding the attacker’s access beyond what is visible to an anonymous guest user.
ServiceNow Service Portal Search Under Attack
The same attacker is also targeting ServiceNow Service Portals through a native endpoint that security researchers had not previously seen abused in widespread attacks. The endpoint is POST /api/now/sp/search?sysparm_cancelable=true, a URL used by ServiceNow’s portal search functionality. It accepts anonymous requests and can return search results when the underlying search sources are configured to permit guest access.
The attack works by varying search terms against the portal search API, effectively turning the search box into a data-extraction mechanism. Reco observed one investigated environment where requests grew from tens per day to hundreds per day. The automated nature of the requests and the consistent attacker IP address made the campaign visible to defenders who knew where to look.
One complication is that ServiceNow transaction logs do not record the POST body of these search requests. A defender can see that automated searches were made and can see the volume of data returned, but cannot reconstruct the exact search terms the attacker used. This creates a forensic blind spot and makes post-incident analysis more difficult.
Because ServiceNow’s portal search is a native feature, blocking the endpoint outright may break legitimate portal functionality. Instead, administrators must revisit which search sources expose guest-accessible data and restrict sensitive sources to authenticated users.
Is This the Work of ShinyHunters?
Given the similarity between the Salesforce Aura activity and previous ShinyHunters attacks, it is reasonable to ask whether City-Forum is a new operation from a well-known group. Reco found no evidence tying the two. The technical overlap is real, but there are meaningful differences in infrastructure and behavior.
Earlier ShinyHunters-related campaigns typically involved multiple systems and a variety of IP addresses. City-Forum has remained on the same IP address since March 2025, which is unusual for an operation that has sustained a high level of activity. The operator has also expanded into LWR and ServiceNow search abuses, techniques that were not part of the original ShinyHunters playbook.
The absence of a confirmed attribution does not change the urgency of the problem. The City-Forum campaign demonstrates that the tools and techniques for exploiting guest access are becoming more sophisticated and more widely available. Even if the current operator is not ShinyHunters, the campaign proves that the attack surface is being actively probed by multiple actors.
Detecting City-Forum Activity in Your Environment
Organizations using Salesforce Experience Cloud or ServiceNow Service Portals can look for several signals that may indicate City-Forum activity. The most direct indicator is traffic from the IP address 158.220.87.79 using the default Go-http-client/1.1 user agent. However, the attacker could modify that user agent, so infrastructure-only hunting is not enough.
On Salesforce, high volumes of requests to /aura, /s/sfsites/aura, or /webruntime/api/services/data/{version}/graphql from a single source deserve investigation. Sudden increases in guest-user traffic to SelectableListDataProviderController.getItems or HostConfigController.getConfigData are particularly relevant. Also monitor attempts to access /SiteRegister and /CommunitiesSelfReg, because these endpoints can reveal whether an attacker is testing self-registration paths.
On ServiceNow, watch for elevated anonymous traffic to /api/now/sp/search. If the request volume is climbing, if the requests are coming from a single IP, and if the portal search sources include sensitive tables, immediate action is warranted. Because transaction logs omit the POST body, defenders should rely on request metadata, response sizes, and source IP context to understand what the attacker may have retrieved.
Securing Salesforce Experience Cloud Against Guest-User Data Theft
Salesforce administrators should treat guest users as a high-risk access path. A practical starting point is to review the guest user profile or guest user record type and compare its object, field, and record-type permissions against the principle of least privilege. If a guest does not need to read Accounts, Contacts, Cases, custom objects, or files, those permissions should be removed.
The following areas deserve particular attention:
- Guest-user sharing rules: Audit all sharing rules that grant guest users access to records owned by internal users or public groups.
- Object and field permissions: Remove visualize? No, remove or restrict read access on objects that are not required for public portal functionality.
- File access: Ensure that guest users cannot access attachments, documents, or content libraries that contain sensitive information.
- Member visibility: Review whether guest users can view other portal members, community profiles, or account details.
- Self-registration settings: Disable self-registration unless it is required. If it is enabled, require approval workflows and restrict self-registered users to a minimal external profile.
For sites built on Lightning Web Runtime, Reco recommends disabling the Experience Builder option that allows guest users to access public APIs when that access is not required. Doing so blocks several API endpoints that the City-Forum attacker uses for data enumeration and theft. This is not a default setting that should remain enabled without a clear business requirement.
Securing ServiceNow Service Portals
ServiceNow administrators should review which search sources are exposed through Service Portals and confirm that sensitive data sources are protected by strict authentication and access controls. If a search source is configured to permit guest access, the portal search endpoint can be used just like the City-Forum attacker uses it.
The most important actions include:
- Audit search sources: List every search source attached to the Service Portal and classify each one by data sensitivity.
- Restrict guest-accessible sources: Remove guest access from any search source that can return records containing personally identifiable information, payment data, credentials, or internal business information.
- Monitor portal search traffic: Alert on unexpected spikes in anonymous requests to /api/now/sp/search and review the response sizes returned to guests.
- Harden self-service portals: Use ServiceNow roles and ACLs to ensure that guest users see only the minimum content required to complete their intended task.
Defenders should not rely on platform logs alone. Since ServiceNow transaction logs do not record the POST body of search requests, additional monitoring or a reverse proxy may be needed to capture the full details of guest-user API calls. In high-security environments, consider blocking anonymous access to portal search entirely and requiring authenticated sessions for all search functionality.
The Lesson for Every Organization with a Customer Portal
The City-Forum campaign is a clear reminder that customer-facing portals are not a border that protects internal data; they are an interface between an organization and the internet. Every configuration decision that affects guest users must be treated as a security decision, not just a usability decision. A guest account may be the smallest privilege in the platform, but across thousands of objects, fields, and search sources, small permissions can add up to a significant data breach.
The fact that the attacker has remained on one IP address for more than a year suggests that the operation is not worried about being discovered. That should concern any organization running Experience Cloud or ServiceNow portals. The campaign is ongoing, the request volume is climbing, and the tools are custom enough to avoid well-known detection rules built around older tooling.
Organizations that respond now by eliminating unnecessary guest access, disabling public API access on LWR sites, restricting ServiceNow search sources, and monitoring for the endpoints described above will be in a strong position. Those that wait for a vendor patch will miss the point: there is no patch for a permission that should never have been granted. The City-Forum campaign will ultimately fade, but guest-user abuse will not. The structural weakness it exploits is a permanent feature of modern portal architectures, and the only meaningful defense is disciplined configuration management, continuous auditing, and a refusal to assume that anonymous access can be safely granted to anything that does not need to be public.
