ShinyHunters no rompió ningún control: usó la confianza que ya estaba concedida

EY confirmó una intrusión a través de una plataforma de soporte de terceros. Días después, el mismo grupo reclamó tres brechas de Salesforce con más de 47 millones de registros, autorizadas por teléfono. En ninguno de los casos hubo una vulnerabilidad de software que parchar.

Qué pasó

Dos operaciones atribuidas al mismo grupo, con un estado de verificación distinto que conviene no mezclar.

El caso de EY está confirmado por la propia firma. Ernst & Young, una de las cuatro mayores auditoras del mundo, confirmó que actores no autorizados accedieron a una plataforma de soporte de terceros utilizada por la compañía. El acceso se habría producido entre el 28 de marzo y el 12 de abril de 2026, un periodo de aproximadamente dos semanas de exposición no detectada. ShinyHunters reclamó públicamente la autoría; EY no ha confirmado ni negado esa atribución específica, y mantiene reserva sobre el alcance exacto de los datos afectados.

Los casos de Salesforce son reclamos no confirmados. El 2 de agosto de 2026, ShinyHunters publicó de forma casi simultánea tres reclamos contra Alcon (Suiza), Lumenis (Estados Unidos) y Questel (Francia). Las cifras reclamadas: ~25 millones de registros en Alcon, 176 GB y 1,1 millones de registros en Lumenis, y 147 GB con ~21 millones de registros en Questel. En conjunto superan los 47 millones. Ninguna de las tres víctimas ha emitido confirmación oficial completa.

El vector técnico reportado para la campaña de Salesforce —y esto también es análisis basado en el modus operandi documentado del grupo, no un hecho verificado— consiste en llamadas de voice phishing a empleados de soporte técnico o mesa de ayuda, haciéndose pasar por personal interno de TI, para inducirlos a autorizar una aplicación conectada de terceros dentro de Salesforce, disfrazada como herramienta legítima de migración o respaldo de datos.

Una vez autorizada, esa aplicación OAuth hereda permisos amplios de lectura y exportación masiva, sin requerir credenciales robadas ni explotar una vulnerabilidad de software.

Por qué importa acá

Salesforce es una de las plataformas CRM más adoptadas por bancos, retailers, aseguradoras y prestadores de salud en Chile y la región. Eso convierte a esta campaña en una advertencia directa, no en una noticia extranjera.

Y el caso de EY toca un nervio distinto. EY mantiene operaciones y clientes corporativos en Chile, incluidos servicios de auditoría externa y asesoría tributaria a empresas listadas y privadas. Bajo la Ley 21.719, las organizaciones chilenas que comparten información con terceros —incluidas firmas de auditoría global— mantienen responsabilidad sobre esos datos incluso cuando el incidente ocurre en la infraestructura del proveedor.

La consecuencia práctica es concreta y poca gente la ejecuta: si tu empresa es cliente de una firma que sufrió una brecha, deberías solicitar formalmente confirmación por escrito sobre si tus datos estuvieron en la plataforma afectada, y documentar esa gestión como parte de tu deber de cuidado regulatorio. No es un trámite: es la evidencia que te va a pedir la autoridad.

La Ley 21.663, por su parte, impone obligaciones de reporte a organismos del Estado y a empresas calificadas como OIV. Muchas organizaciones chilenas con grandes volúmenes de datos en un CRM podrían alcanzar ese umbral sin haberlo evaluado formalmente. La ausencia de un incidente confirmado en Chile hasta la fecha no debe leerse como ausencia de riesgo, sino como una ventana de oportunidad para actuar de forma preventiva.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

• T1199 — El caso EY: el acceso llego por la plataforma del proveedor de soporte.
• T1598 — Variante vishing: llamada a la mesa de ayuda haciendose pasar por personal interno de TI.
• T1550.001 — La app OAuth autorizada opera con permisos legitimos. No hay credencial que revocar.
• T1078 — El acceso persiste mientras la autorizacion siga vigente, aunque cambien las contrasenas.
• T1567 — La exportacion masiva usa el propio canal legitimo de la plataforma.

-- Salesforce: aplicaciones conectadas aprobadas y quien las aprobo.
-- SetupAuditTrail esta disponible en todas las ediciones, sin Event Monitoring.
SELECT CreatedDate, CreatedBy.Name, CreatedBy.Profile.Name, Action, Section, Display
FROM SetupAuditTrail
WHERE CreatedDate = LAST_N_DAYS:180
  AND (Section = 'Connected Apps'
       OR Action LIKE '%connectedapp%'
       OR Action LIKE '%oauth%')
ORDER BY CreatedDate DESC

-- Exportaciones masivas y accesos por API en el mismo periodo
SELECT LoginTime, LoginType, Application, SourceIp, Status, UserId
FROM LoginHistory
WHERE LoginTime = LAST_N_DAYS:180
  AND (Application LIKE '%Data Loader%' OR LoginType = 'Remote Access 2.0')
ORDER BY LoginTime DESC

// Microsoft 365: consentimientos OAuth otorgados a aplicaciones de terceros
AuditLogs
| where TimeGenerated > ago(180d)
| where OperationName in ("Consent to application", "Add OAuth2PermissionGrant",
                          "Add delegated permission grant", "Add app role assignment grant to user")
| extend Quien = tostring(InitiatedBy.user.userPrincipalName)
| extend App = tostring(TargetResources[0].displayName)
| extend Permisos = tostring(TargetResources[0].modifiedProperties)
| project TimeGenerated, Quien, App, OperationName, Permisos
| order by TimeGenerated desc

PROTOCOLO DE VERIFICACION PARA MESA DE AYUDA
Aplicar ante toda solicitud de autorizar una aplicacion, cambiar un permiso o
restablecer un acceso, cuando llegue por telefono o por chat.

REGLA 1 - Nunca se autoriza en la misma llamada.
   Toda solicitud se corta y se devuelve el contacto por un canal independiente:
   el telefono del directorio interno, no el numero que aparece en pantalla.

REGLA 2 - Segundo par de ojos para aplicaciones conectadas.
   Autorizar una app OAuth en el CRM o en el tenant exige aprobacion de una
   segunda persona designada. Nunca lo resuelve quien atiende.

REGLA 3 - La urgencia es una senal de alerta, no un argumento.
   "El auditor lo necesita ahora", "se cae la migracion", "el gerente esta esperando".
   Cuanto mas apuro transmite quien llama, mas estricta es la verificacion.

REGLA 4 - Registrar siempre.
   Quien llamo, desde que numero, que pidio, quien verifico y que se resolvio.
   Sin registro no hay forma de reconstruir el incidente despues.

REGLA 5 - Reportar sin costo reputacional.
   Quien atendio una llamada sospechosa debe poder reportarla sin temor a sancion,
   incluso si alcanzo a hacer algo. El castigo al que reporta compra silencio,
   y el silencio es lo que convierte un intento en una brecha.

Fuentes

• MITRE ATT&CKT1199 — Trusted Relationship
• MITRE ATT&CKT1598 — Phishing for Information
• MITRE ATT&CKT1550.001 — Application Access Token
• BCNLey 21.719 sobre protección de datos personales
• BCNLey 21.663, Ley Marco de Ciberseguridad

Relacionado