Aanvaller haalt 17 maanden lang data uit open Salesforce- en ServiceNow-portalen

Eén server haalt sinds maart 2025 onafgebroken bedrijfsdata uit verkeerd ingestelde Salesforce- en ServiceNow-klantportalen, meldt beveiligingsbedrijf Reco, zonder ook maar één kwetsbaarheid te misbruiken.

Dat maakt dit een controleerbaar probleem in plaats van een patchprobleem. Draait je klantportaal, kennisbank of serviceportaal op Salesforce Experience Cloud of ServiceNow, dan bepaalt één set instellingen wat een anonieme bezoeker mag opvragen. Staat daar te veel open, dan hoeft niemand in te breken: de gastgebruiker vraagt het gewoon op, en in je logs ziet dat verkeer er net zo legitiem uit als een klant die iets zoekt.

Geen lek, maar een vinkje

Reco volgde de campagne terug naar één machine. Het adres 158.220.87.79, een VPS bij hoster Contabo, vraagt sinds 12 maart 2025 gestaag gegevens op bij Salesforce- en ServiceNow-portalen wereldwijd, altijd vanaf datzelfde adres, zonder rotatie. Het verkeer komt uit een zelfgebouwd Go-programma, herkenbaar aan de standaard user agent Go-http-client/1.1. Bij één onderzochte organisatie stonden ruim 560.000 gebeurtenissen van dat ene adres in de logs, vrijwel allemaal opvragingen als gast. De onderzoekers noemen de campagne City-Forum, naar het domein city-forum.com dat in 2002 werd geregistreerd en sinds maart 2025 voor deze infrastructuur wordt hergebruikt.

Nitay Bachrach, onderzoeker bij Reco, zet het probleem scherp: wat publiek is en wat publiek zou moeten zijn, zijn twee verschillende dingen. Kan de gastgebruiker een record lezen, dan kan iedereen met een internetverbinding dat.

Het is een andere route naar dezelfde data dan de campagne waarin ShinyHunters medewerkers telefonisch een frauduleuze OAuth-app in hun Salesforce-tenant liet goedkeuren. Daar gaf een mens toestemming na een overtuigend telefoontje. Hier hoefde niemand iets te geven. Het patroon reikt verder dan SaaS: bij Nextcloud lagen 367.000 interne records open via een verkeerd geconfigureerde Elasticsearch-database, ook zonder exploit.

Drie ingangen, twee platformen

De aanvaller gebruikt geen kant-en-klare scanner maar één zelfgeschreven programma dat drie ingangen tegelijk bedient. Wat het precies aanroept, bepaalt ook waar je in je eigen logs moet kijken:

Salesforce Aura. Het programma somt eerst op welke objecten een gast mag zien via de controller HostConfigController.getConfigData en haalt de records vervolgens op met SelectableListDataProviderController.getItems.

Salesforce Lightning Web Runtime. Op nieuwere sites loopt de opvraging via het UI-API-eindpunt /webruntime/api/services/data/vNN.0/graphql, waarbij systematisch de API-versies v56.0 tot en met v66.0 worden afgegaan. Dit is de eerste keer dat misbruik van die gastlaag in het wild is waargenomen. Scanners die alleen op Aura letten, zien LWR-sites helemaal niet.

ServiceNow Service Portal. Hier gaat het om POST /api/now/sp/search?sysparm_cancelable=true, de eigen zoekfunctie van het portaal. Die geeft resultaten terug op basis van de ingestelde zoekbronnen, zoals kennisbank en servicecatalogus, niet op basis van de vraag of iemand is ingelogd.

Daarnaast test het programma de paden /SiteRegister en /CommunitiesSelfReg, om te zien of een anonieme bezoeker zichzelf een account kan aanmaken en zo verder komt dan gasttoegang.

Wat je vandaag zelf nakijkt

De controle kost een beheerder een middag en vraagt geen enkele aanschaf. Gasttoegang is in beide platformen een profiel dat je niet kunt verwijderen, dus de vraag is niet of je een gast hebt, maar wat die mag. Dit staat op de lijst:

In Salesforce Experience Cloud:

• Deelregels op het gastprofiel: welke Accounts, Contacten en Cases zijn via sharing rules zichtbaar voor een niet ingelogde bezoeker.
• Object- en veldrechten: strip alles van het gastprofiel wat het portaal niet echt nodig heeft.
• Access Activities: deze permissie geeft toegang tot Taken en Gebeurtenissen. Zet hem uit.
• Zelfregistratie: uit, tenzij je hem bewust gebruikt.
• Bestandstoegang en zichtbaarheid van leden voor gasten: uit als het portaal er niet op leunt.
• Voor LWR-sites: zet in Experience Builder de optie "Allow guest users to access public APIs" uit. Die staat los van de permissie "API Enabled", dus controleer hem apart.

In ServiceNow:

• Koppel portalen aan zoekbronnen: kijk in de tabellen sp_portal, m2m_sp_portal_search_source en sp_search_source welke bronnen aan een gastportaal hangen.
• Gescripte bronnen: controleer of er een gs.isLoggedIn()-check in zit en of GlideRecordSecure wordt gebruikt in plaats van een gewone GlideRecord-query.
• Kennisbankcriteria: haal "Any User" met lege scopingvelden weg.
• Login verplicht op portalen waar anoniem zoeken geen functie heeft.

Wat je in de logs zoekt

In Salesforce vind je het spoor in Event Monitoring: haal EventLogFile-records op met EventType AuraRequest of Sites en filter op de user agent Go-http-client/1.1 en client-IP 158.220.87.79. In ServiceNow doe je hetzelfde in de tabel syslog_transaction, gefilterd op dat IP-adres en op URL's die beginnen met /api/now/sp/search.

Een harde beperking hoort erbij: zelfs met die logs is achteraf niet vast te stellen welke gegevens precies zijn opgehaald, zegt Bachrach. De enige manier om je blootstelling te bepalen is het portaal zelf anoniem benaderen en kijken wat eruit komt.

Waar dit naartoe wijst

De campagne is niet afgelopen. Reco ziet het volume juist verder oplopen, tegen telecombedrijven, banken, softwareleveranciers en overheidsportalen tegelijk. Toeschrijven doen de onderzoekers niet: het zelfgebouwde gereedschap en het vaste adres passen niet bij het patroon van bekende groepen.

Wat deze zaak verschuift, is waar je moet kijken. Niet naar de patchlijst van je SaaS-leverancier, want er is niets te patchen. Salesforce en ServiceNow doen precies wat er is aangevinkt, en het aanvinken deed jouw organisatie. Zeventien maanden ononderbroken verkeer vanaf één vast IP-adres laat vooral zien hoe lang een verkeerde instelling kan meedraaien voordat iemand hem opmerkt.