Mir ist neulich eine Vorfall-Analyse untergekommen, die ich seitdem nicht mehr aus dem Kopf kriege. Nicht, weil der Angriff besonders raffiniert war, im Gegenteil. Sondern genau weil er so banal war und trotzdem einen kompletten Server gekostet hat. Das ist die Sorte Geschichte, bei der man unwillkürlich an die eigenen Kisten denkt und sich fragt: “Läuft bei mir eigentlich noch alles sauber?”
Der Aufhänger: entdeckt durch Zufall, nicht durch ein Tool
Das Erste, was an dem Fall hängen bleibt: Der Einbruch wurde nicht durch eine Schutzsoftware entdeckt, nicht durch einen Alert, durch nichts von dem, was eigentlich anspringen sollte.
Aufgefallen ist er, weil ein paar völlig andere Dienste auf dem Server anfingen zu spinnen und abstürzten. Jemand ging also in die klassische Fehlersuche, Dienste wieder hochziehen, und dabei fiel beiläufig ein Prozess auf, der da nichts zu suchen hatte und die CPU auf über 1000 Prozent Last nagelte: ein Krypto-Miner.
Die abgestürzten Dienste waren also gar nicht das Problem, sie waren das Symptom. Der Miner hatte sich so gierig alles gekrallt, dass für den regulären Betrieb schlicht nichts mehr übrig war. Anders gesagt: Der Einbruch flog nur auf, weil der Angreifer zu gierig war. Ein etwas gedrosselter Miner würde vermutlich heute noch fröhlich schürfen. Kein schöner Gedanke.
Was tatsächlich passiert ist
Der Einstieg war eine Web-App auf Next.js 15.3.3. Diese Version hat eine bekannte, üble Lücke: Über eine Server Action lässt sich Code aus der Ferne ausführen (RCE). Und jetzt der Punkt, der mir am meisten hängen geblieben ist: Der verwundbare Code stand nicht in der App des Betreibers. Er steckte im Framework selbst.
Das ist die Falle, in die wir alle laufen können. Man muss selbst keine einzige Zeile falsch schreiben, es reicht, eine Abhängigkeit nicht aktuell zu halten. Am Ende lief es auf so etwas hinaus:
spawnSync('/bin/sh', ['-c', <was auch immer der Angreifer schickt>])Die Payloads waren base64-kodiert, um simple Filter auszutricksen, das Standard-Muster automatisierter Angriffs-Kits. Und in den Logs fanden sich über 26.000 Versuche auf genau diese eine Stelle. Kein gezielter Angriff auf ein bestimmtes Opfer, sondern ein Bot, der das halbe Internet nach dieser Lücke abklopft und irgendwann Erfolg hat.
Und dann der Fehler, der aus einem ärgerlichen Vorfall eine Katastrophe machte: Die App lief als root.
Diese Kombination solltest du dir merken, weil sie tödlich ist:
- Eine RCE-Lücke heißt: Der Angreifer kann Befehle ausführen.
- Als root heißt: Diese Befehle laufen mit vollen Rechten.
- Zusammen heißt das: Ein einziger erfolgreicher Request und der komplette Server gehört ihm.
Der ganze mühsame Zwischenschritt, den ein Angreifer sonst braucht, erst rein, dann Rechte hochschrauben, fiel damit einfach weg. Die Tür war nicht nur offen, es lag gleich der Generalschlüssel daneben.
Was der Angreifer hinterlassen hat
Es blieb nicht beim Miner. Auf der Maschine lag danach ein komplettes Kriminalitäts-Kit:
- ein Krypto-Miner (frisst CPU und Strom)
- eine persistente Hintertür, die auch einen Reboot überlebt hätte
- ein DDoS-Tool, mit dem der Server im Auftrag Dritter andere angreift
- Tarnkomponenten, die das Ganze verstecken
Und der wirklich unangenehme Teil: Das Zeug durchsuchte den Server gezielt nach Zugangsdaten. Config-Files mit Passwörtern, Datenbank-Credentials, SSH-Keys, sogar Live-Zahlungs-Keys. Alles, was Wert hatte, muss nach so einem Vorfall als kompromittiert gelten und rotiert werden. Das ist nicht “Server platt machen und neu aufsetzen”, das ist tagelanges Nachziehen an jeder Ecke, an der der Server jemals angedockt war.
Die Rechnung, die richtig weh tut
Willst du wissen, was der Angreifer mit dem Mining in den paar Stunden bis zur Entdeckung verdient hat? Ein paar Euro. Wirklich. Eine Handvoll Euro.
So viel ist einem Angreifer ein fremder Server wert, weil er ihn ja nicht kauft, sondern einfach nimmt. Für ihn ist das ein Wegwerf-Geschäft im großen Stil: Bot laufen lassen, tausende Server gleichzeitig, bei jedem ein paar Euro, fertig. Auf der anderen Seite steht beim Betreiber: Bereinigung, Rotation sämtlicher Secrets, Ausfall, das ungute Gefühl bei den abgegriffenen Daten, und im Fall des DDoS-Tools sogar mögliche Haftungsfragen, falls die Kiste in der Zwischenzeit jemand anderen angegriffen hat.
Wenige Euro für den Angreifer. Ein Vielfaches davon für das Opfer. Genau dieses Missverhältnis ist der Grund, warum solche Angriffe massenhaft laufen, sie kosten den Täter fast nichts.
Was wir alle daraus mitnehmen sollten
Nichts davon ist neue Weisheit. Das ist Security-Hygiene, die wir alle kennen und die trotzdem gern hinten runterfällt, weil “läuft ja”. Also ganz unaufgeregt die Punkte, die diesen Fall verhindert hätten:
- Dependencies aktuell halten. Nicht sexy, rettet dir aber genau diesen Tag. Die Lücke war längst bekannt und gepatcht, es war nur nicht aktualisiert worden.
- Nichts läuft als root. Wirklich nichts. Ein eigener User mit minimalen Rechten hätte aus dem Totalschaden einen ärgerlichen, aber begrenzten Vorfall gemacht.
- Alte, halb vergessene Apps sind Zeitbomben. Genau so eine war es hier. Selten angefasst, nie aktualisiert, aber schön weiter am Netz. Entweder pflegen und überwachen oder abschalten.
- Monitoring, das dir Bescheid gibt. Der peinlichste Teil der Geschichte ist nicht der Einbruch, es ist, dass er fünf Tage unbemerkt blieb. Mit einer simplen Überwachung auf ungewöhnliche Last oder fremde Prozesse wären es Minuten gewesen, keine Tage.
Der Unterschied zwischen “Minuten” und “fünf Tagen” ist am Ende der Unterschied zwischen einem Schreckmoment und einem echten Schaden.
Die vollständige Forensik zum Nachlesen
Ich hab hier die Kurzfassung mit den Lehren erzählt. Wer den Fall aber richtig forensisch auseinandergenommen haben will, mit dem kompletten Ablauf, der Timeline, der Analyse der Angreifer-Toolchain und einer sehr sauberen Einordnung (auch zur unangenehmen Haftungsfrage bei DDoS-Missbrauch), dem lege ich die Tiefenanalyse von purplebase ans Herz. Die haben den Vorfall komplett zerlegt und in einen praktischen Maßnahmen-Katalog übersetzt:
→ Anatomie einer Server-Übernahme (purplebase Blog)
Wenn du Web-Apps betreibst und beim Lesen ein leises “oh, das könnte bei mir auch so laufen” hattest, dann ist das genau der richtige Moment, einmal ehrlich hinzuschauen. Lieber jetzt selbst, als in fünf Tagen durch Zufall.