DFIR unter Linux: Live-Triage mit UAC und Velociraptor

Drei Uhr nachts, ein Debian 12 zeigt einen verdaechtigen Cron, der alle 90 Sekunden /etc/ld.so.preload neu schreibt. Der falsche Reflex waere, die Maschine auszuschalten; der richtige ist, das Triage-Runbook zu oeffnen und den Live-Zustand zu erfassen, bevor der Angreifer merkt, dass das Licht angeht. Bei Basilisk taucht dieses Szenario monatlich in Simulationslaboren auf, und die Regel ist simpel: Order of Volatility zuerst, Hypothesen spaeter. Speicher, Verbindungen, Prozesse, offene File Descriptors und Kernel-Module haben absolute Prioritaet, denn ein Reboot oder ein fehlplatziertes kill -9 zerstoert 80% dessen, was zaehlt.

Order of Volatility als erstes Gesetz

Die Order of Volatility (RFC 3227) ordnet Beweise nach Fluchtigkeit: CPU-Register und Cache verschwinden in Nanosekunden, RAM beim Stromverlust, Netzwerkverbindungen in Sekunden, laufende Prozesse bis zum naechsten Reboot, Disk am langsamsten. Die Konsequenz fuer die Praxis: du sammelst von fluchtig nach persistent, nie umgekehrt. Ein reboot, um den Cron zu stoppen, loscht genau die Speicherseiten, die den entpackten Payload und die C2-Adresse enthalten.

Konkret heisst das: erst ss -tunap fuer aktive Sockets, ps auxww und /proc/[pid]/exe fuer laufende Prozesse (auch geloschte Binaries lassen sich aus /proc rekonstruieren), lsof -n fuer offene Deskriptoren, cat /proc/modules fuer geladene Kernel-Module. Jede Ausgabe wird mit UTC-Timestamp und Hostname in eine Read-only-Ausgabe geschrieben, nie auf die Opferplatte. Erst wenn der fluchtige Zustand gesichert ist, denkst du ueber Isolation nach.

UAC fuer die One-Shot-Triage

Unser Standard-Werkzeugkasten beginnt mit UAC (Unix-like Artifacts Collector) von Tulpa Security und Velociraptor von Rapid7. UAC ist perfekt fuer Offline-One-Shot-Triage: Sie legen ein ~6MB tar.gz ab, fuehren ./uac -p ir_triage /mnt/beweise aus, und in 8 bis 15 Minuten haben Sie Hashes, /proc-Dumps, journald, bash_history aller Nutzer, Cron-Listings und SSH-Konfiguration komprimiert.

UAC ist bewusst abhaengigkeitsarm: reines Shell, laeuft auf einem Host, auf dem du nichts installieren darfst, und respektiert die Order of Volatility im eingebauten Profil. Der wichtigste Betriebshinweis: fuehre UAC von einem read-only gemounteten Medium aus und schreibe die Ausgabe auf ein separates, verschluesseltes Ziel, damit du keinen einzigen Zeitstempel (atime) auf dem Opfer veranderst. Wer das Basis-Lab noch nicht gebaut hat, sollte vor echten Incident-Simulationen Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen durchgehen.

Speicherakquise mit AVML

Die Speicherakquise bleibt der fragilste Schritt unter Linux. Auf Kernel 6.x ist AVML von Microsoft Research die konsistenteste Option, wenn LiME wegen fehlender Header nicht baut. Echter Befehl: avml --compress /beweise/memdump.lime. Reservieren Sie mindestens die doppelte RAM-Groesse auf Platte und schreiben Sie niemals auf die Opferdisk; mounten Sie ein read-write NFS unter /mnt/triage oder einen LUKS-verschluesselten USB-Stick.

Der Grund fuer AVML statt LiME ist praktisch: LiME wird als Kernel-Modul gegen die exakten Kernel-Header kompiliert, die auf dem Opfer oft fehlen, wahrend AVML ein statisch gelinktes Userspace-Binary ist, das ueber /proc/kcore oder /dev/crash liest. Nach der Erfassung geht die Analyse in Volatility 3 mit auto-erkanntem Profil weiter, und genau hier trifft die Pipeline auf Memory Forensics mit Volatility 3: Dumps im Reproduzierbaren Lab Analysieren. Ohne Memory Dump bleibt jedes LD_PRELOAD-Rootkit eine urbane Legende im Report.

Analyse in Volatility 3

Mit dem Dump in der Hand baust du in Volatility 3 die Prozesshierarchie mit linux.pstree, listest Netzwerkverbindungen mit linux.sockstat und suchst versteckte oder aus dem Prozessbaum entkoppelte Prozesse mit linux.psscan. Der klassische Fund bei einem LD_PRELOAD-Rootkit ist eine Diskrepanz: ps auf dem Live-System zeigt weniger Prozesse als linux.psscan im Dump, weil das Rootkit die Userspace-Sicht manipuliert, aber die Kernel-Strukturen nicht.

Fuer moderne Kernel ist die Symboltabelle (ISF, Intermediate Symbol Format) entscheidend; ohne passende Symbole liefert Volatility unvollstandige Ergebnisse. Generiere die ISF-Datei aus dem vmlinux mit Debug-Symbolen der exakten Kernel-Version des Opfers. Deshalb lohnt es sich, im Vorfeld ein Symbol-Repository fuer die Kernel-Versionen deiner Flotte zu pflegen, damit du im Ernstfall nicht Stunden mit der Symbolbeschaffung verlierst.

Persistenz jagen: nie nur an einem Ort

Persistenz unter Linux wohnt selten an einem Ort. In juengsten Kinsing-Mining-Faellen fanden wir vier gleichzeitige Vektoren: eine systemd-Unit unter /etc/systemd/system/.cache.service, einen Root-Crontab-Eintrag, eine modifizierte /etc/rc.local und einen SUID-Wrapper unter /usr/local/sbin/ssh. UAC faengt all das mit dem Profil ir_triage, aber zusaetzlich find / -newermt '2026-06-01' -type f -mtime -8 2>/dev/null schliesst Luecken.

Vergiss die unauffalligen Ecken nicht: ~/.bashrc und /etc/profile.d/, authorized_keys mit einem untergeschobenen Schluessel, udev-Regeln, PAM-Module und Cron-at-Jobs. Ein einzelner geloschter Vektor gibt dem Angreifer den Host in Stunden zurueck. Zur Korrelation mit aequivalenten Windows-Techniken konsultiert das Team Windows-Persistenz: 10 Dokumentierte Techniken und ihre Gegenmassnahmen, weil opportunistische Angreifer Muster plattformuebergreifend wiederverwenden.

Velociraptor: von einem Host zur Flotte

Velociraptor veraendert das Spiel, sobald wir von einem Host auf eine Flotte wechseln. Wir starten einen Server auf t3.medium, generieren Linux-Clients mit velociraptor config client, verteilen sie per Ansible, und in 20 Minuten haben wir Sichtbarkeit. Die nuetzlichsten Hunts in unserem Playbook sind Linux.Network.NetstatEnriched fuer aktive Sessions, Linux.Sys.SUID fuer verdaechtige Binaries und eine kompilierte Yara-Regel mit Signaturen fuer Pupy, Sliver und Merlin.

Der Vorteil von VQL ist, dass du eine Hypothese als Query formulierst und sie synchron gegen 120 Hosts feuerst: zeige mir jeden Prozess, dessen Binary in /tmp oder /dev/shm liegt und eine ausgehende Verbindung hat. Trifft ein IOC, exportieren wir ein signiertes Collection-Zip und gehen zur statischen Analyse in isolierter Sandbox ueber, wie in Malware-Analyse im Isolierten Lab: Sicheres Setup mit FlareVM und REMnux beschrieben. Der Trick: nie das SHA-256-Hashing vor dem Verschieben von Artefakten ueberspringen.

Super-Timeline mit plaso

Sobald die fluchtigen Beweise gesichert sind, verwandelt eine Super-Timeline verstreute Artefakte in eine Erzahlung. Mit log2timeline.py (plaso) parst du Dateisystem-Timestamps, journald, bash_history, Cron-Logs und Webserver-Zugriffe in eine einzige zeitlich sortierte Ansicht und filterst per psort.py auf das Vorfallsfenster. So siehst du auf einen Blick, dass der SSH-Login um 02:14 UTC dem curl des Payloads um 02:15 und dem Schreiben der systemd-Unit um 02:16 vorausging.

Der haufigste Fehler ist, die Zeitzonen zu vermischen: arbeite konsequent in UTC und notiere den Offset des Hosts, sonst baust du eine Kausalkette, die um Stunden daneben liegt. Achte auf Timestomping (per touch -t zuruckgesetzte mtime); die ctime, die ein Angreifer schwerer falscht, verrat die echte Anderungszeit und entlarvt die Manipulation.

Chain of Custody und Hashing

Jedes Artefakt bekommt beim Erfassen einen SHA-256-Hash, und dieser Hash wird beim Empfang am Analyseplatz erneut berechnet und verglichen. Stimmen sie nicht, ist der Beweis fuer jede formale Verwendung wertlos. Wir dokumentieren jede Entscheidung in einer Chain of Custody mit UTC-Timestamp, Hash und Operator, weil selbst im Lab Disziplin den noetigen Muskel fuer den Ernstfall aufbaut.

Praktisch heisst das: ein append-only Logbuch (idealerweise auf einem separaten System), in dem jeder Befehl, jeder Kopiervorgang und jede Isolationsentscheidung mit Zeitstempel steht. Wer diese Disziplin erst im echten Vorfall lernt, verliert die halbe Nacht mit dem Nachvollziehen dessen, was er selbst getan hat. Automatisiere das Logging so weit wie moeglich, damit es unter Druck nicht vergessen wird.

Nach der Triage: Detektion und Hardening

Post-Triage Threat Hunting schliesst den Kreis. Wir verwandeln Detektionen in Sigma-Regeln und schieben sie in Elastic, was den Incident in dauerhafte defensive Faehigkeit verwandelt, der Fluss ist in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel detailliert. Aus einem einzelnen ld.so.preload-Fund wird so eine flottenweite Detektion, die den naechsten Versuch in Sekunden meldet.

Hosts, die den Incident ueberleben, haerten wir gemaess Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen und ueberpruefen SSH nach SSH-Hardening 2026: Algorithmen, Zertifikate und Bastion-Hosts, bevor sie zurueck in die simulierte Produktion gehen. Ein wiederhergestellter Host ohne geschlossenen Erstzugangsvektor wird in Tagen erneut kompromittiert, meist von derselben automatisierten Kampagne, die den ersten Zugang fand, weil der Scan-Bot die IP bereits kennt und periodisch zuruckkehrt.

Checkliste fuer die Live-Triage

Vor dem Anfassen: (1) Read-only-Toolkit gemountet, Ausgabeziel verschluesselt und getrennt; (2) fluchtiger Zustand erfasst (Sockets, Prozesse, Module, /proc) mit UTC-Timestamps; (3) Memory-Dump per AVML, mindestens 2x RAM Platz reserviert; (4) UAC-ir_triage plus manueller find-Sweep fuer frische Dateien; (5) alle vier Persistenz-Klassen (systemd, cron, rc.local/profile, SUID/authorized_keys) geprueft; (6) jedes Artefakt gehasht und im Custody-Log eingetragen; (7) Isolation erst nach vollstandiger Sammlung; (8) Detektion als Sigma-Regel zurueckgespielt.

FAQ

Soll ich die Maschine sofort vom Netz nehmen? Es kommt darauf an, was du schuetzt. Bei aktiver Datenexfiltration ja, aber ideal per Upstream-Firewall-Regel statt durch Ziehen des Kabels am Host, damit der Speicherzustand und die C2-Verbindung fuer die Erfassung erhalten bleiben. Ein hartes Trennen kann laufende Verschluesselung oder einen Dead-Man-Switch ausloesen.

Reicht Disk-Forensik ohne Memory-Dump? Nein, gegen speicherresidente Malware und LD_PRELOAD-Rootkits nicht. Vieles moderne Tooling beruehrt die Platte kaum. Ohne Memory-Dump siehst du die halbe Geschichte und schreibst Vermutungen in den Report.

UAC oder Velociraptor: was zuerst? Bei einem einzelnen, isolierten Host ist UAC schneller aufgesetzt und braucht keinen Server. Sobald du mehr als eine Handvoll Hosts oder wiederholte Hunts hast, gewinnt Velociraptor durch zentrale Orchestrierung und VQL. In der Praxis kombinieren wir beide: Velociraptor fuer die flottenweite Sichtung, UAC fuer die tiefe Sammlung auf den Hosts, die als kompromittiert markiert wurden. Es ist kein Entweder-oder, sondern eine Sequenz.

Praktisches Takeaway: bauen Sie heute einen LUKS-Stick mit UAC, AVML und einem vorkonfigurierten Velociraptor-Client gegen Ihren Hunt-Server. Testen Sie auf einer sauberen Debian-VM, stoppen Sie die Zeit, justieren Sie das Profil und versionieren Sie das tar.gz in Ihrem internen Repo. Wenn der Pager um 3 Uhr klingelt, wollen Sie keine Dokumentation lesen, sondern Beweise sammeln. Live-Triage ist keine Kunst, sondern eine disziplinierte Checkliste unter Druck.