Hace unos días, el gigante de la publicación educativa McGraw Hill reveló un incidente cibernético que involucró al notorio grupo actor de amenazas ShinyHunters. El episodio comenzó como un incidente de "acceso limitado" y, según fuentes de la empresa, escaló rápidamente en magnitud, ya que casi 13 millones de registros llegaron a la Dark Web y fueron aprovechados por corredores de datos. Aunque McGraw Hill ha afirmado que ShinyHunters explotó una mala configuración en el entorno comprometido de Salesforce para ejecutar la brecha, el incidente no ha afectado a sus otras cuentas de Salesforce, contenido de cursos, bases de datos de clientes ni sistemas internos.

Una brecha sigue siendo una brecha. Se filtraron datos, incluidas credenciales, y algo salió mal en la parte de gobernanza de identidad y acceso en la capa de aplicación. En la entrada del blog de hoy investigamos este incidente y proponemos formas de prevenir su recurrencia.

Antes de comenzar el análisis profundo, no olvides revisar nuestra entrada anterior titulada Los 15 principales desafíos en la protección de CPS y cómo los equipos de OT pueden abordarlos aquí.  

Cronología de la brecha y vector de ataque

La brecha salió a la luz públicamente el 14 de abril de 2026. Esto coincidió con una fecha límite de rescate establecida por ShinyHunters.

La causa raíz: la trampa de "Experience Cloud"

El vector principal no fue un exploit de día cero. En cambio, fue una mala configuración en Experience Cloud de Salesforce (antes Community Cloud). Las empresas usan estas funciones para crear portales públicos o dirigidos a socios para clientes y partners.

• Permisos del usuario invitado: De forma predeterminada, Salesforce ha endurecido los permisos de usuario invitado durante los últimos años. Sin embargo, las configuraciones heredadas a menudo permanecen. En este caso, parece que a los perfiles de usuario invitado se les otorgaron privilegios excesivos en forma de acceso de "Lectura" a objetos internos.

·  La explotación de "Aura": Se ha observado que ShinyHunters utiliza escáneres automatizados para consultar componentes Aura de Salesforce e identificar puntos débiles. Al golpear endpoints específicos no autenticados, pueden hacer "fuzzing" del sistema o, para ser más específicos:

o   Abuso de los endpoints /s/sfsites/aura o /aura

o   Llamada a controladores Apex del lado del servidor

o   Explotación de métodos @AuraEnabled expuestos de forma incorrecta

o   Combinado con contexto de usuario invitado

( para extraer registros que no están debidamente protegidos por permisos de objeto (CRUD), FLS y el modelo de compartición.)

La discrepancia de datos

Nuestra hipótesis: La estructura de datos inconsistente encontrada en los archivos filtrados sugiere que los atacantes no simplemente volcaron una sola base de datos; en su lugar, "rasparon" datos a través de múltiples objetos de Salesforce durante un período prolongado. Esto apunta a una estrategia de exfiltración lenta y sostenida/prolongada que evadió los disparadores de alerta tradicionales basados en volumen.

ShinyHunters estuvieron en el sistema durante un tiempo y exfiltraron datos lentamente.

Análisis forense profundo: "Limitado" vs. "letal"

McGraw Hill se apresuró a declarar que los números de Seguro Social y los datos financieros no estaban involucrados en la brecha. Si bien esta declaración es técnicamente correcta, esto podría verse como un intento de minimizar el impacto total de la brecha. Aunque los datos comprometidos pueden no incluir números de Seguro Social, los hackers y hacktivistas utilizarán las credenciales filtradas para obtener acceso a otras partes de la infraestructura de McGraw Hill.

Aunque en esta brecha quizá no se hayan expuesto identificadores financieros y altamente sensibles, el riesgo de un ataque importante sigue siendo lo suficientemente significativo como para atraer atención y acción. Las direcciones de correo electrónico y los metadatos asociados se aprovechan de forma rutinaria en:

• ataques de relleno de credenciales

• campañas de phishing

• correlación de identidades mediante conjuntos de datos OSINT

Con el tiempo, estos conjuntos de datos permiten a los atacantes construir gráficos de identidad conductual y organizacional, aumentando la probabilidad de compromisos exitosos en campañas futuras. Incluso podemos considerar otro escenario que podría desarrollarse.

Cada vez que se filtran credenciales, los hackers alimentan los datos en los SLMs para predecir patrones de contraseñas a nivel individual mediante modelado de contraseñas (o incluso relleno de credenciales). Con el tiempo, a medida que algunas de las víctimas cuyos datos fueron comprometidos ascienden a puestos directivos (ya sea en la misma empresa o en otra), hay suficientes datos disponibles para adivinar futuras contraseñas. El riesgo de una brecha importante aumenta con cada incidente de este tipo. Por lo tanto, estos incidentes deben verse como una oportunidad para romper esos patrones y aportar más imprevisibilidad.   

El actor de amenaza: ShinyHunters

Quizá recuerdes a ShinyHunters por este incidente. En cierto modo, han evolucionado. Ya no se molestan con el cifrado complejo (ransomware) y la venta de descifradores. Se han convertido en extorsionadores puros (tan puros como vienen).  

TTP de ShinyHunters

• Descubrimiento de activos

  • Escaneo de dominios expuestos de Salesforce Experience Cloud (*.force.com, *.site.com)

• Enumeración de endpoints

  • Objetivos:

    • /s/

    • /aura

  • Identificación de componentes del lado del servidor que pueden invocarse

• Abuso de privilegios

  • Operando dentro de:

    • Contexto de usuario invitado

    • Perfiles estándar mal configurados

• Extracción de datos

  • Recopilación automatizada mediante solicitudes con scripts

  • Enfoque en objetos de alto valor (Contactos, Usuarios, Cuentas)

• Flujo de extorsión

  • Publicación de muestra filtrada

  • Negociación directa o reventa a afiliados

Medidas preventivas: cerrar la bóveda

Para evitar que tu organización se convierta en una víctima de este grupo, necesitas implementar de inmediato estas configuraciones de Salesforce de "Confianza Cero":

Endurecimiento estratégico

• Deshabilita el "Acceso público" de forma predeterminada: audita cada sitio de Salesforce y portal de Experience Cloud. Asegúrate de que el "Acceso público" solo esté habilitado para las páginas que realmente lo requieran.

• Bloqueo del "usuario invitado": usa las reglas de compartición de usuario invitado para asegurarte de que los usuarios invitados nunca puedan acceder a registros de forma predeterminada. Solo deben ver lo que se comparta explícitamente mediante reglas de "Secure Guest User Sharing".

• Seguridad de API: restringe el acceso a la API a rangos de IP específicos y aplica TLS mutuo (mTLS) para integraciones sensibles.

• Audita todos los sitios de acceso público y privilegios. Retira los privilegios que ya no sean necesarios  

• Inicia el cambio de credenciales de todos los IDs de correo externos y luego pide a todos los empleados internos que cambien sus credenciales. Las nuevas contraseñas no deben usar ningún patrón, letra ni carácter especial de las anteriores

·       Audita las clases Apex habilitadas para Aura

·       Identifica todos los métodos @AuraEnabled

·       Asegúrate de:

o   Comprobaciones de autenticación

o   Validación de entradas

o   Sin exposición directa de objetos

·       Endurecimiento de Experience Cloud

·       Revisa todos los sitios:

o   Elimina endpoints no utilizados

o   Deshabilita el acceso público cuando no sea necesario

·       Gobernanza de aplicaciones conectadas

·       Aplica:

o   IP Relaxation = Restringido

o   Sesiones de alta confianza

o   Minimización de ámbitos OAuth 

Controles tácticos

• Salesforce Shield (Monitoreo de eventos): habilita Shield para rastrear los eventos "Report Export" y "Bulk API". Si un usuario invitado (o cualquier usuario) accede repentinamente a varios registros, el sistema idealmente debería poner la sesión en cuarentena automáticamente y generar una alerta multinivel. Hablamos de políticas de seguridad de transacciones, monitoreo de eventos y reglas personalizadas que cubran múltiples escenarios.

• Seguridad a nivel de campo (FLS): incluso si un usuario puede ver un objeto, no debería ver todos los campos. Enmascara los campos de PII para todos excepto para los roles administrativos más esenciales.

• Monitorea:

·  Patrones de acceso URI (/aura, /s/)

·   Picos de eventos de API

·   Exportaciones de informes

KPI: cómo rastrear tu exposición

No puedes gestionar lo que no mides. Da seguimiento mensual a estas métricas:

• Cantidad de permisos de usuario invitado: número de objetos accesibles para perfiles "Invitado" no autenticados. (Objetivo: 0 para objetos sensibles).

• Tasa de desviación de configuración: qué tan seguido se introducen ajustes "permisivos" después de un ciclo de despliegue.

• Tiempo medio de detección (MTTD) para exportaciones masivas: cuántos minutos pasan entre una consulta masiva de datos y una alerta del SOC.

• Porcentaje de usuarios con MFA: asegúrate de que absolutamente todos los usuarios internos y socios estén gobernados por autenticación multifactor.

El incidente de McGraw Hill es un caso clásico de proliferación de SaaS. Cuando una empresa avanza rápidamente para ofrecer plataformas de aprendizaje digital, la seguridad suele quedar detrás de la conveniencia.

No se trató de una brecha de la infraestructura. Fue una falla de disciplina de configuración en un entorno SaaS. ShinyHunters no "entró por la fuerza". En su lugar, pasaron por una puerta que se dejó entreabierta en nombre de la "experiencia del usuario". El atacante no explotó una vulnerabilidad en el sentido convencional. Operó dentro de los límites de lo que el sistema esencialmente permitía.

Para los 13.5 millones de personas cuyos datos ahora están en la red, la lección es clara: en la nube, la configuración es un elemento de seguridad esencial.

Mantén tus registros bajo control y tus permisos aún más estrictos.

Recursos adicionales     

Guía completa sobre Detección y Respuesta de Red (NDR) en 2026 aquí 
Un informe descargable sobre el incidente cibernético de Stryker aquí     
Guías de remediación aquí   
Buenas prácticas de seguridad OT y guía para evaluación de riesgos aquí  
Lista de verificación de evaluación de riesgos OT/ICS basada en IEC 62443 para el sector de manufactura de alimentos y bebidas aquí