Depuis plus d’un an, une activité soutenue baptisée City Forum campaign a été observée sur des portails clients de plusieurs secteurs. Selon une enquête publiée par la plateforme de sécurité d’agents Reco, une même infrastructure a exfiltré des données depuis des environnements Salesforce et ServiceNow, en s’appuyant sur un point commun : l’accès accordé à un utilisateur invité.
Ce qui rend cette campagne particulièrement préoccupante, c’est son étendue d’attaque. Elle ne se limite pas à une seule “surface” technique connue pour les abus d’accès invité : elle touche plusieurs mécanismes de récupération de données, y compris des couches plus récentes côté Salesforce et un point d’entrée de recherche côté ServiceNow.
Une infrastructure unique, identifiée par un même “empreinte” réseau
Reco relie les observations à un serveur précis : 158.220.87.79, hébergé sur un VPS chez le fournisseur allemand Contabo. Les chercheurs indiquent que l’adresse IP n’a pas changé depuis le début de la période analysée, et qu’un historique en passive DNS montre que des domaines associés pointaient vers cette même destination dès mars 2025.
Sur le plan opérationnel, chaque requête présente une signature constante : l’agent utilisateur par défaut de la bibliothèque Go net/http. Autrement dit, les échanges semblent provenir d’un outil compilé, conçu pour automatiser la collecte, plutôt que d’un trafic de navigateur humain.
Des cibles variées, mais un modèle d’accès commun
Les industries touchées sont larges. Reco mentionne notamment des télécoms, des banques et d’autres acteurs des services financiers, ainsi que des éditeurs d’entreprise (dont des sociétés liées à la sécurité et à la protection des données) et des portails du secteur public. Les organisations individuelles n’ont pas été nommées dans le rapport.
Ce qui structure la City Forum campaign, au-delà de l’IP et des signatures, tient à un mécanisme : un compte invité persistant qui exécute des actions pour des visiteurs non authentifiés. Reco explique que sur Salesforce Experience Cloud et sur les portails ServiceNow, ce compte invité ne peut pas être supprimé, seulement restreint. Si ce profil invité a la capacité de lire un enregistrement, ce contenu devient pratiquement accessible, même si l’interface n’affiche pas explicitement tout sans connexion.
Salesforce : du cadre Aura aux API Lightning Web Runtime
La plupart des abus d’accès invité observés historiquement sur Salesforce ciblaient souvent le cadre Aura. Reco indique que cette voie reste majoritaire dans le volume observé : l’entreprise a recensé un cas où une cible a loggé plus de 560 000 événements depuis la même source.
Dans ce schéma classique, l’attaquant envoie de nombreuses requêtes “invité” afin d’énumérer des objets, puis de parcourir les enregistrements. Toutefois, la City Forum campaign se distingue par une seconde couche d’exploitation.
En plus des requêtes Aura, le même serveur interagit avec des sites Salesforce reposant sur le Lightning Web Runtime. Le rapport souligne que l’attaquant passe par une couche de données appelée UI-API (côté Salesforce), en parcourant des versions d’API consécutives, de v56.0 à v66.0. Cette approche est décrite comme plus inhabituelle, faute de détails publics et d’outils de scan largement documentés pour ce type de chemin d’exécution.
ServiceNow : recherche via l’endpoint du Service Portal
La campagne ne s’arrête pas à Salesforce. Reco mentionne également un bombardement d’un point d’entrée précis sur ServiceNow : POST /api/now/sp/search. Le rapport indique que cet endpoint ne dispose pas, en apparence, d’une documentation publique abondante.
Dans la pratique, cela signifie que l’attaquant combine différentes méthodes de récupération : énumération et pagination côté Salesforce, puis recherche côté ServiceNow en s’appuyant sur un comportement attendu par la plateforme, tant que les critères d’accès renvoient des résultats à l’utilisateur invité.
Ce qui “explique” l’abus : le profil invité trop permissif
Les techniques décrites par Reco convergent vers un même défaut de configuration. Les portails Salesforce et ServiceNow exposent, de manière permanente, une identité invitée utilisée par les visiteurs non authentifiés. Si cette identité a des droits de lecture sur des ressources, alors les informations correspondantes peuvent être récupérées par des appels automatisés, y compris via des API ou des endpoints prévus pour des scénarios légitimes.
En clair : la mécanique d’accès est correcte “au sens du produit”, mais l’attribution de permissions ne correspond pas au niveau de contenu que l’organisation souhaitait rendre public.
Détection : actions concrètes pour les équipes sécurité et IT
Bonnes pratiques côté Salesforce
Reco propose des pistes de contrôle adaptées à Salesforce. Les équipes disposant d’outils de supervision comme Event Monitoring ou Shield peuvent :
- Récupérer des événements liés aux logs AuraRequest et aux journaux de Sites.
- Rechercher des corrélations avec le User-Agent Go-http-client et l’IP identifiée.
- Examiner les paths contenant /webruntime/api/services/data.
- Observer des pics d’essais de self-registration sur /SiteRegister et /CommunitiesSelfReg.
L’idée n’est pas uniquement de “bloquer une IP”, mais de repérer des schémas de requêtes cohérents avec une collecte automatisée.
Bonnes pratiques côté ServiceNow
Côté ServiceNow, le rapport recommande d’exploiter la table de logs syslog_transaction. Les défenseurs peuvent filtrer :
- Par source IP.
- Par URLs commençant par /api/now/sp/search.
- Par présence de lignes indiquant la création d’un guest et par des caractéristiques de sortie anormales, notamment un volume ou une longueur de réponse inhabituelle.
Reco présente ces signaux comme les plus efficaces pour repérer un balayage actif.
Remédiation : resserrer l’accès invité plutôt que “casser” l’API
Le cœur du correctif, d’après Reco, consiste à réduire les permissions accordées au profil invité. L’enquête insiste sur le fait que les endpoints utilisés fonctionnent comme prévu : c’est la combinaison “identité invitée + droits de lecture” qui rend l’exploitation fructueuse.
Réduction des droits sur Salesforce
Les actions proposées incluent :
- Revoir les règles de partage appliquées à l’utilisateur invité.
- Retirer les accès inutiles au niveau objets et champs dans le profil invité.
- Désactiver la self registration quand elle n’est pas requise.
- Couper le paramètre Experience Builder permettant aux invités d’atteindre des API publiques.
Ajustement de la logique côté ServiceNow
Pour ServiceNow, Reco recommande d’identifier quelles sources de recherche sont exposées depuis des portails orientés grand public, puis de contrôler les règles relatives au Knowledge Base : en particulier les critères qui déterminent quels résultats sont renvoyés à un appelant anonyme.
Une activité toujours en cours
Reco indique que l’infrastructure utilisée par la City Forum campaign reste active et que le volume d’activité augmente. À ce stade, l’entreprise n’attribue pas l’opération à un groupe connu et nommé.
Pour les organisations, le point crucial n’est donc pas seulement “d’éradiquer un acteur”, mais de traiter la racine technique : l’écart entre ce qui est censé être public et ce que le profil invité peut réellement lire via l’API ou la recherche.
Pourquoi cette histoire pèse sur la planification sécurité
Au-delà du cas d’école, la City Forum campaign illustre la réalité de nombreux projets : les budgets sécurité sont limités, et les priorités se concurrencent. Reco renvoie à un cadre de planification pour aider les équipes dirigeantes à arbitrer, notamment via l’évaluation des fournisseurs et la construction d’un dossier crédible pour le conseil d’administration.
Dans la pratique, l’enjeu est double : surveiller l’exposition applicative (interfaces, API, endpoints) et vérifier que les droits “publics” (invités) sont réellement alignés avec le niveau de contenu que vous souhaitez rendre accessible.
Conclusion : ciblez le profil invité
La City Forum campaign montre comment une infrastructure unique peut, en s’appuyant sur un compte invité trop permissif, extraire des informations depuis des portails Salesforce et ServiceNow. La variété des surfaces atteintes—Aura, UI-API côté Lightning Web Runtime, et endpoint de recherche Service Portal—renforce l’idée que la défense doit être globale.
La stratégie la plus efficace, telle que décrite par Reco, consiste à resserrer l’accès du profil invité, renforcer les contrôles de détection sur les logs pertinents, puis adapter les critères de ce qui peut être renvoyé à des utilisateurs non authentifiés.
Source: https://thehackernews.com/2026/08/one-attacker-has-scraped-both.html
