auditd-EXECVE-Forensik: auid, ses und Hex-Argumente

Kurzfassung. Ist eine execve-Regel geladen, zeichnet audit.log jedes auf dem Host ausgeführte Programm auf. Eine Ausführung besteht aus mehreren Einträgen (SYSCALL, EXECVE, CWD, PATH, PROCTITLE) mit demselben Stempel msg=audit(sec.msec:serial). Gruppieren Sie nach diesem Stempel, dekodieren Sie hex-kodierte Argumente und nutzen Sie auid (den Login-Benutzer) und ses (die Login-Sitzung), um einem Benutzer über sudo -i in eine Root-Shell zu folgen, wo auth.log blind wird.

Hat der Host das überhaupt?

auditd ist unter RHEL und Fedora standardmäßig installiert und aktiviert, unter Debian und Ubuntu nicht. Selbst wo es läuft, gibt es keine execve-Einträge, solange keine Regel sie anfordert, zum Beispiel:

-a always,exit -F arch=b64 -S execve -k exec

Lesen Sie /etc/audit/rules.d/*.rules im Abbild (und die Ausgabe von auditctl -l, falls live gesichert), bevor Sie aus fehlenden Einträgen Schlüsse ziehen. Ohne execve-Regeln erhalten Sie trotzdem die Userspace-Ereignisse: USER_AUTH, USER_LOGIN, USER_START, USER_END, USER_CMD (sudo), USER_CHAUTHTOK (Passwortänderung), ADD_USER sowie Änderungen an der Audit-Konfiguration.

Ein Ereignis, mehrere Einträge

type=SYSCALL msg=audit(1789381120.086:181322): arch=c000003e syscall=59 success=yes exit=0 ppid=3200 pid=3204 auid=1001 uid=0 gid=0 euid=0 tty=pts1 ses=114 comm="tar" exe="/usr/bin/tar" key="exec"
type=EXECVE msg=audit(1789381120.086:181322): argc=4 a0="tar" a1="czf" a2="/tmp/.f.tgz" a3=2F7372762F66696E616E63652F513320636C6F7365
type=CWD msg=audit(1789381120.086:181322): cwd="/home/svc_backup"
type=PATH msg=audit(1789381120.086:181322): item=0 name="/usr/bin/tar" inode=13113204 ... nametype=NORMAL
type=PROCTITLE msg=audit(1789381120.086:181322): proctitle=74617200637A66002F746D702F2E662E74677A002F7372762F66696E616E63652F513320636C6F7365
type=EOE msg=audit(1789381120.086:181322):

Alle sechs Zeilen bilden ein Ereignis. Der Stempel 1789381120.086:181322 besteht aus Epochensekunden (UTC), Millisekunden und einer vom Kernel erzeugten Seriennummer. Die Seriennummer beginnt beim Systemstart von vorn, gruppieren Sie also nach dem gesamten Stempel, nicht nur nach der Seriennummer. Einträge verschiedener Ereignisse können in der Datei ineinandergreifen; die Gruppierung nach Stempel fängt das ab.

Die Befehlszeile zusammensetzen

Der EXECVE-Eintrag enthält argc und ein Feld pro Argument:

Werte in Anführungszeichen (a1="czf") sind Klartext.
Hex-Werte ohne Anführungszeichen (a3=2F7372...) sind hex-kodiert, weil das Argument ein Leerzeichen, ein doppeltes Anführungszeichen, ein Steuerzeichen oder Nicht-ASCII-Bytes enthält. Das Dekodieren von 2F7372762F66696E616E63652F513320636C6F7365 ergibt /srv/finance/Q3 close: ein Argument mit Leerzeichen, das die einfache sudo-Zeile in auth.log nicht von zweien unterscheiden kann.
Lange Argumente werden aufgeteilt: a1_len=N, gefolgt von den Teilstücken a1[0]=..., a1[1]=..., und eine lange Befehlszeile kann sich über mehrere EXECVE-Einträge desselben Ereignisses erstrecken. Fügen Sie die Teilstücke in der richtigen Reihenfolge zusammen, bevor Sie dekodieren.
PROCTITLE enthält die Befehlszeile, wie der Prozess sie sah, hex-kodiert mit NUL-Trennzeichen und bei langen Befehlszeilen vom Kernel abgeschnitten. Bevorzugen Sie EXECVE, wenn beide vorhanden sind.

CWD liefert das Arbeitsverzeichnis, sodass sich relative Pfade in den Argumenten auflösen lassen. PATH-Einträge nennen die ausführbare Datei und den Loader, mit Inode und Eigentümer.

auid und ses: dem Benutzer zu root folgen

Der SYSCALL-Eintrag trägt zwei Identitäten:

uid, euid: unter wem der Prozess gerade läuft (0 innerhalb einer Root-Shell).
auid: die Audit-Login-UID, einmal beim Login des Benutzers gesetzt (der LOGIN-Eintrag: old-auid=4294967295 auid=1001) und von jedem Kindprozess geerbt, auch über sudo und su. 4294967295 bedeutet „nicht gesetzt“: Daemons und Prozesse aus dem Systemstart.

Und eine Sitzung:

ses: die Audit-Sitzungs-ID, zum selben Zeitpunkt gesetzt. Jeder Befehl dieses Logins, ob als Benutzer oder als root, trägt sie.

In der Praxis: auth.log zeigt, wie svc_backup um 10:04 sudo -i ausführt, danach nichts, bis die Shell geschlossen wird. audit.log für ses=114 zeigt, was in dieser Shell geschah:

type=SYSCALL ... auid=1001 uid=0 euid=0 tty=pts1 ses=114 comm="passwd" exe="/usr/bin/passwd"
type=SYSCALL ... auid=1001 uid=0 euid=0 tty=pts1 ses=114 comm="crontab" exe="/usr/bin/crontab" key="exec"
type=EXECVE  ... argc=4 a0="crontab" a1="-u" a2="svc_backup" a3="/tmp/.c"

uid=0 besagt, dass root den Befehl ausgeführt hat; auid=1001 besagt, dass es der Login von svc_backup war. Das Journal speichert dieselben Werte als _AUDIT_LOGINUID und _AUDIT_SESSION, womit Sie Journal-Einträge mit der Audit-Sitzung verknüpfen können.

RAW und ENRICHED

Mit log_format = ENRICHED (Upstream-Standard in aktuellen audit-Versionen; Distributionen können ihn überschreiben) hängt auditd aufgelöste Namen nach einem 0x1D-Byte in Großbuchstaben an: AUID="svc_backup" UID="root" SYSCALL=execve. Diese Namen wurden auf dem ursprünglichen Host aufgelöst und sind daher zuverlässiger als ausearch -i auf einer Analyse-Workstation mit einer anderen /etc/passwd. Bei RAW lösen Sie UIDs mit der /etc/passwd aus dem Abbild auf.

ausearch für die Klassiker

ausearch -if audit.log -m EXECVE -ul 1001 -i        # alles, was unter Login-UID 1001 lief
ausearch -if audit.log --session 114 -i             # eine Login-Sitzung
ausearch -if audit.log -m USER_CMD -i               # sudo-Befehle, hex-dekodiert
ausearch -if audit.log -m CONFIG_CHANGE,DAEMON_END -i   # Audit-Manipulation

-i interpretiert Werte anhand der Kontodateien des Analysesystems, sofern das Log nicht ENRICHED ist.

Worauf Sie achten sollten

Aufklärung direkt nach dem Login: id, uname, cat /etc/passwd, sudo -l.
Persistenz: crontab, systemctl --user enable, Schreibzugriffe unter /etc/systemd/system oder ~/.config/systemd/user.
Bereitstellung und Exfiltration: tar, zip, rclone, curl, scp mit Pfaden zu sensiblen Daten.
Anti-Forensik: rm von Journal-Dateien, Skripte gegen /var/log/wtmp, ln -sf /dev/null ~/.bash_history, history -c (ein Builtin, daher kein execve-Eintrag), auditctl -D oder -e 0.
Befehlszeilen, die nach Reverse Shell aussehen: Interpreter oder Netzwerktools, deren Argumente eine Shell an eine entfernte Adresse umleiten. Behandeln Sie einen Musterfund als Spur und lesen Sie die vollständige Argumentliste.

Im Browser

Linux Log Parser gruppiert Audit-Einträge nach Stempel, setzt EXECVE-Argumente zusammen, auch hex-kodierte und aufgeteilte, liest RAW- und ENRICHED-Logs, ordnet Befehle über ses den rekonstruierten Sitzungen zu und kennzeichnet Persistenz, Befehle zum Löschen von Logs, verdächtige Tools und Reverse-Shell-ähnliche Muster. Die Beispielermittlung verfolgt ses=114 von Anfang bis Ende, und der auditd-Spickzettel behandelt Regeln, Aufbewahrung und Eintragstypen.