City-Forum: 17 meses extrayendo datos de portales de Salesforce y ServiceNow sin tocar una sola credencial
La historia que empieza donde todo funciona como debería
La mayoría de las historias de seguridad empiezan con algo roto. Esta empieza con todo funcionando exactamente como fue diseñado. Investigadores de Reco han seguido durante meses una campaña que han bautizado como City-Forum, bautizada así por un dominio registrado en 2002, abandonado durante décadas y que hoy apunta a un servidor alquilado en un proveedor de hosting alemán. Desde ese servidor, un operador lleva al menos diecisiete meses extrayendo registros de portales de clientes de Salesforce y ServiceNow en todo el mundo.
El caso lo publicó Help Net Security el 12 de agosto de 2026 y lo cubrió también Travis Stein en LinkedIn con un análisis complementario. Para cualquier equipo DevSecOps que opera plataformas SaaS con portales de clientes, este caso no es un incidente técnico tradicional. Es una lección sobre cómo las decisiones de configuración se convierten en fugas masivas de datos silenciosas, persistentes y prácticamente indetectables mediante los controles de seguridad convencionales.
La campaña es operativa hoy. No es histórica. El servidor sigue activo. El operador sigue extrayendo datos. Y el problema de configuración que lo permite sigue presente en miles de organizaciones en producción.
Anatomía técnica de City-Forum
City-Forum no explota ninguna vulnerabilidad. Esa es la parte incómoda. El operador usa tres ingredientes que están disponibles para cualquier atacante con paciencia: una IP persistente, un cliente HTTP personalizado y permisos de invitado que son más generosos de lo que nadie pretendía.
La infraestructura se reduce a una sola dirección IP: 158.220.87.79, alojada en un VPS commodity del proveedor alemán Contabo. Lo que distingue a City-Forum de campañas similares es que el operador ha mantenido esa dirección durante todo el período de actividad sin rotarla en ningún momento. La huella pasiva de DNS muestra que el dominio city-forum.com ha resuelto a esa dirección desde al menos marzo de 2025, lo que confirma que la infraestructura lleva de pie más de un año y medio.
El segundo ingrediente es el cliente HTTP. Todo el tráfico de City-Forum lleva el mismo User-Agent, que coincide con el valor por defecto de la biblioteca net/http de Go. Esa huella es deliberada en el sentido de que identifica un cliente compilado a medida —no un navegador, no una herramienta estándar— pero técnicamente es la cadena por defecto que cualquier programa Go emite sin modificarla. Para los analistas, esa huella significa que el atacante ha escrito un programa específico para esta tarea, no que está reutilizando tooling conocido.
El tercer ingrediente es donde el caso se vuelve instructivo. El atacante no usa credenciales robadas, no explota vulnerabilidades, no despliega malware. Utiliza únicamente los permisos que las propias organizaciones han concedido a usuarios invitados anónimos en sus portales públicos. En Salesforce Experience Cloud, eso significa acceso a través de la capa Aura y de los endpoints GraphQL de Lightning Web Runtime. En ServiceNow, el operador utiliza un endpoint de búsqueda que la propia documentación del producto no documenta de forma prominente pero que devuelve resultados a usuarios anónimos cuando la configuración del portal lo permite.
El volumen de actividad es significativo. Reco documenta que en una sola víctima el operador generó más de 560.000 eventos de extracción a lo largo del período de observación. La actividad es de alto volumen pero protocolarmente legítima, lo que significa que cada petición individual parece un uso normal del portal.
Sectores y víctimas
El alcance sectorial de City-Forum no es aleatorio. Reco identifica víctimas en operadores de telecomunicaciones, bancos y entidades de servicios financieros, vendors de software empresarial —incluidas compañías de seguridad y privacidad de datos— y portales del sector público. La selección sugiere que el operador busca dos cosas: datos de clientes finales almacenados en portales de soporte o atención al cliente, y datos operativos que puedan usarse como base para ataques posteriores.
Los datos de telecomunicaciones son particularmente valiosos para SIM swap y compromiso de cuentas de clientes. Los datos bancarios son útiles para fraude y para alimentar listas de objetivos en campañas de phishing dirigido. Los datos de vendors de seguridad pueden usarse para mapear la superficie de ataque de otras organizaciones que son clientes del vendor afectado.
Que entre las víctimas haya vendors de seguridad y privacidad es un detalle que merece atención. Si tu organización ofrece servicios de seguridad a clientes finales, es muy probable que parte de tu superficie de exposición sean los portales de soporte donde esos clientes gestionan tickets, descargas o configuración. City-Forum documenta que esos portales también están en el mapa del operador.
Por qué este caso es un caso de estudio para DevSecOps
Tres razones convierten a City-Forum en material de referencia obligatoria para cualquier equipo que opera SaaS en producción.
Razón uno — la cadena de ataque no es técnica. No hay exploit, no hay payload, no hay credencial robada. Hay una configuración de guest user más permisiva de lo que la organización cree. Eso significa que el control que falla no está en el código, está en la operación. La responsabilidad es de quien mantiene la configuración, no de quien escribe el software.
Razón dos — la detección tradicional no funciona. La actividad de City-Forum parece uso legítimo del portal. Los WAF no la marcan. Los IDS no la detectan. Los sistemas de gestión de identidad no ven actividad sospechosa porque cada petición se autentica correctamente como guest. Los únicos controles que podrían detectarla son análisis de comportamiento sobre logs de aplicación, lo cual requiere telemetría que la mayoría de organizaciones SaaS no recoge.
Razón tres — el blast radius es invisible. A diferencia de un compromiso de credenciales, donde puedes ver qué cuenta accedió y a qué recursos, una extracción por usuario invitado deja un rastro mucho más difuso. La pregunta "qué datos salieron" no se puede responder con certeza mirando logs de acceso, porque los logs pueden no capturar las respuestas individuales. Reco es explícito al respecto: si vas a buscar este tráfico en tus logs, vas a aprender menos de lo que quisieras.
El playbook DevSecOps para esta semana
### Fase 1 — Inventario de exposición anónima (días 1 a 3)
El primer movimiento es saber qué tienes expuesto a usuarios invitados sin saberlo. Para Salesforce Experience Cloud:
- Auditar cada Experience Cloud site publicado y listar exactamente qué objetos, campos, listas y archivos son accesibles al perfil de guest user. El camino es `Setup → Sites → Builder → Guest User Profile`. - Revisar las sharing rules que aplican al guest user, especialmente las que permiten lectura de objetos Account, Contact, Case, Custom Object y cualquier objeto personalizado que contenga datos de clientes. - Comprobar si las APIs públicas (REST, SOAP, GraphQL via Aura, Bulk API) están habilitadas para el guest user. La API de Aura en particular permite extracción masiva de datos si las sharing rules son permisivas. - Revisar las search sources accesibles al guest user, incluyendo búsqueda global y búsqueda en objetos específicos. La búsqueda es uno de los vectores más poderosos de extracción masiva. - Auditar las Flow, Apex y Lightning Web Components que son accesibles sin autenticación.
Para ServiceNow Service Portal:
- Listar cada widget, página y knowledge base article expuesto al público. - Auditar las ACL (Access Control List) del portal, especialmente las que permiten lectura a usuarios sin autenticación. - Comprobar el endpoint de búsqueda no documentado que City-Forum explota. ServiceNow tiene múltiples endpoints de búsqueda y algunos no aparecen en la documentación principal pero están disponibles en instancias de producción. - Revisar los scripts Include, UI Macros y Widget Server Scripts accesibles sin autenticación. - Verificar la configuración de auto-registro y self-service. Si está habilitada, un atacante puede crear cuentas con permisos mínimos que se sumen a la superficie de ataque.
### Fase 2 — Endurecimiento de permisos de guest user (días 3 a 7)
Para Salesforce:
- Cambiar el Organization-Wide Default de cada objeto relevante a Private o a Public Read Only cuando sea estrictamente necesario. - Reemplazar las sharing rules permisivas por sharing rules basadas en criterios que excluyen explícitamente al guest user. - Desactivar las APIs accesibles al guest user. Si alguna API pública es estrictamente necesaria, limitarla a objetos y campos específicos que no contengan datos sensibles. - Eliminar el acceso de guest user a las search sources que devuelven datos de clientes. - Implementar Field-Level Security estricta en cada objeto accesible al guest user.
Para ServiceNow:
- Aplicar el principio de mínimo privilegio en cada ACL. Cada ACL que permite acceso a usuarios anónimos debe justificar específicamente por qué existe. - Desactivar el endpoint de búsqueda no documentado si está accesible. Si la documentación oficial no lo cubre, es razonable desactivarlo o restringirlo. - Auditar las referencias públicas y eliminarlas si no son necesarias. - Implementar rate limiting agresivo en el portal público.
### Fase 3 — Telemetría y detección (días 7 a 14)
- Activar Event Monitoring en Salesforce si está disponible. Esta funcionalidad captura accesos a nivel de campo y permite análisis de comportamiento que detectarían patrones similares a City-Forum. Activar al menos los eventos de Report Event, ListView Event y API Event. - En ServiceNow, activar Transaction Logs y auditar logs de Service Portal para detectar patrones de scraping. - Implementar alertas sobre volumen anormal de accesos desde una sola IP. Un usuario invitado legítimo no genera 560.000 eventos en semanas. - Crear dashboard de actividad por guest user que permita identificar anomalías en patrones de uso. - Implementar honey tokens o datos canario. Coloca registros con campos que ningún usuario legítimo debería ver ni consultar. Si esos registros aparecen en logs de acceso o en resultados de búsqueda, sabes que tienes un visitante no invitado.
### Fase 4 — Auditoría retrospectiva (días 14 a 30)
- Buscar en logs históricos patrones compatibles con City-Forum: una IP externa que ha hecho muchas peticiones autenticadas como guest durante meses. - Evaluar si tienes datos en logs suficientes para responder a la pregunta "qué datos salieron". Si no los tienes, ese es el hallazgo principal: la ausencia de telemetría es el agujero real. - Documentar la superficie de exposición histórica. Qué era accesible al guest user durante los últimos 17 meses, qué objetos, qué campos. - Si determinas que hubo exposición, evaluar obligaciones regulatorias. En el contexto europeo, el RGPD impone notificación a autoridades de supervisión en 72 horas cuando hay riesgo para derechos de personas. Los datos extraídos por City-Forum incluyen nombres, emails, teléfonos y datos de cuentas en muchos casos — eso suele calificar como dato personal.
Errores sistemáticos que cometen los equipos
Error uno — confiar en que la configuración por defecto es segura. La configuración por defecto de un portal SaaS suele ser más permisiva de lo necesario. El equipo que despliega el portal rara vez revisa cada sharing rule y cada ACL con mentalidad de mínimo privilegio.
Error dos — tratar guest user como usuario no humano sin riesgo. Un guest user no autenticado sigue siendo un principal de seguridad. Tiene permisos que se ejecutan contra datos reales. La actitud correcta es tratarlo como un usuario con todos los privilegios que le has dado, no como un visitante inocuo.
Error tres — medir el riesgo de configuración por cantidad de incidentes visibles. Si tu portal SaaS no ha tenido un incidente de seguridad visible, eso no significa que la configuración sea correcta. City-Forum lleva 17 meses extrayendo datos sin que ninguna víctima haya detectado la actividad de forma orgánica. La ausencia de incidentes no es evidencia de seguridad.
Error cuatro — no correlacionar logs entre sistemas. La detección de City-Forum requirió que Reco correlacione logs de múltiples víctimas para identificar el patrón. Una sola organización mirando sus propios logs no tiene la visión agregada necesaria para detectar campañas multi-target como esta.
El párrafo para liderazgo
Si necesitas el párrafo para un comité de seguridad: City-Forum es una campaña de extracción de datos activa desde marzo de 2025 que afecta portales públicos de Salesforce Experience Cloud y ServiceNow en sectores de telecomunicaciones, banca, software empresarial y sector público. El operador utiliza únicamente los permisos concedidos a usuarios invitados anónimos, sin credenciales robadas, sin exploits y sin malware. Una sola víctima documentada registra más de 560.000 eventos de extracción. La mitigación inmediata pasa por auditar y endurecer los permisos de guest user en cada portal SaaS público, activar telemetría que permita detectar patrones de scraping persistente, e implementar rate limiting y datos canario. La lección estratégica es que una configuración SaaS permisiva es una vulnerabilidad silenciosa que ningún WAF ni IDS detecta hasta que es demasiado tarde.
Cambios estructurales después de este incidente
Cambio uno — guest user como principal de seguridad de primera clase. Si tu organización trata el guest user como un actor sin riesgo, este incidente lo invalida. El guest user merece el mismo nivel de auditoría que cualquier otro principal de seguridad.
Cambio dos — telemetría obligatoria sobre accesos anónimos. Las plataformas SaaS que publican portales deben tener telemetría a nivel de campo, no solo a nivel de acceso. Sin esa granularidad, campañas como City-Forum son invisibles hasta que un tercero las reporta.
Cambio tres — honey tokens como control estándar. Incluir datos canario en cada portal público es una práctica de coste bajo y valor alto. La primera vez que un atacante externo los consulte, sabes que hay actividad no autorizada.
Cambio cuatro — threat modeling que incluya SaaS público. Si tu modelo de amenaza trata los portales SaaS como infraestructura sin valor para el atacante, este incidente lo invalida. Un portal de soporte accesible públicamente es un objetivo de scraping persistente exactamente igual que un endpoint API mal configurado.
Fuentes verificadas
- Help Net Security, "A stranger has been reading Salesforce and ServiceNow portals worldwide for 17 months", 12 de agosto de 2026. https://www.helpnetsecurity.com/2026/08/12/salesforce-servicenow-guest-user-exposure - Travis Stein en LinkedIn, "City-Forum: 17 Month Salesforce and ServiceNow Data Breach via Guest User Account", agosto de 2026. https://www.linkedin.com/posts/twstein86_someone-was-reading-salesforce-and-servicenow-activity-7493789910299234304-MBEQ - xacademia, "City-Forum Campaign Targets Salesforce and ServiceNow Guest Access", agosto de 2026. https://xcademia.com/news/city-forum-campaign-targets-salesforce-and-servicenow-guest-access - daily.dev, "City-Forum Campaign Is Quietly Scraping Salesforce and ServiceNow Guest Portals", agosto de 2026. https://daily.dev/posts/city-forum-campaign-is-quietly-scraping-salesforce-and-servicenow-guest-portals-myzkh41dw - Kevin J. Conlan en LinkedIn, análisis complementario sobre la campaña City-Forum. https://www.linkedin.com/posts/kevin-j-conlan-604170119_the-city-forum-campaign-an-advanced-attacker-activity-7493477434684502016-77nQ
Recomendaciones de cierre
Audita cada portal Salesforce y ServiceNow expuesto públicamente con la pregunta directa: "qué datos puede ver un usuario anónimo hoy". Endurece cada permiso de guest user hasta que la respuesta sea "solo lo estrictamente necesario". Activa telemetría que permita detectar patrones de scraping persistente. Implementa honey tokens en cada portal público. Y finalmente, integra el SaaS público en tu modelo de amenaza con la misma seriedad que un endpoint API expuesto a internet. La diferencia entre esos dos marcos es lo que separa a los equipos que descubren City-Forum en su infraestructura antes de que Reco lo publique, de los que lo descubren cuando ya es tarde.