BePrime Breach: Lack of MFA Causes Data Leak

A security firm fails to set up MFA on its own admin accounts. One stolen password later: 12.6 GB of customer data made public, 1,858 network devices under outside control – plus plaintext passwords in the stolen files.

What is BePrime? BePrime is a Mexican cybersecurity provider that offers managed security services to mid-sized and large companies. Its customers include companies from the energy, steel, consumer goods and food service sectors – all industries with a high need to protect operational technology and network infrastructure.

The BePrime incident is instructive because it shows what happens when compliance and security operations drift apart. BePrime is no small startup without a security budget. The company is a cybersecurity provider – it professionally protects other firms against exactly these attacks. Yet it failed to implement the simplest available control in-house.

That is the core of this case study: the missing MFA matters less than the gap between compliance rhetoric and operational security reality. That gap is so wide that it exists even inside security firms.

What the attacker found: an open system

The sequence of events was unspectacular. An attacker using the alias “dylanmarly” gained access to an admin account without multi-factor authentication. One stolen password was enough for full system access. What followed required no advanced intrusion technique: the attacker simply grabbed everything within reach.

What the 12.6 GB of stolen data contained:

1. Plaintext passwords – Credentials were stored without hashing or encryption. A basic mistake that has been considered unacceptable for decades.
2. PostgreSQL superuser credentials – Full access to databases holding customer data. A single credential with no rotation concept.
3. MinIO S3 bucket data – Object storage with internal documents; MinIO is typically used for sensitive operational data.
4. Cisco Meraki API keys – This is where the real escalation lies: Meraki API keys grant full control over connected network devices. 1,858 devices were taken over.
5. Internal customer security audit reports – This is the most problematic part for those affected. These documents describe vulnerabilities in customer infrastructures. They are now publicly accessible.
6. Live surveillance feeds – Through the hijacked Meraki consoles, camera feeds from active surveillance systems were accessible.

The customers that appear in the stolen data: Iberdrola (energy utility), Whirlpool, ArcelorMittal and Alsea (operator of Starbucks and Domino’s in Latin America).

Compliance theater versus real security ops

What BePrime had	What was missing
Security services portfolio for customers	MFA on its own admin accounts
Audit reports on customer security	Encryption of credentials in the database
Position of trust with sensitive customers	Least privilege for API keys and service accounts
Public communication about its expertise	Credential rotation and monitoring of API key usage
Customer data stored and managed	Incident response that goes beyond lawyers’ letters

The response: a lesson in misplaced priorities

After the breach became public, BePrime released no technical analysis. No public communication to customers. Instead: legal threats against journalists who reported on the incident.

Security teams should know this pattern well. The reason has little to do with rarity: it is a reliable signal of how mature a company is. Anyone whose first thought under incident pressure goes to the legal department instead of forensic investigation and customer communication has failed to internalize security as an operational discipline.

The irony is hard to miss: BePrime writes security audit reports for customers – and exactly these reports sat unencrypted in the system and are now public. Including the customer vulnerabilities documented in them. Beyond the reputational damage for BePrime, this creates a direct risk for Iberdrola, ArcelorMittal, Whirlpool and Alsea.

What DACH security teams can concretely do

Three directly actionable consequences of this incident:

First: vendor security assessments must include technical verification, since documents alone prove little. A questionnaire that asks about MFA is no proof that MFA is active. Access to technical evidence – or at least an Entra/Okta reporting screenshot – should become standard.

Second: third-party API keys need scoping and rotation. Meraki API keys with full access to 1,858 devices in a service provider’s system are a risk regardless of how well the provider is secured. Least-privilege API keys that are read-only and rotate automatically beat permanent full-access credentials.

Third: security audit reports are highly sensitive documents. They describe vulnerabilities. Wherever the service provider stores them, they must meet the same protection requirements as the systems they describe.

Frequently Asked Questions

Each question is locked. One tap unlocks the answer.

What is multi-factor authentication and why is a password alone insufficient?

MFA requires a second proof in addition to the password – typically a TOTP code or a push notification. A stolen password alone therefore grants no access. In the BePrime case, MFA would very likely have stopped the attack, since the attacker had no access to the second-factor device.

Why are plaintext passwords in databases a risk in their own right?

Stolen hashed passwords can often be cracked with modern GPUs, yet that costs time and resources. Plaintext passwords are usable immediately – for credential stuffing against other services, lateral movement and account takeover. Storing passwords in plaintext goes beyond a configuration error: it is a fundamental flaw that has no place in any system holding production data.

What should affected companies (BePrime customers) do now?

Priority one: rotate all credentials BePrime ever had access to – API keys, service account passwords and shared logins. Priority two: check whether the publicly available stolen data contains details about their own network. Priority three: review the Meraki configurations and audit logs of their own devices for unauthorized access.

How exactly would MFA have stopped this attack?

MFA works at the authentication layer. If the attacker “dylanmarly” had an admin password but no access to the second-factor device, the login would have failed. There are scenarios in which MFA can be bypassed (SIM swapping, authenticator phishing), yet these require considerably more effort than simple credential theft. The BePrime breach did not look like a targeted, sophisticated attack.

Which compliance standards make MFA mandatory for privileged accounts?

Article 21 of NIS2 requires technical and organizational measures to secure privileged access – MFA is implicit there and often explicit in national implementations. DORA requires financial service providers to have IAM controls that include MFA. ISO 27001:2022 explicitly names MFA in Annex A as a control for privileged access. For a security provider operating in NIS2-relevant sectors, MFA was never an optional nice-to-have.