Schwache Passwörter und verspätete Erkennung beim Datenleck im dänischen CPR-Register
Die Verwendung des Passworts „123456“ durch ein kleines IT-Unternehmen ermöglichte unbefugten Zugriff auf das dänische Zivilregister über 21 Tage hinweg und legte Daten von 8,8 Millionen Menschen offen.
Automatisch aus dem englischen Original übersetzt.
Hacker nutzten schwache Zugangsdaten bei einem kleinen dänischen IT-Unternehmen aus, um über drei Wochen im September 2026 auf das nationale Zivilregistrierungssystem (CPR) zuzugreifen. Das Leck legte personenbezogene Daten von rund 8,8 Millionen Bürgern frei und hob kritische Versäumnisse bei grundlegenden Zugriffskontrollen und Überwachungsmaßnahmen hervor.
Was passiert ist
Der Angriff richtete sich gegen Pays ApS, ein Zwei-Mitarbeiter-IT-Unternehmen mit Sitz in Odense, das legitime Zugriffsrechte für Abfragen der CPR-Datenbank besaß. Berichten von Politiken und TV 2 zufolge verschafften sich Angreifer mit dem Passwort „123456“ Zugang zu mindestens drei Konten, darunter ein Administratorkonto. Jens Myrup Pedersen, Professor an der Aarhus University, bezeichnete diese Sicherheitslage als „hoffnungslos“ und wies darauf hin, dass solche gängigen Passwörter bei automatisierten Angriffen zu den ersten Ratestücken gehören.
Nach dem Eindringen setzte der Angreifer eigene Skripte ein, um Daten zu extrahieren und extern zu speichern. Der unbefugte Zugriff begann am 10. September und dauerte bis zum 2. Oktober, insgesamt 21 Tage und 17 Stunden. Vorläufige Ermittlungen deuten darauf hin, dass die aktive Datenexfiltration möglicherweise um den 20. September eingestellt wurde, die Verbindung aber noch weitere zehn Tage offen blieb. Das Leck wurde erst entdeckt, als Behörden eine anomal hohe Rechnung für Suchabfragen bemerkten, die etwa 14 Millionen Abfragen umfasste und das normale operative Volumen des Unternehmens weit überstieg.
Wichtige Details
- Betroffene Entität: Pays ApS, ein kleines IT-Unternehmen mit zwei Mitarbeitern, bestätigte, dass es der Einfallstor für den Angriff war.
- Schwache Zugangsdaten: Mindestens drei Konten, einschließlich eines Admin-Kontos, verwendeten das Passwort „123456“.
- Umfang der Offenlegung: Auf Daten, die mit rund 8,8 Millionen CPR-Nummern verknüpft waren, wurde zugegriffen.
- Dauer: Der Angreifer hatte vom 10. September bis zum 2. Oktober 2026 21 Tage und 17 Stunden lang Zugriff.
- Erkennungsmethode: Das Leck wurde über Rechnungsanomalien identifiziert, nicht über Sicherheitswarnungen; 14 Millionen Suchvorgänge wurden markiert.
- Angreifer-Behauptung: Ein anonymer Hacker gab an, ein geleaktes Passwort eines ehemaligen Mitarbeiters verwendet zu haben, und plante nicht, die Daten zu veröffentlichen.
Hintergrund
Das CPR-Register ist Dänemarks zentrale Datenbank für die Zivilregistrierung und enthält wesentliche persönliche Informationen wie Namen, Adressen und Identifikationsnummern der Einwohner. Private Unternehmen können Zugang zu diesem System beantragen, wenn sie einen legitimen Bedarf nachweisen, beispielsweise zur Überprüfung von Kundenadressen oder zur Verwaltung von Mitgliederlisten. Dieser Zugang wird typischerweise durch strenge Nutzungsrichtlinien und Auditierungsmechanismen geregelt, um Missbrauch zu verhindern.
In diesem Fall war das Sicherheitsversagen kein komplexer technischer Exploit, sondern ein grundlegender Mangel im Identitätsmanagement. Die Verwendung leicht erratbarer Passwörter wie „123456“ macht ausgefeilte Hacking-Tools überflüssig. Darüber hinaus unterstreicht die Verzögerung bei der Erkennung ein häufiges Problem bei Drittanbieter-Zugangsmodellen: Ohne Echtzeitüberwachung von Abfragevolumina oder Verhaltensanomalien können Lecks unentdeckt bleiben, bis finanzielle oder administrative Unstimmigkeiten auftreten.
Warum es wichtig ist
Für Teams, die Self-Hosted-Software verwalten oder in externe APIs integrieren, dient dieser Vorfall als deutliche Erinnerung daran, dass menschliche Faktoren oft schwerer wiegen als technische Verteidigungsmaßnahmen. Selbst wenn Ihre Infrastruktur gegen Netzwerkangriffe gehärtet ist, schaffen schwache Zugangsdaten auf privilegierten Konten ein offenes Tor. Kleine Teams, wie das hier beteiligte Zwei-Personen-Unternehmen, verfügen möglicherweise nicht über dediziertes Sicherheitspersonal, was sie anfällig für einfache Nachlässigkeiten macht, die massive nachgelagerte Konsequenzen haben.
Die Abhängigkeit von Rechnungsaudits zur Erkennung ist besonders besorgniserregend für DevOps- und IT-Leiter. Wenn man auf eine ungewöhnliche Rechnung wartet, ist der Schaden bereits angerichtet. In einer Self-Hosted-Umgebung müssen Sie davon ausgehen, dass Standard-Logging für die Sicherheitsüberwachung nicht ausreicht. Sie benötigen proaktive Warnmeldungen für anomales Verhalten, wie plötzliche Spitzen bei API-Aufrufen oder Anmeldeversuche von ungewöhnlichen Standorten, um das Fenster der Exposition zu verkürzen.
Zusätzlich erweitert die Nutzung von Drittanbietern mit Zugang zu sensiblen Daten Ihre Angriffsfläche. Wenn Sie externen Partnern oder internen Diensten Zugang zu kritischen Datenbanken gewähren, sind Sie dafür verantwortlich, sicherzustellen, dass sie robuste Sicherheitsstandards einhalten. Ein Leck bei einem kleinen Anbieter kann Ihr gesamtes Ökosystem gefährden und zu regulatorischer Prüfung sowie Vertrauensverlust führen.
Was Sie tun können
- Starke Passwortrichtlinien durchsetzen: Schreiben Sie komplexe Passwörter vor und nutzen Sie einen Passwortmanager, um Wiederverwendung zu vermeiden. Erlauben Sie niemals Standard- oder gängige Passwörter wie „123456“.
- Multi-Faktor-Authentifizierung (MFA) implementieren: Fordern Sie MFA für alle administrativen Konten und jeden Dienst mit Zugang zu sensiblen Daten.
- API-Nutzung aktiv überwachen: Richten Sie Warnmeldungen für ungewöhnliche Spitzen bei Abfragevolumina oder Datenexporten ein, statt sich auf monatliche Rechnungsprüfungen zu verlassen.
- Drittanbieter-Zugänge auditieren: Überprüfen Sie regelmäßig, wer Zugang zu Ihren Systemen hat, und widerrufen Sie Berechtigungen für ehemalige Mitarbeiter oder ungenutzte Konten sofort.
- Zugangsdaten regelmäßig rotieren: Ändern Sie Passwörter und API-Schlüssel periodisch, insbesondere nach Personalwechseln oder wenn die Sicherheitslage eines Anbieters infrage gestellt wird.
- Penetrationstests durchführen: Simulieren Sie Angriffe, um Schwachstellen in Ihrer Authentifizierungs- und Überwachungskonfiguration zu identifizieren, bevor echte Angreifer dies tun.



