Records are being pulled from Salesforce and ServiceNow portals that need no login

Reco is tracking an ongoing campaign it has named City-Forum, in which a purpose built tool pulls records from customer portals in Salesforce Experience Cloud and in ServiceNow. Reco reports that all the traffic comes from one single server, a rented machine at the German provider Contabo on the address 158.220.87.79, and that the requests carry the default fingerprint of the HTTP client in the Go programming language. The name comes from the domain city-forum.com, which according to Reco has pointed at that same address since 12 March 2025. The targets span telecoms, banks and financial services firms, software vendors in security and privacy, and public sector portals. Reco reports that the campaign is still running and that the volume is climbing.

What happens technically

No vulnerability is being exploited here. A customer portal in Experience Cloud or ServiceNow is built to show something to people who have not logged in, and it does so through a guest user. If that guest user is granted access to more than the one page it is meant to show, the rest of the data is also reachable through the same interfaces the portal itself uses. Reco describes the tool querying Aura, the older interface in Salesforce, and also reaching Lightning Web Runtime through a data layer the company has not seen described in any public tool or write up. The tool sweeps several versions of the API and probes whether the portal allows anyone to register themselves.

On ServiceNow the way in is a portal search endpoint that is open to guests and, according to Reco, barely documented. What makes the campaign notable is not the individual techniques but that the actor has built its own tooling for interfaces with little public material behind them. Reco reports seeing activity only from guest users, never from a logged in account, while noting it cannot rule the latter out. One marker is worth taking straight to your own logs: a guest session arriving from Go, python-requests or curl has no legitimate explanation, because a customer portal is served to browsers. Reco also advises resolving the domain rather than visiting it.

What this means for you if you own a customer portal

If you run a portal for customers, partners or citizens, this is a story about your own settings. No patch helps. What decides whether you are exposed is how much your guest user is allowed to see, and that is often set wide because something had to work in time for a launch. The campaign has been running for over a year from the same address, so the question is not whether you will be asked, but what you answer when you are.

Our assessment is that this belongs in privacy handling from the first hour, not only in security handling. If customer records are pulled out through a guest user with too much access, you have an incident under data protection law without anyone having broken in anywhere. That means you need to be able to show what the guest user actually had access to, and which requests were answered. Under NIS2 article 21 this is access control and logging. We would add that the responsibility here sits with you rather than with the platform vendor, because you set the permissions.

Berigo recommends

• Review what the guest user in your portal actually has access to, object by object, and remove everything that does not need to be there.
• Turn off self registration in portals where it is not in use.
• Search your logs for guest sessions with client fingerprints from Go, python-requests or curl.
• Block or limit traffic from hosting providers where you have no customers, if the portal can take it.
• Agree in advance who decides whether an extraction of customer data is a privacy incident, and how quickly that has to happen.