City-Forum Campaign Targets Salesforce and ServiceNow Guest Access

Introduction

A long-running cyber campaign is targeting publicly accessible Salesforce Experience Cloud and ServiceNow Service Portals, with attackers using custom tooling to search for data exposed through guest-user permissions.

Security research firm Reco disclosed the activity on August 12, 2026, naming it the City-Forum Campaign after the domain associated with infrastructure used in the activity. Reco says the campaign has been observed from a single IP address, 158.220.87.79, with infrastructure linked to the domain city-forum.com in passive DNS records since March 2025.

The research is notable because the attacker is not relying solely on the better-known Salesforce Aura attack surface. Reco observed activity against Salesforce Lightning Web Runtime, or LWR, through the UI-API, as well as a ServiceNow Service Portal search endpoint that has received comparatively little public documentation and tooling.

Reco says the activity has targeted organisations across telecommunications, banking and financial services, enterprise software, security and data privacy, and public-sector portals. The company did not identify individual victims.

The campaign's central weakness: guest access

The most important finding is that Reco does not describe this as a Salesforce or ServiceNow software vulnerability.

Instead, the campaign is taking advantage of information and functionality that organisations have made accessible to unauthenticated guest users through configuration, permissions, sharing rules or portal search sources.

Both platforms maintain a guest identity for unauthenticated activity. If that identity has permission to read a record, an internet-based attacker can potentially access the same information without authenticating.

Reco therefore describes the underlying problem as excessive guest permissions rather than a platform-level security flaw.

A single infrastructure trail

Reco traced the campaign to 158.220.87.79, hosted through Contabo and associated with ASN 51167. The same infrastructure resolves to city-forum.com, which gives the campaign its name.

The research also identifies several subdomains associated with the infrastructure, including www.city-forum.com, server.city-forum.com, www.server.city-forum.com, mail.city-forum.com and www.mail.city-forum.com.

Reco observed the default Go HTTP client user agent, Go-http-client/1.1, across the requests. According to the researchers, this fingerprint is consistent with a compiled tool rather than normal browser-based activity.

Reco says the same IP was observed against Salesforce and ServiceNow environments and that the infrastructure remains active.

The research does not attribute the campaign to a specific threat group. Reco notes similarities with previous ShinyHunters activity but explicitly says the available evidence is insufficient to identify the operator.

Salesforce Aura remains a major target

One part of the operation focuses on Salesforce Experience Cloud sites using the Aura framework.

The attacker sends requests to the /aura endpoint and uses Salesforce functionality to identify objects accessible through the guest context. Reco observed activity involving HostConfigController.getConfigData and SelectableListDataProviderController.getItems.

The first technique can reveal API names and key prefixes for objects accessible to the guest identity. The attacker can then attempt to enumerate records associated with those objects.

Reco says one heavily targeted environment recorded more than 560,000 events from the observed IP during the campaign window, with most of that activity involving guest Aura enumeration.

The underlying security issue remains permissions. Aura only returns information available to the guest according to object permissions, field-level security and sharing rules.

LWR introduces another attack surface

The research also highlights Salesforce's Lightning Web Runtime.

Unlike Aura-based sites, LWR sites do not expose the same /aura surface. Instead, their data layer operates under /webruntime/api/services/data/{version}/.

Reco observed the attacker probing Salesforce API versions from v56.0 through v66.0 against the GraphQL endpoint. The activity can reveal queryable objects and then retrieve records that are accessible to the guest identity.

The researchers describe this as an important development because LWR has received less attention from public offensive tooling than Aura.

Reco also observed REST interfaces associated with the same UI-API surface, including endpoints for object metadata and direct record access.

The important distinction is that the UI-API is not automatically a vulnerability. The data returned is governed by the permissions and sharing configuration of the guest user.

Self-registration adds another potential escalation path

The Salesforce activity also includes probing for self-registration.

Reco observed requests to /SiteRegister and /CommunitiesSelfReg across many Experience Cloud sites.

The objective appears to be determining whether an unauthenticated visitor can create an external account. If self-registration is enabled, an attacker may obtain an authenticated external identity with different permissions from the anonymous guest account.

Reco says this behaviour appeared consistently enough across targets to be considered part of the campaign's methodology rather than incidental scanning.

ServiceNow activity focuses on portal search

On ServiceNow, Reco observed a different technique.

The campaign targets the Service Portal search endpoint:

/api/now/sp/search?sysparm_cancelable=true

The endpoint is used by Service Portal functionality and accepts search information through a POST request.

Reco's investigation found that access decisions depend heavily on the search sources connected to a public portal. These sources are associated with ServiceNow tables including sp_portal, m2m_sp_portal_search_source and sp_search_source.

This means defenders should not focus exclusively on whether the endpoint itself is publicly reachable. Instead, they need to determine what information the connected search sources can expose to a guest user.

For example, Reco examined Catalog and Knowledge Base search sources and found that their access behaviour differs. The Catalog source includes a login check, while Knowledge Base access relies on its configured "Can Read" criteria.

That makes search-source configuration an important part of the security review.

How defenders can hunt for the campaign

Reco provides platform-specific detection guidance.

For Salesforce, organisations with Salesforce Event Monitoring can examine request-level logs for indicators including the observed IP address and Go-http-client/1.1 user agent.

Relevant Salesforce event types include AuraRequest and Sites. Researchers recommend looking for repeated Aura actions, LWR requests containing /webruntime/api/services/data/v, and bursts involving /SiteRegister or /CommunitiesSelfReg.

For ServiceNow, the relevant activity can be investigated through the syslog_transaction table.

Reco recommends filtering for the observed IP address and requests beginning with /api/now/sp/search. The transaction records can also provide the user agent and output length, helping defenders identify unusual guest search activity.

The transaction log does not retain the POST body, according to Reco, so defenders cannot reconstruct the exact search terms from those records alone.

Recommended Salesforce hardening

Reco's remediation guidance centres on reducing the guest user's privileges to the minimum required for public functionality.

Key areas include:

• Review guest-user sharing rules and remove unnecessary record exposure.

• Remove object and field permissions that are not required for anonymous users.

• Remove the Access Activities permission from the guest profile where it is not needed.

• Disable self-registration unless the site requires it.

• Review guest file access and member visibility.

• For LWR sites, review the Allow guest users to access public APIs setting.

• Treat the UI-API setting separately from the API Enabled profile permission.

Reco specifically warns that disabling the API Enabled permission does not by itself close the LWR UI-API exposure. The researchers also distinguish API access from the setting controlling whether visitors can interact with a site without logging in.

Recommended ServiceNow hardening

For ServiceNow, Reco recommends first mapping public portals to their search sources.

Security teams should identify:

1. Which Service Portals are reachable without authentication.

2. Which search sources are connected to those portals.

3. What each search source can query.

4. Whether the source enforces authentication and access controls.

5. Whether Knowledge Base read criteria unintentionally grant access to everyone.

For scripted search sources, Reco recommends checking whether the logic verifies that the user is logged in and whether it uses GlideRecordSecure to enforce ACLs.

For table-backed sources, administrators should review the source table, conditions and role requirements.

Where anonymous access is unnecessary, requiring authentication can reduce the exposed attack surface.

Why the campaign matters

The City-Forum campaign illustrates a broader SaaS security problem: a system can be technically functioning as designed while still exposing more information than an organisation intended.

Public portals often need some degree of anonymous access. The security challenge is ensuring that the guest identity can access only the content and functionality required by that public experience.

The campaign also demonstrates why security monitoring needs to evolve alongside SaaS platforms. Traditional Salesforce monitoring that focuses only on Aura may miss activity against newer LWR interfaces. Similarly, ServiceNow monitoring that ignores guest-facing portal search behaviour may overlook suspicious enumeration.

For enterprises, this could mean treating guest identities as security principals that require the same level of governance as authenticated accounts, even though they are designed for anonymous visitors.

The development reflects growing demand for continuous SaaS security posture management, particularly as organisations expose more customer-facing functionality through cloud platforms.

Attribution remains unconfirmed

Reco has deliberately avoided assigning the campaign to a specific threat actor.

The researchers acknowledge similarities with ShinyHunters activity but also identify differences in infrastructure and tooling. They say the evidence does not establish whether the same group is responsible.

The campaign instead appears technically consistent with a custom multi-platform toolset capable of interacting with Salesforce Aura, Salesforce LWR and ServiceNow from the same infrastructure.

That distinction matters. Similar techniques or infrastructure patterns alone are not enough to make a reliable attribution.

What organisations should do now

Organisations using Salesforce Experience Cloud or ServiceNow Service Portals should review anonymous access rather than assuming that a public portal is safe simply because no known software vulnerability is present.

The immediate priorities are:

• Audit guest-user permissions.

• Review public Salesforce sharing rules.

• Check Salesforce LWR UI-API exposure.

• Review self-registration settings.

• Examine ServiceNow public portal search sources.

• Validate Knowledge Base and catalog access criteria.

• Search logs for unusual guest activity.

• Investigate requests associated with the indicators published by Reco.

• Remove anonymous access that is not required for legitimate business functionality.