Valid Accounts erkennen: den Missbrauch legitimer Konten sichtbar machen

Valid Accounts erkennen ist die schwierigste und zugleich wichtigste Disziplin der Erkennung, weil der Angreifer hier nichts mitbringt, was von sich aus bösartig ist. Er nutzt Anmeldeinformationen, die er zuvor über Phishing, einen LSASS-Dump, Kerberoasting oder Password Spraying erbeutet hat, und meldet sich damit an wie ein legitimer Nutzer. Dieser Beitrag aus der Serie "Angriff erkennen" geht es bewusst nicht um Anmelde-Grundlagen, sondern um den Missbrauch: Wie trennt man die legitime von der bösartigen Nutzung desselben Kontos? Der Schlüssel liegt darin, die Kontoarten zu unterscheiden und jede gegen ihr Normalprofil zu prüfen. Dazu kommen vier Sigma-Regeln, die Härtung, eine Checkliste und der Test.

Was der Angreifer tut

Der Missbrauch gültiger Konten sieht je nach Kontoart anders aus und hinterlässt andere Spuren. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Lokale Konten (T1078.003). Ein erbeutetes lokales Administrator-Passwort oder dessen Hash wird über das Netz an weiteren Systemen wiederverwendet. Ist das lokale Admin-Passwort überall gleich, öffnet ein einziger Fund das ganze Netz. Sichtbar wird das an einer Netzwerk-Anmeldung mit einem lokalen Konto, oft per NTLM.
• Domänenkonten (T1078.002). Nach dem Diebstahl von Domänen-Anmeldeinformationen bewegt sich der Angreifer als regulärer Nutzer durch das Netz. Verräterisch ist, dass ein Konto sich plötzlich an Systemen anmeldet, die es sonst nie nutzt, oder an auffällig vielen in kurzer Zeit.
• Cloud- und Entra-Identitäten (T1078.004). Ein per Phishing erbeutetes Cloud-Konto wird direkt bei Entra ID angemeldet, gern über veraltete Protokolle, die keine MFA erzwingen, oder von einem ungewohnten Standort. Die Risiko-Signale von Entra ID sind hier der beste Ausgangspunkt.
• Dienstkonten. Dienstkonten haben oft hohe Rechte und schwache, selten gewechselte Passwörter. Sie sind für nicht-interaktive Nutzung gedacht; eine interaktive oder RDP-Anmeldung eines Dienstkontos ist fast immer Missbrauch.
• Abgrenzung zu Tickets und Tokens. Wird ein gestohlenes Passwort oder Konto genutzt, ist es T1078. Werden stattdessen ein Hash, ein Kerberos-Ticket oder ein OAuth-Token ohne das Passwort weiterverwendet, gehört das zu Pass-the-Hash und Pass-the-Ticket (T1550) - verwandt, aber eine eigene Technik mit eigener Erkennung.

Der gemeinsame Nenner ist, dass die Anmeldung technisch gültig ist. Erkennbar wird sie nur als Abweichung vom Normalprofil des jeweiligen Kontos. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• Windows Security-Log. Event 4624 zeigt jede Anmeldung mit Logon-Typ, Konto und Quelle; der Logon-Typ trennt interaktiv (2), Netzwerk (3) und RDP (10). Event 4648 nennt die Nutzung expliziter Anmeldeinformationen, Event 4672 privilegierte Anmeldungen und Event 4625 die Fehlversuche davor.
• Domain Controller. Event 4768 (TGT) und Event 4769 (Service-Ticket) zeigen Kerberos-Anmeldungen zentral, Event 4776 die NTLM-Validierung und Event 4740 Kontosperren. Damit lässt sich ein Domänenkonto über alle Systeme hinweg verfolgen.
• Entra ID Sign-in-Logs. Sie liefern pro Anmeldung das Ergebnis, das Risiko-Level, das verwendete Clientprotokoll (und damit Legacy-Authentifizierung), den Standort und die Conditional-Access-Entscheidung. Die Grundlagen dazu stehen unter Cloud-Sicherheit für Blue Teams.
• Die Baseline. Keine dieser Quellen ist allein aussagekräftig. Erst das Normalprofil eines Kontos - seine üblichen Logon-Typen, Quell-Hosts, Zeiten und die Zahl der genutzten Systeme - macht die Abweichung sichtbar.

Das Muster im Log

Weil jede einzelne Anmeldung gültig ist, entsteht das Muster erst aus dem Vergleich mit dem Gewohnten. Vier Abweichungen sind besonders aussagekräftig: ein Logon-Typ, der nicht zur Kontoart passt, etwa ein Dienstkonto, das sich interaktiv anmeldet; eine Quelle oder Zeit außerhalb des üblichen Profils, etwa ein Konto, das sich nachts von einem fremden Host meldet; eine ungewöhnliche Breite, also ein Konto, das sich in kurzer Zeit an vielen Systemen anmeldet; und ein Risiko-Signal aus der Cloud, etwa eine Anmeldung über ein Legacy-Protokoll oder aus einem neuen Land. Am belastbarsten wird der Fall, wenn eine dieser Abweichungen mit einem vorangehenden Schritt der Credential-Access-Phase zusammenfällt. Deshalb geht es nicht um einen pauschalen ungewöhnlichen Login, sondern um die konkrete Abweichung pro Kontoart.

Vier Sigma-Regeln

Die Regeln sind mit sigma-cli validiert. Die erste fängt das interaktive Dienstkonto, die zweite die Netzwerk-Anmeldung des lokalen Administrators, die dritte das Konto an vielen Systemen (als Korrelation), die vierte die riskante Cloud-Anmeldung. Die Übersetzung ins SIEM steht unter Sigma-Regeln.

1. Dienstkonto meldet sich interaktiv an (T1078). Dienstkonten gehören nicht an eine interaktive Sitzung. Das Namensschema wird angepasst.

title: Dienstkonto meldet sich interaktiv an
id: 40d22290-6345-47c3-9738-3e1224733e00
status: experimental
description: Erkennt eine interaktive oder per RDP erfolgte Anmeldung eines
  Dienstkontos. Dienstkonten melden sich normalerweise nur als Dienst oder ueber das
  Netzwerk an; eine interaktive Anmeldung deutet auf ein missbrauchtes gueltiges
  Konto hin (Valid Accounts). Das Namensschema der Dienstkonten ist anzupassen.
references:
  - https://attack.mitre.org/techniques/T1078/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1078
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType:
      - 2
      - 10
    TargetUserName|startswith: 'svc'
  condition: selection
falsepositives:
  - Administrative Wartung mit einem Dienstkonto - bekannte Faelle als Baseline ausnehmen
level: high

2. Netzwerk-Anmeldung mit dem Administrator-Konto (T1078.003). Ein lokaler Administrator über das Netz ist das klassische Wiederverwendungs-Muster.

title: Netzwerk-Anmeldung mit dem Administrator-Konto
id: 183c9e50-927f-45e3-a916-051f56851986
status: experimental
description: Erkennt eine Netzwerk-Anmeldung (LogonType 3) mit dem eingebauten
  Administrator-Konto. Der Einsatz eines lokalen Administrators ueber das Netz ist
  ein klassisches Muster fuer die Wiederverwendung gueltiger Anmeldeinformationen und
  seitliche Bewegung (Valid Accounts, lokale Konten).
references:
  - https://attack.mitre.org/techniques/T1078/003/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1078.003
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
    TargetUserName: 'Administrator'
  condition: selection
falsepositives:
  - Legitime administrative Zugriffe mit einem lokalen Administrator - bekannte Quell-Hosts ausnehmen
level: medium

3. Ein Konto an auffällig vielen Systemen (T1078). Eine Korrelation zählt die Zielsysteme je Konto in einem Zeitfenster. Die Schwelle wird an die Umgebung angepasst.

title: Netzwerk-Anmeldung als Basisereignis
id: 0b799985-f252-4aa6-9d41-62af610361ed
name: net_logon_base
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 3
  condition: selection
---
title: Gueltiges Konto an auffaellig vielen Systemen verwendet
id: b512bbc1-c6c3-4b42-93fe-f6b89f101e81
status: experimental
description: Erkennt, wenn sich ein einzelnes Konto in kurzer Zeit ueber das Netzwerk
  an auffaellig vielen Systemen anmeldet. Das ist ein typisches Muster, wenn ein
  Angreifer gueltige Anmeldeinformationen fuer seitliche Bewegung wiederverwendet
  (Valid Accounts). Die Schwelle ist an die Umgebung anzupassen.
references:
  - https://attack.mitre.org/techniques/T1078/
author: blue-team.net
tags:
  - attack.lateral-movement
  - attack.t1078
correlation:
  type: value_count
  rules:
    - net_logon_base
  group-by:
    - TargetUserName
  timespan: 1h
  condition:
    gte: 15
    field: Computer
falsepositives:
  - Verwaltungs- und Monitoring-Konten, die sich regulaer an vielen Systemen anmelden
level: medium

4. Riskante Anmeldung an Entra ID (T1078.004). Die Risiko-Einstufung von Entra ID als Ausgangspunkt für die Untersuchung einer Cloud-Anmeldung.

title: Riskante Anmeldung an Entra ID
id: 25a65b35-abf3-41e4-9fb0-2173386aafbe
status: experimental
description: Erkennt eine erfolgreiche Anmeldung an Entra ID, die als riskant
  eingestuft wird. Angreifer verwenden gueltige Cloud-Anmeldeinformationen, um sich
  als legitimer Nutzer anzumelden, oft nach Phishing oder Passwortdiebstahl
  (Valid Accounts, Cloud-Konten). Risiko-Signale von Entra ID sind hier der
  Ausgangspunkt fuer die Untersuchung.
references:
  - https://attack.mitre.org/techniques/T1078/004/
author: blue-team.net
tags:
  - attack.initial-access
  - attack.t1078.004
logsource:
  product: azure
  service: signinlogs
detection:
  selection_success:
    ResultType: 0
  selection_risk:
    RiskLevelDuringSignIn:
      - 'high'
      - 'medium'
  condition: selection_success and selection_risk
falsepositives:
  - Fehlklassifizierte Risiko-Anmeldungen - im Einzelfall pruefen und bekannte Faelle ausnehmen
level: medium

Härtung

• MFA und Conditional Access. MFA für alle Konten erzwingen und Legacy-Authentifizierung in Entra ID blockieren. Das entwertet gestohlene Cloud-Passwörter und schließt den häufigsten Weg über veraltete Protokolle.
• Lokale Admin-Passwörter eindeutig machen. LAPS vergibt je System ein eigenes lokales Admin-Passwort. Damit öffnet ein einzelner Fund nicht mehr das ganze Netz, und Regel 2 wird zur echten Ausnahme.
• Dienstkonten entschärfen. Group Managed Service Accounts (gMSA) statt statischer Passwörter einsetzen und den interaktiven Login per Richtlinie verbieten (Deny log on locally und through Remote Desktop). Dann ist Regel 1 ein sicheres Signal.
• Privilegien trennen. Ein Tiering-Modell hält privilegierte Konten von Arbeitsplatzsystemen fern, und eigene Admin-Konten ohne Mehrfachnutzung erleichtern die Baseline. Die Mitgliedschaft in privilegierten Gruppen laufend überwachen.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, in einer kleinen Domäne mit zentralem Security-Log und, für die vierte Regel, einem Entra-ID-Testtenant:

• Für Regel 1 ein Testdienstkonto interaktiv oder per RDP anmelden. Event 4624 mit LogonType 2 oder 10 muss die Regel auslösen.
• Für Regel 2 sich mit dem lokalen Administrator per Netzwerk an einem zweiten System anmelden und den Treffer prüfen.
• Für Regel 3 mit einem Testkonto in kurzer Zeit auf viele Systeme zugreifen und die Korrelation ab der gesetzten Schwelle prüfen. Danach die Schwelle an die lauteste legitime Quelle anpassen.
• Für Regel 4 im Testtenant eine Risiko-Anmeldung auslösen (etwa über das Tor-Netzwerk) und den Sign-in-Log-Eintrag mit erhöhtem Risiko prüfen. Vergleiche mit den Fällen zu T1078 aus Atomic Red Team.

Fehlalarme und Tuning

• Verwaltungs- und Monitoring-Konten. Sie melden sich legitim an vielen Systemen an und lassen Regel 3 auslösen. Ihre Konten als Baseline hinterlegen und die Schwelle knapp über ihre lauteste legitime Nutzung setzen.
• Jump-Server und Admin-Arbeitsplätze. Von dort kommen viele administrative Anmeldungen. Bekannte Quell-Hosts ausnehmen, statt die Regel zu entschärfen.
• Dienstkonten mit Sonderrolle. Einzelne Dienstkonten brauchen manchmal doch eine interaktive Wartung. Diese seltenen Fälle einzeln dokumentieren und gezielt ausnehmen.
• Cloud-Risiko im Kontext. Entra-Risiko-Signale sind Hinweise, keine Beweise. Ein hohes Risiko in Verbindung mit Legacy-Auth oder einem neuen Land wiegt schwerer als ein mittleres Risiko eines Reisenden.

Analysten-Checkliste

• Kontoart bestimmen: lokales Konto, Domänenkonto, Cloud-/Entra-Identität oder Dienstkonto?
• Passt der Logon-Typ zur Kontoart (ein Dienstkonto interaktiv, ein lokaler Admin über das Netz)?
• Liegen Quell-Host, IP und Zeit im Normalprofil des Kontos?
• An wie vielen Systemen hat sich das Konto im Zeitfenster angemeldet?
• Cloud: Risiko-Level, Legacy-Protokoll, Standort und Conditional-Access-Ergebnis prüfen.
• Gab es vorher einen Credential-Access-Schritt (LSASS-Dump, Kerberoasting, Phishing) oder Fehlversuche?
• Handelt es sich wirklich um gültige Anmeldeinformationen (T1078) oder um Ticket- und Token-Missbrauch (T1550)? Die richtige Technik bestimmt die weiteren Schritte.

Fazit

Der Missbrauch gültiger Konten lässt sich nicht an einer bösartigen Datei festmachen, sondern nur an der Abweichung vom Normalen - und die ist nur sichtbar, wenn man die Kontoarten trennt und jede gegen ihr Profil prüft. Ein interaktives Dienstkonto, ein lokaler Administrator über das Netz, ein Konto an zu vielen Systemen und eine riskante Cloud-Anmeldung sind vier konkrete, belastbare Signale statt eines diffusen ungewöhnlichen Logins. Wer die Windows-Anmeldeereignisse, die Kerberos-Daten vom Domain Controller und die Entra-Sign-in-Logs zusammenführt, eine Baseline je Konto pflegt und mit MFA, LAPS und gMSA härtet, erkennt den legitimen Zugang in der falschen Hand. Der Schritt davor steht unter Password Spraying und Mimikatz und LSASS-Dump, der verwandte Ticket-Missbrauch unter Pass-the-Hash, der Innentäter-Blick unter Insider-Bedrohungen. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Initial Access.