SANS SEC555: Eindrücke aus München
Wie man Angriffe erkennt, wenn sich Dateien ständig ändern, und warum lokale KI im Betrieb sinnvoll ist.
Ich erlebe gerade ein sehr intensives Training im Bereich der IT-Sicherheit. Der SANS-Kurs SEC555 in München hat neben viel Fachwissen auch interessante Gespräche gebracht. Im Mittelpunkt stehen Detection Engineering, der Einfluss von KI auf Angriffswerkzeuge und die Frage, warum gute technische Regeln in Unternehmen oft an der Realität vorbeigehen.
Hochverdichtete Informationsvermittlung
Wie bei jedem SANS-Event wurde auch diesmal sehr viel Wissen in wenig Zeit vermittelt. Druckbetankung also.
Aber auch in den Pausen gab es regen Austausch unter den Teilnehmern. Natürlich konnte niemand über interne Abläufe berichten. Die Tools, die zusammengetragen wurden, waren absolutes Gold wert, weswegen ich Onlineschulungen eher ungern mache. Gerade der Austausch unter den Experten wäre dann verloren. Grundsätzlich schienen die anderen Teilnehmer aber ähnliche Erfahrungen in ihrem Arbeitsumfeld zu erleben. Alle haben aufregende Aufgaben. Doch werden einige durch seltsame Prozesse gehindert. Ich versuche es mal mit einem konstruierten Beispiel:
Die Firewall-Regel prüft die falsche Richtung
Server A enthält Daten, die nicht zu Server B wandern dürfen. Also verbietet das Management dass per Firewallregel A eine Verbindung zu B aufbauen kann. Auf dem Papier ist das sauber, technisch aber fraglich. Die Firewall kontrolliert, wer eine Verbindung eröffnet, nicht wohin die Daten fließen.
Stellt B eine Verbindung zu A her und lädt die Dateien per HTTPS oder SFTP herunter, sieht die Firewall nur einen gewöhnlichen Verbindungsaufbau von B nach A. Die Daten laufen dann als Antwort über genau diese Verbindung zurück. Vergleichbar ist das mit einem Türsteher, der nur prüft, wer klingelt, aber nicht, wer mit dem Paket wieder hinausgeht.
Diese Management-Vorgaben erzeugten allerhöchstens Frustration unter den Administratoren, aber die Dokumentation ist zufriedengestellt.
Warum der Hash als Beweis ausgedient hat
Ein Hash wie SHA-256 ist eine feste Zeichenkette, die aus dem Inhalt einer Datei berechnet wird. Ändert sich ein einziges Byte, ändert sich der gesamte Wert. Über viele Jahre war der Hash von mimikatz ein verlässliches Erkennungsmerkmal. Virenscanner und IOC-Listen arbeiteten genau damit.
Seit KI-Modelle Code in Sekunden neu schreiben, ist dieses Verfahren kaum noch belastbar. Jede neu generierte Variante hat einen anderen Hash, andere Funktionsnamen und oft einen anderen Dateinamen. Die Liste der bekannten Hashes veraltet, bevor sie jemand ausrollt. Der Hash taugt deshalb höchstens noch als Hinweis auf bekannte, unveränderte Dateien. Als alleiniger Beweis für einen Angriff reicht er nicht mehr.
Verhalten statt Signatur: User Behaviour Analytics
Was sich bei einer Neuschreibung nicht ändert, ist das Verhalten. Um Zugangsdaten aus dem Speicher eines Windows-Systems auszulesen, muss ein Programm auf den Prozess lsass.exe zugreifen. Diesen Zugriff kann man mit Sysmon protokollieren, etwa über das Ereignis mit der ID 10, und in Wazuh auswerten.
Cristina Garrido
Die Analogie aus dem Kurs trifft es ganz gut: Ein Täter kann die Kleidung wechseln, aber sein Vorgehen bleibt meist gleich. Entsprechend sollten Regeln ansetzen, die beschreiben, was ein Angreifer tun muss, und nicht, wie sein Werkzeug aussieht. Das ist aufwendiger, weil man Normalverhalten kennen und Baselines pflegen muss, aber es funktioniert auch dann, wenn sich die verwendeten Werkzeuge ändern.
Wazuh trifft Claude: Incident-Analyse per Sprache
Im Kurs wurde Wazuh per MCP mit Claude verbunden. Über das Protokoll kann das KI-Modell auf Alerts und Agenten zugreifen. Man stellt Fragen in gesprochener Sprache und bekommt Zusammenhänge erklärt, etwa warum sich bei einem Host mehrere Anmeldefehler häufen. Das senkt die Einstiegshürde für Analysten spürbar und zeigt, wie viel Zeit bei Routineabfragen verloren geht.
Für den eigenen Betrieb empfiehlt sich allerdings eine lokale KI. Jede Abfrage enthält Logdaten, und diese verlassen bei einem Cloud-Modell das eigene Netz. Auf einer eigenen GPU lässt sich dasselbe Prinzip mit einem lokalen Modell umsetzen, ohne dass sensible Daten das Unternehmen verlassen. Der Kurs hat dafür den Weg gezeigt, die konkrete Umsetzung bleibt Aufgabe des jeweiligen Betriebs. Es ist im Prinzip die Erweiterung meiner bereits bestehenden Voranalyse von Alarmen.
Michael Meister
So kann man als Analyst einfach seine offenen Fragen stellen. Zum Beipiel: "Was ist mir in diesem Incident entgangen? Was ist mit Systemen passiert, die mit dem angegriffenen System in Kontakt standen?"
PHP2Shell schlägt während des Trainings zu
PHP2Shell gehört zu den Schwachstellen, die man derzeit sehr ernst nehmen sollte. Am Tag nach der Bekanntgabe stand sie im SANS-Kurs SEC555 in München auf dem Stundenplan, passend zum Thema Detection.
PHP läuft auf einem großen Teil der Webserver, oft unauffällig im Hintergrund von Content-Management-Systemen, Shops oder Intranet-Anwendungen. Die beiden genannten Schwachstellen erlauben nach aktuellem Stand Remote Code Execution ohne Anmeldung. Ein Angreifer muss also kein Konto besitzen, sondern erreicht den Webserver über das Netz und führt dort Befehle aus.
Wilhelm Drehling
Die Befehle laufen mit den Rechten des PHP-Prozesses. Von dort aus lassen sich Dateien ablegen, Konfigurationen mit Zugangsdaten auslesen, Hintertüren einrichten und weitere Systeme im internen Netz anvisieren. Wer das Problem unterschätzt, verliert Zeit, weil der Angriff oft erst bemerkt wird, wenn bereits Daten abgeflossen sind.
Hinzu kommt das Zeitfenster zwischen Bekanntgabe und Einspielen des Updates. Berichten zufolge wurden verwandte Angriffe teils schon vor der öffentlichen Ankündigung beobachtet. Deshalb ist es sinnvoll, Patchen und Erkennen gleichzeitig anzugehen.
Patchen zuerst, und zwar vollständig
Der wichtigste Schritt bleibt das Aktualisieren der PHP-Installation. Dabei sollte man nicht nur die CLI-Version prüfen, denn der Webserver nutzt oft eine eigene Laufzeit über PHP-FPM oder mod_php. Die Ausgabe von php -v allein sagt daher wenig über den tatsächlichen Dienst aus.
Im Kurs wurde gezeigt, wie man Schwachstellen über die Vulnerability Detection von Wazuh findet. Dafür muss die Software-Inventarisierung aktiv sein, damit die installierten Pakete erfasst werden. Schwieriger wird es bei PHP, das in Containern, Appliances oder Anwendungen mitgeliefert wird, denn dort taucht es in der Paketliste oft nicht auf.
Michael Meister
Dateien im Blick behalten mit FIM
Viele Angriffe hinterlassen zuerst eine neue oder veränderte PHP-Datei. Die Dateiintegritätsüberwachung (FIM) von Wazuh meldet solche Änderungen in Echtzeit. Im Kurs wurde folgende Ergänzung für die bestehende <syscheck>-Sektion der Agentenkonfiguration besprochen:
<syscheck>
<directories realtime="yes" check_all="yes" report_changes="yes">/var/www/html</directories>
<directories realtime="yes" check_all="yes">/tmp</directories>
<directories realtime="yes" check_all="yes">/var/tmp</directories>
</syscheck>
Der Pfad /var/www/html ist durch das eigene Verzeichnis zu ersetzen, das überwacht werden soll. Beschreibbare Upload- und Cache-Verzeichnisse verdienen besondere Aufmerksamkeit. Die Option report_changes liefert Inhaltsdifferenzen, die allerdings Quelltext oder Zugangsdaten enthalten können und entsprechend geschützt werden sollten.
Auf dem Manager lassen sich darauf aufbauend eigene Regeln ergänzen. Die Regelnummern 554 (Datei hinzugefügt) und 550 (Datei geändert) stammen aus der Wazuh-Dokumentation. Die Auswahl verdächtiger PHP-Funktionen wie eval oder shell_exec ist eine Heuristik. Auch legitimer Anwendungscode nutzt diese Funktionen, weshalb ein Treffer eine Prüfung auslöst und kein Urteil darstellt.
Verhalten des Webservers beobachten
Ein Satz aus dem Kurs blieb hängen: Eine Neuschreibung ändert die Datei, aber selten das Verhalten. Ein Webserver, der plötzlich sh, curl oder wget startet, ist auffällig, auch wenn der Angriffscode unbekannt ist. Einige Teilnehmer haben dafür in ihren Unternehmen den Weg über auditd gewählt, der Prozessstarts unter dem Konto des Webservers protokolliert.
Diese Methode erkennt verdächtige Prozessstarts, aber nicht jeden erfolgreichen Angriff. Läuft der Schadcode vollständig innerhalb des PHP-Prozesses, ohne ein Kindprozess zu starten, schlägt die Regel nicht an. Deshalb ergänzen sich die Schichten.
Die gemeinsamen Ideen der Teilnehmer
Besonders wertvoll war der Austausch über Kombinationen. Jede Methode hat blinde Flecken, zusammen ergeben sie ein brauchbares Bild:
- Versionsinventar findet verwundbare Installationen.
- FIM findet abgelegte oder veränderte Dateien.
- auditd und Sysmon finden verdächtige Prozessaktivität des Webservers.
- Logs liefern den Kontext, aus welcher Richtung der Angriff kam.
Der Einsatz von KI ist natürlich ebenfalls eine Hilfe - aber eben nur eine Hilfe.
Erfahrungen aus der Social Night
Der Austausch am Abend war ergiebig. Man hört, wie andere Firmen Anomalien erkennen, welche Baselines sich bewährt haben und wo die Grenzen einfacher Regeln liegen. Solche Gespräche sind wertvoll, weil die Praxis selten in Lehrbüchern steht und neue Ideen entstehen.
Ein Thema kehrte allerdings immer wieder: Viele Experten haben den Eindruck, dass Prozesse von Personen gestaltet werden, die die technischen Zusammenhänge im eigenen Unternehmen nicht detailliert genug kennen. Die Folge sind Anforderungen wie die oben beschriebene Firewall-Regel, die formal erfüllt werden müssen, aber wirkungslos sind. Wer Entscheidungen trifft, sollte die Menschen anhören, die das System betreiben, bevor die Richtlinie festgelegt wird. Ähnlich wie ein Richter sich auf die Aussagen seiner Sachverständigen verlassen muss.
Fazit
Der Kurs hat neues Wissen zu Detection Engineering und zu den Auswirkungen von KI auf Angriffswerkzeuge gebracht. Verhaltensbasierte Erkennung gewinnt gegenüber Signaturen und Hashes an Bedeutung. Wer Regeln formuliert, sollte die Experten frühzeitig einbinden.