Wiederherstellung unter aktivem Beschuss
Ein Feiertag, früher Morgen. Die Meldung kam ohne Vorwarnung: Komplettausfall einer kritischen Web-Plattform, kein administrativer Zugriff mehr, Zeitpunkt der Kompromittierung unbekannt. Vermutlich eine politische Bewegung.
Was wir vorfanden, war kein gewöhnlicher Sicherheitsvorfall.
Ausgangssituation & Herausforderung
Die digitale Infrastruktur eines gemeinnützigen Vereins – eine öffentlich sichtbare, thematisch exponierte Web-Plattform – war über Feiertage Ziel eines koordinierten, mehrstufigen Cyberangriffs geworden. Der Zeitpunkt war strategisch gewählt: Feiertage bedeuten eingeschränkte Erreichbarkeit bei Hostern und Dienstleistern, verlängerte Reaktionsketten und größere Handlungsspielräume für Angreifer.
Das Angriffsziel beschränkte sich nicht auf eine bloße Nichtverfügbarkeit des Systems. Die kompromittierte Infrastruktur wurde aktiv als Distributionsplattform für illegale Inhalte missbraucht – mit der klaren Absicht, die Domain-Reputation nachhaltig zu beschädigen und in Suchmaschinen- sowie Sicherheitssystemen als problematisch einzustufen. Einbrechende organische Sichtbarkeit, degradierte E-Mail-Zustellbarkeit, langfristiger Reputationsschaden: Der potenzielle Schaden wäre weit über einen temporären Ausfall hinausgegangen.
Was die Situation besonders anspruchsvoll machte:
- Sämtliche administrativen Zugänge waren gesperrt und kompromittiert
- Die vorhandene Backup-Infrastruktur war durch den Angriff unbrauchbar für eine saubere Wiederherstellung
- Parallel zur aktiven Kompromittierung lief ein massiver volumetrischer Angriff auf die Netzwerkinfrastruktur – bewusst eingesetzt, um Bereinigungsmaßnahmen zu blockieren und die Reaktionszeit zu maximieren
Das Besondere an diesem Vorfall war sein adaptiver Charakter. Sobald wir begonnen haben, Firewall-Regeln anzupassen und Traffic-Quellen zu isolieren, haben die Angreifer in Echtzeit reagiert: neue Infrastruktur wurde hochgezogen, teils bewusst in jurisdiktionsnah positionierten Rechenzentren, um geografische Sperren zu umgehen. Der Angriffs-Traffic hat sich dynamisch angepasst. Kein automatisierter Bot-Angriff – sondern ein koordinierter Vorgang mit aktiver menschlicher Steuerung in Echtzeit.
Die Analyse: Ein Wurm mit Zeitverzögerung
Die forensische Schadcode-Analyse offenbarte das eigentliche Ausmaß: Keine einfache Datenbankinjektion, sondern ein applikationsübergreifender Wurm, der sich systematisch durch die gesamte Plattform-Architektur verteilt und mit bewusster zeitlicher Verzögerung aktiviert hatte. Das Ziel dieser Verzögerungslogik war eindeutig: Backup-Zyklen sollten die infizierte Codebasis längst gespiegelt haben, bevor der Angriff überhaupt sichtbar wird. Eine Wiederherstellung aus scheinbar intakten Backups wäre damit direkt in die nächste Kompromittierung gemündet.
Dieses Muster sehen wir zunehmend häufiger. Angreifer planen Gegenmaßnahmen aktiv ein. Wer Backup-Verfügbarkeit mit Wiederherstellungsfähigkeit gleichsetzt, übersieht, dass ein durchdachter Angriff exakt dieses Backup zur Waffe macht.
Die Lösung: Paralleles Vorgehen und isolierte Backup-Appliance
Während ein Teil des Teams unmittelbar DNS-Routing und Reverse-Proxy-Konfiguration angepasst hat, um den volumetrischen Angriff sauber zu absorbieren und die Systemstabilität herzustellen, hat der andere Teil parallel daran gearbeitet, administrative Zugänge wiederherzustellen, die Systemumgebung zu isolieren und den Schadcode vollständig zu analysieren und zu entfernen.
Der entscheidende Faktor für eine saubere Wiederherstellung war eine physisch separierte, netzwerkseitig nicht angebundene Langzeit-Backup-Appliance – außerhalb der kompromittierten Infrastruktur, nicht erreichbar für die Angreifer. Über diesen isolierten Wiederherstellungspfad ließ sich das System auf einen nachweislich sauberen Stand zurücksetzen, ohne auf kompromittiertes Material zurückgreifen zu müssen.
Noch am selben Tag war die Plattform vollständig bereinigt, strukturell abgesichert und wieder stabil in Betrieb.
Was dieser Fall zeigt
Das ist kein Einzelfall – und die Lehren daraus sind unbequem:
„Wir haben Backups“ ist keine Sicherheitsstrategie. Wenn Backup-Systeme in derselben Infrastrukturumgebung operieren wie die produktive Plattform, sind sie im Ernstfall Teil des Problems. Angreifer reagieren heute in Echtzeit auf Incident-Response-Maßnahmen. Und die meisten Setups sind exakt so konzipiert, dass ein Angriff dieser Qualität funktioniert.
Sicherheit fängt nicht beim Incident Response an. Sie fängt bei der Infrastruktur an, die man aufbaut, bevor etwas passiert.
Key Facts
| Merkmal | Detail |
|---|---|
| Angriffstyp | Koordinierter mehrstufiger Cyberangriff mit parallelem volumetrischem DDoS |
| Besonderheit | Adaptiver Angriff mit aktiver menschlicher Echtzeit-Steuerung |
| Schadcode | Applikationsübergreifender Wurm mit zeitverzögerter Aktivierungslogik |
| Wiederherstellung | Über physisch isolierte, nicht kompromittierbare Backup-Appliance |
| Ergebnis | System am selben Tag vollständig bereinigt und stabil in Betrieb |