Hackean a una empresa de ciberseguridad en México: BePrime expone datos y cámaras de Iberdrola, ArcelorMittal y Alsea

#security #cybersecurity #webdev #programming

El 15 de abril de 2026, el periodista mexicano Ignacio Gómez Villaseñor publicó en X que un actor con el alias dylanmarly había subido al foro Darkforums un manifiesto con datos exfiltrados de BePrime, una firma de ciberseguridad y conectividad con sede en Monterrey, Nuevo León. En las dos semanas siguientes, medios mexicanos y analistas independientes confirmaron que la brecha alcanzó al menos 12.6 GB de información, incluyendo credenciales en texto plano, llaves de API de Cisco Meraki, reportes de pentest de los clientes, transmisiones en vivo de cámaras y control sobre 1,858 dispositivos de red activos. Entre las empresas mencionadas como afectadas aparecen Iberdrola, ArcelorMittal, Whirlpool, Vitro, Grupo Bafar y Alsea —operador en México de Starbucks, Domino’s Pizza, Vips y Burger King—. El caso es la pesadilla clásica de la cadena de suministro digital: un proveedor único acumuló accesos privilegiados de varias corporaciones, y bastó una sola cuenta administrativa sin segundo factor para que todo terminara publicado.

Qué es BePrime y por qué su caída arrastra a tantos clientes

BePrime es una empresa regiomontana que ofrecía servicios de monitoreo de seguridad, redes y conectividad a corporativos grandes. En la jerga de seguridad, este tipo de proveedor opera como concentrador de confianza (trust concentrator): un solo vendor con accesos privilegiados a la infraestructura de varios clientes simultáneamente. Es un modelo eficiente desde el punto de vista comercial —un solo NOC, un solo equipo de monitoreo, economías de escala— pero que concentra todo el riesgo en un único punto.

Cuando ese punto cae, la onda expansiva no afecta a un cliente: afecta a todos los clientes a los que el proveedor tenía conectados. La promesa implícita del modelo —que el proveedor invertirá en seguridad mejor que cada cliente individual— solo se cumple si el proveedor lo hace. Y la causa raíz reportada del incidente sugiere que en este caso no fue así.

El vector de entrada: cuentas administrativas sin segundo factor

Según los reportes publicados por medios como Quinta Fuerza, el análisis técnico de SecAlly y la cobertura de Botcrawl, el atacante no necesitó un día cero, una cadena de exploits ni una operación sofisticada de ingeniería social. La causa raíz documentada fue cuentas con privilegios administrativos sin autenticación multifactor (MFA/2FA).

Una vez dentro, el atacante reutilizó esas credenciales para acceder a las API keys de Cisco Meraki que BePrime tenía guardadas para administrar las redes de sus clientes. Desde ahí, el alcance se replicó hacia abajo: cada cliente con infraestructura Meraki gestionada por BePrime quedó visible y, según el manifiesto del atacante, controlable. El control no se limitó al stack Meraki; los reportes describen también acceso a bases de datos PostgreSQL con credenciales de superusuario, agentes de monitoreo FortiMonitor con inventario de vulnerabilidades, y data lakes en MinIO/S3.

El detalle que más se ha resaltado en la cobertura no es la cifra de gigabytes, sino el carácter elemental del control que falló. La autenticación multifactor en cuentas privilegiadas es, literalmente, el primer ítem del primer capítulo de cualquier guía de hardening publicada por NIST, CIS o el propio Microsoft. Que una empresa cuyo trabajo es vender ciberseguridad no la tuviera activada en cuentas administrativas es la noticia detrás de la noticia.

Qué se filtró: el inventario del manifiesto

El actor dylanmarly publicó el dump y un manifiesto descriptivo en Darkforums. El inventario consolidado a partir de las fuentes de prensa y de los análisis de Botcrawl y SecAlly incluye:

~12.6 GB de datos en total (la cifra inicial del foro fue 10 GB; reportes posteriores ampliaron la cuenta).
1,858 dispositivos de red controlados —switches, routers y cámaras Meraki con GPS habilitado—.
2,600+ equipos visibles en el tráfico de las redes administradas.
48 bases de datos PostgreSQL con credenciales de superusuario.
9,966 casos de soporte de Salesforce con detalles financieros estimados en 2.37 millones de pesos.
1,722 vulnerabilidades de servidores identificadas a través del agente FortiMonitor de los clientes.
2.5 millones de registros de tracking WiFi de clientes en sucursales de Little Caesars.
Llaves de API de Cisco Meraki, credenciales en texto plano y tokens de acceso a múltiples plataformas.
Reportes de pentest realizados a clientes corporativos, con vulnerabilidades descritas en lenguaje claro.

Este último punto es particularmente delicado. Un reporte de pentest es, en esencia, un mapa actualizado de las debilidades de una empresa. Quien hoy tenga ese PDF tiene en sus manos la lista de cosas que están mal en Iberdrola, ArcelorMittal o Alsea según los propios auditores que las escanearon. El valor para un atacante secundario es mayor que el de la fuga original.

Quiénes son los afectados

Las fuentes consultadas mencionan, en distintas combinaciones, a las siguientes empresas como clientes de BePrime cuya información apareció en el dump:

Alsea —operador en México de Starbucks, Domino’s Pizza, Vips y Burger King—.
Iberdrola —energía, presencia global—.
ArcelorMittal —siderurgia—.
Whirlpool —electrodomésticos—.
Grupo Bafar —alimentos—.
Vitro —vidrio industrial—.
Interceramic —pisos y materiales—.
Little Caesars —cadena de pizzerías—.
NAZAN (Impuls).
CTU.
Mexicana de Gas.
Orsan.

El propio LinkedIn corporativo de BePrime documentó previamente al incidente una visita de Grupo Alsea a su NOC, lo que respalda la relación comercial, sin que ello implique necesariamente la magnitud del impacto en cada cliente. Hasta el cierre de esta nota, ninguna de las empresas mencionadas ha publicado un comunicado oficial confirmando o negando exposición específica.

La respuesta de BePrime: continencia operativa y amenazas legales a la prensa

BePrime reconoció públicamente el incidente, afirmó haber activado protocolos de contención y declaró que no hubo afectación a la continuidad operativa de sus servicios. La empresa no publicó indicadores de compromiso (IoC), no detalló timeline de detección y respuesta, ni explicó por qué cuentas privilegiadas operaban sin MFA al momento del incidente.

Lo más controvertido de la respuesta fue el componente legal: BePrime advirtió que tomaría acciones contra periodistas y publicaciones que difundieran «información falsa, inexacta o sacada de contexto». El mensaje generó pushback inmediato en la comunidad de seguridad mexicana, que en redes interpretó la postura como un intento de silenciar la cobertura en lugar de aportar transparencia técnica. La práctica habitual en incidentes responsables es la contraria: publicar un reporte público con timeline, alcance, IoC y medidas de remediación, para que la comunidad pueda validar y aprender. Cuando la primera reacción de un proveedor de seguridad es jurídica en lugar de técnica, el costo reputacional excede al del incidente original.

Por qué este caso es distinto: efecto cascada en supply chain

La industria lleva años hablando de ataques de cadena de suministro como el riesgo emergente más serio para empresas grandes. El caso BePrime es un ejemplar canónico de la categoría, con varias particularidades que lo hacen especialmente útil para entender el patrón:

1. El radio de impacto se mide en clientes, no en datos. Si Iberdrola hubiera sufrido una brecha equivalente directamente en su infraestructura, el alcance se limitaba a Iberdrola. Al ocurrir en BePrime, el alcance simultáneo abarca al menos a una docena de corporaciones grandes. La métrica relevante no es «cuántos GB se filtraron» sino «cuántas empresas tienen que tratar este incidente como si fuera propio».

2. La causa raíz es elemental, no exótica. No fue una vulnerabilidad nueva en Cisco Meraki. No fue un implante en la cadena de build. Fue ausencia de MFA en cuentas administrativas. Esto es importante porque significa que la mitigación es conocida, barata y ampliamente documentada. El fallo es de gobernanza, no de capacidades.

3. Los datos accesorios son a veces más valiosos que los datos primarios. Las credenciales y las llaves de API permiten al atacante seguir actuando aunque BePrime las rote (mientras el cliente no rote también). Los reportes de pentest son utilizables por cualquier tercero que los obtenga. El control sobre cámaras y dispositivos de red no necesita más fuga: es uso operativo del acceso.

4. La asimetría de comunicación pesa. El cliente final paga por la promesa de seguridad, pero no audita el proveedor con la profundidad necesaria. Cuando ocurre el incidente, el cliente se entera por la prensa, no por su proveedor. Esa asimetría destruye más confianza que el incidente técnico mismo.

Lecciones para empresas en LATAM

El caso es particularmente relevante para empresas medianas y grandes en América Latina porque el modelo de outsourcing de seguridad a un solo proveedor regional es común en la región, donde los equipos internos de ciberseguridad son escasos y caros. Algunas tomas de acción razonables:

Auditar al auditor. Pedir al proveedor evidencias concretas: cuentas con MFA habilitada, política de rotación de llaves, segregación de datos por cliente, reporte de incidentes anteriores. Si el proveedor no puede demostrar lo que vende, el problema no es del incidente: es del contrato.
Segregación por cliente. Las llaves de API y credenciales de un cliente no deberían vivir en el mismo silo que las de otros clientes en el lado del proveedor. La compromisión de un cliente no debe escalar lateralmente.
Inventario propio de accesos delegados. Las empresas necesitan saber qué llaves tienen entregadas a qué proveedores y qué pasaría si un proveedor las pierde. La rotación periódica obligatoria es barata y reduce el blast radius.
Plan de respuesta ante caída del proveedor. Asumir que el proveedor de seguridad puede ser comprometido y diseñar el modelo operativo para sobrevivirlo. Tener una vía alterna de monitoreo, alguna forma de detectar tráfico anómalo aunque el SOC del proveedor caiga, y procedimientos para revocar accesos en bloque.
MFA obligatorio en cuentas privilegiadas. Sin excepción, sin atajos para «convenience», sin desactivaciones temporales. Tanto del lado del cliente como del proveedor. Esta es la línea que falló en BePrime y que falla en la mayoría de incidentes documentados de la última década.

La ironía del caso es difícil de ignorar: la firma contratada para defender a sus clientes ahora es el vector que los expone. Pero el dato útil no está en la ironía, sino en la causa: si una empresa que vende ciberseguridad no tenía MFA en cuentas administrativas, vale la pena verificar si la propia organización lo tiene. Estadísticamente, la respuesta probable es la misma.