Security researchers are tracking an ongoing campaign using custom tooling to search Salesforce and ServiceNow environments for data inadvertently exposed through unauthenticated guest access.
Dubbed City-Forum by researchers at Reco, the activity has been observed against organisations in telecommunications, banking and financial services, enterprise software, security, data privacy and the public sector.
What makes the campaign particularly interesting is its breadth. Rather than concentrating on a single Salesforce technology, the attacker is targeting both Aura and newer Lightning Web Runtime (LWR) Experience Cloud sites, while also probing ServiceNow Service Portals. Reco says the same Go-based tooling and infrastructure have been observed across all three attack paths.
There is currently no evidence that the underlying Salesforce or ServiceNow platforms have been compromised. Instead, the attacker is exploiting a problem that continues to cause trouble across SaaS environments: legitimate anonymous access that has been configured too broadly.
A different approach to Salesforce data theft
Salesforce Experience Cloud sites can provide unauthenticated users with access to public content through a Guest User profile. That is a legitimate feature, but the permissions assigned to the profile determine what an anonymous visitor can retrieve.
If access to objects, records or fields is broader than intended, an attacker may be able to query the same information without authenticating.
This is not a new problem. In March 2026, Salesforce warned customers about a separate campaign targeting overly permissive Experience Cloud guest-user configurations. That activity involved a modified version of Mandiant's open-source AuraInspector tool and was subsequently claimed by the ShinyHunters cybercrime group.
ShinyHunters claimed to have targeted hundreds of organisations. Salesforce maintained that the activity was caused by customer configuration rather than a vulnerability in the Salesforce platform, and advised customers to audit guest-user permissions, restrict public API access and apply least-privilege controls.
The City-Forum activity appears technically distinct from that campaign. Reco has not attributed City-Forum to ShinyHunters and says it currently does not know who is behind the operation.
Custom tooling targets Aura, LWR and ServiceNow
According to Reco's investigation, City-Forum traffic originates from 158.220.87.79, an address hosted on Contabo infrastructure. The address has also been associated with city-forum.com, which gave the campaign its name.
Passive DNS records reviewed by Reco indicate that the domain has pointed to the address since at least March 2025. The researchers say they have observed no infrastructure rotation during that period.
Requests across both Salesforce and ServiceNow use Go-http-client/1.1, the default user-agent associated with Go's HTTP client. The consistent fingerprint, combined with the same source infrastructure and automated request patterns, led Reco to assess that the attacker is using purpose-built tooling rather than simply running an existing public scanner.
On Salesforce Aura sites, the activity includes high-volume requests to the /aura interface and enumeration of data available to the site's guest context.
Reco says one heavily targeted environment recorded more than 560,000 events during the campaign window, with almost all of that activity attributed to guest Aura enumeration.
LWR introduces another attack surface
The LWR activity is potentially more significant from a research perspective.
Reco reports that the attacker is querying Salesforce's UI API through GraphQL endpoints exposed by LWR sites. The observed requests step through consecutive Salesforce API versions, apparently testing which versions and data are available to the unauthenticated user.
The researchers describe this as the first in-the-wild campaign they have observed exploiting the LWR UI API guest surface in this way.
This distinction matters because an administrator may have secured an Experience Cloud site's visible pages without necessarily removing guest access to its public APIs. Salesforce documentation confirms that guest access is controlled through several separate mechanisms, including object permissions, record sharing, field-level security and public API settings.
Salesforce's security guidance recommends disabling Allow guest users to access public APIs where it is not required, as well as removing the API Enabled permission from guest profiles. Administrators should not assume that restricting the visible website alone has removed the underlying data-access paths.
ServiceNow portals are being searched as well
City-Forum does not stop at Salesforce.
Reco has also observed the same infrastructure sending automated requests to the ServiceNow Service Portal search API at /api/now/sp/search.
The endpoint is legitimate ServiceNow functionality. The risk depends on what search sources have been made available to unauthenticated users and whether the underlying access controls correctly prevent sensitive information from being returned.
The attacker appears to use automated searches to identify responses containing useful content. Response size can provide a simple indicator: a request returning substantially more data than the normal empty-search response suggests that the query has located something worth retrieving.
This again makes the activity difficult to classify as a conventional exploit. The attacker is using normal application functions and asking the platform for information the guest account has been permitted to see.
Legitimate requests make detection harder
There is another reason City-Forum deserves attention. Much of the observed traffic is protocol-valid and does not require malware, a conventional exploit chain or a compromised employee account.
An organisation relying primarily on failed authentication alerts or obvious exploit signatures could therefore miss the activity. From the application's perspective, an anonymous user may simply be making a large number of permitted requests.
This reflects a wider shift seen in recent SaaS attacks. Attackers increasingly look for excessive permissions, public interfaces, compromised identities and trusted integrations rather than depending entirely on exploitable software vulnerabilities.
In the earlier Salesforce Aura campaign, for example, Salesforce said attackers were able to query CRM objects directly where customers had configured guest profiles with excessive permissions. FINRA subsequently issued an alert to financial firms warning about the same type of Experience Cloud exposure.
Self-registration adds another potential route
Reco has also observed City-Forum probing Salesforce paths associated with site self-registration.
Salesforce Experience Cloud can be configured to allow visitors to create their own accounts. Where self-registration is required, the permissions assigned to those accounts need the same scrutiny as any other external identity.
Reco has not observed the City-Forum attacker successfully moving from anonymous guest access to an authenticated account. Its telemetry has so far shown guest activity only.
Nevertheless, Salesforce recommends disabling self-registration where it is not required. Where it is necessary, organisations should ensure newly registered users receive the most restrictive appropriate profile and that the registration process is properly controlled.
What administrators should check
Blocking 158.220.87.79 provides a straightforward defence against the infrastructure currently associated with City-Forum, but treating the IP address as the fix would miss the larger problem. The same exposed permissions could be discovered and exploited from another address.
Salesforce administrators should review every Experience Cloud site's Guest User profile and determine exactly which objects, records and fields can be accessed anonymously. Guest sharing rules and field-level security should be reduced to the minimum required for the public site to operate.
Public API access should be disabled where it is unnecessary, and self-registration should also be switched off unless there is a genuine business requirement for it. Salesforce additionally recommends reviewing member visibility, file access and Event Monitoring data for unusual guest activity.
Reco's City-Forum indicators include Salesforce Aura requests involving high volumes of getItems and getConfigData activity, LWR requests containing /webruntime/api/services/data/v, bursts of requests to self-registration paths, and traffic using Go-http-client/1.1.
ServiceNow administrators should review guest activity against /api/now/sp/search, particularly automated or high-volume requests. Public Service Portals should also be checked to establish which search sources are exposed and whether their underlying records and knowledge bases are genuinely intended for anonymous access.
The important distinction is that City-Forum does not need to defeat the security controls protecting this data if those controls already permit the guest identity to retrieve it. Organisations running public-facing SaaS portals should therefore treat anonymous identities as real security principals and audit their effective permissions accordingly.
Sources: Reco City-Forum campaign research; Salesforce guidance on securing Experience Cloud guest access; SecurityWeek reporting on the March 2026 Salesforce Aura campaign; FINRA Salesforce Experience Cloud security alert.
No comments:
Post a Comment