Kurzfassung: Programme, die in einem Registry-Run-Schlüssel oder im Autostart-Ordner stehen, starten bei jeder Anmeldung - genau das macht sie zum beliebtesten Weg der Persistenz. Angreifer tragen dort eine PowerShell, ein LOLBin oder eine abgelegte Nutzlast ein, die den Zugang nach jedem Neustart wiederherstellt. Die Erkennung setzt an drei Stellen an: dem Schreiben eines Run-Keys, dem verdächtigen Wert darin und der ausführbaren Datei im Autostart-Ordner. Drei sigma-cli-validierte Sigma-Regeln, Härtung und der Test im Lab. Serie "Angriff erkennen".
Mit diesem Beitrag beginnt die Persistenz-Reihe. Nachdem der Angreifer Code ausgeführt hat, will er bleiben - auch über Neustart und Abmeldung hinweg. Der einfachste und mit Abstand häufigste Weg dafür sind die Autostart-Mechanismen von Windows: die Run-Schlüssel in der Registry und der Autostart-Ordner im Startmenü. Beide sind dafür gedacht, dass Programme automatisch starten, und beide sind für einen Benutzer ohne Administratorrechte beschreibbar. Das macht sie bequem für die Verwaltung und ebenso bequem für einen Angreifer. Der Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.
Einordnung in ATT&CK: Die Technik ist Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001), ein Unterpunkt von T1547. MITRE führt sie in der Taktik Persistence (TA0003) und zugleich in Privilege Escalation (TA0004), weil ein Eintrag im systemweiten Schlüssel (HKLM) im Kontext des angemeldeten Benutzers oder des Systems startet. Verwandt ist die Verknüpfung im Autostart, die der Beitrag zur LNK-Ausführung behandelt.
Was der Angreifer tut
Der Missbrauch der Autostart-Mechanismen läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Varianten ab:
- Run-Schlüssel setzen. Ein Eintrag unter Run oder RunOnce - in HKCU für den Benutzer, in HKLM für alle - startet das hinterlegte Programm bei der nächsten Anmeldung.
- Den Befehl verstecken. Als Wert dient oft kein fester Programmpfad, sondern eine PowerShell mit codiertem Befehl, ein LOLBin oder eine Datei aus einem Nutzer- oder Temp-Verzeichnis.
- In den Autostart-Ordner ablegen. Alternativ landet eine ausführbare Datei oder ein Skript direkt im Startup-Ordner - alles dort wird bei der Anmeldung gestartet.
- Unauffällig benennen. Der Eintrag bekommt einen harmlos wirkenden Namen, der an echte Software erinnert, um bei einem flüchtigen Blick nicht aufzufallen.
Für die Erkennung ist entscheidend: Das Schreiben dieser Schlüssel und das Anlegen im Autostart-Ordner sind sauber protokolliert, und ein Run-Wert, der auf eine Shell zeigt, ist ein lautes, spezifisches Signal.
Welche Logquellen die Technik zeigt
- Registry-Änderung. Sysmon Event 13 schreibt beim Setzen eines Registry-Werts den Schlüssel, den Wert und den auslösenden Prozess - die wichtigste Quelle für die Run-Schlüssel.
- Dateianlage. Sysmon Event 11 meldet jede neu angelegte Datei; eine EXE oder ein Skript im Autostart-Ordner wird damit sichtbar.
- Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen den Prozess, der den Eintrag setzt (etwa reg.exe oder powershell), und später den Start der Nutzlast bei der Anmeldung.
- Die nachgelagerte Aktion. Startet der Eintrag eine PowerShell oder ein LOLBin, greifen die LOLBins-Erkennung und die Endpunkt-Telemetrie, siehe Sysmon einrichten.
Das Muster im Log
Das klarste Signal ist der Inhalt des Run-Werts. Ein Eintrag, der auf einen festen Installationspfad unter Programme zeigt, ist Alltag; ein Eintrag, der eine PowerShell mit codiertem Befehl, ein LOLBin oder eine Datei aus AppData, Temp oder dem öffentlichen Benutzerordner startet, hat selten einen legitimen Grund. Dazu kommt der auslösende Prozess: Setzt reg.exe, powershell oder ein Office-Programm einen Run-Schlüssel, ist das aufmerksamkeitswürdig. Das dritte Signal ist die ausführbare Datei im Autostart-Ordner, die ohne einen bekannten Installer dort auftaucht. Ein regulärer Autostart-Eintrag stammt von einem Installer und zeigt auf einen signierten Programmpfad. Wie immer trennt der Blick auf Wert, auslösenden Prozess und Pfad den Alltag vom Angriff.
Drei Sigma-Regeln
Die Regeln sind mit sigma-cli geprüft. Die erste nimmt das Schreiben eines Run-Keys breit, die zweite grenzt auf verdächtige Werte ein, die dritte nimmt den Autostart-Ordner. Die zweite ist die spezifischste.
1. Autostart über Registry-Run-Key (T1547.001). Das Schreiben in einen der Run-Schlüssel - das breite Signal. Die Regel steht auf level: medium, weil auch Installer diese Schlüssel nutzen.
title: Autostart ueber Registry-Run-Key gesetzt
id: 1f6a3c84-2b57-4e09-9d12-7a4c6e2b85f1
status: experimental
description: |
Erkennt das Schreiben in die klassischen Autostart-Schluessel der Registry (Run, RunOnce,
RunServices und die Explorer-Run-Richtlinie). Programme in diesen Schluesseln starten bei jeder
Anmeldung - ein einfacher und sehr haeufiger Weg zur Persistenz. Die Regel ist breit angelegt;
die naechste Regel grenzt auf verdaechtige Werte ein.
references:
- https://attack.mitre.org/techniques/T1547/001/
author: blue-team.net
tags:
- attack.persistence
- attack.privilege-escalation
- attack.t1547.001
logsource:
product: windows
category: registry_set
detection:
selection:
TargetObject|contains:
- '\CurrentVersion\Run\'
- '\CurrentVersion\RunOnce\'
- '\CurrentVersion\RunServices\'
- '\CurrentVersion\RunServicesOnce\'
- '\CurrentVersion\Policies\Explorer\Run\'
condition: selection
falsepositives:
- Softwareinstaller und legitime Anwendungen tragen sich in Run-Schluessel ein; bekannte Faelle als Baseline ausnehmen
level: medium
2. Verdächtiger Wert in einem Autostart-Key (T1547.001). Ein Run-Wert, der auf Skript-Host, LOLBin, codierten Befehl, URL oder Nutzerpfad zeigt - das spezifische Signal. Auf level: high.
title: Verdaechtiger Wert in einem Registry-Autostart-Key
id: 8d2b5f17-6a39-4c24-8e71-3b5a7c1d94e6
status: experimental
description: |
Erkennt einen Autostart-Eintrag in der Registry, dessen Wert auf einen Skript-Host, ein LOLBin,
einen codierten Befehl, eine URL oder ein Nutzer- und Temp-Verzeichnis zeigt. Legitime Programme
tragen in Run-Schluesseln ihren festen Installationspfad ein, nicht powershell mit codiertem
Befehl. Das ist das spezifische Signal fuer Persistenz ueber die Registry.
references:
- https://attack.mitre.org/techniques/T1547/001/
author: blue-team.net
tags:
- attack.persistence
- attack.privilege-escalation
- attack.t1547.001
logsource:
product: windows
category: registry_set
detection:
sel_key:
TargetObject|contains:
- '\CurrentVersion\Run'
- '\CurrentVersion\Policies\Explorer\Run'
sel_val:
Details|contains:
- 'powershell'
- 'pwsh'
- 'cmd.exe'
- 'mshta'
- 'rundll32'
- 'regsvr32'
- 'wscript'
- 'cscript'
- '-enc'
- 'FromBase64String'
- 'DownloadString'
- 'http://'
- 'https://'
- '\AppData\'
- '\Temp\'
- '\ProgramData\'
- '\Users\Public\'
condition: sel_key and sel_val
falsepositives:
- Einzelne legitime Anwendungen starten aus Nutzerpfaden; bekannte Faelle nach Pfad und Konto ausnehmen
level: high
3. Datei im Autostart-Ordner (T1547.001). Eine neu angelegte EXE oder Skriptdatei im Startup-Ordner - Verknüpfungen bleiben dem Beitrag zur LNK-Ausführung vorbehalten. Ebenfalls level: high.
title: Ausfuehrbare oder Skriptdatei im Autostart-Ordner angelegt
id: 3a7c9e62-5b14-4d38-b602-6f1a8c3e47d5
status: experimental
description: |
Erkennt das Anlegen einer ausfuehrbaren oder Skriptdatei im Autostart-Ordner. Alles in diesem
Ordner wird bei jeder Anmeldung gestartet - der zweite Weg der Technik neben den Run-Schluesseln.
Verknuepfungen (.lnk) sind bewusst ausgenommen, die behandelt der Beitrag zur LNK-Ausfuehrung.
Legitime Software legt dort selten direkt eine EXE oder ein Skript ab.
references:
- https://attack.mitre.org/techniques/T1547/001/
author: blue-team.net
tags:
- attack.persistence
- attack.privilege-escalation
- attack.t1547.001
logsource:
product: windows
category: file_event
detection:
sel_path:
TargetFilename|contains: '\Startup\'
sel_ext:
TargetFilename|endswith:
- '.exe'
- '.dll'
- '.bat'
- '.cmd'
- '.ps1'
- '.vbs'
- '.js'
- '.hta'
- '.scr'
condition: sel_path and sel_ext
falsepositives:
- Einzelne Softwareinstaller legen Startobjekte direkt im Autostart-Ordner ab; bekannte Faelle ausnehmen
level: high
Härtung: der Angriff, der ins Leere läuft
- Autostart überwachen und inventarisieren. Die Run-Schlüssel und Autostart-Ordner regelmäßig gegen eine bekannte Baseline prüfen; Werkzeuge wie Autoruns machen die Einträge sichtbar.
- Schreibzugriff einschränken. Die systemweiten Schlüssel (HKLM) und den gemeinsamen Autostart-Ordner nur der Administration überlassen und Änderungen protokollieren.
- Skript-Hosts aus dem Autostart bremsen. Mit Anwendungssteuerung (WDAC, AppLocker) und ASR-Regeln verhindern, dass PowerShell und LOLBins aus Nutzerpfaden starten.
- Verhaltensregel scharf schalten. Ein Run-Wert, der eine Shell mit codiertem Befehl startet, sollte immer alarmieren - das ist die zuverlässigste Einzelregel.
Der Test
Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon:
- Für Regel 1 und 2 mit reg add einen harmlosen Testeintrag unter dem HKCU-Run-Schlüssel setzen, dessen Wert auf powershell zeigt. Sysmon Event 13 muss den Schlüssel und den Wert zeigen; danach wieder entfernen.
- Für Regel 3 eine harmlose EXE oder ein Skript in den eigenen Startup-Ordner kopieren. Sysmon Event 11 muss die Anlage mit dem Pfad zeigen.
- Breiter wird der Test mit den Fällen zu T1547.001 aus Atomic Red Team.
Fehlalarme und Tuning
- Softwareinstaller. Installer tragen legitim Run-Schlüssel ein und legen Startobjekte an. Für Regel 1 die bekannten Installer und festen Programmpfade als Baseline ausnehmen.
- Verwaltungssoftware. Agenten und Verwaltungswerkzeuge nutzen Autostart legitim. Für Regel 2 die bekannten Pfade und Konten dokumentieren und filtern.
- Benutzerprofile. Einzelne Anwendungen starten aus AppData. Grenze Regel 2 mit einer Allowlist der bekannten Programme ein, statt die Regel zu entschärfen.
- Korrelation schlägt Einzelregel. Wer das Schreiben des Schlüssels, den auslösenden Prozess und die spätere Ausführung bei der Anmeldung als Kette betrachtet, trennt Verwaltung und echten Angriff zuverlässiger als jede Einzelregel.
Fazit
Die Autostart-Mechanismen von Windows sind der einfachste Weg, einen Zugang über Neustart und Abmeldung zu retten - und damit der häufigste Einstieg in die Persistenz. Die verlässlichen Signale sind das Schreiben eines Run-Schlüssels, ein verdächtiger Wert darin und die ausführbare Datei im Autostart-Ordner. Die wirksamste Härtung inventarisiert den Autostart gegen eine Baseline, beschränkt den Schreibzugriff auf die systemweiten Schlüssel und bremst Skript-Hosts aus Nutzerpfaden. Als Nächstes in der Persistenz-Reihe folgt die dauerhafte Persistenz über WMI Event Subscriptions. Verwandt ist die LNK-Ausführung, die den Autostart über Verknüpfungen nutzt. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Persistence.