Los ataques City-Forum representan una campaña centrada en el abuso de superficies de acceso sin autenticar en dos plataformas empresariales muy usadas: Salesforce y ServiceNow. Según los investigadores, el objetivo no es “romper” la infraestructura, sino aprovechar configuraciones y endpoints disponibles para lograr reconocimiento, extracción de contenido y rastreo de permisos.
La campaña, denominada City-Forum, se dirige tanto a implementaciones basadas en Aura como a las versiones más nuevas con LWR, y además incorpora componentes que afectan a ServiceNow. Lo interesante es que todo el flujo parece ejecutarse desde un mismo origen y con un toolset multi-plataforma personalizado, en lugar de herramientas ya conocidas y disponibles públicamente.
Qué es la campaña City-Forum
Los investigadores describen una actividad sofisticada y relativamente innovadora, porque se apoya en un conjunto de herramientas hecho a medida que puede operar sobre más de una tecnología. En este caso, la campaña observa y explota superficies en Salesforce y en ServiceNow, afectando organizaciones de distintos sectores.
Los sectores más mencionados como probables objetivos incluyen telecomunicaciones, banca y servicios financieros, proveedores de software empresarial (incluidas organizaciones de seguridad y privacidad de datos) y portales del sector público.
Cómo atacan Salesforce: acceso de usuario invitado
En Salesforce, el punto de apoyo principal identificado por los investigadores es el Guest User, es decir, el usuario invitado que habilita acceso para visitas no autenticadas en Experience Cloud. La explicación clave es que cada Experience Cloud puede contar con su propio usuario invitado, lo que crea múltiples “puertas” potenciales.
Un aspecto crítico del riesgo es que estos usuarios invitado no se eliminan fácilmente: incluso si se exige iniciar sesión, la configuración del perfil, los permisos, las reglas de compartición y el código que corre en ese contexto pueden seguir existiendo. En términos prácticos, si el invitado puede leer registros, cualquier persona en Internet podría alcanzar esa información, según los permisos configurados.
Entrada en Aura y LWR con un mismo flujo
Los ataques City-Forum contemplan tanto Salesforce Aura como implementaciones LWR (Lightning Web Runtime). De acuerdo con el análisis, se observó una explotación “en el mundo real” relacionada con una superficie de UI-API orientada a invitado.
Además, los investigadores señalan que el ataque sobre Aura y el ataque sobre LWR se integran en un único toolset. Esto significa que un mismo componente puede alternar entre tecnologías, reduciendo la fragmentación operativa del atacante.
También se indica que el comportamiento observado es coherente con un conjunto de herramientas propio, no con algo “listo para usar” como AuraInspector. La idea detrás de este punto es que la campaña busca adaptarse a cómo se expone el contenido en cada implementación.
Cómo atacan ServiceNow: búsqueda con poca documentación
En paralelo, la campaña se apoya en ServiceNow mediante la explotación de un endpoint de búsqueda del Service Portal. Los investigadores destacan que este endpoint tiene poca documentación pública y no es tan conocido, lo que puede dificultar la identificación temprana.
La lógica de ataque se apoya en detectar contenido a través de las respuestas del endpoint. Por ejemplo, se menciona que la columna “Output length” resulta útil: cuando el valor es notablemente mayor que el “basal” esperado para resultados vacíos, suele indicar que la búsqueda devolvió contenido real.
Con esa señal, el atacante puede priorizar los resultados más probables para extraer información con mayor eficacia.
La campaña usa un solo equipo y una huella estable
Otro elemento que llama la atención en los ataques City-Forum es la aparente utilización de una única máquina. En el análisis se menciona una dirección IP específica (158.220.87.79) y que el mismo dominio asociado se mantuvo durante un periodo prolongado.
Según la información recopilada, esa IP continuó escaneando durante al menos diecisiete meses sin rotación. Desde el punto de vista defensivo, una huella constante puede facilitar el bloqueo si se conoce, pero también puede reducir la “presencia” que generan cambios frecuentes en los sistemas de monitoreo. En otras palabras: la estabilidad del origen puede ayudar a mantener el patrón menos ruidoso para algunos mecanismos de detección.
No hay evidencia de brecha… pero sí extracción
Los investigadores subrayan que, hasta donde llega lo observado, no se sugiere una intrusión directa que comprometa la plataforma. De hecho, cada byte obtenido habría sido contenido que los propietarios de los sitios ya habían expuesto a usuarios anónimos.
Esto marca una diferencia importante: no estaríamos ante un “hack” típico de una vulnerabilidad que toma control del sistema central, sino ante un aprovechamiento del acceso ya publicado, especialmente el que se ofrece a usuarios invitado y visitantes sin autenticación.
Actividad a gran escala en Aura y uso de GraphQL
Los datos recogidos indican que el componente de Aura fue particularmente activo. En el análisis se menciona que el objetivo más ocupado llegó a registrar más de 560.000 eventos en la ventana de la campaña, y que la mayor parte de esa actividad correspondía a enumeración de Aura en el contexto de usuario invitado.
Además, se reporta extracción de información desde sitios LWR utilizando GraphQL. Esto sugiere que la campaña no se limita a páginas estáticas, sino que aprovecha mecanismos de consulta para obtener datos de manera más estructurada.
Conversión a usuario autenticado: posible en Salesforce, no en ServiceNow
Un detalle operativo relevante es que los ataques City-Forum apuntan a acceso de invitado sin autenticar, pero en Salesforce podría existir la posibilidad de “convertir” el acceso hacia un usuario autenticado si la organización tiene habilitado el autoservicio de registro.
En ServiceNow, en cambio, los investigadores indican que no existe un mecanismo equivalente que permita ese tipo de escalado desde una condición similar. Por eso, el riesgo principal en ServiceNow recae sobre la exposición del endpoint y la información accesible a través de la búsqueda del portal.
Qué hacer para reducir el riesgo
Si tu organización utiliza Experience Cloud en Salesforce o portales en ServiceNow, los hallazgos apuntan a una prioridad clara: revisar la configuración de acceso de invitados y limitar lo que puede leerse sin autenticar.
Como medida inmediata, se recomienda evitar que se permita el registro por autoservicio, ya que esto podría dificultar un intento de pasar de invitado a un perfil más privilegiado. En el mismo espíritu, es importante comprobar permisos, reglas de compartición y cualquier código que se ejecute en el contexto del usuario invitado.
También conviene monitorear patrones de enumeración en Aura y actividad de consultas relacionadas con GraphQL en los entornos LWR. En ServiceNow, presta atención a usos anómalos del endpoint de búsqueda del Service Portal, especialmente cuando se detecten respuestas con longitudes de salida consistentemente superiores al comportamiento normal.
Comparación con campañas anteriores
Para entender el salto de sofisticación, los investigadores comparan City-Forum con ataques anteriores dirigidos a Salesforce Aura. Se menciona el trabajo de ShinyHunters, que en marzo de 2026 habría revelado una campaña enfocada en Aura (sin evidencia conocida de apuntar a ServiceNow) y que utilizó una variante modificada de AuraInspector.
En cambio, City-Forum se describe como un toolset multi-plataforma nuevo y personalizado. Aunque no se descarta que actores detrás de campañas anteriores puedan estar relacionados, los investigadores enfatizan que no existe confirmación de atribución.
Conclusión: protege el acceso de invitados
Los ataques City-Forum muestran cómo una campaña puede ser efectiva sin necesidad de “romper” Salesforce o ServiceNow. Al centrarse en el acceso de usuario invitado y en endpoints de búsqueda poco documentados, el atacante aprovecha configuraciones que permiten leer contenido sin autenticar.
La defensa, por tanto, no se limita a parches: requiere higiene de permisos, revisión de exposición en portales y observabilidad para detectar patrones de enumeración y extracción. Si haces estos ajustes a tiempo, reduces significativamente el impacto de este tipo de campañas basadas en accesos ya publicados.
