BePrime-Breach: Fehlende MFA führt zu Datenleck
Eine Sicherheitsfirma richtet keine MFA auf eigenen Admin-Konten ein. Ein gestohlenes Passwort später: 12,6 GB Kundendaten öffentlich, 1.858 Netzwerkgeräte unter fremder Kontrolle – und Klartextpasswörter in den gestohlenen Dateien.
6 Min. Lesezeit
Das Wichtigste in Kürze
- Kein MFA, ein Passwort, Vollzugriff. Ein gestohlener Admin-Zugang ohne zweiten Faktor reichte für den vollständigen Systemzugriff.
- 12,6 GB Daten öffentlich. Klartextpasswörter, PostgreSQL-Superuser-Credentials, MinIO S3-Daten und Meraki API-Keys wurden gestohlen und veröffentlicht.
- 1.858 Netzwerkgeräte übernommen. Über gestohlene Cisco Meraki API-Keys wurden Kundengeräte übernommen – Surveillance-Cameras waren live zugänglich.
- Kunden exponiert. Iberdrola, Whirlpool, Alsea und ArcelorMittal – darunter vertrauliche Sicherheits-Auditberichte mit dokumentierten Schwachstellen.
- Reaktion: Anwaltspost. BePrimes Incident-Response bestand hauptsächlich aus juristischen Drohungen gegen berichtende Journalisten.
Was ist BePrime? BePrime ist ein mexikanischer Cybersecurity-Dienstleister der Managed-Security-Services für mittelständische und große Unternehmen anbietet. Zu ihren Kunden zählen Unternehmen aus den Bereichen Energie, Stahl, Konsumgüter und Gastronomie – allesamt Branchen mit hohem Schutzbedarf für Betriebstechnologie und Netzwerkinfrastruktur.
Der Incident bei BePrime ist deshalb lehrreich, weil er zeigt was passiert wenn Compliance und Security-Ops auseinanderfallen. BePrime ist kein kleines Startup ohne Security-Budget. Das Unternehmen ist Cybersecurity-Dienstleister – schützt also professionell andere Firmen vor genau diesen Angriffen. Und hat die einfachste verfügbare Kontrolle im eigenen Haus nicht umgesetzt.
Das ist der Kern dieser Case Study: nicht dass MFA fehlt, sondern dass der Abstand zwischen Compliance-Rhetorik und operativer Security-Realität so groß ist, dass er selbst in Sicherheitsfirmen existiert.
Was der Angreifer vorfand: ein offenes System
Der Ablauf war unspektakulär. Angreifer-Alias „dylanmarly“ erlangte Zugang zu einem Admin-Account ohne Multi-Faktor-Authentifizierung. Ein gestohlenes Passwort reichte für vollständigen Systemzugriff. Was dann folgte, war keine fortgeschrittene Intrusion – sondern ein schlichtes Abgreifen von allem was erreichbar war.
Was in den 12,6 GB gestohlenen Daten steckte:
- Klartextpasswörter – Credentials wurden nicht gehasht oder verschlüsselt gespeichert. Ein grundlegender Fehler der seit Jahrzehnten als inakzeptabel gilt.
- PostgreSQL-Superuser-Credentials – Vollzugriff auf Datenbanken die Kundendaten enthielten. Ein einzelnes Credential, kein Rotationskonzept.
- MinIO S3-Bucket-Daten – Object-Storage mit internen Dokumenten; MinIO wird typischerweise für sensible betriebliche Daten genutzt.
- Cisco Meraki API-Keys – Hier liegt die eigentliche Eskalation: Meraki-API-Keys erlauben vollständige Kontrolle über angebundene Netzwerkgeräte. 1.858 Geräte wurden übernommen.
- Interne Sicherheits-Auditberichte von Kunden – Das ist der problematischste Teil für Betroffene. Diese Dokumente beschreiben Schwachstellen in Kundeninfrastrukturen. Sie sind jetzt öffentlich zugänglich.
- Live-Surveillance-Feeds – Über die übernommenen Meraki-Konsolen waren Kamera-Feeds aktiver Überwachungsanlagen zugänglich.
Die Kunden die in den gestohlenen Daten auftauchen: Iberdrola (Energieversorger), Whirlpool, ArcelorMittal und Alsea (Betreiber von Starbucks und Domino’s in Lateinamerika).
Compliance-Theater versus echte Security-Ops
| Was BePrime hatte | Was fehlte |
|---|---|
| Security-Dienstleistungsangebot für Kunden | MFA auf eigenen Admin-Konten |
| Audit-Reports über Kundensicherheit | Verschlüsselung von Credentials in der Datenbank |
| Vertrauensstellung bei sensiblen Kunden | Least Privilege für API-Keys und Service-Accounts |
| Öffentliche Kommunikation über Expertise | Credential-Rotation und Monitoring auf API-Key-Nutzung |
| Kundendaten gelagert und verwaltet | Incident Response der nicht aus Anwaltsbriefen besteht |
Die Reaktion: ein Lehrstück in falschen Prioritäten
Nach Bekanntwerden des Breach veröffentlichte BePrime keine technische Analyse. Keine öffentliche Kundenkommunikation. Stattdessen: juristische Drohungen gegen Journalisten die über den Vorfall berichteten.
Das ist ein Muster das Security-Teams kennen sollten – nicht weil es selten wäre, sondern weil es ein zuverlässiges Signal für den Reifegrad eines Unternehmens ist. Wer im Incident-Stress als erstes an die Rechtsabteilung denkt statt an forensische Aufarbeitung und Kundenkommunikation, hat Security nicht als operative Disziplin verinnerlicht.
Der Ironiefaktor ist hoch: BePrime erstellt Sicherheits-Auditberichte für Kunden – genau diese Berichte lagen unverschlüsselt im System und sind jetzt öffentlich. Inklusive der darin dokumentierten Schwachstellen der Kunden. Das ist nicht nur ein Reputationsschaden für BePrime, das ist ein direktes Risiko für Iberdrola, ArcelorMittal, Whirlpool und Alsea.
Was DACH-Security-Teams konkret tun können
Drei direkt umsetzbare Konsequenzen aus diesem Incident:
Erstens: Vendor-Security-Assessments müssen technisch sein, nicht nur dokumentenbasiert. Ein Fragebogen der nach MFA fragt ist kein Beweis dass MFA aktiv ist. Zugang zu einem technischen Nachweis – oder zumindest ein Entra-/Okta-Reporting-Screenshot – sollte Standard werden.
Zweitens: Drittanbieter-API-Keys brauchen Scoping und Rotation. Meraki-API-Keys mit vollem Zugriff auf 1.858 Geräte in einem Dienstleister-System sind ein Risiko unabhängig davon wie gut der Dienstleister gesichert ist. Least-Privilege-API-Keys die nur lesen und automatisch rotieren sind besser als Full-Access-Dauerzugang.
Drittens: Sicherheits-Auditberichte sind hochsensible Dokumente. Sie beschreiben Schwachstellen. Ihre Lagerung beim Dienstleister muss denselben Schutzanforderungen genügen wie die beschriebenen Systeme selbst.
Häufige Fragen
Was ist Multi-Faktor-Authentifizierung und warum reicht ein Passwort allein nicht?
MFA verlangt neben dem Passwort einen zweiten Nachweis – typischerweise einen TOTP-Code oder Push-Notification. Ein gestohlenes Passwort allein gibt damit keinen Zugang. Im BePrime-Fall hätte MFA den Angriff mit hoher Wahrscheinlichkeit gestoppt, da der Angreifer keinen Zugriff auf das zweite Faktor-Gerät hatte.
Warum sind Klartextpasswörter in Datenbanken ein eigenständiges Risiko?
Gestohlene gehashte Passwörter können mit modernen GPUs oft geknackt werden, aber das kostet Zeit und Ressourcen. Klartextpasswörter sind sofort nutzbar – für Credential-Stuffing gegen andere Dienste, Lateral Movement und Account-Takeover. Klartextspeicherung ist kein Konfigurationsfehler, sondern ein Grundfehler der in keinem System existieren darf das Produktionsdaten hält.
Was sollten betroffene Unternehmen (Kunden von BePrime) jetzt tun?
Priorität eins: alle Credentials rotieren die BePrime jemals zugänglich waren – API-Keys, Service-Account-Passwörter und geteilte Zugänge. Priorität zwei: prüfen ob in den öffentlich verfügbaren gestohlenen Daten Details zum eigenen Netzwerk enthalten sind. Priorität drei: die Meraki-Konfigurationen und Audit-Logs der eigenen Geräte auf unberechtigte Zugriffe prüfen.
Wie hätte MFA diesen Angriff konkret gestoppt?
MFA greift an der Authentifizierungsschicht. Wenn der Angreifer „dylanmarly“ ein Admin-Passwort hatte aber keinen Zugriff auf das zweite Faktor-Gerät, wäre der Login gescheitert. Es gibt Szenarien in denen MFA umgangen werden kann (SIM-Swapping, Authenticator-Phishing), aber diese erfordern erheblich mehr Aufwand als ein einfacher Credential-Diebstahl. Der BePrime-Breach sah nicht nach einem zielgerichteten sophistizierten Angriff aus.
Welche Compliance-Standards machen MFA für Privileged Accounts zur Pflicht?
NIS2 schreibt in Artikel 21 technische und organisatorische Maßnahmen zur Sicherung privilegierter Zugänge vor – MFA ist dort implizit, in nationalen Umsetzungen oft explizit. DORA verlangt für Finanzdienstleister IAM-Controls die MFA umfassen. ISO 27001:2022 nennt MFA in Annex A explizit als Kontrolle für privilegierten Zugang. Für einen Sicherheitsdienstleister der in NIS2-relevanten Sektoren tätig ist, war das kein optionales Nice-to-have.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Tima Miroshnichenko / Pexels
