Persistenz erkennen: ein Blue-Team-Jagd-Leitfaden

Ein Einbruch ist selten ein einzelner Moment. Nachdem ein Angreifer Fuss gefasst hat, ist seine erste Prioritaet sicherzustellen, dass er zurueckkehren kann, selbst wenn die Maschine neu startet, das Passwort sich aendert oder der urspruengliche Einstiegspunkt geschlossen wird. Diese Faehigkeit heisst Persistenz, und die Jagd danach ist eine der wertvollsten Taetigkeiten, die ein Blue Team ausfuehrt. Dieser Leitfaden nimmt eine defensive Haltung ein: Wir beschreiben die Kategorien der Persistenz, damit Sie ihre Spuren erkennen, konzentrieren uns auf die Telemetrie, Event-IDs und Jagd-Workflows, die sie enthuellen, und schliessen mit Haertung. Ziel ist es, Erkennung und Beseitigung zu lehren, nicht jemandem ein Rezept fuers Verborgenbleiben zu geben. Wenn Sie Persistenz zuverlaessig finden, verwandeln Sie eine verbleibende Kompromittierung in einen eingedaemmten Vorfall.

Was Persistenz ist und warum sie zaehlt#

Persistenz ist jeder Mechanismus, der einem Angreifer erlaubt, den Zugriff auf ein System ueber Unterbrechungen wie Neustarts, Abmeldungen oder Passwort-Resets hinweg aufrechtzuerhalten. Im MITRE-ATT&CK-Rahmenwerk ist es die Taktik TA0003, und sie steht im Kern dessen, warum Einbrueche langlebig werden. Die unbequeme Wahrheit fuer Verteidiger ist, dass Beseitigung scheitert, sobald Persistenz uebersehen wird: Sie koennen die Schadsoftware entfernen, ein Passwort rotieren und einen Dienst neu aufbauen, aber wenn der Angreifer einen geplanten Task, ein betruegerisches Konto oder einen geaenderten Starteintrag hinterliess, kommt er einfach zurueck. Deshalb umfasst Incident Response stets eine bewusste Persistenzjagd, bevor ein System als sauber erklaert wird. Die erste Nutzlast zu finden ist nicht die Ziellinie; jeden Stuetzpunkt zu finden schon.

Die Persistenz-Denkweise fuer Verteidiger#

Wirksame Jagd beginnt mit einer einfachen Praemisse: Ein Angreifer, der einen Neustart ueberleben will, muss etwas hinterlassen, das das Betriebssystem automatisch ausfuehrt. Diese Einschraenkung ist Ihr Vorteil, denn die Menge der Orte, an denen das Betriebssystem nach Auszufuehrendem sucht, ist endlich und gut dokumentiert. Statt unendliche Moeglichkeiten zu jagen, zaehlen Sie die bekannten Autostart-Orte auf und fragen fuer jeden, ob das dort Lebende erwartet ist. Die Disziplin ist Baselining: zu wissen, wie normal aussieht, damit Anomalien hervorstechen. Ein geplanter Task, um drei Uhr morgens von einem Benutzer erstellt, der nie skriptet, ein Dienst, der auf eine Binaerdatei in einem Temp-Ordner zeigt, oder ein neues lokales Admin-Konto sind nicht subtil, sobald Sie eine Baseline zum Vergleich haben.

Wo sich Persistenz unter Windows versteckt#

Unter Windows sollten Verteidiger routinemaessig eine bekannte Menge von Autostart-Erweiterungspunkten pruefen. Dazu gehoeren die Registry-Schluessel Run und RunOnce, geplante Tasks, Windows-Dienste, Autostart-Ordner, WMI-Ereignisabonnements und der Missbrauch legitimer Mechanismen wie DLL-Suchreihenfolge oder Barrierefreiheitsfunktionen. Kontobasierte Persistenz zaehlt genauso: neu erstellte lokale oder Domaenenkonten, zu privilegierten Gruppen hinzugefuegte Benutzer und geaenderte Anmeldeskripte. Werkzeuge wie Sysinternals Autoruns sind genau dafuer gebaut, diese Orte aufzuzaehlen, und gepaart mit Sysmon-Telemetrie erhalten Sie Sichtbarkeit ueber Prozesserstellung, Registry-Aenderung und Image-Load. Ziel beim Pruefen jedes Ortes ist nicht, jede Technik auswendig zu lernen, sondern den Eintrag zu erspaehen, der nicht dorthin gehoert, und dann zu pivotieren, wer ihn erstellte und wann.

Wo sich Persistenz unter Linux versteckt#

Auf Linux- und Unix-Systemen ist die Autostart-Flaeche anders, aber ebenso aufzaehlbar. Cron-Jobs und systemd-Timer und -Units sind haeufige Stuetzpunkte, ebenso geaenderte Shell-Startdateien wie profile- und rc-Skripte, hinzugefuegte SSH-Authorized-Keys und neue oder veraenderte Dienstdefinitionen. Angreifer missbrauchen auch geplante Tasks, die als Root laufen, und beim Boot geladene Konfigurationsdateien. Defensiv pruefen Sie diese Orte gegen eine bekannte Baseline, achten auf Dateien mit jungen Aenderungszeiten, die kein Change-Ticket erklaert, und ueberwachen das Hinzufuegen von SSH-Keys zu Konten. Auditd und Endpunkt-Telemetrie helfen, indem sie Prozessausfuehrung und Dateiaenderungen aufzeichnen, sodass ein Cron-Eintrag, der ausserhalb Ihrer Deployment-Pipeline erscheint, zum Signal wird statt zur Ueberraschung, die Sie Wochen spaeter finden.

Cloud- und Identitaets-Persistenz#

Moderne Persistenz ist zunehmend identitaetsbasiert und lebt oberhalb eines einzelnen Hosts. In Cloud- und SaaS-Umgebungen suchen Angreifer dauerhaften Zugriff ueber neue Anmeldedaten statt Dateien: einen frischen Access Key auf einem Service Principal, eine hinzugefuegte Foederations- oder Vertrauensbeziehung, eine OAuth-Anwendung mit breiten delegierten Berechtigungen oder eine versteckte Mail-Weiterleitungsregel. Da diese Mechanismen legitime administrative Funktionen sind, fuegen sie sich ein, sofern Sie nicht das Audit-Log beobachten. Jagen Sie neu erstellte Keys und App-Registrierungen, Aenderungen an Rollenvertrauen und Foederation sowie Zustimmungserteilungen an unbekannte Anwendungen. Das defensive Prinzip spiegelt die Host-Welt: Zaehlen Sie die kleine Menge an Orten auf, an denen dauerhafter Zugriff gepflanzt werden kann, baselinen Sie das Erwartete und behandeln Sie jede unerklaerte Ergaenzung der Identitaet als moeglichen Stuetzpunkt.

Erkennungssignale und Telemetrie#

Persistenzjagd ist nur so gut wie die Telemetrie darunter. Unter Windows sind sicherheitsrelevante Event-IDs unbezahlbar: 4698 erfasst die Erstellung geplanter Tasks, 7045 markiert neue Dienstinstallation, 4720 zeigt Kontoerstellung und 4732 erfasst ein zu einer sicherheitsaktivierten Gruppe hinzugefuegtes Mitglied. Sysmon fuegt granulare Prozesserstellungs-, Registry- und Image-Load-Ereignisse hinzu, die Techniken erwischen, welche die Standard-Audit-Policy verpasst. Unter Linux bieten auditd und Shell-History aequivalente Sichtbarkeit, und EDR-Plattformen vereinen beide Welten mit verhaltensbasierter Erkennung. Das maechtigste Signal ist jedoch der Vergleich gegen eine Baseline: Alarmieren Sie beim erstmaligen Auftreten eines Autostart-Eintrags, eines Dienstes mit ungewoehnlichem Pfad oder einer Kontoerstellung ausserhalb Ihres Provisionierungsprozesses. Anomalie schlaegt Signatur, wenn Angreifer bordeigene Mittel nutzen.

Ein praktischer Jagd-Workflow#

Verwandeln Sie die Konzepte in eine wiederholbare Routine. Beginnen Sie mit dem Aufzaehlen der Autostart-Orte ueber Ihre Flotte mit Werkzeugen, die Registry-Run-Keys, geplante Tasks, Dienste und Startelemente melden, oder deren Linux- und Cloud-Aequivalente. Als Naechstes baselinen: Vergleichen Sie den aktuellen Zustand mit einem bekannt-guten Snapshot oder mit der Mehrheit aehnlicher Hosts, denn Ausreisser sind, wo Sie zuerst schauen. Dann anreichern Sie jeden Kandidaten mit der Frage, wer ihn erstellte, wann, von welchem Konto und ob ein entsprechender Change-Datensatz existiert. Korrelieren Sie mit Prozess- und Authentifizierungslogs, um eine Zeitleiste zu bauen, und schliesslich validieren Sie, ob der Eintrag gutartig oder boesartig ist, bevor Sie handeln. Dokumentieren Sie Gefundenes, damit die naechste Jagd von einer besseren Baseline startet, und fuehren Sie bestaetigte Muster in automatisierte Erkennungen zurueck.

Minderung und Haertung#

Erkennung und Praevention verstaerken einander. Verkleinern Sie die Persistenzflaeche, indem Sie geringste Rechte durchsetzen, sodass wenige Konten ueberhaupt Dienste, geplante Tasks oder neue Benutzer erstellen koennen. Verlangen Sie Multi-Faktor-Authentifizierung und ueberwachen Sie privilegierte Gruppenmitgliedschaft, damit kontobasierte Stuetzpunkte schwer zu pflanzen und schnell zu bemerken sind. Zentralisieren und schuetzen Sie Logs an einem Ort, den der Angreifer nicht bearbeiten kann, und aktivieren Sie die Audit-Policies und die Sysmon- oder auditd-Konfiguration, die Persistenz sichtbar machen. Application Allowlisting begrenzt, was ueberhaupt aus dem Autostart ausgefuehrt werden kann. In der Cloud beschraenken Sie, wer Anmeldedaten praegen und Zustimmung erteilen darf, und alarmieren bei Vertrauens- und Foederationsaenderungen. Jede Kontrolle, die verengt, wo dauerhafter Zugriff gepflanzt werden kann, verkleinert auch den Raum, den Sie durchsuchen muessen.

Haeufige Fallstricke#

Mehrere Fehler lassen Persistenz ueberleben. Responder beseitigen die offensichtliche Nutzlast und erklaeren den Sieg, ohne Autostart-Orte aufzuzaehlen, sodass ein geplanter Task den Einbruch still wiederherstellt. Teams jagen auf dem Host, vergessen aber Identitaets-Persistenz in der Cloud und lassen einen Access Key zurueck, der den Neuaufbau ueberlebt. Baselines fehlen, sodass ein boesartiger Dienst auf den ersten Blick nicht von einem legitimen zu unterscheiden ist. Telemetrie ist nicht konfiguriert, sodass genau die Event-IDs, die einen neuen Task oder ein neues Konto enthuellen wuerden, nie aufgezeichnet wurden. Und Ermittler finden einen Stuetzpunkt und hoeren auf, ohne zu erkennen, dass Angreifer haeufig mehrere zur Redundanz pflanzen. Die Heilung ist eine systematische Jagd, die Hosts und Identitaeten abdeckt, gestuetzt auf Baselines und vollstaendige Telemetrie, und die Regel, nie nach nur einem Fund sauber zu erklaeren.

Blue-Team-Persistenz-Checkliste#

Nutzen Sie dies als Jagdsequenz. 1. Bestaetigen Sie, dass Audit-Policy, Sysmon oder auditd und Log-Zentralisierung vorhanden sind, bevor Sie sie brauchen. 2. Zaehlen Sie Windows-Autostart-Punkte auf: Run-Keys, geplante Tasks, Dienste, Autostart-Ordner, WMI-Abonnements. 3. Zaehlen Sie Linux-Aequivalente auf: cron, systemd, Shell-rc-Dateien, SSH-Keys. 4. Zaehlen Sie Identitaets-Persistenz auf: neue Keys, App-Registrierungen, Vertrauens- und Zustimmungsaenderungen. 5. Baselinen Sie jedes gegen bekannt-gute oder Peer-Hosts und markieren Sie Ausreisser. 6. Reichern Sie mit Ersteller, Zeitstempel und Change-Datensatz-Korrelation an. 7. Bauen Sie eine Zeitleiste aus Event-IDs 4698, 7045, 4720, 4732 und Prozesslogs. 8. Nehmen Sie Redundanz an: Jagen Sie nach dem ersten Fund weiter. 9. Beheben, dann erneut verifizieren. 10. Fuehren Sie bestaetigte Muster in automatisierte Erkennungen zurueck.

FAQ: Reicht das Finden eines Persistenzmechanismus, um einen Host sauber zu nennen?#

Nein, und das anzunehmen ist einer der teuersten Fehler in der Incident Response. Angreifer pflanzen routinemaessig mehrere Persistenzmechanismen, gerade damit das Entfernen eines sie nicht aussperrt. Wenn Sie einen boesartigen geplanten Task finden, behandeln Sie ihn als Signal, haerter zu jagen, nicht als Ende der Untersuchung, und zaehlen Sie jeden anderen Autostart-Ort auf dem Host sowie identitaetsbasierte Persistenz in jeder verbundenen Cloud auf. Bauen Sie eine vollstaendige Zeitleiste dessen, was der Angreifer tat und wann, denn die gefundene Persistenz weist oft auf das Konto und Zeitfenster hin, in dem andere Stuetzpunkte erstellt wurden. Erklaeren Sie ein System erst nach vollstaendiger Aufzaehlung sauber, nicht nach dem ersten Treffer.

FAQ: Welche Telemetrie sollte ich bei begrenzten Ressourcen priorisieren?#

Wenn Sie klein starten muessen, priorisieren Sie die Signale, die die haeufigsten Stuetzpunkte enthuellen. Unter Windows aktivieren Sie Auditing fuer die Erstellung geplanter Tasks, Dienstinstallation sowie Konto- und Gruppenaenderungen, die den Event-IDs 4698, 7045, 4720 und 4732 entsprechen, und rollen Sie Sysmon fuer Prozess- und Registry-Sichtbarkeit aus. Unter Linux aktivieren Sie auditd fuer Prozessausfuehrung und ueberwachen cron, systemd und SSH-Authorized-Keys. In der Cloud erfassen Sie das Identitaets-Audit-Log und alarmieren bei neuen Anmeldedaten und Vertrauensaenderungen. Zentralisieren Sie all dies irgendwo, das der Angreifer nicht aendern kann. Damit decken Sie einen grossen Teil realer Persistenz ab und koennen die Abdeckung ausbauen, sobald Ressourcen es erlauben.

Fazit#

Persistenz macht aus einem kurzen Einbruch einen langen, und ihre Jagd macht aus einem langen wieder einen eingedaemmten Vorfall. Der Vorteil des Verteidigers ist strukturell: Betriebssystem und Cloud-Plattformen suchen an einer endlichen, dokumentierten Menge von Orten nach Autostart-Elementen und dauerhaften Anmeldedaten, sodass eine disziplinierte Jagd sie alle abdecken kann. Aktivieren Sie zuerst die Telemetrie, baselinen Sie, wie normal aussieht, zaehlen Sie Host- und Identitaets-Stuetzpunkte auf, korrelieren Sie Erstellungsereignisse zu einer Zeitleiste und erklaeren Sie nie nach einem einzigen Fund sauber. Paaren Sie Erkennung mit geringsten Rechten und Allowlisting, damit es von vornherein weniger Orte zum Pflanzen eines Stuetzpunkts gibt. Konsequent ausgefuehrt ist Persistenzjagd der Schritt, der Beseitigung real macht.