Viele Teams in der IT investieren ihre Energie vor allem in die Abwehr: Angreifer sollen gar nicht erst ins System gelangen. Doch der entscheidende Wettbewerb findet oft danach statt. Ein Vorfall, den ein Sicherheitsteam untersucht hat, macht deutlich, wie viel Zeit und Aufwand Angreifer in der Phase nach dem Eindringen investieren – und warum diese Post-Breach-Betrachtung für den Schutz genauso wichtig ist wie die reine Schadensverhinderung im Voraus.
Im Kern zeigt der Fall: Wer nach einem Sicherheitsvorfall nur „aufräumt“, aber die Ursache am Einstiegspunkt nicht beseitigt, gibt Angreifern möglicherweise schon bald die nächste Tür frei. Im Folgenden sehen Sie, wie es bei dem untersuchten Angriff konkret lief – und welche praktischen Schlüsse Verteidiger daraus ziehen können.
So gelang der Angreifer ins Netzwerk
Die ersten Hinweise kamen über verdächtige Aktivitäten im Zusammenhang mit einem Prozess, der mit Microsoft SQL Server verknüpft war. Allerdings griff der Angreifer nicht direkt „die Datenbank“ an, wie man es bei SQL-Themen häufig erwartet.
Stattdessen fanden die Analysten eine Webseite auf demselben System, die Nutzereingaben nicht korrekt prüfte. Genau diese Lücke ist typisch für eine SQL-Injection: Wenn eine Anwendung Informationen übernimmt, die ein Besucher eingibt (z. B. in einem Suchfeld oder Login), diese aber ungeprüft an die Datenbank weiterreicht, kann daraus ein direkter Zugriff auf das dahinterliegende Windows-System entstehen.
Warum SQL-Injection ein wiederkehrendes Risiko bleibt
SQL-Injection gehört weiterhin zu den verbreitetsten und zugleich am besten vermeidbaren Schwachstellen bei Webanwendungen. Das Muster ist immer ähnlich: Eine fehlende Validierung erlaubt es, Eingaben so zu gestalten, dass die Anwendung nicht mehr nur „sichere“ Abfragen ausführt, sondern ungewollte Anweisungen verarbeitet.
Für Verteidiger bedeutet das: Selbst wenn ein Angreifer auf einem Windows-Host agiert, kann die echte Ursache weiterhin im Web liegen. Post-Breach ist damit nicht nur „was nachher passiert“, sondern auch: wie konsequent Sie die Einstiegsspur bis zur fehlerhaften Eingabeprüfung zurückverfolgen.
Erkundung statt Aktionismus: Was nach dem Einstieg zählt
Nachdem der Angreifer initialen Zugriff hatte, agierte er offenbar nicht wie ein „Sofort-Entscheider“ mit Fokus auf schnellen Diebstahl oder schnellen Zerstörungseffekten. Stattdessen nahm er sich Zeit, um sich im System zurechtzufinden.
Ein typischer Schritt war die Ausführung eines eingebauten Windows-Befehls, der laufende Dienste sichtbar macht. Solche Recon-Schritte helfen Angreifern, herauszufinden, was sich lohnt anzugreifen oder welche Prozesse sich eventuell als „normal“ tarnen lassen.
Die Ergebnisse wurden zudem an einen Kontrollserver gesendet. Das kann sowohl der späteren Auswertung dienen als auch dafür, Entscheidungen zu automatisieren.
Zugänge festigen: Remote Desktop und ein neuer Administrator
Im weiteren Verlauf begann die Phase, die im Kontext Post-Breach besonders kritisch ist: Der Angreifer wollte dauerhaft präsent sein und sich nicht auf einmalige Zugänge verlassen.
- Er aktivierte Remote Desktop, obwohl diese Funktion zuvor nicht eingeschaltet war.
- Er legte einen neuen Benutzer an und nahm ihn in die lokale Administratorengruppe auf. Damit erhielt er sofort weitreichende Rechte – und der Zugang konnte auch nach einem Neustart oder einer grundlegenden Bereinigung erhalten bleiben.
- Anschließend nutzte er Remote Desktop, um sich mit dem neu geschaffenen Konto einzuloggen.
Das ist ein Muster, das viele Verteidiger unterschätzen: Gerade wenn Sie nur die „offensichtlichen“ Artefakte entfernen, aber persistente Zugänge nicht sauber identifizieren und zurücksetzen, bleibt die Gefahr bestehen.
Schutzmechanismen abschalten – aber nicht alles
Ein weiterer Schritt war das Deaktivieren von Windows Defender. Das ist für Angreifer ein logischer Move, weil er die Hürde für weitere Aktivitäten senkt.
Bemerkenswert ist jedoch, dass andere Monitoring- oder Sicherheitsfunktionen (wie EDR) unangetastet blieben. Das könnte bedeuten, dass der Angreifer die zusätzliche Absicherung nicht wahrgenommen hat – oder dass es ihm nicht möglich war, diese Ebene ebenfalls zu deaktivieren. Für Verteidiger ist genau diese Detailtiefe wichtig: Nicht jede Abschaltung ist vollständig, und dennoch kann bereits das Deaktivieren einzelner Komponenten reichen, um die Kontrolle zu gewinnen.
Den Webserver zur Manipulationsplattform machen
Nachdem der Zugriff auf Betriebssystemebene stabil war, ging der Angreifer weiter zur Manipulation des Webservers. Konkret installierte er bösartige Add-ons für Internet Information Services (IIS).
Diese Komponenten werden einer bekannten Malware-Familie zugerechnet, die darauf abzielt, legitimen Website-Traffic umzuleiten oder für Suchmaschinenbetrug aufzubereiten. Typische Folgen sind unter anderem:
- Besucher werden auf andere Inhalte umgeleitet.
- Es können versteckte Links injiziert werden.
- Die angezeigten Inhalte weichen vom ab, was die eigentliche Website vorsieht.
Aus Sicht des Opfers entsteht dadurch ein zweifacher Schaden: Zum einen wird die Infrastruktur missbraucht, zum anderen bleibt der Eingriff oft länger unbemerkt, weil „die Website läuft ja doch“ – nur eben in einer manipulierteren Form.
Crypto-Mining als zusätzliche Einnahmequelle
Im nächsten Schritt wurde ein Programm zum Mining von Kryptowährungen auf dem System platziert. Das nutzt Rechenleistung, um Erträge zu generieren – wobei die Energiekosten typischerweise beim Opfer anfallen.
Damit das Mining nicht sofort auffällt, wurden verschiedene Maßnahmen ergriffen:
- Die Dateien des Miners wurden mit Attributen versehen, die sie weniger sichtbar machen (z. B. „versteckt“, „system“ und „read-only“).
- Der Miner wurde so eingerichtet, dass er als Windows-Service läuft, über ein legitimes, frei verfügbares Administrations-Tool. So startet er typischerweise automatisch und bleibt auch nach einem Neustart aktiv.
- Zusätzlich wurde ein Tool abgelegt, das darauf ausgelegt ist, die Erkennung zu erschweren.
Mehrstufige Tools: Scripts, die unauffällig laufen
Über den Verlauf des Angriffs bezog der Angreifer weitere Komponenten nach. Dabei wurden mehrere PowerShell-Skripte und Batch-Dateien von externen Servern geladen.
Besonders auffällig ist, dass PowerShell so eingesetzt wurde, dass es möglichst still ablief: keine sichtbaren Fenster, keine auffälligen Prompt-Fenster und keine hinderliche Ausführungspolitik. Für Incident-Responder bedeutet das: „Da lief doch etwas, aber wir haben keine Benutzerinteraktion gesehen“ ist nicht gleichbedeutend mit „da war nichts“.
Was im konkreten Fall die Ermittler hervorhob, war weniger die einzelne Technik – sondern die Vielzahl an Änderungen, die auf einem einzigen System und in einer einzigen Angriffsmal umgesetzt wurden. Genau diese Dichte macht Post-Breach-Analysen so wertvoll: Sie zeigen, dass ein Angreifer nicht nur „kommt und geht“, sondern ein System aktiv umformt.
Was Verteidiger daraus lernen sollten
Für viele wirkt es so, als hätten eigene Administratoren einen Heimvorteil: Sie kennen die Umgebung und wissen, was „normal“ ist. Doch ohne einen klaren Plan für das Vorgehen nach einer Kompromittierung kann dieser Vorteil schnell kippen. Angreifer können dann die Umgebung so umbauen, wie sie es für ihre Ziele brauchen – häufig weit über das reine Abschalten von Schutzsoftware oder das Abladen von Malware hinaus.
Die wichtigste Erkenntnis: Einstiegspunkte identifizieren und beheben ist genauso entscheidend wie die Bereinigung sichtbarer Artefakte. Wenn in diesem Fall zwar Tools und Accounts entfernt worden wären, die zugrunde liegende SQL-Injection-Lücke aber offen geblieben wäre, hätte der Angreifer womöglich über denselben Angriffsweg erneut zugreifen können. Das nächste Mal kann die Entdeckung dann deutlich schwerer werden.
Praktische Schritte für die Absicherung nach einem Vorfall
Starten Sie mit den Grundlagen. Ziel ist Transparenz: Wer weiß, was im eigenen Betrieb vorhanden ist, kann schneller beurteilen, ob etwas fehlt, ob etwas hinzugekommen ist oder ob sich Konfigurationen geändert haben.
- Inventar erstellen und aktuell halten: Erfassen Sie Systeme (physisch und virtuell), Anwendungen und Versionen.
- Angriffsfläche reduzieren: Je weniger exponierte Dienste und Webanwendungen, desto geringer ist die Chance, dass ein Angreifer einen Einstieg findet.
- Unnötiges entfernen: Alles, was nicht gebraucht wird, ist nicht nur Komfortrisiko, sondern auch Sicherheitsrisiko.
- Zugriff absichern: Nur autorisierte Nutzer, und wo möglich Standardisierung auf Multi-Faktor-Authentifizierung.
- Aktualisieren und überwachen: Patches regelmäßig einspielen und sicherstellen, dass aktive Anwendungen in der Überwachung abgedeckt sind.
- Jeden Vorfall mit Ursachenfokus untersuchen: Hören Sie nicht bei „Malware weg“ auf. Klären Sie, wie der Zugriff wirklich zustande kam, und verbessern Sie genau diese Stelle.
Angreifer kalkulieren damit, dass sich Verteidiger häufig auf die Oberfläche konzentrieren. Gerade die Tiefe – also die echte Ursache und der Einstieg – sorgt dafür, dass Ihr Heimvorteil bei Ihnen bleibt.
Fazit
Der untersuchte Angriff macht deutlich, was Post-Breach in der Praxis bedeutet: Der Zeitraum nach dem Eindringen ist häufig die Phase, in der Angreifer Persistenz schaffen, Systeme anpassen, Schutz umgehen und zusätzliche Aktivitäten anstoßen. Entscheidend ist daher nicht nur die nachgelagerte Bereinigung, sondern vor allem das Schließen des Einstiegspfads – in diesem Fall eine nicht ausreichend abgesicherte Eingabe in einer Webanwendung.
Wer konsequent Ursache und Einstiegsschwachstelle behebt, reduziert das Risiko, dass Angreifer „durch dieselbe offene Tür“ zurückkommen. Damit wird aus Aufräumen echte Resilienz.
