Forensische Webspuren: Was nach einem Angriff übrig bleibt
Nach einem erfolgreichen Angriff auf eine Website sieht die Situation häufig erstaunlich unspektakulär aus. Eine unbekannte Datei wird entdeckt, ein Benutzerkonto gelöscht, ein verdächtiges Plugin entfernt und anschließend scheint wieder alles normal zu funktionieren. Genau darin liegt jedoch eine interessante technische Täuschung. Was ein Administrator als „bereinigt“ wahrnimmt, ist nicht zwangsläufig ein System, aus dem sich der vorherige Ablauf nicht mehr rekonstruieren lässt. Moderne Websites bestehen aus wesentlich mehr Ebenen als den Dateien, die gerade im Webverzeichnis sichtbar sind. Webserver, Datenbanken, Caches, Content-Delivery-Netzwerke, Backup-Systeme, Betriebssysteme, DNS-Infrastruktur und externe Dienste erzeugen jeweils eigene zeitliche und technische Nebenprodukte. Ein Angreifer müsste all diese Ebenen verstehen und gleichzeitig manipulieren, um tatsächlich ohne Spuren zu verschwinden.
Die interessantesten Beweise liegen oft nicht in der Schadsoftware
Bei der Untersuchung kompromittierter Websites wird intuitiv zuerst nach verdächtigen Dateien gesucht. Das ist sinnvoll, aber erstaunlich eng gedacht. Eine hochgeladene PHP-Shell kann gelöscht worden sein. Ein manipuliertes Plugin lässt sich überschreiben. Ein eingeschleuster Administrator kann aus der Benutzerverwaltung verschwinden. Trotzdem können andere Systeme dokumentiert haben, dass diese Objekte existierten oder verwendet wurden. Gerade diese indirekten Hinweise sind häufig besonders wertvoll, weil sie nicht dort gespeichert werden, wo der Angreifer unmittelbar gearbeitet hat.
Ein Webserver kann beispielsweise Zugriffe auf eine inzwischen gelöschte Datei protokolliert haben. Ein Backup enthält möglicherweise eine frühere Version des kompromittierten Systems. Eine CDN-Plattform hat Anfragen an eine URL verarbeitet, die heute überhaupt nicht mehr existiert. In der Datenbank können IDs, Zeitangaben oder verwaiste Einträge zurückbleiben. Solche Spuren erzählen keine vollständige Geschichte für sich allein. Zusammengesetzt können sie jedoch eine technische Chronologie ergeben.
Der erste Reflex kann wertvolle Spuren vernichten
Genau deshalb ist hektisches „Aufräumen“ nach einem verdächtigen Vorfall nicht immer die beste erste Reaktion. Wer Dateien löscht, Systeme aktualisiert, Plugins neu installiert, Logs leert oder ein Backup zurückspielt, verändert den Zustand, den er eigentlich untersuchen möchte. Für eine normale technische Wiederherstellung kann das vollkommen sinnvoll sein. Soll dagegen nachvollzogen werden, wann ein Zugriff erfolgte, welche Dateien verändert wurden oder ob Daten abgeflossen sein könnten, bekommt die unveränderte Ausgangssituation eine andere Bedeutung.
Spätestens wenn ein Vorfall geschäftlich, versicherungsrechtlich oder juristisch relevant werden könnte, geht es deshalb nicht mehr ausschließlich um Website-Administration. Dann kann professionelle IT-Forensik sinnvoll werden, weil nicht nur verdächtige Dateien betrachtet, sondern digitale Spuren möglichst nachvollziehbar gesichert und in einen zeitlichen Zusammenhang gebracht werden müssen. Ein funktionierender Webauftritt und ein belastbarer Nachweis darüber, was zuvor geschehen ist, sind zwei unterschiedliche technische Ziele.
Dateizeitstempel erzählen nur einen Teil der Geschichte
Eine der naheliegendsten Spuren sind Zeitangaben von Dateien. Betriebssysteme verwalten abhängig vom verwendeten Dateisystem verschiedene Metadaten wie Änderungs-, Zugriffs- oder Statuszeiten. Auf den ersten Blick scheint damit leicht erkennbar zu sein, wann eine verdächtige Datei entstanden ist. Ganz so einfach ist es jedoch nicht.
Dateien können kopiert, entpackt, verschoben oder durch Deployment-Prozesse ersetzt werden. Manche Vorgänge übernehmen vorhandene Zeitstempel, andere erzeugen neue. Angreifer können Metadaten außerdem gezielt verändern. Deshalb sollte ein einzelner Zeitstempel kaum isoliert interpretiert werden. Interessanter wird es, wenn zahlreiche unabhängige Ereignisse ungefähr denselben Zeitraum markieren. Eine ungewöhnliche Dateiänderung um 03:14 Uhr gewinnt erheblich an Aussagekraft, wenn wenige Sekunden vorher ein verdächtiger HTTP-Request auftaucht und kurz danach ein neuer Datenbankeintrag angelegt wurde.
Logdateien sind die schwarzen Kästen des Webservers
Webserver protokollieren abhängig von ihrer Konfiguration eine enorme Menge unscheinbarer Informationen. Eine typische Access-Log-Zeile kann Zeitpunkt, angeforderte URL, HTTP-Methode, Statuscode, übertragene Datenmenge, Referrer, User-Agent und weitere Angaben enthalten. Für den alltäglichen Betrieb wirken diese Daten oft banal. Nach einem Sicherheitsvorfall können genau sie plötzlich interessant werden.
Auffällig wäre beispielsweise eine POST-Anfrage auf eine Datei, die normalerweise ausschließlich per GET aufgerufen wird. Ebenso interessant können sehr ungewöhnliche URL-Parameter, Zugriffe auf selten verwendete Administrationspfade oder große Antwortmengen sein. Eine einzelne ungewöhnliche Anfrage beweist noch keinen Angriff. Häufen sich entsprechende Muster jedoch in einem engen Zeitfenster, entsteht ein wesentlich konkreteres Bild.
Besonders wertvoll sind Logs auch deshalb, weil sie Aktivitäten dokumentieren können, deren Ergebnis inzwischen entfernt wurde. Die fragliche Datei existiert nicht mehr, der Zugriff darauf steht aber weiterhin im Protokoll.
Der HTTP-Statuscode kann eine verschwundene Datei indirekt bestätigen
Ein kurioses Beispiel liefert der Statuscode einer Anfrage. Angenommen, in den heutigen Dateien findet sich keinerlei Spur einer Datei namens update-old.php. In älteren Webserverlogs tauchen jedoch wiederholt Anfragen auf genau diese URL auf. Liefert der Server dabei über einen längeren Zeitraum HTTP 200 zurück, deutet das darauf hin, dass unter dieser Adresse zumindest eine erfolgreiche Serverantwort erzeugt wurde.
Nach einer Bereinigung können dieselben Zugriffe plötzlich HTTP 404 erzeugen. Die Kombination beider Zustände kann damit interessanter sein als das heutige Dateisystem allein. Sie zeigt zumindest, dass sich das Verhalten dieser URL verändert hat.
Solche Kleinigkeiten machen forensische Webanalysen reizvoll. Nicht immer wird ein Beweis direkt gefunden. Häufig ergibt sich eine Hypothese aus Unterschieden zwischen mehreren technischen Zuständen.
Datenbanken besitzen ihre eigenen Geister
Bei Content-Management-Systemen befindet sich ein großer Teil des eigentlichen Zustands nicht in Dateien, sondern in Datenbanken. Benutzerkonten, Einstellungen, Beiträge, Sessions, Plugin-Konfigurationen und zahllose Metadaten können dort gespeichert sein. Wird ein unerwünschter Benutzer gelöscht, bedeutet dies nicht zwangsläufig, dass sämtliche Beziehungen zu diesem Datensatz verschwinden.
Je nach Anwendung können verwaiste Metadatensätze, fortlaufende IDs, historische Einträge oder Referenzen in anderen Tabellen erhalten bleiben. Eine ungewöhnliche Lücke in einer ID-Sequenz ist für sich genommen völlig harmlos. Zusammen mit weiteren Spuren kann sie jedoch eine Frage aufwerfen: Welcher Datensatz befand sich ursprünglich dort?
Besonders interessant sind Systeme, in denen Plugins eigene Tabellen anlegen. Ein Angreifer oder eine kompromittierte Erweiterung kann einen Teil seiner Aktivität an Stellen hinterlassen, die bei einer oberflächlichen Kontrolle der Standardtabellen überhaupt nicht untersucht werden.
Autoincrement-IDs können verschwundene Vorgänge sichtbar machen
Viele Datenbanken vergeben numerische IDs automatisch fortlaufend. Wird beispielsweise ein Datensatz mit der ID 814 erzeugt und später wieder gelöscht, beginnt die Nummerierung nicht zwangsläufig erneut bei 814. Der nächste Eintrag erhält vielleicht 815.
Damit entsteht ein merkwürdiger Schatten eines nicht mehr vorhandenen Objekts. Aus der fehlenden Nummer lässt sich selbstverständlich nicht ableiten, was gelöscht wurde oder weshalb. Existieren jedoch Backups verschiedener Zeitpunkte, können solche Lücken helfen, Veränderungen zeitlich einzugrenzen.
Ein Datenbankdump von Montag enthält möglicherweise ID 813 als höchsten Wert. Am Mittwoch beginnt die sichtbare Folge bei 815. Ein Backup vom Dienstag könnte dann entscheidend sein. Der eigentlich interessante Datensatz ist nicht mehr im aktuellen System vorhanden, aber die Kombination verschiedener Zustände führt zu ihm zurück.
Backups sind unbeabsichtigte Zeitmaschinen
Backups werden normalerweise für den schlimmsten Fall erstellt: Datenverlust, Serverausfall oder eine fehlgeschlagene Aktualisierung. Für die Rekonstruktion eines Sicherheitsvorfalls besitzen sie jedoch eine zweite Eigenschaft. Sie speichern historische Zustände.
Wer mehrere Generationen eines Webauftritts besitzt, kann Dateien und Datenbanken miteinander vergleichen. Dadurch wird sichtbar, wann eine Veränderung erstmals auftrat. Ein unbekanntes Script existiert beispielsweise im Backup vom 12. März noch nicht, erscheint am 13. März und fehlt nach einer Bereinigung am 15. März wieder. Schon damit lässt sich der mögliche Zeitraum erheblich eingrenzen.
Noch spannender werden inkrementelle Backups. Sie speichern häufig gerade jene Dateien, die sich seit dem vorherigen Sicherungslauf verändert haben. Damit fungiert das Backup-System unbeabsichtigt als Protokoll der Veränderungen.
Ein Cache kann Inhalte überleben lassen, die am Ursprung längst gelöscht sind
Caching-Systeme schaffen eine weitere Ebene. Eine dynamisch erzeugte Webseite wird zwischengespeichert, damit spätere Besucher nicht jedes Mal denselben Prozess auslösen müssen. Wird der Ursprungsinhalt verändert, kann eine ältere Version je nach Cache-Konfiguration noch einige Zeit vorhanden sein.
Das kann bei einer kompromittierten Website ausgesprochen interessant werden. Vielleicht wurde für wenige Stunden fremder JavaScript-Code ausgeliefert und anschließend wieder entfernt. Im aktuellen HTML ist nichts mehr davon zu sehen. Eine Cache-Kopie könnte jedoch noch eine frühere Fassung enthalten.
Dasselbe Prinzip gilt für verschiedene Ebenen gleichzeitig. Browsercache, Reverse Proxy, WordPress-Caching, serverseitige Page-Caches und Content-Delivery-Netzwerke können jeweils unterschiedliche Versionen derselben Ressource gespeichert haben.
Aus Sicht der Performance ist diese Mehrschichtigkeit manchmal lästig. Aus Sicht einer Rekonstruktion kann sie ein Glücksfall sein.
CDN-Protokolle bilden eine zweite Beobachtungsposition
Nutzt eine Website ein Content Delivery Network oder einen vorgeschalteten Proxy, entstehen häufig Protokolle außerhalb des eigentlichen Webservers. Das ist ein wichtiger Unterschied. Ein Angreifer mit vollständigem Zugriff auf den Webserver könnte dort lokale Logs verändern oder löschen. Systeme außerhalb dieses Servers liegen dagegen möglicherweise außerhalb seiner Reichweite.
Damit entsteht eine unabhängige Beobachtungsposition. Der Ursprungsserver behauptet vielleicht, ein bestimmter Zugriff sei nie erfolgt. Der vorgeschaltete Dienst hat denselben Request jedoch verarbeitet.
Besonders wertvoll werden solche unabhängigen Datenquellen, wenn mehrere Zeitlinien miteinander verglichen werden können. Absolute Gewissheit entsteht dadurch noch nicht automatisch, aber Manipulationen auf nur einer Ebene verlieren an Wirkung.
Auch DNS-Änderungen können Teil der Spur sein
Nicht jeder Website-Angriff betrifft unmittelbar Dateien. Domains können umgeleitet, Nameserver verändert oder einzelne DNS-Einträge manipuliert werden. Besucher landen dann möglicherweise auf einem fremden Server, obwohl die originale Website technisch vollkommen unverändert geblieben ist.
Wer in einer solchen Situation ausschließlich den Webspace untersucht, findet unter Umständen überhaupt nichts Verdächtiges.
Deshalb können historische DNS-Daten, Verwaltungsprotokolle des Registrars oder Benachrichtigungsmails relevant werden. Wieder zeigt sich dasselbe Prinzip: Die Website ist kein einzelnes System. Sie ist eine Kette verschiedener technischer Komponenten. Ein Vorfall kann an jeder Stelle dieser Kette stattfinden.
E-Mails können eine unerwartete Nebenchronologie liefern
Viele Systeme versenden automatisch Nachrichten, wenn Passwörter geändert, Administratoren angelegt, Plugins aktualisiert oder neue Geräte erkannt werden. Im normalen Alltag werden solche Mails kaum beachtet. Nach einem Vorfall können sie zu kleinen Zeitmarken werden.
Ein Administrator findet beispielsweise morgens eine Benachrichtigung über eine Passwortänderung von 02:51 Uhr. Das betreffende Benutzerkonto wurde inzwischen gelöscht. Die Website selbst enthält kaum noch Hinweise auf den Vorgang, doch die externe Mailbox besitzt eine Kopie der Systemmeldung.
Auch hier ist die Information allein nicht ausreichend, um einen vollständigen Ablauf zu beweisen. Sie bietet aber einen weiteren unabhängigen Zeitpunkt, der mit Server- und Datenbankdaten abgeglichen werden kann.
Cronjobs sind besonders interessante Verstecke
Webanwendungen nutzen zeitgesteuerte Aufgaben für Wartung, Backups, Veröffentlichungen und zahlreiche Hintergrundprozesse. WordPress besitzt beispielsweise ein eigenes System geplanter Ereignisse, während Server zusätzlich klassische Cronjobs verwenden können.
Ein Angreifer muss Schadcode nicht dauerhaft über eine offensichtliche Datei aktiv halten. Ein manipulierter zeitgesteuerter Vorgang kann dafür sorgen, dass entfernte Komponenten später erneut erzeugt werden. Genau deshalb wirken manche kompromittierten Websites nach einer Bereinigung zunächst sauber und zeigen wenige Stunden später wieder dieselben Auffälligkeiten.
Wer nur den sichtbaren Schadcode entfernt, beseitigt in einem solchen Fall die Wirkung, nicht aber den Mechanismus, der sie erzeugt.
Temporäre Verzeichnisse werden leicht übersehen
Webanwendungen schreiben Daten nicht ausschließlich in ihre bekannten Upload- und Plugin-Verzeichnisse. Temporäre Dateien können während Uploads, Updates, Archivoperationen oder anderer Prozesse entstehen. Manche werden automatisch entfernt, andere bleiben nach Fehlern bestehen.
Auch Betriebssysteme und Laufzeitumgebungen besitzen eigene temporäre Bereiche. Gerade dort können ungewöhnliche Fragmente auftauchen, die bei einer normalen Website-Prüfung gar nicht berücksichtigt werden.
Interessant ist dabei nicht unbedingt die vollständige Datei. Schon Dateinamen, Größen, Fragmente oder Zeitpunkte können helfen, eine Aktivität mit anderen Ereignissen zu verbinden.
Der Browser eines Administrators kann ebenfalls Teil der Geschichte sein
Die Spurensuche muss nicht zwangsläufig auf dem Server enden. Wurde ein Administratorkonto missbraucht, können lokale Systeme eine Rolle spielen. Browser speichern Verlauf, Cookies, Cache-Einträge, Downloads und weitere Zustände. Passwortmanager oder lokale Sicherheitssoftware besitzen wiederum eigene Protokolle.
Damit wird eine zunächst rein serverseitig wirkende Untersuchung plötzlich breiter. Vielleicht erfolgte der Einstieg gar nicht über eine Schwachstelle der Website, sondern über ein kompromittiertes Administratorgerät.
Das erklärt auch, warum das bloße Neuinstallieren einer Website manche Vorfälle nicht dauerhaft löst. Bleibt der ursprüngliche Zugangskanal offen, beginnt das Problem erneut.
Zeitzonen können eine perfekte Chronologie scheinbar zerstören
Bei der Zusammenführung verschiedener Datenquellen taucht ein erstaunlich banales Problem auf: Nicht jedes System verwendet dieselbe Uhrzeit. Der Server arbeitet möglicherweise mit UTC, das CMS speichert lokale Zeit, ein externer Dienst verwendet eine andere Darstellung und exportierte Logs enthalten zusätzlich Zeitverschiebungen.
Ein Zugriff um 01:43 Uhr kann deshalb scheinbar eine Stunde vor einer Dateiänderung um 02:43 Uhr stattgefunden haben, obwohl beide Einträge denselben Moment beschreiben.
Noch komplizierter wird es bei Sommerzeitumstellungen, falsch konfigurierten Serveruhren oder Geräten ohne zuverlässige Zeitsynchronisation. Eine forensische Timeline ist deshalb nicht einfach eine Sortierung sämtlicher Zeitstempel. Zunächst muss geklärt werden, welches System welche Zeitbasis verwendet.
Der stärkste Hinweis entsteht häufig aus mehreren schwachen Spuren
Eine einzelne Logzeile kann durch einen normalen Bot entstanden sein. Eine merkwürdige Datei könnte zu einem legitimen Plugin gehören. Eine ungewöhnliche Datenbank-ID kann vollkommen harmlos sein. Eine fehlgeschlagene Anmeldung beweist keinen Einbruch.
Treffen jedoch zahlreiche unabhängige Beobachtungen zeitlich zusammen, verändert sich ihre Bedeutung. Um 04:17 Uhr erscheint eine ungewöhnliche POST-Anfrage. Sekunden später wird eine Datei verändert. Kurz darauf entsteht ein neuer Administrator. Danach ruft dieselbe IP-Adresse eine bislang unbekannte PHP-Datei auf. Eine Stunde später beginnt ungewöhnlicher ausgehender Datenverkehr.
Keine einzelne dieser Beobachtungen erzählt die ganze Geschichte. Ihre Reihenfolge tut es möglicherweise.
Eine Website besitzt mehr Gedächtnis, als ihre Oberfläche vermuten lässt
Die faszinierendste Erkenntnis ist deshalb nicht, dass Server viele Logdateien speichern. Interessanter ist die Redundanz moderner Webinfrastruktur. Dieselbe Handlung kann unbeabsichtigt an mehreren Orten Spuren erzeugen. Eine Anfrage wird vom CDN gesehen, vom Webserver protokolliert, vom Anwendungscode verarbeitet, verändert eine Datenbank und löst anschließend eine E-Mail aus. Vielleicht landet der veränderte Zustand wenige Minuten später zusätzlich in einem Backup.
Für einen Angreifer bedeutet das, dass vollständiges Spurenlöschen erheblich schwieriger ist als das Entfernen der sichtbaren Schadsoftware. Er müsste nicht nur wissen, welche Systeme existieren, sondern auch Zugriff auf sämtliche unabhängigen Ebenen besitzen.
Für Betreiber bedeutet es umgekehrt, dass nach einem Vorfall nicht unbedingt alles verloren ist, nur weil die offensichtlichste Spur verschwunden ist.
Gute Protokollierung beginnt lange vor dem Angriff
Der Nutzen dieser Spuren hängt allerdings davon ab, ob sie überhaupt vorhanden sind. Werden Access Logs nur einen Tag gespeichert, Backups ständig überschrieben und externe Dienste ohne Historie betrieben, verschwindet ein großer Teil des technischen Gedächtnisses sehr schnell.
Damit bekommt Logging eine Funktion, die über Fehlersuche und Statistik hinausgeht. Aufbewahrungszeiträume, zentrale Protokollierung und getrennte Backup-Generationen bestimmen mit darüber, wie weit sich ein vergangener Vorfall später noch rekonstruieren lässt.
Das Interessante daran: Viele dieser Maßnahmen müssen gar nicht speziell für Forensik eingerichtet worden sein. Ein sinnvoll organisiertes Backup-System, nachvollziehbare Administrationsprotokolle und ausreichend lange Log-Rotation schaffen bereits eine wesentlich bessere Ausgangslage.
Manchmal ist Nichtstun für einige Minuten die technisch klügste Aktion
Das klingt für Administratoren zunächst widersinnig. Wird eine kompromittierte Website entdeckt, möchte man den Schaden sofort beseitigen. Bei akutem Risiko kann schnelles Eingreifen selbstverständlich notwendig sein. Trotzdem sollte zwischen Eindämmung und unüberlegter Veränderung unterschieden werden.
Ein vorschnell ausgeführtes Komplettupdate verändert hunderte oder tausende Dateien gleichzeitig. Ein zurückgespieltes Backup ersetzt genau den Zustand, den man möglicherweise analysieren wollte. Das Löschen vermeintlich verdächtiger Dateien entfernt nicht nur Schadcode, sondern eventuell auch Informationen über dessen Herkunft und Funktion.
Die erste Frage nach einem ernsthaften Vorfall lautet deshalb nicht ausschließlich: Wie bekommen wir die Website möglichst schnell wieder sauber? Ebenso wichtig kann sein: Welche Informationen brauchen wir später noch, um zu verstehen, was hier passiert ist?
Das digitale Echo eines Angriffs ist oft langlebiger als der Angriff selbst
Webangriffe wirken häufig flüchtig. Ein Script wird hochgeladen, einige Aktionen werden ausgeführt und die Datei verschwindet wieder. Die sichtbare Aktivität kann nur Minuten dauern. Ihr technisches Echo lebt dagegen möglicherweise in Backups, Logarchiven, Datenbanken, Caches, Mailkonten und externen Diensten weiter.
Genau diese verteilten Schatten machen die Analyse moderner Websites so interessant. Eine Website besteht nicht nur aus dem Zustand, den der Browser gerade ausliefert. Sie besitzt Vergangenheit – verteilt auf zahlreiche Systeme, die jeweils einen kleinen Ausschnitt davon gespeichert haben.
Wer nach einem Sicherheitsvorfall ausschließlich nach der einen verdächtigen Datei sucht, betrachtet deshalb vielleicht gerade den unwichtigsten Teil der Geschichte. Die spannendsten Spuren können dort liegen, wo niemand absichtlich etwas dokumentieren wollte.