Análisis editorial original de OrbTrail ampliado con investigación complementaria, contexto práctico y referencias verificadas.
Una campaña seguida por Reco y divulgada el 12 de agosto cambia una suposición importante en la defensa de portales Salesforce. El actor denominado City‑Forum utiliza herramientas propias contra sitios Experience Cloud creados tanto con Aura como con Lightning Web Runtime (LWR), además de portales ServiceNow. La infraestructura asociada al indicador principal existe desde marzo de 2025 y la actividad observada sigue creciendo. En uno de los objetivos, los investigadores registraron más de 560.000 eventos vinculados casi por completo a enumeración Aura como usuario invitado. La cifra no significa 560.000 víctimas ni registros robados; es un conteo de eventos en un entorno analizado y debe comunicarse con esa precisión.
El punto central es más incómodo que una vulnerabilidad recién descubierta. Según Salesforce y la investigación independiente, las solicitudes se ejecutan como el guest user persistente del sitio y reciben solo lo que permiten los objetos, el uso compartido, la seguridad de campos y la configuración pública. La evidencia publicada no muestra evasión de autenticación ni un defecto inherente de la plataforma. El problema es que una página aparentemente correcta puede convivir con una superficie de datos mayor que la visible para el administrador. La pregunta operativa es: ¿cómo demostrar que cada camino anónimo —página, Aura, UI API, GraphQL, Apex, archivos y autorregistro— entrega únicamente información intencionalmente pública?
Aura y LWR son superficies distintas
Aura expone solicitudes /aura; LWR usa UI API y GraphQL. Probar un solo framework deja el otro sin evidencia.
El guest user define la respuesta
Objetos, registros, campos, archivos y código anónimo deben probarse como una identidad externa real.
Los logs conectan patrón y resultado
AuraRequest y Sites muestran IP, user agent, acciones y barridos de versiones; el inventario indica qué podía leerse.
Cerrar el exceso sin borrar el recorrido
Elimina APIs y permisos innecesarios, conserva solo casos públicos probados y vuelve a monitorear después de cada cambio.
Aura y LWR llegan a los mismos datos por caminos diferentes
En Aura, la herramienta observada consulta /aura o /s/sfsites/aura. El reconocimiento usa getConfigData para identificar objetos alcanzables en el contexto invitado; después, getItems pagina registros de los candidatos. La técnica ya se conocía por campañas anteriores, pero sigue siendo relevante porque muchos portales aún usan Aura. La señal defensiva no es una URL aislada: es la combinación de identidad invitada, volumen, secuencia de acciones, objetos inesperados, IP y user agent incompatible con navegación humana.
En LWR, /aura está desactivado, pero la capa de datos vive bajo /webruntime/api/services/data/{versión}. La investigación encontró llamadas GraphQL a UI API, incluida una secuencia que probaba versiones de v56.0 a v66.0. Los permisos de objeto, campo y registro todavía se aplican; el riesgo aparece cuando autorizan más de lo que necesita el recorrido público. Esto desmonta dos falsas garantías: migrar a LWR no elimina el riesgo de autorización anónima y que un scanner Aura no encuentre nada no prueba que el sitio sea seguro.
Página cerrada, API abierta: tres controles que parecen equivalentes, pero no lo son
La visibilidad de páginas en Experience Builder, el permiso de sistema API Enabled del perfil invitado y la preferencia Allow guest users to access public APIs gobiernan superficies diferentes. Reco advierte que retirar API Enabled no cierra por sí solo la UI API de LWR; la preferencia de APIs públicas controla específicamente GraphQL y UI API REST. La guía de Salesforce recomienda desactivar ambos cuando no son indispensables. Exigir login para navegar tampoco elimina el guest user, sus reglas de acceso ni el código que todavía pueda ejecutarse en contexto anónimo.
El autorregistro crea una cuarta frontera. La campaña probó rutas como /SiteRegister y /CommunitiesSelfReg para descubrir si un visitante podía crear una cuenta externa y alcanzar permisos más amplios. Desactivar la función cuando no existe un requisito es la decisión directa. Cuando sea necesaria, el handler debe respetar sharing, asignar el perfil más restrictivo, verificar el correo e impedir que datos recolectados como invitado seleccionen una cuenta o relación indebida. La prueba debe cubrir el estado antes y después del registro, no solo la pantalla de alta.
Una auditoría útil comienza desde cero y reconstruye cada necesidad pública
Salesforce describe cuatro capas secuenciales: acceso al objeto, acceso al registro, seguridad a nivel de campo y enmascaramiento del valor. La revisión debe comenzar por el perfil invitado de cada sitio, porque cada Experience tiene su propia identidad anónima. Para cada objeto legible, registra qué componente o proceso lo necesita, qué registros deben ser públicos, qué campos se muestran y si adjuntos, actividades, usuarios o documentos entran por relación. Sin un recorrido y un responsable, retira el acceso antes de restaurar selectivamente un alcance explícito.
Recorrer páginas haciendo clic no basta. Usa una sesión no autenticada para probar páginas y formularios, pero valida también respuestas de APIs públicas, componentes personalizados, Flows y Apex ejecutados para el invitado. Coloca datos sintéticos marcadores en sandbox para descubrir qué capa expuso un campo. Los casos negativos son esenciales: ID de otro registro, filtro vacío, paginación amplia, campo oculto, archivo relacionado y error de validación. La evidencia es sencilla de expresar y difícil de fingir: el visitante recibe el mínimo por todos los caminos, no solo por la interfaz feliz.
La caza debe combinar indicadores, comportamiento y posibilidad de acceso
Reco publicó IP, dominio, user agent y firmas de solicitudes asociadas a la campaña. Permiten una búsqueda inicial, pero no concluyen la investigación porque infraestructura y herramientas pueden cambiar. En Event Monitoring, AuraRequest y Sites ayudan a localizar getConfigData, getItems, llamadas /webruntime/, barridos consecutivos de versiones y pruebas de autorregistro. Salesforce recomienda buscar picos de consultas, objetos que no deberían ser públicos, orígenes desconocidos y horarios anormales. Event Monitoring a nivel de solicitud requiere Salesforce Shield o el add-on independiente, por lo que una brecha de licencia entra en el riesgo residual.
Encontrar una firma demuestra actividad, no necesariamente exfiltración; no encontrarla solo demuestra que el indicador no apareció en los logs disponibles. La investigación debe cruzar solicitudes con el estado histórico de permisos del invitado, sharing rules, FLS, preferencias de API, archivos y autorregistro. Si un objeto era accesible, estima qué registros y campos podían consultarse y preserva los logs antes de que expire la retención. Bloquear la IP reduce la presión inmediata, pero no corrige la exposición ni detecta otra dirección usando la misma técnica.
Conclusión: el acceso público es una API de datos aunque el proyecto se gestione como sitio
City‑Forum no cambia el principio de seguridad; demuestra que los atacantes ya automatizaron caminos más allá de las comprobaciones conocidas de Aura. El plan más seguro es inventariar cada sitio y framework, desactivar APIs y autorregistro innecesarios, reconstruir el acceso invitado por recorrido, probar resultados negativos y mantener detección de comportamiento. Publicar un portal también publica una identidad técnica y contratos de datos. La revisión necesita responsable, cadencia y regresión porque una nueva página, Flow, regla o campo puede reabrir la exposición sin cambiar la apariencia del portal.
