Neues Konto als Hintertür erkennen: Persistenz über Benutzerkonten

Nach den Registry-Run-Keys und der WMI-Event-Subscription folgt die direkteste Form der Persistenz: das eigene Konto. Wer ein gültiges Benutzerkonto besitzt, braucht keine Schadsoftware, um zurückzukehren - er meldet sich einfach an. Deshalb legen Angreifer nach der Übernahme gern ein zusätzliches Konto an, tarnen es mit einem Namen, der an einen Dienst oder einen Mitarbeiter erinnert, und statten es mit genug Rechten aus, um weiterzuarbeiten. Das Konto fällt im Alltag kaum auf, weil Anmeldungen damit völlig normal aussehen. Der Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Das Anlegen einer Konto-Hintertür läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Schritten ab:

• Das Konto anlegen. Ein lokales Konto auf dem Host oder ein Domänenkonto im Verzeichnis - per net user, PowerShell oder den Verzeichniswerkzeugen.
• Unauffällig benennen. Der Name erinnert an einen Dienst oder ein Systemkonto, etwa svc- oder backup-, um in der Kontoliste nicht aufzufallen.
• Rechte geben. Das Konto wandert in die lokale Administratorengruppe oder, im schlimmeren Fall, in die Domain Admins - erst damit wird es zur vollwertigen Hintertür.
• Zugang sichern. Oft wird der Fernzugang erlaubt (Remote Desktop oder WinRM), damit das Konto auch aus der Ferne nutzbar ist.

Für die Erkennung ist entscheidend: Kontoanlage und Gruppenaufnahme sind nativ und zuverlässig protokolliert, und beide zusammen in kurzer Folge sind ein lautes Signal.

Welche Logquellen die Technik zeigt

• Kontoanlage. Event 4720 meldet jedes neu angelegte Benutzerkonto samt Namen und anlegendem Konto - auf dem Domain Controller für Domänenkonten, lokal für lokale Konten.
• Gruppenaufnahme. Die Events 4728, 4732 und 4756 protokollieren die Aufnahme in eine globale, lokale oder universelle sicherheitsaktivierte Gruppe - der entscheidende Schritt bei den Administratorgruppen.
• Prozess-Telemetrie. Event 4688 zeigt die Kommandozeile von net user, net localgroup oder den PowerShell-Cmdlets, mit denen das Konto angelegt wird.
• Die spätere Nutzung. Anmeldungen mit dem neuen Konto und ein erlaubter Fernzugang runden das Bild ab, siehe die Endpunkt-Telemetrie unter Sysmon einrichten.

Das Muster im Log

Das stärkste Signal ist die Kette: Ein Event 4720 (Konto angelegt), kurz darauf gefolgt von einem 4732 oder 4728 (in eine Administratorgruppe aufgenommen) - und das außerhalb der bekannten Verwaltungsfenster oder durch ein ungewöhnliches Konto. Einzeln sind beide Ereignisse Alltag, in Folge und zur falschen Zeit sind sie ein Alarm. Dazu kommen die verräterischen Namen: ein Konto, das wie ein Dienstkonto aussieht, aber interaktiv genutzt wird, oder ein Name mit Tippfehler-Tarnung nahe an einem echten Konto. Das dritte Signal ist die Kommandozeile mit net user /add oder net localgroup administrators /add. Eine reguläre Kontoanlage kommt von der IT, aus einem bekannten Provisionierungswerkzeug und zu erwartbaren Zeiten. Wie immer trennt der Blick auf anlegendes Konto, Name und Zeitpunkt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft. Die erste nimmt die Kontoanlage, die zweite die Aufnahme in eine Admin-Gruppe, die dritte die Anlage über die Kommandozeile. Ein Hinweis zur Abdeckung: Die ersten beiden Regeln nutzen das Security-Eventlog und übersetzen sauber nach Splunk und Elastic; für die KQL-Backends liegen diese Ereignisse in der Tabelle SecurityEvent statt im Advanced-Hunting-Schema, auf das die automatische Übersetzung zielt, deshalb greift dort direkt nur die dritte, prozessbasierte Regel. Das ist eine Grenze des Schemas, kein Regelfehler - in Sentinel lassen sich 4720 und die Gruppen-Events über SecurityEvent natürlich ebenso abfragen.

1. Neues Benutzerkonto (T1136.001/.002). Event 4720, die Anlage eines Kontos - das breite Signal. Die Regel steht auf level: medium.

title: Neues Benutzerkonto angelegt
id: 6a2c8e41-3b57-4d19-9f02-7a4c6e2b85d2
status: experimental
description: |
  Erkennt das Anlegen eines Benutzerkontos ueber Event 4720 im Security-Log. Ein frisch angelegtes
  Konto ist ein einfacher und dauerhafter Rueckweg ins System - besonders, wenn es kurz darauf in
  eine privilegierte Gruppe aufgenommen wird. Die Regel ist breit; sie lebt von der Korrelation mit
  der Gruppenaufnahme und dem Zeitpunkt (ausserhalb der Verwaltungsfenster).
references:
  - https://attack.mitre.org/techniques/T1136/001/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1136.001
  - attack.t1136.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4720
  condition: selection
falsepositives:
  - Regulaere Kontoanlage durch Administration und Identity-Management; nach Konto, Quelle und Zeitfenster als Baseline ausnehmen
level: medium

2. Aufnahme in eine Administratorgruppe (T1136.001/.002). Die Events 4728/4732/4756 mit einem Gruppennamen, der Admin enthält - das spezifische Signal. Auf level: high.

title: Konto zu einer Administratorgruppe hinzugefuegt
id: 9c3d7f22-5a48-4c26-8e71-2b6a4c1d95e4
status: experimental
description: |
  Erkennt die Aufnahme eines Kontos in eine Administrator- oder privilegierte Gruppe ueber die
  Events 4728, 4732 und 4756 (Mitglied zu einer sicherheitsaktivierten globalen, lokalen oder
  universellen Gruppe hinzugefuegt), gefiltert auf Gruppennamen mit Admin. Ein frisch angelegtes
  Konto, das kurz darauf in die Administratoren oder Domain Admins wandert, ist das klare Zeichen
  einer Hintertuer.
references:
  - https://attack.mitre.org/techniques/T1136/001/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1136.001
  - attack.t1136.002
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4728
      - 4732
      - 4756
    TargetUserName|contains: 'Admin'
  condition: selection
falsepositives:
  - Regulaere Rechtevergabe durch die Administration; bekannte Faelle nach Konto und Zeitfenster ausnehmen
level: high

3. Anlage über die Kommandozeile (T1136.001/.002). net user /add, New-LocalUser, New-ADUser oder net localgroup administrators /add - greift auf allen Backends. Ebenfalls level: high.

title: Kontoanlage oder Admin-Gruppenaufnahme ueber die Kommandozeile
id: 2f7c9a15-6b36-4d26-b803-5f1a8c3e47d7
status: experimental
description: |
  Erkennt das Anlegen eines Kontos oder die Aufnahme in eine Administratorgruppe ueber die
  Kommandozeile - mit net user /add, New-LocalUser, New-ADUser, dsadd oder net localgroup
  administrators /add. Das greift auch ohne die nativen Security-Events und zeigt den anlegenden
  Prozess und das Konto direkt.
references:
  - https://attack.mitre.org/techniques/T1136/001/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1136.001
  - attack.t1136.002
logsource:
  product: windows
  category: process_creation
detection:
  sel_create:
    CommandLine|contains:
      - 'New-LocalUser'
      - 'New-ADUser'
      - 'dsadd user'
  sel_netuser:
    CommandLine|contains: 'net user '
  sel_add:
    CommandLine|contains: '/add'
  sel_admingroup:
    CommandLine|contains:
      - 'localgroup administrators'
      - 'localgroup administratoren'
      - 'domain admins'
      - 'enterprise admins'
  condition: sel_create or (sel_netuser and sel_add) or sel_admingroup
falsepositives:
  - Verwaltungsskripte und Provisionierung legen legitim Konten an; bekannte Skripte und Konten ausnehmen
level: high

Härtung: der Angriff, der ins Leere läuft

• Kontoanlage zentralisieren und protokollieren. Konten nur über ein Identity-Management anlegen, die Events 4720 und die Gruppen-Events zentral sammeln und die Kette als Alarm schalten.
• Privilegierte Gruppen überwachen. Administratoren, Domain Admins und die übrigen Tier-0-Gruppen eng einfassen und jede Änderung melden; die Mitgliedschaft regelmäßig gegen eine Baseline prüfen.
• Lokale Konten eindämmen. Mit LAPS und einer klaren Richtlinie verhindern, dass auf den Hosts unbemerkt zusätzliche lokale Admin-Konten entstehen.
• Fernzugang kontrollieren. Die Mitgliedschaft in Remote Desktop Users und die WinRM-Berechtigungen prüfen, damit ein neues Konto nicht sofort aus der Ferne nutzbar ist.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen:

• Für Regel 1 und 3 mit net user ein harmloses Testkonto anlegen. Event 4720 und die Kommandozeile müssen erscheinen; danach wieder entfernen.
• Für Regel 2 das Testkonto mit net localgroup administrators in die lokale Administratorengruppe aufnehmen. Event 4732 muss die Aufnahme zeigen.
• Breiter wird der Test mit den Fällen zu T1136 aus Atomic Red Team.

Fehlalarme und Tuning

• Reguläre Kontoanlage. IT und Identity-Management legen laufend Konten an. Für Regel 1 die bekannten Quellen, Konten und Zeitfenster als Baseline ausnehmen.
• Reguläre Rechtevergabe. Die Aufnahme in Admin-Gruppen passiert auch legitim. Für Regel 2 die bekannten Verwalter und Wartungsfenster dokumentieren und filtern.
• Provisionierungsskripte. Automatisierung legt Konten per PowerShell an. Für Regel 3 die bekannten Skripte und Dienstkonten ausnehmen, statt die Regel zu entschärfen.
• Korrelation schlägt Einzelregel. Wer Kontoanlage, Gruppenaufnahme und erste Anmeldung als Kette betrachtet, trennt Verwaltung und echten Angriff zuverlässiger als jede Einzelregel.

Fazit

Das neue Konto ist die direkteste Hintertür: ein gültiger Zugang, der jeden Neustart übersteht und sich im Alltag versteckt. Die verlässlichen Signale sind die Kontoanlage (Event 4720), die Aufnahme in eine Administratorgruppe (4728/4732/4756) und die Anlage über die Kommandozeile - am stärksten als Kette in kurzer Folge. Die wirksamste Härtung zentralisiert die Kontoanlage, überwacht die privilegierten Gruppen und dämmt lokale Admin-Konten mit LAPS ein. Als Nächstes in der Persistenz-Reihe folgen die IFEO- und Accessibility-Debugger. Verwandt sind die Registry-Run-Keys und die WMI-Event-Subscription. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Persistence.