Im vorigen Beitrag über Rootkits lief alles auf eine These hinaus: das moderne Rootkit sieht nicht mehr wie ein Rootkit aus, sondern wie legitime Admin-Infrastruktur — ein signierter Treiber, ein eBPF-Programm, ein Scheduled Task. Wer in der Forensik nach den alten Mustern sucht, findet nichts. Dieser Beitrag nimmt die andere Hälfte desselben Phänomens in den Blick: die Persistenz. Denn die Frage „wie bringt man eine Reverse Shell gut getarnt beim Systemstart zum Laufen?" ist im Grunde die Fortsetzung desselben Gedankens — nur eine Schicht weiter oben, im Userspace, und mit einem Artefakt-Set, das man in der Forensik wirklich täglich findet.
Wieder die gleiche Regel wie vorher: Das hier ist konzeptionell, nicht operational. Keine Schrittfolgen, keine Payloads. Wer forensisch arbeitet, muss ahnen, wie die Werkzeuge gedacht sind, ohne sie gebaut zu haben.
Tarnung ist drei Probleme, nicht eines
Die naive Vorstellung von „Reverse Shell beim Autostart" ist ein einziges Problem: ein Eintrag, der etwas ausführt. Tatsächlich zerfällt es in drei unabhängige Teilprobleme, weil jedes für sich entdeckt werden kann — und gute Tarnung heißt, alle drei Achsen gleichzeitig unauffällig zu besetzen:
- Der Autostart-Mechanismus — wie wird der Code beim Boot oder Logon überhaupt ausgeführt?
- Der Payload-Container — was wird ausgeführt: eine nackte Shell oder etwas, das wie etwas anderes aussieht?
- Der C2-Kanal — wie kommt die Verbindung nach Hause, ohne im Netzwerk-Logging aufzufallen?
Die naive Antwort — Run-Key, bash -i >& /dev/tcp/…, öffentliche IP — ist auf allen drei Achsen gleichzeitig laut und stirbt deshalb in Minuten. Die interessanten Antworten spielen die Achsen gegeneinander aus. Bevor wir das zusammensetzen, lohnt sich ein Blick auf die Mechanismen selbst.
Windows: ein ganzes ASEP-Feld
Autostart-Erweiterungspunkte gibt es dutzendfach; die MITRE-ATT&CK-Tactic Persistence (TA0003) ist nichts anderes als ein Katalog davon. Grob geordnet von laut-klassisch nach leise-modern:
Laut und klassisch — was Forensiker als Erstes suchen. Run- und RunOnce-Keys in der Registry (HKLM\…\Run, HKCU\…\Run) sind trivial zu finden und sterben sofort gegen jeden Autostart-Scanner. Dienste (SCM) sind mächtig, weil sie als SYSTEM laufen, aber ein neuer Dienst mit eigenem Binary fällt auf; ein getarnter Dienst nutzt ein legitimes, signiertes Binary mit einem manipulierten Argument — „signed binary proxy execution". Geplante Aufgaben sind ebenfalls SYSTEM-fähig und dazu mit feinen Triggern („bei Event-Log-ID X", „bei Logon", „alle 47 Minuten"), aber die Aufgabe selbst ist ein hartes Forensik-Artefakt.
Leiser — Mechanismen, die im Kontext legitimer Prozesse laufen. Hier wird es interessant. WMI-Permanent-Subscriptions kombinieren einen __EventFilter (etwa „Boot oder alle 8 Stunden") mit einem CommandLineEventConsumer oder ActiveScriptEventConsumer. Das ist der konzeptionell mächtigste Windows-Mechanismus, weil er nicht in einem eigenen Prozess läuft, sondern von WmiPrvSE.exe als legitimer Systemprozess ausgeführt wird, und weil er historisch nicht in jedem Autostart-Scanner auftauchte. Forensisch ein eigener Bereich: man muss das WMI-Repository diffen, nicht nur die Registry scannen.
COM-Hijacking geht einen anderen Weg: anstatt etwas Neues zu starten, trägt man sich in die InprocServer32/LocalServer32-Einträge einer selten genutzten COM-Klasse ein. Lädt ein legitimer Prozess diese Klasse beim Start, lädt er den Angreifer-Code in seinem eigenen Kontext. Für jemanden, der nur nach neuen Autostart-Einträgen sucht, ist das oft unsichtbar — weil der Eintrag schon immer da war, nur der Wert hat sich geändert. DLL-Suchreihen-Hijacking funktioniert analog: ein privilegiertes Autostart-Programm lädt eine DLL, die nicht im Systemverzeichnis liegt; legt man die eigene DLL in dessen Verzeichnis, wird sie beim Start mitgeladen — wieder im Kontext des legitimen Programms.
Tief und seltener. BITS-Jobs (Background Intelligent Transfer Service) mit Notification-Command laden im Hintergrund Daten und führen beim Abschluss einen Befehl aus — sieht nach Windows-Update-Traffic aus. IFEO-Debugger-Einträge lenken den Start eines legitimen Programms um. Die COR_PROFILER-Umgebungsvariable bringt den .NET-CLR-Profiler dazu, eine DLL in jeden .NET-Prozess zu laden.
Linux: die systemd-Ära
Auf Linux hat systemd die Persistenz-Landschaft vereinfacht und gleichzeitig diversifiziert. Die Mechanismen, die man kennen sollte:
systemd-Units und -Timer sind die moderne Entsprechung von Init-Skripten und cron. Ein eigener Dienst mit After=network-online.target startet sauber beim Boot; ein systemd-timer ersetzt cron mit feineren Triggern. Forensisch: systemctl list-unit-files und Unit-Diffs gegen das Paket-Original. cron @reboot ist klassisch, immer noch gültig, aber auffällig in crontab//etc/cron.d.
Shell-Profile (.bashrc, .bash_profile, /etc/profile, /etc/profile.d/*) laufen beim Login — unauffällig, weil ohnehin oft voll mit Admin-Zeug, aber nutzerspezifisch und an Login gekoppelt, nicht an Systemstart. /etc/ld.so.preload bzw. LD_PRELOAD ist der Userland-Rootkit-Anker auf Linux: eine Bibliothek, die in jeden dynamisch gelinkten Prozess injiziert wird — tief, mächtig, forensisch ein klassischer Versteckort, und der direkte Anschluss an das Rootkit-Thema des vorigen Beitrags.
PAM-Module laufen tief im Authentifizierungspfad; ein trojanisiertes oder zusätzliches Modul ist nicht das, was man bei „Autostart" als Erstes sucht. udev-Regeln feuern bei Geräte-Events — ein ungewöhnlicher, aber stabiler Trigger. Und initramfs/GRUB/Kernel-Module bieten tiefe Persistenz, analog zu Windows-Bootkits.
Was „gut getarnt" konzeptionell bedeutet
Jetzt wird das eigentliche Thema greifbar. Die naive Reverse Shell ist auf drei Achsen gleichzeitig laut: ein neuer Autostart-Eintrag (forensisch ein frisches Artefakt ohne Historie), ein unbekanntes Binary (trifft YARA-Regeln und Reputation-Checks), eine langlebige TCP-Verbindung zu einer unbekannten IP (fällt in Netflow-Anomalien). Tarnung heißt, auf jeder Achse das Unauffällige zu wählen — und das bedeutet fast immer: sich einklinken statt sich anmelden.
Autostart — sich einklinken statt sich anmelden. Statt eines neuen Eintrags einen bestehenden übernehmen: ein legitimer Dienst, dem ein zweites Argument oder eine DLL untergeschoben wird; ein COM-Objekt, dessen Server-Pfad umgebogen wird; ein WMI-Subscription, der in einem Systemprozess läuft. Das Forensik-Prinzip dahinter: neue Dinge haben keine Historie, veränderte Dinge müssen gegen einen bekannten Soll-Zustand gedifft werden. Letzteres ist für den Verteidiger teurer — also genau da ansetzen.
Payload — Living off the Land statt eigenes Binary. Die eigentliche Reverse Shell muss gar keine „Reverse Shell" sein. Der modernste Ansatz ist: gar keinen eigenen Payload mitbringen, sondern ein legitimes Remote-Management-Tool zweckentfremden — Atera, ConnectWise, AnyDesk, ScreenConnect, selbst PowerShell-Remoting oder SSH. Die Verbindung nach draußen ist dann eine gewollte Fernwartungsverbindung, nicht eine verdächtige Reverse Shell. Forensisch ist das kaum von legitimer Admin-Arbeit zu trennen, weil es genau das ist, was ein Administrator auch tut. Alternativ:
LOLBins
— certutil, mshta, rundll32, powershell mit verschleiertem Einzeiler — laden den echten Code erst zur Laufzeit aus dem Netz („fileless"), sodass keine persistente Binärdatei auf der Platte liegt, die ein Virenscanner trifft.
Kanal — C2, der wie normaler Traffic aussieht. Die Ära der rohen TCP-Verbindungen ist vorbei; moderner C2 mimt legitimen Traffic: HTTPS zu einer Domain, die visuell einer bekannten ähnelt; Domain Fronting über CDNs, sodass der Ziel-Host im TLS-SNI einer legitimen CDN-Domain steht; Cloud-API-Abuse (Azure-, AWS-, Office365-Endpunkte, GitHub, Slack als C2-Kanal) — Traffic zu diesen Zielen ist in fast jedem Unternehmensnetzwerk Alltag und fällt in Allowlist-basierten Proxies nicht auf. Auf Linux ist ein SSH-Reverse-Tunnel durch einen legitimen Bastion-Host die analoge unauffällige Variante.
Das zusammengesetzte Bild
Konzeptionell sähe „gut getarnt" also so aus — ein Muster, keine Schrittfolge: Persistenz über einen bestehenden legitimen Vektor (WMI-Subscription, COM-Hijack, trojanisiertes Argument eines signierten Dienstes), so dass kein neues Autostart-Artefakt entsteht, sondern ein verändertes. Payload als Living-off-the-Land: kein fremdes Binary auf der Platte, sondern ein legitimes Tool, das zur Laufzeit angewiesen wird, eine Verbindung herzustellen — fileless, ohne YARA-Treffer. Kanal über einen Allowlist-freundlichen Endpunkt: Cloud-API oder CDN-fronted HTTPS, das in den Proxy-Logs wie ganz normaler Traffic aussieht. Und als Timing: nicht sofort beim Boot, sondern verzögert oder event-getriggert, um die Boot-Timeline-Forensik nicht zu füttern.
Das Ergebnis ist etwas, das keiner der naiven Erkennungen trifft — Autostart-Scan, Virenscanner, Netflow-Anomalie —, weil es auf jeder Achse innerhalb der legitimen Verteilung liegt. Genau das ist der Grund, warum moderne Persistenz so lange unentdeckt bleibt.
Die forensische Gegenperspektive
Und deshalb ist die Gegenmaßnahme eine andere geworden als früher. Baselining statt Signatur-Scan: die Frage ist nicht „gibt es einen WMI-Subscription?", sondern „gab es diesen Subscription gestern auch?". Das erfordert Soll-Zustands-Erfassung, die viele Umfelder nicht betreiben — und ist der Grund, warum diese Persistenzen wochen- oder monatelang überleben. Legitimacy-Scoring: Remote-Admin-Tools nicht per se verbieten, sondern ihren Gebrauch anomaliedetektieren — welcher Admin, von welcher IP, zu welcher Uhrzeit, auf welche Hosts? Das de-facto-Rootkit taucht hier als statistischer Ausreißer auf, nicht als Signatur-Treffer. Timeline-Analysis: wann entstand der Autostart-Eintrag, und korreliert das mit einem anderen Ereignis? Veränderte Persistenz ist datiert; neue Persistenz hat einen Zeitstempel. Oft ist genau das der härteste Hinweis.
Die Brücke zurück
Damit schließt sich der Bogen zum Rootkit-Beitrag. Die gut getarnte Reverse-Shell beim Systemstart ist dasselbe Phänomen wie das moderne Rootkit — es ist nicht verschwunden, es sieht nur nicht mehr so aus. Es sieht aus wie ein legitimer Dienst mit leicht verändertem Argument, wie ein COM-Server, der auf einen anderen Pfad zeigt, wie ein Remote-Admin-Tool, das ein Admin hätte starten können. Das Forensik-Handwerk von heute besteht nicht mehr darin, das Verborgene zu finden, sondern das Legitime, das es nicht sein sollte — und dafür braucht man beides: den Katalog der Mechanismen und die Idee, wie ein Angreifer sie besetzen würde. Persistenz ist nicht das Ende der Angriffskette, sondern ihre dauerhafteste Spur. Wer sie lesen kann, hat meistens schon die halbe Geschichte.