Zum Inhalt springen
Beveiligingsnieuws

Scraping über Salesforce & ServiceNow: City Forum

City Forum scraping

Wenn Kundendaten in Portalen nur scheinbar „öffentlich“ sind, entsteht oft eine gefährliche Grauzone. Genau dort setzt die City Forum Kampagne an: Über mehr als ein Jahr hat ein einzelner Angreifer, bzw. eine klar erkennbare Infrastruktur, wiederholt Datensätze aus Salesforce– und ServiceNow-Kundenschnittstellen gezogen. Laut aktueller Forschung geschieht das nicht durch klassische Browser-Interaktion, sondern über ein gezielt gebautes Tool, das Anfragen in gleichbleibender Signatur versendet.

Die Studie zeigt außerdem, warum dieser Vorfall für viele Organisationen besonders relevant ist: Die Aktivität deckt unterschiedliche Angriffsflächen ab, inklusive älterer Salesforce-Mechanismen und moderner UI-Datenpfade. Gleichzeitig werden auch ServiceNow-Endpunkte angesprochen, für die kaum öffentlich dokumentierte Scan-Workflows existieren. Für Security- und IT-Teams heißt das vor allem eines: Sie müssen nicht nur einzelne Endpunkte härten, sondern den Zugriff von Gastidentitäten konsequent begrenzen.

Ein Server, lange Laufzeit und wiederkehrende Spuren

Die City Forum Kampagne lässt sich auf eine zentrale Infrastruktur zurückführen: Ein Server mit der IP-Adresse 158.220.87.79, gehostet auf einem preisgünstigen Virtual Private Server (VPS) bei Contabo. Dieses System wurde in den beobachteten Zeiträumen nicht verlagert, und jeder Request trägt eine konsistente Fingerprint-Signatur.

Forschende ordnen die Technik dabei einem Programm zu, das typischerweise nicht aus einem normalen Webbrowser heraus agiert. Als Indiz dient der konstante User-Agent, der dem Standard von Go net/http entspricht. Damit ist weniger „menschliches Surfen“ erkennbar, sondern eher ein automatisierter Scraper, der gezielt Inhalte abruft und durch wiederholte Muster Einträge ausliest.

Welche Portale betroffen sind und welche Branchen das trifft

Die bisherigen Erkenntnisse deuten auf eine breite Streuung der Ziele hin. Laut Analyse wurden unter anderem Telekommunikationsunternehmen, Banken sowie weitere Finanzdienstleister identifiziert. Auch Enterprise-Software-Anbieter, darunter Sicherheits- und Datenschutzunternehmen, sowie öffentliche Sektoren mit Portaloberflächen gehören zu den erfassten Zielkategorien.

Wichtig: Die Forschung nennt keine konkreten Organisationen namentlich. Für Betroffene bedeutet das dennoch: Gerade wenn Sie Salesforce Experience Cloud oder ServiceNow Portale betreiben, sollten Sie die beschriebenen Muster als potenzielles Risiko-Template behandeln.

Warum die City Forum Kampagne auffällt

In der Vergangenheit gab es wiederholt Berichte über Gastzugriffs-Fehlverwendungen bei Salesforce. Häufig betraf das Ausnutzung älterer Frameworks, bei denen Angreifer über viele Anfragen Objekte enumerieren und Seiten durchlaufen, um Datensätze zu „durchforsten“. Die City Forum Kampagne folgt zwar teilweise diesem klassischen Muster, geht aber deutlich weiter.

Ein Großteil des Verkehrs betrifft weiterhin Salesforce-Mechanismen, bei denen die älteren Request-Arten dominieren. In einem Beispiel dokumentierte ein Zielprotokoll über 560.000 Ereignisse mit derselben Quell-IP. Doch zusätzlich nutzt das Tool auch neuere Wege, um auf Daten über die UI-Logik zuzugreifen.

Salesforce: Aura und zusätzlich Lightning Web Runtime

Die Forschenden beobachten zwei große Bereiche. Erstens bleibt Aura ein zentraler Anteil der Requests. Zweitens greift die Infrastruktur auch Lightning Web Runtime-basierte Seiten an und nutzt dafür eine Datenebene, die über UI-API-Schichten erreichbar ist.

Dabei werden API-Versionen in einer Folge von v56.0 bis v66.0 durchlaufen. Das wirkt wie eine systematische Annäherung, bei der der Scraper prüft, welche Versionen in der Praxis Daten liefern oder welche Response-Strukturen stabil funktionieren.

ServiceNow: Service-Portal-Suche per POST

Zusätzlich feuert derselbe Server auch einen nativen ServiceNow Service Portal Such-Endpunkt an: POST /api/now/sp/search. Gerade dieser Pfad ist in der Praxis relevant, weil es zu ihm kaum öffentlich bekannte Scans gibt, anhand derer man Angriffe leicht „wiedererkennt“. Der Scraper sendet dabei nahezu ohne öffentlich greifbare Dokumentationsspuren Informationen aus, die dennoch intern verwertbar sind.

Der Kern der Schwachstelle: Gastidentität mit zu viel Leserecht

Der wichtigste gemeinsame Nenner der beobachteten Techniken ist weniger ein „Spezialhintertür“-Gedanke, sondern ein Berechtigungs-Designproblem: Eine Gastidentität erhält Zugriff, der für die echte öffentliche Nutzung nicht nötig ist.

Sowohl Salesforce Experience Cloud-Sites als auch ServiceNow-Portale verwenden eine persistente Guest-Identität. Unauthentifizierte Besucher führen Aktionen und Sichtzugriffe über diese Identität aus. Entscheidend ist: Diese Rolle kann laut Forschung nicht gelöscht werden, sondern nur eingeschränkt. Wenn das Gastprofil jedoch ein bestimmtes Objekt oder einen Datensatz lesen kann, dann ist dieser Datensatz faktisch „öffentlich“, selbst wenn eine Browseransicht Login fordert.

Erkennen: Konkrete Hinweise für Monitoring-Teams

Damit aus der Erkenntnis keine bloße Theorie wird, beschreibt die Forschung auch konkrete Schritte, wie Security- und IT-Teams die City Forum Kampagne wahrscheinlicher einordnen und stoppen können.

Salesforce: Event Monitoring oder Shield auswerten

Auf Salesforce-Seite empfiehlt die Studie, Events aus Event Monitoring oder Shield zu ziehen. Dabei sollen vor allem folgende Aspekte helfen, um die relevanten Muster zu finden:

  • Log-Ereignisse zu AuraRequest und zu Sites
  • Der Go-http-client-User-Agent als Erkennungsmerkmal
  • Die feststehende Quell-IP 158.220.87.79
  • Request-Pfade, die auf den UI-API-Bereich mit /webruntime/api/services/data verweisen
  • Spitzen bei Self-Registrierung über /SiteRegister und /CommunitiesSelfReg

Gerade die Kombination aus Signatur (User-Agent) und Pfadmuster liefert in der Praxis häufig die schnellste „Trefferquote“, statt nur allgemein „ungewöhnlichen Traffic“ zu sehen.

ServiceNow: Transaktionslog und Suche-URL filtern

Bei ServiceNow wird als hilfreiche Datenquelle die syslog_transaction-Tabelle genannt. Die Empfehlung lautet, die Suche im Log auf zwei Kriterien zu begrenzen:

  • Filtern nach Source-IP der verdächtigen Anfragen
  • Filtern nach URLs, die mit /api/now/sp/search beginnen

Als besonders eindeutiges Signal beschreibt die Forschung dabei Zeilen, in denen Gast-erstellte Einträge auftauchen und die Ausgabe-Längen ungewöhnlich wirken. Damit lässt sich ein laufender Sweep auch dann identifizieren, wenn einzelne Requests allein nicht sofort auffällig wären.

Stoppen: Remediation setzt bei Gastzugriff an

Die Forschung legt nahe, dass der eigentliche „Fix“ nicht primär in der Blockade von Endpunkten liegt, sondern in der Berechtigungskonfiguration der Gastrolle. Der Hintergrund: UI-API bzw. die ServiceNow Service-Portal-Suche arbeiten aus Sicht der Plattform „wie vorgesehen“. Problematisch wird es, wenn die Gastrolle Inhalte liefern kann, die eigentlich nicht öffentlich sein sollten.

Salesforce: Sharing-Regeln und öffentliche API-Erreichbarkeit prüfen

Für Salesforce bedeutet das laut Studie:

  • Überprüfen, welche Guest Sharing Rules aktiv sind
  • Unnötige Object- und Field-level Access aus dem Gastprofil entfernen
  • Self Registration deaktivieren, sofern diese Funktion nicht zwingend benötigt wird
  • Eine Experience-Builder-Option ausschalten, die Gastbenutzern öffentliche APIs erreichbar macht

Diese Punkte zielen nicht nur auf einzelne Angriffsversuche, sondern auf das Grundprinzip: Gastzugriff muss exakt auf öffentliche Nutzung zugeschnitten sein.

ServiceNow: Welche Suchquellen sind für Portale freigegeben?

Auch bei ServiceNow setzt die Abhilfe am Berechnungsmodell an: Die Studie empfiehlt, den Suchzugriff nachzuvollziehen und zu prüfen, welche Suchquellen in public facing portals überhaupt exponiert werden. Zusätzlich wird das Kriterium hervorgehoben, das entscheidet, was ein anonymer Aufruf innerhalb der Knowledge Base zurückbekommt.

Praktisch heißt das: Wenn anonyme Suche mehr Ergebnisse liefert als für den öffentlichen Portalbetrieb gedacht, sollte genau dieser Rückgabemechanismus restriktiver werden.

Was Unternehmen jetzt priorisieren sollten

Die Forschenden betonen, dass die zugrunde liegende Infrastruktur weiterhin aktiv ist und die Menge der Anfragen steigt. Gleichzeitig wurde die Aktivität bislang nicht einer namentlich bekannten Gruppe zugeordnet. Für die Verteidigung ist das aber zweitrangig: Entscheidend ist, ob Ihre Portale die beobachteten Angriffsflächen unterstützen und ob Gastrollen zu viel lesen können.

Als Startpunkte bietet sich an, die Logging-Umgebung schnell auf die beschriebenen Signaturen auszurichten, dann die Gastprofile sauber zu auditieren und zuletzt die Self-Registration sowie die öffentliche Erreichbarkeit von APIs im Experience-Builder kritisch zu prüfen.

Fazit: City Forum Kampagne zeigt, wie schnell „public“ wird

Die City Forum Kampagne zeigt in eindrucksvoller Breite, wie ein automatisierter Scraper über einen festen Server Daten aus Salesforce- und ServiceNow-Portalen ziehen kann. Über verschiedene Oberflächen hinweg nutzt der Angreifer dasselbe Grundproblem: Eine Gastidentität hat mehr Leserechte als für den öffentlichen Betrieb erforderlich.

Mit gezieltem Monitoring (User-Agent, IP, Request-Pfade) und einer konsequenten Begrenzung der Guest-Berechtigungen lässt sich dieses Risiko deutlich reduzieren. Wer Portale betreibt, sollte diese Muster daher nicht nur als „Einzelfall“ betrachten, sondern als klaren Hinweis auf systematische App-Exposition in Berechtigungsmodellen.

Quelle: https://thehackernews.com/2026/08/one-attacker-has-scraped-both.html