Warum exponierte Datenbanken nachts Kopfzerbrechen bereiten sollten

Fangen wir mit einer Zahl an, die keinen Raum für Interpretation lässt: Bei kürzlich untersuchten 2.931 offenen MySQL-Datenbanken waren 2.930 bereits von Ransomware-Gruppen als Ziel markiert. Das ist keine Vermutung. Das ist kein "könnte passieren." Das ist Fakt.

Die Zahl dahinter? Enorm: 99,96 Prozent.

Wenn du bisher dachtest, dass eine exponierte Datenbank vielleicht unbemerkt bleibt – still vor sich hin wartet, bis zufällig jemand darüber stolpert – dann solltest du das Bild sofort über den Haufen werfen. Bedrohungsakteure warten nicht. Sie beobachten längst.

Ein Angriffsschema, das seit sechs Jahren funktioniert

Das Unbequeme daran: Die Methodik, die hier zum Einsatz kommt, ist alles andere als hochentwickelt. Keine Zero-Day-Exploits, keine nationstaatlichen Superhirne. Was wir sehen, ist im Wesentlichen derselbe Ansatz, der seit etwa 2019 bis 2020 die Runde macht.

Konkret läuft es so ab:

• Automatisiertes Scannen nach offenen Datenbank-Ports (bei MySQL typischerweise 3306)
• Credential Stuffing mit Standard- oder schwachen Passwörtern
• Datenbank-Enumeration zur Identifikation wertvoller Ziele
• Stille Datenextraktion bevor die Verschlüsselung beginnt
• Ransomware-Einsatz mit zunehmend aggressiven Zeitplänen

Die Tools wurden besser. Die Automatisierung wurde raffinierter. Aber der Kernangriffspunkt? Fehlkonfiguration. Offene Ports. Vergessene Testumgebungen, die noch mit dem öffentlichen Internet verbunden sind.

Das ist kein Zeichen für besonders findige Angreifer. Das ist opportunistisches Scannen im industriellen Maßstab – von Gruppen, die den Datenbank-Diebstahl zu einem effizienten Geschäftsmodell gemacht haben.

Warum exponierte Datenbanken so leicht zu ernten sind

Man könnte sich fragen: Wenn das so bekannt ist, warum bleiben Datenbanken dann trotzdem offen?

Die Antwort ist einfacher, als du vielleicht denkst:

1. Entwickler-Bequemlichkeit – Lokale Entwicklung bedeutet oft offene Ports für einfachen Zugriff. Manchmal landen diese Einstellungen unverändert in der Produktion.

2. Cloud-Fehlkonfigurationen – Öffentliche Cloud-Instanzen starten häufig mit permissiven Security Groups "nur zum Testen."

3. Vergessene Testumgebungen – Der Staging-Server von 2022? Läuft noch. Ist noch exponiert.

4. Fehlende Übersicht – Teams wissen schlicht nicht, welche Systeme wirklich vom Internet erreichbar sind.

5. Der Trugschluss der Unsichtbarkeit – "Wer sollte uns angreifen?" Die Antwort: automatisierte Bots, die nicht diskriminieren.

Was das für deine Infrastruktur bedeutet

Betreibst du MySQL-Datenbanken – ob für Anwendungen, Analysen oder Kundendaten – dann behandle jede exponierte Instanz so, als wäre sie bereits kompromittiert. Auch wenn du noch keine Anzeichen eines Einbruchs gesehen hast.

Was die Angreifer annehmen:

• Datenbanken werden schlecht überwacht
• Backups liegen oft auf demselben kompromittierten System
• Organisationen geraten in Panik und zahlen, statt aus verifizierten Backups wiederherzustellen
• Erkennungs- und Reaktionszeiten sind langsam genug für eine profitable Verschlüsselung

Und ehrlich gesagt? In vielen Fällen liegen sie damit richtig.

Sofortmaßnahmen, die du umsetzen solltest

Überprüfe deine Angriffsfläche:

• Nutze Tools wie Shodan, Censys oder BinaryEdge, um zu prüfen, ob deine IPs in Datenbanken für Internet-Scans auftauchen
• Kontrolliere die Security Groups und Network ACLs deines Cloud-Providers
• Stelle sicher, dass kein Datenbank-Port von 0.0.0.0/0 erreichbar ist

Stärke die Authentifizierung:

• Erzwinge starke, eindeutige Passwörter für alle Datenbank-Accounts
• Implementiere IP-Allowlisting, wo immer möglich
• Erwäge VPN-Tunnel oder Bastion-Hosts statt direkter Exposition

Prüfe deine Backup-Strategie:

• Liegen Backups offline oder in einer separaten Sicherheitszone?
• Wann wurde zuletzt erfolgreich aus einem Backup wiederhergestellt?
• Verfügst du über Point-in-Time-Recovery?

** Aktiviere Logging und Monitoring:**

• Datenbank-Audit-Logs sollten Verbindungsversuche, Abfragen und Admin-Aktionen erfassen
• Richte Alerts für ungewöhnliche Zugriffsmuster oder Massen-Datenexporte ein
• Erwäge Database Activity Monitoring (DAM)-Lösungen

Der größere Zusammenhang: Sicherheit als Basisinfrastruktur

Das hier ist kein reines Datenbank-Problem. Es ist eine Erinnerung daran, dass Sicherheit als grundlegende Infrastruktur behandelt werden muss – nicht als nachträglicher Einfall.

Bei NameOcean sehen wir dieses Muster immer wieder: Startups und Entwickler, die schnell unterwegs sind, Features ausliefern und dabei unwissentlich Infrastruktur exponieren. Der Druck, schnell zu iterieren, ist real. Aber die Kosten eines Ransomware-Vorfalls oder Datenlecks übersteigen die Entwicklungsstunden, die nötig gewesen wären, um things von Anfang an richtig abzusichern.

Dein Domain-Registrar, dein Hosting-Provider, deine DNS-Konfiguration – das sind alles Einfallstore, die dieselbe Aufmerksamkeit verdienen wie hoffentlich deine Datenbank-Schicht.

Fazit: Gehe davon aus, dass du beobachtet wirst

Die 2.930 markierten Datenbanken sind keine Ausreißer. Sie repräsentieren eine breitere Realität: Wenn deine Datenbanken öffentlich erreichbar sind, stehen sie bereits auf jemandes Radar.

Das Angriffsschema ist sechs Jahre alt – gerade weil es funktioniert. Lass dich nicht durch die Vertrautheit dieser Methoden in falscher Sicherheit wiegen. Nutze sie stattdessen als Motivation zum Handeln.

Prüfe deine Angriffsfläche. Schließe Zugriffe ab. Verifiziere deine Backups. Und vergiss nicht: In der aktuellen Bedrohungslandschaft ist Unsichtbarkeit keine Sicherheitsstrategie.

Bleib sicher.