Mirko Zorz , Director of Content, Help Net Security August 12, 2026 Share A stranger has been reading Salesforce and ServiceNow portals worldwide for 17 months Most security stories start with something broken. This one starts with everything working as designed. Researchers at Reco have been tracking a campaign they call City-Forum, named after a domain registered in 2002, abandoned, and now resolving to a generic rented server from a German hosting provider. From that server, someone has been pulling records out of Salesforce and ServiceNow portals around the world. The activity has not stopped, and there is more of it than there was. Every request Reco has seen from this address arrived as a guest. The targets they can see span telecom operators, banks and financial-services firms, enterprise-software vendors including security and data-privacy companies, and public-sector portals. What passive DNS establishes is that the domain has resolved to this address since at least March 2025, so the infrastructure has been standing for a while. When the scanning started is a different question. Here is the part worth sitting with: no software was exploited. No credentials were needed. There is no vulnerability here to patch. The attacker visited public customer portals as an anonymous visitor and asked them, politely and repeatedly, for their contents. The portals answered. The guest in the room Salesforce gives every Experience Cloud site its own standing account called the guest user, and every ServiceNow instance has one too. It is a real user with a profile and permissions like any other. When an unauthenticated stranger loads your support portal or your knowledge base, that is who they are browsing as. The guest user is not optional, it cannot be deleted, and it arrives with permissions that somebody, at some point, configured. Nothing came out of these portals that they had not been configured to hand over. Nitay Bachrach , Security Researcher at Reco, describes the underlying problem: “The core issue is that ‘what is public’ and ‘what should be public’ are two different things, and that’s exactly what the attacker exploited.” Why this one stands out Attackers have been abusing over-permissioned Salesforce guest users for a while, and there are off-the-shelf tools for it. This operator did not use them. They built their own instead. Most of the resulting traffic still went down the well-trodden route: Salesforce’s older Aura framework, whose guest user has been a documented target for long enough that Reco has written up a previous campaign working the same way. That is where the bulk of this operator’s Salesforce effort landed. The busiest single target Reco observed logged over 560,000 events from this one address across the campaign window, almost all of it Aura enumeration. What makes the campaign worth reading about is the rest of the toolkit, pointed at two places nobody had bothered to look. The first is the data layer behind Salesforce’s newer site framework, which the existing attack tools ignore entirely. Reco’s phrase for it is an offensive blind spot. The second is a ServiceNow portal search endpoint so undocumented that ServiceNow publishes no reference for it. Reco worked out how it behaves by reading the code behind the search box on a stock portal. Obscurity is not what makes it dangerous, though. The endpoint is public by design, and what it hands back depends entirely on how the sources behind it are configured. One of the two most common sources that ship with the platform checks whether you are logged in before it goes near data. The other has no such check at all. It relies entirely on who has been granted read access to each knowledge base, which is a configuration question with nothing in the code to warn you either way. The two behave nothing alike. On the Salesforce side the new work was thin next to the Aura flood, a few requests against each API version on each subsite it found, which is roughly what you would expect while Aura sites are still the more common target. On ServiceNow it was the opposite: once the tool found a portal, almost everything it did there went at that one search endpoint. Both halves show the same homework. They point to someone who sat down with these platforms, learned them properly, and went looking for doors no scanner was checking. Who that someone is, Reco will not say. The activity resembles the ShinyHunters Experience Cloud campaign, guest enumeration of Salesforce over Aura and GraphQL, and Reco’s position is that a campaign not matching a group’s last known fingerprint tells you nothing on its own, since actors rewrite tooling and rent new boxes constantly. One thing is unlike those campaigns, offered as a soft signal rather than a finding: this operator has held a single address for at least seventeen months, with no rotation at any point. The uncomfortable bit: you cannot see what left Suppose you go looking and find this traffic in your own logs...