BePrime-Breach: La falta de MFA provoca filtraciones de datos.

Una empresa de seguridad no activa la MFA en sus propias cuentas de administrador. Tras el robo de una sola contraseña: 12,6 GB de datos de clientes expuestos públicamente, 1.858 dispositivos de red bajo control ajeno – y contraseñas en texto plano en los archivos robados.

¿Qué es BePrime? BePrime es un proveedor mexicano de ciberseguridad que ofrece servicios de seguridad gestionada a medianas y grandes empresas. Entre sus clientes figuran compañías de los sectores de energía, acero, bienes de consumo y restauración – todos ellos sectores con una elevada necesidad de protección de la tecnología operativa y la infraestructura de red.

El incidente de BePrime resulta instructivo porque muestra lo que ocurre cuando el cumplimiento normativo y las operaciones de seguridad se separan. BePrime no es una pequeña startup sin presupuesto de seguridad. La empresa es un proveedor de ciberseguridad, es decir, protege profesionalmente a otras compañías frente a exactamente este tipo de ataques. Y no aplicó en su propia casa el control más sencillo disponible.

Ese es el núcleo de este caso práctico: la ausencia de MFA es solo el síntoma. Lo relevante es que la distancia entre la retórica del cumplimiento y la realidad operativa de la seguridad es tan grande que existe incluso en las empresas de seguridad.

Lo que encontró el atacante: un sistema abierto

El desarrollo fue poco espectacular. El atacante con el alias «dylanmarly» obtuvo acceso a una cuenta de administrador sin autenticación multifactor. Una contraseña robada bastó para obtener acceso completo al sistema. Lo que siguió fue una simple recolección de todo lo que estaba al alcance, sin ninguna intrusión avanzada.

Lo que contenían los 12,6 GB de datos robados:

1. Contraseñas en texto plano – Las credenciales se almacenaban sin hash ni cifrado. Un error básico que se considera inaceptable desde hace décadas.
2. Credenciales de superusuario de PostgreSQL – Acceso total a bases de datos que contenían datos de clientes. Una sola credencial y ningún concepto de rotación.
3. Datos de buckets de MinIO S3 – Almacenamiento de objetos con documentos internos; MinIO se utiliza habitualmente para datos operativos sensibles.
4. Claves API de Cisco Meraki – Aquí está la verdadera escalada: las claves API de Meraki permiten el control total de los dispositivos de red conectados. Se tomó el control de 1.858 dispositivos.
5. Informes internos de auditoría de seguridad de clientes – Es la parte más problemática para los afectados. Estos documentos describen vulnerabilidades en las infraestructuras de los clientes. Ahora son de acceso público.
6. Transmisiones de vigilancia en directo – A través de las consolas de Meraki comprometidas se podía acceder a las imágenes de cámaras de sistemas de vigilancia activos.

Los clientes que aparecen en los datos robados: Iberdrola (compañía energética), Whirlpool, ArcelorMittal y Alsea (operador de Starbucks y Domino’s en Latinoamérica).

Teatro del cumplimiento frente a operaciones de seguridad reales

Lo que BePrime tenía	Lo que faltaba
Oferta de servicios de seguridad para clientes	MFA en sus propias cuentas de administrador
Informes de auditoría sobre la seguridad de los clientes	Cifrado de credenciales en la base de datos
Relación de confianza con clientes sensibles	Mínimo privilegio para claves API y cuentas de servicio
Comunicación pública sobre su experiencia	Rotación de credenciales y monitorización del uso de claves API
Datos de clientes almacenados y gestionados	Una respuesta a incidentes que va más allá de las cartas de abogados

La reacción: una lección de prioridades equivocadas

Tras conocerse la brecha, BePrime no publicó ningún análisis técnico. Tampoco hubo comunicación pública a los clientes. En su lugar llegaron amenazas legales contra los periodistas que informaron sobre el incidente.

Es un patrón que los equipos de seguridad deberían conocer. Aparece con frecuencia y es una señal fiable del grado de madurez de una empresa. Quien, bajo la presión de un incidente, piensa primero en el departamento jurídico antes que en el análisis forense y la comunicación con los clientes, no ha interiorizado la seguridad como disciplina operativa.

La ironía es evidente: BePrime elabora informes de auditoría de seguridad para sus clientes – precisamente esos informes estaban sin cifrar en el sistema y ahora son públicos. Incluidas las vulnerabilidades de los clientes documentadas en ellos. Además del daño reputacional para BePrime, esto supone un riesgo directo para Iberdrola, ArcelorMittal, Whirlpool y Alsea.

Qué pueden hacer en concreto los equipos de seguridad de la región DACH

Tres consecuencias directamente aplicables de este incidente:

Primero: las evaluaciones de seguridad de proveedores deben ser técnicas y apoyarse en algo más que documentos. Un cuestionario que pregunta por la MFA no demuestra que la MFA esté activa. El acceso a una prueba técnica – o al menos una captura de pantalla de los informes de Entra/Okta – debería convertirse en estándar.

Segundo: las claves API de terceros necesitan un alcance limitado y rotación. Claves API de Meraki con acceso total a 1.858 dispositivos dentro del sistema de un proveedor son un riesgo, independientemente de lo bien protegido que esté el proveedor. Las claves API de mínimo privilegio, solo de lectura y con rotación automática, son mejores que un acceso completo permanente.

Tercero: los informes de auditoría de seguridad son documentos altamente sensibles. Describen vulnerabilidades. Su almacenamiento en el proveedor debe cumplir los mismos requisitos de protección que los propios sistemas descritos.

Preguntas frecuentes

Cada pregunta está cerrada. Un toque desbloquea la respuesta.

¿Qué es la autenticación multifactor y por qué no basta con una contraseña?

La MFA exige, además de la contraseña, una segunda prueba – normalmente un código TOTP o una notificación push. Así, una contraseña robada por sí sola no da acceso. En el caso de BePrime, la MFA habría detenido el ataque con alta probabilidad, ya que el atacante no tenía acceso al dispositivo del segundo factor.

¿Por qué las contraseñas en texto plano en bases de datos son un riesgo por sí mismas?

Las contraseñas con hash robadas a menudo pueden descifrarse con GPU modernas, aunque eso cuesta tiempo y recursos. Las contraseñas en texto plano se pueden usar de inmediato – para credential stuffing contra otros servicios, movimiento lateral y toma de cuentas. Guardar contraseñas en texto plano va más allá de un fallo de configuración: es un error de base que no debe existir en ningún sistema con datos de producción.

¿Qué deberían hacer ahora las empresas afectadas (clientes de BePrime)?

Prioridad uno: rotar todas las credenciales a las que BePrime haya tenido acceso alguna vez – claves API, contraseñas de cuentas de servicio y accesos compartidos. Prioridad dos: comprobar si los datos robados disponibles públicamente contienen detalles de la propia red. Prioridad tres: revisar las configuraciones de Meraki y los registros de auditoría de los propios dispositivos en busca de accesos no autorizados.

¿Cómo habría detenido la MFA este ataque en concreto?

La MFA actúa en la capa de autenticación. Si el atacante «dylanmarly» tenía una contraseña de administrador pero ningún acceso al dispositivo del segundo factor, el inicio de sesión habría fallado. Hay escenarios en los que la MFA puede eludirse (SIM swapping, phishing de autenticadores), pero exigen bastante más esfuerzo que un simple robo de credenciales. La brecha de BePrime no parecía un ataque sofisticado y dirigido.

¿Qué estándares de cumplimiento hacen obligatoria la MFA para cuentas privilegiadas?

La NIS2 establece en su artículo 21 medidas técnicas y organizativas para proteger los accesos privilegiados – la MFA está implícita allí y a menudo es explícita en las transposiciones nacionales. DORA exige a los proveedores de servicios financieros controles de IAM que incluyan la MFA. La ISO 27001:2022 cita la MFA de forma explícita en el anexo A como control para el acceso privilegiado. Para un proveedor de seguridad que opera en sectores relevantes para la NIS2, la MFA era una obligación clara.