158.220.87.79

A single piece of infrastructure has been pulling records out of Salesforce and ServiceNow customer portals across multiple industries for more than a year, according to research published this week by agent security platform Reco. The activity, which Reco has named the City Forum campaign after a domain tied to the attacker's IP address, traces back to one server: 158.220.87.79, hosted on a commodity VPS through the German provider Contabo. Every request from that server carries the same fingerprint, the default user agent of Go's net/http library, which tells researchers the tool behind it is a compiled, purpose built program rather than anything run from a browser. Passive DNS shows the same domain pointed at that IP as far back as March 2025, and the server has not moved since. Targets identified so far span telecoms, banks and other financial services firms, enterprise software vendors including security and data privacy companies, and public sector portals, though Reco has not named individual organizations. What sets this campaign apart from prior Salesforce guest access abuse, including the widely reported activity attributed to ShinyHunters, is the range of surfaces it touches. Most known attackers in this space lean on Salesforce's older Aura framework, sending high volumes of guest requests to enumerate objects and page through records. This actor does that too, and Aura still accounts for the bulk of the traffic Reco observed, with one target logging over 560,000 events from the same IP. But the tool also reaches Salesforce's newer Lightning Web Runtime sites through the UI-API, a data layer that has no public write ups or known scanning tools associated with it, walking through API versions v56.0 through v66.0 in sequence. On top of that, the same server hammers a native ServiceNow Service Portal search endpoint, POST /api/now/sp/search, that carries almost no public documentation of its own. According to Reco's writeup, the common thread across every technique is the same underlying issue: a guest identity that was granted more access than the site actually needed to serve the public. Salesforce Experience Cloud sites and ServiceNow portals both maintain a persistent guest user that unauthenticated visitors execute as, and that user cannot be deleted, only restricted. If the guest profile can read a record, the record is effectively public, whether or not the site requires login to view it in a browser. The research lays out concrete detection steps for security and IT teams on both platforms. On Salesforce, defenders with Event Monitoring or Shield can pull AuraRequest and Sites log events and look for the Go-http-client user agent, the specific IP, and request paths containing /webruntime/api/services/data, alongside spikes in self registration attempts at /SiteRegister and /CommunitiesSelfReg. On ServiceNow, the transaction log table syslog_transaction can be filtered by source IP and by URLs starting with /api/now/sp/search, with guest created rows and unusual output length flagged as the clearest signal of a live sweep. Remediation, per the research, centers on tightening the guest profile rather than the endpoints themselves, since both the UI-API and the ServiceNow search endpoint are working as designed. On Salesforce, that means reviewing guest sharing rules, stripping unnecessary object and field level access from the guest profile, disabling self registration where it is not required, and turning off the Experience Builder setting that allows guest users to reach public APIs. On ServiceNow, the fix is mapping which search sources are exposed to public facing portals and auditing the Knowledge Base read criteria that decide what an anonymous search actually returns. Reco says the infrastructure behind the campaign is still active and the volume is climbing, and the firm has not attributed the activity to a specific named group. The full technical breakdown, including request signatures, sample queries, and a closer look at how the Service Portal search endpoint decides what to hand back to an anonymous caller, is available in Reco's writeup of the City Forum campaign. Security leaders weighing how much of their budget to put toward this kind of app exposure, versus other priorities competing for the same dollars, can find a planning framework in Reco's guide to AI security investment, which covers how to size budget, evaluate vendors, and build a business case for the board.

Update 8/14: Added statement from ServiceNow. An ongoing data theft campaign uses custom tools to steal data exposed to anonymous users through Salesforce Experience Cloud and ServiceNow customer portals. The data-theft campaign, dubbed City-Forum by SaaS security firm Reco, has been traced to a single server that has targeted multiple organizations worldwide. These organizations include telecommunications companies, banks and financial services firms, enterprise software vendors, security and data privacy companies, and public-sector portals. Reco says the attacks are ongoing, with activity continuing to increase. The City-Forum data theft attacks Reco says all of the attacks originate from the IP address 158.220.87.79, hosted by German VPS provider Contabo, and almost always use the default Go-http-client/1.1 user agent when downloading data. This IP address is associated with the city-forum.com domain, which has resolved to the server since at least March 2025, indicating that the infrastructure has remained in place for more than a year. The researchers say these combined IOCs have been seen across almost all attacks targeting Salesforce and ServiceNow environments in this campaign. "The same fingerprint appears against both Salesforce and ServiceNow, across multiple organizations worldwide. It is still running, and the volume is climbing," explains Reco. "So far, we have only seen guest user activities - never an authenticated user, but we cannot rule it out." These attacks are not exploiting a vulnerability in Salesforce or ServiceNow. Instead, they steal data that organizations have mistakenly exposed to unauthenticated guest users through overly permissive sharing rules, permissions, or portal configurations. Both Salesforce Experience Cloud and ServiceNow use guest accounts to manage unauthenticated visitors. If these accounts are given access to data records, anyone on the Internet can potentially retrieve them through various API endpoints. On Salesforce, most of the observed activity targets the older Aura framework, where attackers are sending requests to the /aura or /s/sfsites/aura endpoint to determine which objects, such as Accounts, Contacts, Cases, are publicly accessible. Reco says the attacker first invokes HostConfigController.getConfigData to enumerate objects available to the guest account and then uses SelectableListDataProviderController.getItems to retrieve records from accessible objects. Reco says the busiest target recorded more than 560,000 events from the attacker's IP address, with nearly all of them related to guest Aura enumeration. This type of Salesforce guest-user abuse is not new and has previously been used in ShinyHunters data theft campaigns. ShinyHunters previously used a modified version of the AuraInspector tool to steal exposed records from misconfigured Experience Cloud portals. However, the City-Forum attacker is not only targeting these same Aura endpoints, but also Salesforce sites built using the newer Lightning Web Runtime (LWR) framework. On LWR sites, the attacker uses Salesforce's UI API to steal data exposed to guest accounts through GraphQL requests sent to /webruntime/api/services/data/{version}/graphql. Reco says it has not seen any public attack tools using this technique, and existing tools such as AuraInspector, S-RET, and CirrusGo do not use the webruntime interface. The attacker also targets Experience Cloud sites for /SiteRegister and /CommunitiesSelfReg endpoints to determine whether self-registration is enabled, which could allow a guest to create an authenticated external account with broader access. The same attacker is targeting ServiceNow Service Portals through the native POST /api/now/sp/search?sysparm_cancelable=true endpoint, which Reco says it had not previously seen abused in attacks. The endpoint, used by ServiceNow's portal search functionality, accepts anonymous requests and can return data when search sources are configured to permit guest access. Reco says attackers can vary search terms to enumerate exposed information, with one investigated environment seeing requests grow from tens to hundreds per day. Because ServiceNow transaction logs do not record the POST body, defenders can see that automated searches occurred and how much data was returned, but cannot determine the exact search terms used by the attacker. While some of this Salesforce activity is similar to previous ShinyHunters attacks, Reco says there is no evidence tying the current campaign to that group. The researchers also noted that previous campaigns such as ShinyHunters' typically used multiple systems and different IP addresses, while the City-Forum infrastructure has remained on the same IP address since March 2025. Salesforce administrators are advised to review guest-user sharing rules, object and field permissions, file access, member visibility, and self-registration settings. For LWR sites, Reco also recommends disabling the Experience Builder option that allows guest users to access public APIs when it is not required. Doing so will block access to various API endpoints used for data enumeration and theft. ServiceNow administrators should review which search sources are exposed through Service Portals and ensure that sensitive data search sources use strict authentication and access controls. After publishing this story, ServiceNow shared the following statement with BleepingComputer, confirming that its environment was not compromised as part of these attacks. "ServiceNow is aware of a security company's blog post claiming that improperly configured Service Portals can create unintended security risk. We can confirm there is no compromise of the ServiceNow environment," ServiceNow told BleepingComputer. "We proactively work with customers to support the ongoing security of their environments to best suit their unique business needs and encourage customers to reach out to ServiceNow support if they have questions regarding specific configurations." Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Reco is tracking a sophisticated and innovative campaign targeting both Salesforce and ServiceNow via what appears to be a custom made multi-platform toolset. Researchers believe the primary targets include telecoms, banks and financial-services firms, enterprise-software vendors (including security and data-privacy companies), and public-sector portals. The campaign has been named ‘City-Forum’. It is directed at both Salesforce Aura and the newer LWR implementations, where it is the first observed in‑the‑wild exploitation of Salesforce’s UI‑API guest surface. Furthermore, attacks on Aura (necessarily included in a Salesforce campaign since Aura users still outnumber LWR users) are integrated with the LWR attacks in a single toolset. “One Go binary hit Salesforce over both Aura and LWR and hit ServiceNow, from the same box,” comment the researchers in a blog report. This is consistent with a custom toolset rather than anything off the shelf like AuraInspector. The primary access key for both platforms is the Guest User. Every Salesforce Experience Cloud has its own Guest User in which an unauthenticated request works. ServiceNow is similar. “You cannot delete those guest users, and requiring login doesn’t remove them – the profile, its permissions, its sharing rules, and any code running in its context all still exist. If the guest can read a record, so can anyone on the internet.” To better understand the degree of innovation in this campaign, it is useful to compare the City-Forum campaign with other attacks targeting Aura – especially the ShinyHunters’ Salesforce Aura Campaign disclosed in March 2026. As well as targeting LWR in Salesforce, “[City-Forum] hammers a native ServiceNow Service Portal search endpoint that has almost no online documentation or well-known open source tools.” ShinyHunters targeted just Aura in Salesforce (no known targeting of ServiceNow) and used a modified version of the existing AuraInspector. City-Forum uses a new custom multi-platform toolset. Reco is at pains to explain that it doesn’t rule out ShinyHunters also being behind City-Forum, and goes on to add “We don’t know who this is, and we’re not ruling anyone in or out.” The City-Forum campaign uses a single machine. “The same IP has carried the same domain since March 2025 and is still scanning today – at least seventeen months on one address, with no rotation at any point.” That IP (158.220.87.79) resolves to city-forum.com. Reco draws no inference from this, but the main advantage of a single machine is that it reduces the attacker’s footprint to anomaly detection systems. It may be easier to block if known, but harder to detect if stealthy. The campaign targets unauthenticated guest user access in both Salesforce and ServiceNow. However, conversion to an authenticated user in Salesforce would be possible if self-registration is enabled. There is no similar mechanism for ServiceNow. Being an authenticated guest user is not necessary, but could provide access to more sensitive data. Since many organizations misconfigure guest permissions, this is a continuing possibility. However, “So far, we have only seen guest user activities – never an authenticated user, but we cannot rule it out,” comment the researchers.” Aura gives up the majority of the Salesforce data collected and exfiltrated. “The busiest target logged over 560,000 events… across the campaign window, essentially all of it guest Aura enumeration,” say the researchers. Data is also pulled from the Salesforce LWR sites using GraphQL. The ServiceNow attack targets the effectively undocumented search endpoint. It uses this to detect substantial content. “The Output length column is worth a glance while you’re here: rows returning noticeably more than the small empty-result baseline are searches that came back with content.” The attacker can pull from the most likely results. The exfiltration is not noisy – it is high volume but protocol-legitimate. This makes detection difficult, perhaps confirming the stealth intent behind using a single constant destination address. As with the ShinyHunters attack, there is no suggestion of a breach of the Salesforce or ServiceNow platforms. “Every byte the attacker retrieved was something a site owner had exposed to anonymous users.” Being targeted by City-Forum is not a noisy easy-to-see attack. But most things can be found if you know where to look. The Reco research blog includes detailed IOCs and remediation instructions. At the very least, as soon as possible make sure that self-registration is not enabled. This will hinder any attempt for an unauthenticated guest to upgrade to an authenticated guest. Related: BeyondTrust, LastPass Impacted by Klue-Salesforce Incident Related: Salesforce Instances Hacked via Gainsight Integrations Related: Extortion Group Leaks Millions of Records From Salesforce Hacks Related: Hackers Extorting Salesforce After Stealing Data From Dozens of Customers