Filtración de datos de Cloudflare

Filtración de datos de Cloudflare


Publicado: 31/10/2025

Escrito por: Monica Burgess

Un problema en el sistema de un proveedor externo generó repercusiones en Cloudflare, un actor clave en la infraestructura de internet. Esto no fue un robo directo típico; fue una explotación sutil de una brecha de seguridad de un proveedor que llevó a una filtración. Aunque el impacto directo en Cloudflare fue contenido, el incidente muestra cuán interconectadas están nuestras cadenas de suministro digitales y cómo un solo eslabón débil puede exponer incluso a los sistemas más protegidos.

Filtración de datos de Cloudflare explicada: ¿qué pasó?

La filtración de datos de Cloudflare se originó en incidentes de seguridad en dos de sus proveedores externos, Salesloft y Drift (desviación de configuración). Los atacantes comprometieron estas plataformas, que los equipos de ventas y soporte de Cloudflare usaban para la gestión de relaciones con los clientes. Este acceso permitió a los actores de amenazas ver ciertos datos de clientes, específicamente de personas que habían interactuado con los equipos de ventas y soporte de Cloudflare.

¿Cuándo ocurrió la filtración de datos de Cloudflare?

El ataque se desarrolló entre el 9 y el 17 de agosto de 2025. Salesforce y Salesloft notificaron a Cloudflare el 23 de agosto de 2025. Después de completar su propia investigación forense, Cloudflare reveló públicamente el incidente el 2 de septiembre de 2025 a través de su blog de seguridad, notificando directamente ese mismo día a todos los clientes afectados por correo electrónico y mediante un aviso en el panel.

¿Quién hackeó a Cloudflare?

Se identificó al actor de amenazas. El propio equipo de inteligencia de amenazas de Cloudflare, Cloudforce One, nombró al grupo GRUB1. El Grupo de Inteligencia de Amenazas de Google rastreó actividad superpuesta bajo la designación UNC6395, y la investigación de Mandiant confirmó que el mismo actor estaba detrás de la campaña más amplia de desviación de configuración de Salesloft, dirigida a cientos de organizaciones a nivel mundial. El objetivo del grupo parece haber sido la recolección de credenciales a gran escala, usando datos robados de casos de soporte de Salesforce para alimentar ataques posteriores contra los clientes de cada organización afectada.

¿Cómo ocurrió la filtración de Cloudflare?

Este es un ataque a la cadena de suministro B2B—de empresa a proveedor a proveedor—y entender la cadena importa.

Salesloft es una plataforma de interacción de ventas. Su producto Drift (desviación de configuración) es una herramienta de chat que se integra con Salesforce mediante OAuth, lo que le permite leer e interactuar con datos de CRM y soporte en nombre de los clientes. La cuenta de GitHub de Salesloft se vio comprometida desde marzo de 2025, lo que le dio a GRUB1 meses de acceso para realizar reconocimiento antes de que comenzara la fase activa del ataque en agosto.

Para cuando dirigieron su atención a Cloudflare, ya tenían tokens de OAuth válidos para la integración de Drift (desviación de configuración) con Salesforce. Esos tokens no requerían entrar por la fuerza en la red de Cloudflare; le dieron al atacante acceso autenticado a través de un canal de integración confiable que se mezclaba sin problemas con el tráfico normal de API.

Cronología del ataque

  • 9 de agosto de 2025: GRUB1 realiza un reconocimiento inicial e intenta validar un token de API de Cloudflare usando TruffleHog (un escáner de secretos de código abierto) como su agente de usuario. El token falla la validación.
  • 12 de agosto de 2025: GRUB1 inicia sesión en el inquilino de Salesforce de Cloudflare usando la credencial OAuth robada de desviación de configuración (Drift) desde la IP 44[.]215[.]108[.]109 y comienza a enumerar los objetos de datos disponibles.
  • 13 de agosto de 2025: GRUB1 regresa para extraer información del esquema de casos y comienza consultas amplias contra los objetos de casos de Cloudflare.
  • 14 de agosto de 2025: Día de reconocimiento extenso. GRUB1 cuenta cuentas, contactos y usuarios; analiza los flujos de trabajo de los casos; confirma que están en un entorno de producción; y consulta los límites de tasa de la API para entender cómo exfiltrar datos sin activar la detección.
  • 16 de agosto de 2025: GRUB1 regresa tras una pausa de 48 horas y ejecuta un conteo final de registros (SELECT COUNT() FROM Case) para confirmar el tamaño exacto del conjunto de datos que están a punto de robar.
  • 17 de agosto de 2025: GRUB1 cambia a nueva infraestructura (208[.]68[.]36[.]90) y usa la API Bulk 2.0 de Salesforce para exfiltrar todos los datos de texto de los casos en poco más de tres minutos. Intentan eliminar el trabajo para cubrir sus huellas, pero los registros residuales permiten a Cloudflare reconstruir por completo el ataque.
  • 20 de agosto de 2025: Salesloft revoca las conexiones de desviación de configuración (Drift) a Salesforce en toda su base de clientes. En este punto, Cloudflare aún no ha sido notificado.
  • 23 de agosto de 2025: Salesforce y Salesloft notifican a Cloudflare. Cloudflare inicia de inmediato su respuesta ante el incidente.
  • 25 al 29 de agosto de 2025: Cloudflare deshabilita la integración de desviación de configuración (Drift), elimina todo el software de Salesloft de su entorno, rota las credenciales en todos los servicios de terceros y comienza a analizar los datos exfiltrados en busca de secretos expuestos.
  • 2 de septiembre de 2025: Cloudflare revela públicamente el incidente y notifica directamente a todos los clientes afectados.

Detalles técnicos

GRUB1 accedió al entorno de Salesforce de Cloudflare por completo a través de la integración legítima de OAuth de desviación de configuración (Drift): sin malware, sin compromiso de endpoint, sin intrusión de red del lado de Cloudflare. El ataque tuvo éxito porque a la integración se le había otorgado acceso a los objetos de casos de Salesforce, y el atacante poseía credenciales válidas para esa integración.

La exfiltración usó Bulk API 2.0 nativa de Salesforce, diseñada para exportaciones de datos a gran escala. Luego GRUB1 intentó eliminar el trabajo de la API para ocultar sus huellas. El equipo forense de Cloudflare aun así pudo reconstruir el ataque completo a partir de los datos residuales de los registros.

Indicadores de compromiso (IoC)

Cloudflare no publicó indicadores de compromiso (IoC) específicos, como direcciones IP, hashes de archivos o dominios. La investigación se centró en el alcance del acceso dentro de las aplicaciones de terceros, en lugar de malware o intrusiones en la red de los propios sistemas de Cloudflare.

Investigación forense y de incidentes

El equipo de seguridad interno de Cloudflare realizó una investigación exhaustiva de inmediato al ser notificado. Trabajaron para entender el alcance completo de la vulneración al analizar los registros y los accesos dentro de las plataformas de proveedores comprometidas. Sus hallazgos confirmaron que ningún sistema de Cloudflare fue vulnerado directamente y que la exposición se limitó a los datos alojados en Salesloft y desviación de configuración. También tomaron medidas inmediatas para contener la amenaza al deshabilitar las integraciones y forzar el restablecimiento de contraseñas para los empleados afectados.

¿Qué datos se vieron comprometidos en la brecha de Cloudflare?

Los datos comprometidos se limitaron a la información de clientes usada para interacciones de ventas y soporte. Esto incluyó:

  • Nombres de clientes

  • Direcciones de correo electrónico

  • Números de teléfono

  • Nombres de empresas

  • El contenido de comunicaciones de soporte y ventas

Fundamentalmente, Cloudflare confirmó que no se expuso información financiera sensible, contraseñas ni datos de configuración centrales de clientes.

¿A cuántas personas afectó la brecha de datos de Cloudflare?

Cloudflare identificó 104 de sus propios tokens de autenticación de API en los datos exfiltrados y rotó todos de inmediato; no se identificó actividad sospechosa contra esos tokens de autenticación. Más allá de eso, no se ha cuantificado públicamente el número de clientes individuales cuya información de contacto o contenido de casos quedó expuesto, pero Cloudflare notificó directamente a cada cliente afectado por correo electrónico y notificación en el panel.

¿Se expusieron mis datos en la brecha de Cloudflare?

Si tu información fue expuesta, es probable que Cloudflare te hubiera notificado. La filtración afectó específicamente a personas que se habían comunicado con los equipos de ventas o soporte de Cloudflare. Si no interactuaste con estos equipos, es poco probable que tu información se haya visto involucrada. No existe una herramienta pública de búsqueda para verificar la exposición.

Impactos clave de la filtración de datos de Cloudflare

Aunque no fue una brecha catastrófica en sus sistemas principales, el incidente tuvo varios impactos clave:

  • Daño reputacional: Como empresa líder en ciberseguridad e infraestructura, cualquier incidente de seguridad, incluso indirecto, puede afectar la confianza.

  • Interrupción operativa: Cloudflare tuvo que suspender temporalmente el uso de las plataformas afectadas, lo que interrumpió los flujos de trabajo de ventas y soporte.

  • Preocupación de los clientes: La filtración generó preocupación entre los clientes sobre cómo se maneja su información, incluso por parte de terceros.

  • Escrutinio de la cadena de suministro: El incidente puso en evidencia los riesgos inherentes de depender de proveedores externos y la necesidad de una evaluación rigurosa.

Respuesta a la filtración de datos de Cloudflare

La respuesta de Cloudflare fue rápida y transparente. Pocas horas después de confirmar el incidente, la empresa publicó una entrada de blog detallada donde explicaba qué pasó, qué datos se expusieron y los pasos que estaban tomando. Esto incluyó:

  • Desactivar de inmediato las aplicaciones comprometidas.

  • Forzar la rotación de contraseñas y tokens de sesión para cualquier empleado que pudiera haberse visto afectado.

  • Trabajar con los proveedores para entender la causa raíz.

  • Comunicarse abiertamente con los clientes y el público.

Esta comunicación rápida y clara es un buen modelo para una respuesta eficaz ante una filtración de datos.

Lecciones de la filtración de datos de Cloudflare

Este incidente ofrece algunas conclusiones críticas para cualquier empresa. No querrás aprender esto de la manera difícil.

  • Tu seguridad es tan fuerte como tu proveedor más débil: Esta filtración es un ejemplo clásico de riesgo en la cadena de suministro. Debes evaluar y monitorear continuamente las prácticas de seguridad de todos tus proveedores externos.

  • La transparencia es clave: La divulgación rápida y detallada de Cloudflare ayudó a controlar la narrativa y mantener la confianza de los clientes. Cuando ocurre una filtración, ocultarla solo empeora las cosas. Adelántate a la situación.

  • Principio de privilegio mínimo: Limita los datos a los que pueden acceder las aplicaciones externas. Si Salesloft y desviación de configuración solo hubieran podido acceder al mínimo de datos necesarios, el impacto habría sido aún menor.

  • Ten un plan de respuesta a incidentes: Cloudflare pudo actuar rápido porque tenía un plan. ¿Tú tienes uno?

¿Es seguro Cloudflare después de la filtración?

Sí. Es importante reiterar que la infraestructura principal, la red y los servicios al cliente de Cloudflare nunca se vieron comprometidos. La seguridad interna de la empresa sigue siendo sólida. Tras el incidente, Cloudflare mejoró sus procesos de revisión de seguridad de proveedores y reforzó sus protocolos de seguridad internos para protegerse aún más contra ataques a la cadena de suministro.

Estrategias de mitigación y prevención

No puedes simplemente esperar que una filtración como esta no te pase a ti. Necesitas actuar. Aquí tienes algunos pasos prácticos para proteger a tu organización de ataques similares a la cadena de suministro:

  • Implementa la autenticación multifactor (MFA): Exige MFA en todos los servicios, especialmente en aplicaciones de terceros. Esto hace mucho más difícil que los atacantes usen credenciales robadas.

  • Realiza evaluaciones de seguridad de proveedores: Antes de firmar un contrato, haz tu tarea. Examina de cerca las prácticas de seguridad de cualquier proveedor que manejará tus datos.

  • Aplica el principio de mínimo privilegio: Asegúrate de que los usuarios y las aplicaciones externas solo tengan acceso a los datos y sistemas que necesitan estrictamente para hacer su trabajo. Nada más.

  • Monitoreo continuo: Usa herramientas de seguridad para monitorear actividad sospechosa en tu red y en tus aplicaciones en la cloud. Una alerta temprana puede marcar la diferencia.

  • Desarrolla un plan de respuesta a incidentes: Sabe exactamente a quién llamar y qué hacer cuando ocurre un incidente de seguridad. Practícalo.

Preguntas frecuentes sobre la filtración de datos de Cloudflare

Un actor de amenazas llamado GRUB1 robó credenciales de OAuth vinculadas a la integración del chatbot Drift (desviación de configuración) de Salesloft con Salesforce. Esas credenciales le dieron acceso autenticado al inquilino de Salesforce de Cloudflare, donde realizó nueve días de reconocimiento antes de exfiltrar en masa datos de casos de soporte. La red y la infraestructura propias de Cloudflare nunca se vieron afectadas.

Los datos expuestos se limitaron a información de interacciones de ventas y soporte. Esto incluyó nombres, direcciones de correo electrónico, números de teléfono y el contenido de las comunicaciones. No se comprometieron contraseñas, datos financieros ni detalles sensibles de configuración de clientes.

El actor de amenazas o grupo específico detrás del ataque a los proveedores de Cloudflare no se ha identificado públicamente. La investigación se centró en el compromiso de terceros, y el culpable final sigue siendo desconocido.

Las empresas pueden reducir su riesgo evaluando rigurosamente la seguridad de sus proveedores de software, implementando la autenticación multifactor en todas partes y aplicando el principio de mínimo privilegio para limitar el acceso a los datos. Contar con un plan de respuesta a incidentes bien ensayado también es fundamental para una reacción rápida.

Protege lo que importa

Protege endpoints, correo electrónico y empleados con el poder de nuestro SOC 24/7. Prueba Huntress gratis y despliega en minutos para empezar a combatir las amenazas.
Prueba Huntress gratis