Une nouvelle campagne baptisée City-Forum attire l’attention des spécialistes de la sécurité. D’après les chercheurs, elle vise à la fois Salesforce et ServiceNow en s’appuyant sur un outil multi-plateforme sur mesure. L’objectif principal : exploiter des surfaces exposées à des utilisateurs non authentifiés, notamment via les guest users.
Ce qui rend les attaques City-Forum particulièrement intéressantes, c’est leur combinaison : une approche pensée pour plusieurs environnements, une exécution à partir d’une même machine, et un niveau de discrétion qui complique la détection. Dans cet article, on détaille les observations clés et les pistes de remédiation évoquées par les chercheurs.
Une campagne nommée City-Forum, centrée sur l’accès “guest”
Les chercheurs suivent une campagne sophistiquée, décrite comme innovante, et orientée vers des cibles variées. Parmi les secteurs visés figurent notamment les télécommunications, les banques et les services financiers, mais aussi des éditeurs de logiciels d’entreprise (incluant des acteurs sécurité et confidentialité) ainsi que des portails du secteur public.
Au cœur de la logique de l’attaque, il y a une réalité opérationnelle : sur les deux plateformes, l’accès via l’utilisateur invité est souvent présent par défaut dans l’expérience de portail.
Salesforce : chaque Experience Cloud possède un Guest User
Dans Salesforce, chaque Experience Cloud dispose de son propre Guest User. Les chercheurs précisent qu’une requête non authentifiée peut fonctionner dans ce contexte. Même si l’on tente de “rendre l’accès” plus contraignant via la connexion, les comptes invités restent en place, y compris leur profil, leurs autorisations, leurs règles de partage et du code susceptible d’être exécuté dans ce contexte.
Autrement dit : si le guest peut lire un enregistrement, alors l’attaque peut s’appuyer sur cette capacité depuis l’Internet public. C’est précisément le mécanisme que la campagne cherche à exploiter.
ServiceNow : un modèle similaire côté portail et accès non authentifié
ServiceNow présente un schéma comparable pour les accès de portail. Les chercheurs notent qu’on ne peut pas supprimer ces utilisateurs invités, et que l’exigence de connexion ne supprime pas pour autant leur existence ni leurs capacités. Le résultat est le même : si l’utilisateur invité a des droits de lecture, un acteur externe peut potentiellement en tirer parti.
Salesforce Aura et LWR : exploitation coordonnée sur plusieurs surfaces
Les attaques City-Forum ne se limitent pas à une seule génération de composants côté Salesforce. Les chercheurs estiment que la campagne vise à la fois Salesforce Aura et les implémentations plus récentes basées sur LWR (selon leur description, la campagne représente la première exploitation observée en conditions réelles “dans la nature” de la surface UI-API guest).
Un point important : les attaques sur Aura sont considérées comme intégrées à l’ensemble visant LWR, via un outil unique. Cela permet d’expliquer pourquoi les chercheurs observent une stratégie cohérente, plutôt qu’une simple addition de scripts isolés.
Un binaire et une exécution depuis la même source
Les chercheurs mentionnent qu’un même binaire (un exécutable “Go”) est capable de frapper Salesforce sur Aura et LWR, puis de viser ServiceNow “depuis la même boîte”. Le libellé exact insiste sur le fait qu’il s’agit d’une logique sur mesure, et non d’un outil “prêt à l’emploi” du type AuraInspector.
Ce choix d’architecture se reflète aussi dans l’infrastructure : la campagne repose sur une seule machine.
Un seul hôte, une discrétion accrue, moins de rotation
Un autre signal observé par les chercheurs concerne la continuité de l’activité. Le même adresse IP porterait le même domaine depuis mars 2025 et continuerait de scanner, au moins jusqu’à la période de l’observation. Les chercheurs évoquent une présence sur un intervalle d’environ dix-sept mois sur la même adresse, sans rotation.
Ils indiquent aussi que cette IP (158.220.87.79) pointe vers city-forum.com. Les chercheurs précisent ne pas tirer de conclusion directe à partir de ce seul fait, mais soulignent un avantage potentiel : réduire le “footprint” de l’attaquant face aux systèmes de détection d’anomalies.
En clair, bloquer une adresse connue peut sembler plus simple, mais la détection devient plus difficile si l’activité est planifiée pour paraître moins “bruyante” et moins variable.
Comparaison avec d’autres attaques : de Aura à un outil multi-plateforme
Pour mesurer l’innovation, les chercheurs mettent en parallèle City-Forum avec d’autres attaques visant Salesforce Aura, en particulier une campagne divulgée par ShinyHunters au mois de mars 2026 (selon les informations rapportées).
D’après leur comparaison, ShinyHunters aurait ciblé uniquement Aura dans Salesforce et ne viserait pas ServiceNow. L’outil utilisé serait une version modifiée d’un outil existant, AuraInspector.
À l’inverse, les attaques City-Forum se distinguent par un nouvel outil multi-plateforme, et par l’intégration d’un volet ServiceNow qui exploite un endpoint de recherche côté Service Portal disposant de peu de documentation en ligne et de peu d’outils open source connus.
Le point d’appui côté Salesforce : enu mération via GraphQL et UI-API
Les chercheurs indiquent que les Guest Users constituent la base de l’accès, et que la campagne se traduit par une collecte d’informations et une exfiltration à partir de ce qui est accessible sans authentification.
Du côté Aura, les chercheurs observent un volume d’événements élevé. Ils citent qu’une cible très active aurait généré plus de 560 000 événements au cours de la fenêtre d’observation, essentiellement concentrés sur de l’énumération autour d’Aura via le contexte guest.
Pour LWR, les chercheurs mentionnent une extraction via GraphQL. Là encore, le mécanisme repose sur le fait que certains contenus peuvent être accessibles depuis l’Internet public si les paramètres de permissions côté guest sont trop permissifs.
ServiceNow : exploitation d’un endpoint de recherche peu documenté
Le volet ServiceNow des attaques City-Forum exploite un endpoint de recherche d’un portail. Les chercheurs soulignent que cet élément est “effectivement peu documenté”, ce qui le rend moins évident à anticiper par rapport à des interfaces plus connues.
L’objectif semble être la détection de contenu : les requêtes renverraient des résultats dont la “valeur” devient visible en comparant des lignes présentant un volume ou une longueur de sortie supérieure à la base de référence, censée correspondre à des réponses vides.
Autrement dit, l’attaquant peut apprendre quelles requêtes donnent des informations plus riches, puis orienter ses récupérations en conséquence.
Exfiltration : pas “bruyante”, plutôt conforme aux protocoles
Un point notable des attaques City-Forum concerne le profil d’exfiltration. Les chercheurs indiquent que cette activité n’est pas bruyante au sens “explosif”. Elle génère un volume élevé, mais reste légitime au niveau du protocole.
Cette combinaison rend la détection plus complexe. En particulier, l’usage d’une adresse de destination constante pourrait contribuer à cette apparente normalité.
Aucune preuve de compromission de la plateforme
Les chercheurs précisent qu’il n’y a pas d’indication suggérant une violation profonde des plateformes Salesforce ou ServiceNow. Leur lecture est que chaque octet récupéré correspond à des éléments déjà exposés par les propriétaires de sites, accessibles aux utilisateurs anonymes (au travers du contexte guest).
Cela renforce une idée centrale : la campagne ne “casse” pas nécessairement la plateforme, elle exploite des configurations et des surfaces d’accès qui permettent la consultation sans authentification.
Ce que les organisations peuvent faire en priorité
Être ciblé par les attaques City-Forum n’implique pas automatiquement une compromission. En revanche, la campagne montre que “l’invisible” peut rester à la portée de systèmes ouverts.
Les chercheurs recommandent au minimum d’agir rapidement sur les paramètres d’accès. L’un des conseils donnés consiste à s’assurer que la auto-inscription n’est pas activée. Cela pourrait freiner une tentative où un utilisateur guest non authentifié chercherait à évoluer vers un statut authentifié dans Salesforce.
Ils ajoutent qu’ils n’ont observé, pour l’instant, que des actions depuis le compte guest. Ils ne peuvent toutefois pas exclure qu’une conversion ou des scénarios plus avancés existent ailleurs dans la campagne.
Enfin, comme la campagne s’appuie sur des permissions guest potentiellement mal configurées, la démarche la plus efficace consiste à revoir concrètement ce que chaque portail autorise : permissions de lecture, règles de partage, scripts exécutés dans le contexte guest, et étendue réelle des données accessibles depuis l’Internet public.
Conclusion
Les attaques City-Forum illustrent une approche méthodique : un outil multi-plateforme, une exécution depuis une source unique, et un ciblage du contexte Guest User sur Salesforce (Aura et LWR) et ServiceNow (recherche via Service Portal). Plutôt que de provoquer un incident spectaculaire, la campagne exploite des surfaces accessibles et mène une collecte qui peut ressembler à une activité “propre” au niveau des requêtes.
La meilleure défense reste donc pragmatique : réduire l’exposition des accès non authentifiés, vérifier les permissions des utilisateurs invités, et limiter les voies qui pourraient transformer un accès guest en accès plus sensible.
