Öffentlich erreichbare MongoDB-Server stehen erneut im Fokus automatisierter Erpressungskampagnen. Angreifer scannen großflächig das Internet nach fehlkonfigurierten Instanzen, löschen produktive Datenbanken und hinterlassen Erpresserschreiben, in denen sie Lösegeld für eine angebliche Wiederherstellung verlangen. Für Organisationen ohne belastbare Backups bedeutet dies häufig den vollständigen Verlust geschäftskritischer Informationen.
Massenscans auf offene MongoDB-Instanzen: Umfang und Schadensbild
Laut aktuellen Analysen des Sicherheitsunternehmens Flare wurden weltweit über 208.500 öffentlich zugängliche MongoDB-Server identifiziert. Ein erheblicher Anteil ist unsicher konfiguriert: Mehr als 100.000 Instanzen legen Betriebsinformationen wie Clusterstatus und Konfiguration offen, rund 3.100 Server lassen sogar Verbindungen ohne jegliche Authentifizierung zu.
Besonders kritisch: Beinahe die Hälfte (45,6 %) der MongoDB-Instanzen mit unbeschränktem Zugriff war bereits kompromittiert. Auf diesen Systemen wurden legitime Datenbanken entfernt und durch Collections mit Erpressernachrichten ersetzt. Flare zählte rund 1.400 aktiv betroffene Opfer solcher Ransomware-Angriffe.
Typischer Ablauf eines automatisierten MongoDB-Ransomware-Angriffs
Das Angriffsmuster ist stark automatisiert und technisch vergleichsweise simpel. Skripte der Angreifer durchsuchen das Internet nach offenen MongoDB-Ports (standardmäßig 27017/27018). Findet sich ein Server, der ohne Authentifizierung von außen erreichbar ist, erfolgt ein direkter Zugriff mit Standardrechten. Anschließend werden die vorhandenen Datenbanken gelöscht und durch eine neu angelegte Datenbank oder Collection mit einer Lösegeldforderung ersetzt.
In den von Flare beobachteten Fällen fordern die Angreifer typischerweise 0,005 BTC innerhalb von 48 Stunden (zum Analysezeitpunkt rund 500–600 US-Dollar). Die Zahlung soll auf einen von fünf Bitcoin-Adressen erfolgen, wobei eine einzelne Adresse in etwa 98 % aller Fälle auftaucht. Dies deutet auf einen dominanten Betreiber oder eine eng koordinierte Gruppe hinter der Kampagne hin.
Altes Problem, neue Angriffswelle: Offene Datenbanken als Dauerziel
Angriffe auf ungeschützte MongoDB-Instanzen sind seit Jahren bekannt. Bereits vor 2021 wurden tausende offen erreichbare Datenbanken massenhaft gelöscht oder verschlüsselt. In manchen Fällen verzichteten Angreifer sogar auf jede Lösegeldforderung und vernichteten die Daten sofort – mit irreversiblen Folgen für Organisationen ohne Sicherungskopien.
Aktuell setzen sich diese Kampagnen fort, wenn auch in leicht reduziertem Umfang. Auffällig ist laut Flare, dass einige prinzipiell verwundbare Instanzen trotz fehlender Sicherheitsmechanismen unberührt blieben. Eine plausible Erklärung ist, dass Administratoren bereits gezahlt haben und die Angreifer diese Systeme anschließend aussparen, um Aufmerksamkeit zu vermeiden.
Fehlkonfiguration und veraltete Versionen als Hauptursachen
Die zentrale Ursache für erfolgreiche Angriffe bleibt eine unsichere Konfiguration von MongoDB. Häufig werden Instanzen zunächst zu Testzwecken oder für Prototypen aufgesetzt und später ohne Sicherheitsreview in die Produktion übernommen. Typische Probleme sind:
- Bindung an 0.0.0.0 und damit direkter Internetzugang,
- fehlende oder deaktivierte Authentifizierung,
- schwache oder Standard-Passwörter und gemeinsam genutzte Konten.
Hinzu kommt ein hoher Anteil veralteter Softwareversionen: Knapp 95.000 öffentlich erreichbare MongoDB-Instanzen laufen laut Flare auf nicht mehr aktuellen Releases, für die bereits Schwachstellen dokumentiert sind. Viele dieser Lücken ermöglichen zwar „nur“ Denial-of-Service-Angriffe, können jedoch in komplexeren Szenarien mit Fehlkonfigurationen kombiniert und so zur vollständigen Kompromittierung genutzt werden.
Warum die Zahlung von Lösegeld kaum je eine verlässliche Option ist
Auch wenn Erpresser in ihren Notizen versprechen, Daten nach Zahlung „zurückzugeben“ oder zu „entschlüsseln“, existiert in den meisten MongoDB-Fällen keinerlei technische Grundlage für diese Zusage. Historisch wurden Datenbanken häufig schlicht gelöscht – ohne Verschlüsselung und ohne Sicherungskopie auf Angreiferseite. Selbst bei Zahlungsbereitschaft wären die Informationen damit verloren.
Internationale Leitlinien von Behörden und Fachgremien (u. a. BSI, ENISA, NIST) raten daher ausdrücklich davon ab, Lösegeld zu zahlen. Das Risiko, nach Zahlung keine Wiederherstellung zu erhalten, ist hoch, gleichzeitig werden kriminelle Geschäftsmodelle finanziert. Der Fokus sollte auf Prävention, Härtung der Systeme und belastbaren Backup-Strategien liegen.
Best Practices: So schützen Sie MongoDB-Server wirksam vor Ransomware
1. Netzwerkanbindung strikt begrenzen. MongoDB sollte nicht direkt aus dem Internet erreichbar sein. Nutzen Sie bind_ip, um nur interne Interfaces zu binden, setzen Sie Firewalls mit Allowlists ein und führen Sie Administration ausschließlich über VPN oder Bastion-Hosts durch.
2. Verbindliche Authentifizierung und starke Zugangsdaten. Aktivieren Sie konsequent die MongoDB-Authentifizierung, verwenden Sie getrennte Konten nach dem Prinzip der minimalen Rechte und setzen Sie eindeutige, komplexe Passwörter ein. Standard- oder Test-Accounts haben in Produktionsumgebungen keinen Platz.
3. Sichere Konfiguration in Cloud- und Kubernetes-Umgebungen. In Kubernetes und Public-Cloud-Umgebungen sollten Network Policies, Security Groups und Zugriffskontrollen so definiert werden, dass nur notwendige Dienste und Subnetze auf MongoDB zugreifen können. Vermeiden Sie unreflektiertes Kopieren von Beispielkonfigurationen.
4. Aktualisierung und kontinuierliches Schwachstellenmanagement. Halten Sie MongoDB und abhängige Komponenten auf einem aktuellen Patchstand. Ergänzen Sie dies durch regelmäßige Schwachstellenscans, eine Inventarisierung aller exponierten Dienste und ein strukturiertes Patch-Management.
5. Robuste Backups und getestete Wiederherstellung. Regelmäßige, automatisierte und getrennt gespeicherte Backups sind die einzige verlässliche Absicherung gegen Datenverlust. Testen Sie Restore-Prozesse realistisch und stellen Sie sicher, dass Angreifer keine direkten Löschrechte auf Backup-Ziele besitzen.
Automatisierte Ransomware-Kampagnen gegen offene MongoDB-Instanzen verdeutlichen, wie schnell eine einzelne Konfigurationsschwäche zur vollständigen Datenvernichtung führen kann. Organisationen sollten kurzfristig alle Datenbankserver inventarisieren, deren Internet-Exponierung und Authentifizierung prüfen, unnötige Ports schließen und Sicherheitsrichtlinien durchsetzen. Ergänzend lohnt sich ein Abgleich mit Hardening-Guides des Herstellers und Empfehlungen von Fachbehörden. Wer jetzt in Härtung, Monitoring und Backup-Strategien investiert, reduziert das Risiko erheblich, dass die nächste Erpressernachricht auf dem eigenen MongoDB-Server landet.
