A campaign dubbed "City-Forum" has been observed exfiltrating data from public-facing Salesforce and ServiceNow portals globally for at least 17 months, according to researchers at Reco. The activity, which began no later than March 2025, involves an attacker operating from a single, consistent IP address associated with a German hosting provider.
The core of the campaign relies not on exploiting vulnerabilities or compromising credentials, but on leveraging over-permissioned guest user accounts. Both Salesforce Experience Cloud sites and ServiceNow instances include a non-optional guest user profile, which unauthenticated visitors browse as. The attacker simply requested content from these public portals, and the portals, configured to do so, provided it.
Reco researchers emphasize that the issue stems from a discrepancy between what is publicly accessible and what *should* be public. The campaign targets a wide array of organizations, including telecommunication operators, financial institutions, enterprise software vendors (including security and data privacy companies), and public-sector entities.
While attackers have previously abused over-permissioned Salesforce guest users, often using readily available tools, the City-Forum operator developed custom tooling. A significant portion of the Salesforce activity focused on the older Aura framework, a known target for guest enumeration. Reco observed one Salesforce target logging over 560,000 events from the attacker's IP, predominantly Aura enumeration requests.
However, the custom tooling also targeted two previously overlooked areas. On the Salesforce side, it probed the data layer behind the newer site framework, an area Reco describes as an "offensive blind spot." On ServiceNow, the attacker identified and utilized an undocumented portal search endpoint. Reco researchers reverse-engineered the behavior of this endpoint by examining the code behind a stock portal's search box.
The ServiceNow search endpoint is public by design, and its responses depend entirely on the configuration of its underlying data sources. One common source checks for user authentication, while another does not, relying solely on read access permissions for knowledge bases. This configuration nuance, without explicit warnings in the code, dictates what an anonymous guest can access.
While the new Salesforce attack methods were less frequent than Aura enumeration, the ServiceNow activity heavily concentrated on the undocumented search endpoint once a portal was identified. This suggests a deliberate and thorough understanding of both platforms by the attacker.
Organizations attempting to identify this activity in their logs will face challenges in determining precisely what data was exfiltrated. Salesforce Event Monitoring logs can indicate *what* actions were attempted (e.g., Aura actions, GraphQL version sweeps, self-registration probes) but not *which specific records or fields* were returned. Similarly, ServiceNow transaction logs record that a search occurred and the approximate response size, but not the search terms themselves.
According to Reco, it is not possible to definitively determine leaked data from audit logs alone. Organizations would need to simulate the attacker's requests internally as an anonymous user and analyze the responses to understand what was accessible. A further complication on ServiceNow is that the portal search endpoint returns an HTTP 201 status code regardless of whether it provides data, meaning a leaking portal and a secure one appear identical externally until the response body is examined. The attacker overcame this by mapping portal contents based on which search terms yielded non-empty responses.
The most common misconfiguration identified as the root cause on both platforms was excessive permissions granted to guest or anonymous users. While Salesforce guest sharing rules offer the highest-impact fix, it is crucial for organizations to review all guest permissions comprehensively.
For Salesforce, organizations should check Event Monitoring for AuraRequest and Sites entries with `USER_TYPE = Guest`, looking for high volumes of `getItems` and `getConfigData`, `/webruntime/ /vNN.0/graphql` version sweeps, and hits on `/SiteRegister` and `/CommunitiesSelfReg`. On ServiceNow, `syslog_transaction` should be reviewed for `/api/now/sp/search` requests made by guest users.
