City-Forum: hoe een enkele server 17 maanden lang data stal uit Salesforce en ServiceNow zonder een kwetsbaarheid te gebruiken

Al minstens 17 maanden haalt een onbekende dreigingsactor rustig records op uit Salesforce Experience Cloud-sites en ServiceNow Service Portals wereldwijd – zonder een softwarekwetsbaarheid te misbruiken, inloggegevens te stelen of authenticatie te omzeilen. De aanvaller gebruikte simpelweg wat organisaties al openbaar hadden gemaakt via de ingebouwde gastgebruiker (anonieme toegang) van de platforms.

Beveiligingsbedrijf Reco heeft deze lopende campagne City-Forum genoemd, naar het domein city-forum.com dat aan de infrastructuur van de aanvaller is gekoppeld. Sinds ten minste maart 2025 oogst een enkele gehuurde server in Duitsland systematisch gegevens van telecomproviders, banken, financiële dienstverleners, enterprise softwareleveranciers en overheidsportals.

Hoe de exploitatie werkt: geen kwetsbaarheid nodig

Zowel Salesforce als ServiceNow hebben permanente gastgebruikersaccounts voor niet-geauthenticeerde bezoekers. Deze gastgebruikers kunnen niet worden verwijderd. Hun machtigingen – welke records en objecten ze kunnen lezen – worden door elke organisatie zelf ingesteld. Als het gastprofiel leestoegang heeft tot een record, kan iedereen op internet dat record via volledig legitieme API-eindpunten ophalen.

Op Salesforce (Aura-framework):

• De tool stuurt POST-verzoeken naar het /aura- of /s/sfsites/aura-eindpunt.
• Het roept eerst HostConfigController.getConfigData aan om te inventariseren welke objecten (Account, Contact, Case, Lead, User, ContentDocument, enz.) toegankelijk zijn voor de gast.
• Vervolgens gebruikt het SelectableListDataProviderController.getItems om alle records op elk toegankelijk object te doorlopen.
• Het drukste enkele doelwit registreerde meer dan 560.000 gebeurtenissen vanaf het IP van de aanvaller, bijna allemaal Aura-enumeratie door een gast.

Op Salesforce (LWR-framework – Lightning Web Runtime):

• Dit is de eerste waargenomen in-the-wild exploitatie van Salesforce’s UI-API-gastopperlak op LWR-sites.
• De tool richt zich op een GraphQL-eindpunt op

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  , eerst het schema enumererend via EntityDefinition, vervolgens records uitlezend met cursor-gebaseerde paginering.
• Het doorloopt API-versies v56.0 tot en met v66.0 in volgorde tegen elke ontdekte LWR-site.

Op ServiceNow:

• De tool richt zich op het /api/now/sp/search-eindpunt – een native Service Portal-zoek-API die grotendeels ongedocumenteerd is en waarvoor bijna geen online documentatie of open-source tools bestaan.
• Dit eindpunt is standaard openbaar. Welke gegevens het teruggeeft, hangt volledig af van welke zoekbronnen aan een gastgerichte portal zijn gekoppeld en of die bronnen toegangscontroles afdwingen.

Zelfregistratieprobes (Salesforce):

• De tool voegt /SiteRegister en /CommunitiesSelfReg toe aan elk ontdekt experience-site-pad om te testen of zelfregistratie is ingeschakeld. Als dat zo is, kan een gast zichzelf promoveren tot een geverifieerde externe gebruiker en toegang krijgen tot veel meer gegevens.

De aangepaste toolset en infrastructuur

• Bron-IP: 158.220.87.79, gehost op een Contabo VPS (Duitse hostingprovider), verwijzend naar het domein city-forum.com (een in 2002 geregistreerd domein dat verlaten was en vervolgens opnieuw is gebruikt).
• Hetzelfde IP heeft sinds maart 2025 hetzelfde domein gehost zonder rotatie – minstens 17 maanden op één adres.
• Aangepaste Go-binary: Een enkele in Go gecompileerde tool die zowel Salesforce via Aura- en LWR-frameworks als ServiceNow benadert – allemaal vanaf dezelfde server. Dit is een aangepaste, multi-platform toolset, geen standaardtool zoals AuraInspector.
• De tool gebruikt de standaard Go-http-client User-Agent-string, waardoor deze gemakkelijk te herkennen is in logs.

Doelwitten

Reco meldt dat de primaire doelwitten zijn:

• Telecomoperators
• Banken en financiële dienstverleners
• Enterprise softwareleveranciers (waaronder beveiligings- en privacybedrijven)
• Overheidsportals

Waarom standaard auditlogs niet kunnen laten zien welke gegevens zijn buitgemaakt

Voor ServiceNow: De transactielogs (syslog_transaction) van het platform slaan de POST-body van /api/now/sp/search-verzoeken niet op. Beveiligers kunnen zien dat er geautomatiseerde zoekopdrachten zijn uitgevoerd en hoeveel gegevens zijn teruggegeven (via de kolom uitvoerlengte), maar kunnen niet bepalen welke exacte zoektermen of specifieke records zijn opgehaald.

Voor Salesforce: Het gast-enumeratieverkeer bestaat uit legitieme, protocolconforme API-aanroepen die op normale siteverkeer lijken. Hoewel Event Monitoring het volume van AuraRequest- en Sites-gebeurtenissen van gastgebruikers kan tonen, laten de logs zien dat er om gegevens is gevraagd, maar niet de specifieke inhoud van wat er in de GraphQL- of Aura-antwoorden is teruggegeven.

Met andere woorden: u kunt zien dat de aanvaller er was en hoeveel hij heeft opgehaald, maar u kunt niet reconstructen welke records of velden precies zijn geëxtraheerd.

Aanbevolen herstelstappen

Voor Salesforce (aanbevelingen van Reco):

1. Beperk gastdeelregels – dit is de meest effectieve maatregel. Verwijder elke deelregel die records deelt met de gastgebruiker die niet strikt noodzakelijk is voor de publieke functionaliteit van de site.
2. Verwijder object- en veldmachtigingen uit het gastprofiel. Haal leestoegang weg voor objecten die de site niet nodig heeft voor anonieme bezoekers.
3. Verwijder de machtiging "Activiteiten openen" uit het gastprofiel (dit stelt Taken en Gebeurtenissen bloot).
4. Schakel "API ingeschakeld" uit voor de gastgebruiker.
5. Schakel zelfregistratie uit tenzij de site dit echt nodig heeft.
6. Schakel gastbestandstoegang en zichtbaarheid van leden uit, zodat gasten geen ContentDocument-bestanden kunnen ophalen of andere sitemembers kunnen inventariseren.
7. Voor LWR-sites alleen: Ga in Experience Builder naar Workspaces → Beheer → Voorkeuren en schakel "Gastgebruikers toegang geven tot openbare API's" uit. Dit sluit in één keer de GraphQL- en UI-API-REST-eindpunten af.

Voor ServiceNow (aanbevelingen van Reco):

1. Breng gastgerichte portals en hun zoekbronnen in kaart. Controleer de tabellen sp_portal, m2m_sp_portal_search_source en sp_search_source. Ontkoppel zoekbronnen die een openbaar portal niet nodig heeft.
2. Controleer de logica van elke zoekbron – vooral is_scripted_source, data_fetch_script en of deze GlideRecordSecure (ACL-handhavend) gebruikt in plaats van gewone GlideRecord (die geen ACL-handhaving biedt).
3. Controleer de "Mag lezen"-gebruikerscriteria van knowledge bases – let op onbeperkte "Elke gebruiker"-toegang die gevoelige KB's blootstelt via gastzoekopdrachten.
4. Ontkoppel foutieve kb_uc_can_read_mtom-koppelingen in plaats van blindelings deelregels te bewerken.

Detectie:

• Salesforce Event Monitoring: Let op hoge volumes van getItems en getConfigData van

  USER_TYPE = 'Guest'

  , /webruntime/.../vNN.0/graphql-versie-scans en hits op /SiteRegister en /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Let op /api/now/sp/search-verzoeken die als gast worden gedaan. Sorteer op uitvoerlengte – rijen die aanzienlijk meer teruggeven dan de kleine, lege baseline duiden op zoekopdrachten die inhoud hebben teruggegeven.