Anomalien

A-LAPS-Nicht-Installiert

Was es bedeutet

Jeder Windows-Computer hat ein integriertes lokales Administratorkonto. Standardmäßig hat dieses Konto oft auf allen Rechnern dasselbe Passwort oder ein Passwort, das sich nie ändert. Wenn ein Angreifer einen Rechner kompromittiert, kann er dieses Passwort wiederverwenden, um auf alle anderen zuzugreifen.

LAPS (Local Administrator Password Solution) löst dieses Problem, indem automatisch auf jedem Computer ein eindeutiges, zufällig generiertes Passwort festgelegt und sicher in Active Directory gespeichert wird. Nur autorisierte Administratoren können es abrufen.

Was der Scan prüft

Der AD-Scan sucht nach Hinweisen darauf, dass LAPS in Ihrem Active Directory eingerichtet wurde. Konkret prüft er, ob die erforderlichen LAPS-Datenfelder in Ihrer AD-Konfiguration vorhanden sind. Wenn nicht, bedeutet das, dass LAPS nie installiert wurde.

Warum die Warnung bestehen bleiben kann

• LAPS nur über Intune verwaltet: Wenn Sie Microsoft Intune verwenden, um LAPS-Passwörter in der Cloud zu verwalten (ohne das lokale AD zu konfigurieren), kann der AD-Scan dies nicht erkennen. Der Scan prüft nur Ihr lokales Active Directory.

• LAPS wurde nur teilweise installiert: Die LAPS-Einrichtung wurde möglicherweise begonnen, aber nicht abgeschlossen.

So diagnostizieren Sie das Problem

# Prüfen, ob LAPS in Ihrem Active Directory eingerichtet ist
Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext `
  -Filter "name -like 'ms-Mcs-AdmPwd' -or name -eq 'ms-LAPS-Password'" |
  Select-Object Name, whenCreated

Wenn dies keine Ergebnisse liefert, ist LAPS nicht installiert.

So beheben Sie das Problem

Für Windows Server 2019 und neuer (empfohlen): Modernes LAPS ist in Windows integriert. Aktivieren Sie es über die Gruppenrichtlinie:

1. Öffnen gpmc.msc (Gruppenrichtlinienverwaltung)

2. Bearbeiten oder erstellen Sie ein GPO, das mit Ihren Computer-OUs verknüpft ist

3. Navigieren Sie zu: Computerkonfiguration > Administrative Vorlagen > System > LAPS

4. Konfigurieren Sie die LAPS-Einstellungen (aktivieren, Passwortkomplexität festlegen usw.)

Für ältere Umgebungen: Laden Sie Legacy LAPS von Microsoft herunter und führen Sie die Schemaerweiterung aus:

Update-LapsADSchema

Hinweis: Wenn Sie lokale Administratorkennwörter mit einem anderen Tool verwalten (CyberArk, nur Intune-LAPS usw.), wenden Sie sich an den Stoïk-Support, um dies als akzeptierte Ausnahme zu dokumentieren.

A-LAPS-Beigetretene-Computer

Was es bedeutet

Wenn jemand einen Computer zur Active-Directory-Domäne hinzufügt („beitritt“), wird diese Person zum Ersteller des Computerobjekts in AD. Standardmäßig erhält der Ersteller spezielle Berechtigungen für dieses Objekt.

Das Problem ist: Wenn LAPS installiert ist, wird das lokale Administratorkennwort auf demselben Computerobjekt gespeichert. Wenn der Ersteller noch die richtigen Berechtigungen hat, kann er das LAPS-Passwort lesen, selbst wenn er kein Administrator ist. Das bedeutet, dass ein normaler Benutzer, der einmal einen PC mit der Domäne verbunden hat, das lokale Administratorkennwort für diesen Rechner abrufen könnte.

Was der Scan prüft

Für jeden aktivierten Computer mit eingesetztem LAPS prüft der AD-Scan zwei Dinge:

1. Ist die Person, die den Computer hinzugefügt hat, noch der „Besitzer“ des Computerobjekts? Besitzer können sich selbst jede Berechtigung erteilen, einschließlich des Lesens des LAPS-Passworts.

2. Hat der Ersteller noch explizite Berechtigungen für das Computerobjekt, wie zum Beispiel Alle erweiterten Rechte (was das Lesen des LAPS-Passworts erlaubt), WriteDacl (was das Ändern von Berechtigungen erlaubt), WriteOwner (was das Zurückerlangen des Besitzes erlaubt), oder GenericWrite?

Die Warnung wird ausgelöst, wenn entweder eine der Bedingungen erfüllt ist.

Warum die Warnung bestehen bleiben kann

Dies ist die häufigste Ursache für Verwirrung: das Ändern des Besitzers ist nur die halbe Lösung.

Viele Administratoren ändern den Besitzer auf „Domain Admins“ und erwarten, dass die Warnung verschwindet. Der AD-Scan prüft jedoch auch auf verbliebene Berechtigungen (ACEs oder Access Control Entries), die dem ursprünglichen Ersteller gewährt wurden. Diese Berechtigungen bleiben auch nach dem Ändern des Besitzers bestehen und müssen separat entfernt werden.

So diagnostizieren Sie das Problem

# Computer auflisten, bei denen der Ersteller noch riskante Berechtigungen hat
Get-ADComputer -Filter "Enabled -eq `$true" `
  -Properties "mS-DS-CreatorSID", "nTSecurityDescriptor" |
  Where-Object { $_."mS-DS-CreatorSID" -ne $null } |
  ForEach-Object {
    $comp = $_
    $acl = $comp.nTSecurityDescriptor
    $creatorSid = $comp."mS-DS-CreatorSID"
    $owner = $acl.GetOwner([System.Security.Principal.SecurityIdentifier])

    $isOwner = ($owner.Value -eq $creatorSid.Value)

    $riskyAces = $acl.Access | Where-Object {
      -not $_.IsInherited -and
      $_.IdentityReference.Value -eq $creatorSid.Value -and
      ($_.ActiveDirectoryRights -match 'WriteDacl|WriteOwner|GenericWrite|ExtendedRight')
    }

    if ($isOwner -or $riskyAces) {
      [PSCustomObject]@{
        Computer       = $comp.Name
        CreatorIsOwner = $isOwner
        RiskyRights    = ($riskyAces | ForEach-Object { $_.ActiveDirectoryRights }) -join ", "
      }
    }
  } | Format-Table -AutoSize

So beheben Sie das Problem

Sie müssen beides für jeden betroffenen Computer tun:

1. Den Besitzer ändern auf Domain Admins

2. Die expliziten Berechtigungen des Erstellers entfernen

Das folgende Skript erledigt beides automatisch:

#Requires -Modules ActiveDirectory

$affectedComputers = Get-ADComputer -Filter "Enabled -eq `$true" `
  -Properties "mS-DS-CreatorSID", "nTSecurityDescriptor" |
  Where-Object { $_."mS-DS-CreatorSID" -ne $null }

foreach ($comp in $affectedComputers) {
  $path = "AD:$($comp.DistinguishedName)"
  $acl = Get-Acl -Path $path
  $creatorSid = $comp."mS-DS-CreatorSID"
  $modified = $false

  # Schritt 1: Besitzer auf Domain Admins ändern
  $domainAdmins = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN", "Domain Admins")
  $acl.SetOwner($domainAdmins)
  $modified = $true

  # Schritt 2: Explizite Berechtigungen entfernen, die dem Ersteller (und verwaisten SIDs) gewährt wurden
  $toRemove = @($acl.Access | Where-Object {
    -not $_.IsInherited -and
    ($_.IdentityReference.Value -eq $creatorSid.Value -or
     $_.IdentityReference.Value -match '^S-1-5-21-')  # Verwaiste SIDs (gelöschte Konten)
  })

  foreach ($ace in $toRemove) {
    $acl.RemoveAccessRuleSpecific($ace)
    Write-Host "$($comp.Name): [$($ace.ActiveDirectoryRights)] für $($ace.IdentityReference) entfernt"
  }

  if ($modified) {
    Set-Acl -Path $path -AclObject $acl
    Write-Host "$($comp.Name): Behoben" -ForegroundColor Green
  }
}

Tipp: Führen Sie zuerst den Diagnosebefehl aus, um die Liste der betroffenen Computer zu prüfen, bevor Sie die Korrektur anwenden.

A-Keine-Dienstkontorichtlinie

Was es bedeutet

Dienstkonten sind Konten, die von Anwendungen und Diensten (z. B. SQL Server, Sicherungsagenten) zur Authentifizierung in Active Directory verwendet werden. Im Gegensatz zu normalen Benutzerkonten sind Dienstkonten hochwertige Ziele: Sie haben oft erhöhte Berechtigungen und ihre Kennwörter werden selten geändert.

Eine Feingranulare Kennwortrichtlinie (PSO) ist eine spezielle Kennwortrichtlinie, die Sie auf bestimmte Kontogruppen anwenden können. Der AD-Scan erwartet, dass Ihre Dienstkonten durch eine PSO abgedeckt sind, die Kennwörter von mindestens 20 Zeichen, wodurch sie viel schwerer zu knacken sind.

Was der Scan prüft

Der AD-Scan sucht nach mindestens einer Kennwortrichtlinie (GPO oder PSO), die eine Mindestkennwortlänge von 20 Zeichen oder mehr.

Warum die Warnung bestehen bleiben kann

1. Das Scan-Konto hat keine Berechtigung, die PSO zu lesen. Kennwortrichtlinien werden in einem geschützten Bereich von AD gespeichert, den standardmäßig nur Domain Admins lesen können. Wenn der Scan mit einem weniger privilegierten Konto ausgeführt wird, kann er die PSO einfach nicht sehen, obwohl sie vorhanden ist.

2. Die PSO existiert, aber die Mindestlänge liegt unter 20 (z. B. 12 oder 15 Zeichen).

3. Die PSO existiert, ist aber keiner Gruppe oder keinem Benutzer zugewiesen.

So diagnostizieren Sie das Problem

# Alle feingranularen Kennwortrichtlinien und ihre Einstellungen auflisten
Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, MinPasswordLength, @{N="AppliedTo"; E={$_.AppliesTo -join ", "}}, Precedence

Wenn dies nichts zurückgibt, existiert entweder keine PSO oder dem Konto, das den Befehl ausführt, fehlen die Berechtigungen, sie zu sehen. Versuchen Sie es mit einem Domain-Admin-Konto.

So beheben Sie das Problem

Wenn die PSO existiert, der Scan sie aber nicht sehen kann: Führen Sie den AD-Scan mit einem Domain-Admin-Konto aus.

Wenn keine PSO existiert: Erstellen Sie eine und weisen Sie sie Ihren Dienstkonten zu:

# Eine Kennwortrichtlinie für Dienstkonten erstellen
New-ADFineGrainedPasswordPolicy -Name "Service Accounts - Strong Password" `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -MaxPasswordAge "90.00:00:00" `
  -MinPasswordAge "1.00:00:00" `
  -PasswordHistoryCount 24 `
  -ComplexityEnabled $true `
  -ReversibleEncryptionEnabled $false `
  -LockoutDuration "00:30:00" `
  -LockoutObservationWindow "00:30:00" `
  -LockoutThreshold 5

# Einer Sicherheitsgruppe mit Ihren Dienstkonten zuweisen
Add-ADFineGrainedPasswordPolicySubject `
  -Identity "Service Accounts - Strong Password" `
  -Subjects "SG_ServiceAccounts"

Hinweis: Das Erstellen einer PSO erzwingt nicht sofort Kennwortänderungen. Bestehende Kennwörter funktionieren weiter, bis sie ablaufen oder manuell zurückgesetzt werden. Ab dann gilt die neue Mindestlänge von 20 Zeichen.

A-AuditDC

Was es bedeutet

Überwachungsrichtlinien bestimmen, welche Ereignisse auf Ihren Domänencontrollern protokolliert werden. Ohne ordnungsgemäße Überwachung können Angriffe wie der Diebstahl von Anmeldeinformationen, unautorisierte Gruppenänderungen oder Replikationsmissbrauch (DCSync) stattfinden, ohne irgendeine Spur in den Protokollen zu hinterlassen.

Der AD-Scan überprüft, ob Ihre Domänencontroller so konfiguriert sind, dass sie die wichtigsten Sicherheitsereignisse protokollieren.

Was der Scan prüft

Der Scan sucht nach 13 bestimmten Unterkategorien der Überwachung , die über Gruppenrichtlinien auf allen Domänencontrollern aktiviert sein sollten:

Kategorie	Was es protokolliert
Kerberos-Authentifizierungsdienst	Anmeldeversuche über Kerberos
Kerberos-Dienstticket-Operationen	Dienstticket-Anforderungen (erkennt Kerberoasting)
Verwaltung von Computerkonten	Computerbeitritte/-änderungen in AD
Verwaltung von Sicherheitsgruppen	Änderungen der Gruppenmitgliedschaft
Verwaltung von Benutzerkonten	Benutzererstellung, -löschung, Kennwortrücksetzungen
DPAPI-Aktivität	Nutzung der Data Protection API (Zugriff auf Anmeldeinformationen)
Prozesserstellung	Neue gestartete Prozesse (erkennt schädliche Tools)
Anmeldung / Abmeldung	Interaktive und entfernte Anmeldungen
Spezielle Anmeldung	Anmeldungen mit erhöhten Rechten
Änderung der Authentifizierungsrichtlinie	Änderungen an den Authentifizierungseinstellungen
Verwendung sensibler Berechtigungen	Verwendung sensibler Berechtigungen
Erweiterung des Sicherheitssystems	Änderungen am Sicherheits-Subsystem

Warum die Warnung bestehen bleiben kann

1. Einstellungen angewendet über auditpol direkt auf dem DC werden nicht erkannt. Der AD-Scan liest Gruppenrichtliniendateien, nicht die lokale DC-Konfiguration. Sie müssen ein GPO verwenden.

2. Konfliktierende GPOs: Ein GPO aktiviert die Einstellung, aber ein anderes GPO mit höherer Priorität deaktiviert sie.

3. GPO nicht mit der OU „Domain Controllers“ verknüpft: Das GPO existiert, ist aber mit einer anderen OU verknüpft.

So diagnostizieren Sie das Problem

# Die wirksame Überwachungsrichtlinie auf einem Domänencontroller prüfen
auditpol /get /category:*

Wenn die lokalen Einstellungen korrekt aussehen, die Warnung aber bestehen bleibt, prüfen Sie, ob die Einstellungen aus einem GPO stammen (nicht aus einer lokalen Überschreibung):

# Prüfen, welche GPOs mit der OU „Domain Controllers“ verknüpft sind
Get-GPInheritance -Target "OU=Domain Controllers,$($(Get-ADDomain).DistinguishedName)"

So beheben Sie das Problem

1. Öffnen gpmc.msc (Gruppenrichtlinienverwaltungskonsole)

2. Erstellen oder bearbeiten Sie ein GPO, das verknüpft ist mit OU=Domain Controllers

3. Navigieren Sie zu: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Überwachungsrichtlinien

4. Aktivieren Erfolg und Fehler für alle oben aufgeführten Unterkategorien

5. Ausführen gpupdate /force auf allen Domänencontrollern

Prüfen Sie die Korrektur:

auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Logon/Logoff"

A-Schlechter-Nachfolger

Was es bedeutet

Windows Server 2025 führte einen neuen Typ von Dienstkonto namens dMSA (Delegated Managed Service Account). Es wurde eine Sicherheitslücke entdeckt, bei der ein normaler Benutzer mit bestimmten Berechtigungen auf einem Active-Directory-Ordner (einer Organisationseinheit oder OU) ein dMSA erstellen und damit vollständigen Administratorzugriff auf die Domäne erlangen konnte.

Dieser Angriff ist nur möglich, wenn:

• Sie mindestens einen Windows Server 2025 Domänencontroller

• Eine KDS Root Key vorhanden ist (erforderlich für verwaltete Dienstkonten)

• Ein Nicht-Administrator-Benutzer hat das Recht, Objekte in einer OU zu erstellen

Was der Scan prüft

Der AD-Scan sucht nach nicht privilegierten Benutzern oder Gruppen, die Berechtigungen zum Erstellen oder Steuern von dMSA-Objekten in einer beliebigen OU haben, wie z. B. CreateChild, GenericAll, WriteDacl, oder WriteOwner.

Warum die Warnung bestehen bleiben kann

• Die Korrektur muss auf jeder betroffenen OU angewendet werden, nicht nur auf einer.

• Von übergeordneten OUs geerbte Berechtigungen gelten weiterhin für untergeordnete OUs.

• Benutzerdefinierte Administratorgruppen werden vom Scan möglicherweise nicht als „privilegiert“ erkannt.

So diagnostizieren Sie das Problem

# Voraussetzungen prüfen
Get-KdsRootKey  # Der KDS Root Key muss vorhanden sein, damit der Angriff möglich ist

Get-ADDomainController -Filter * |
  Where-Object { $_.OperatingSystem -like "*2025*" } |
  Select-Object Name, OperatingSystem  # Mindestens ein Win2025-DC

# OUs mit riskanten Delegierungen finden
Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor |
  ForEach-Object {
    $ou = $_
    $ou.nTSecurityDescriptor.Access |
      Where-Object {
        -not $_.IsInherited -and
        $_.ActiveDirectoryRights -match 'GenericAll|CreateChild|WriteDacl|WriteOwner'
      } | ForEach-Object {
        [PSCustomObject]@{
          OU        = $ou.Name
          Principal = $_.IdentityReference
          Rights    = $_.ActiveDirectoryRights
        }
      }
  } | Format-Table -AutoSize

So beheben Sie das Problem

Entfernen Sie für jede markierte OU die riskanten Berechtigungen von Nicht-Administrator-Benutzern:

$ouDN = "OU=Servers,DC=yourdomain,DC=com"  # Durch Ihre OU ersetzen
$path = "AD:$ouDN"
$acl = Get-Acl -Path $path

# Riskante Rechte für eine bestimmte Gruppe entfernen
$identity = New-Object System.Security.Principal.NTAccount("YOURDOMAIN", "HelpDeskTeam")
$toRemove = $acl.Access | Where-Object {
  $_.IdentityReference -eq $identity -and
  $_.ActiveDirectoryRights -match 'CreateChild|GenericAll'
}

foreach ($ace in $toRemove) {
  $acl.RemoveAccessRuleSpecific($ace)
}
Set-Acl -Path $path -AclObject $acl

A-AdminSDHolder

Was es bedeutet

Wenn ein Benutzer zu einer privilegierten Gruppe in Active Directory (wie Domain Admins) hinzugefügt wird, markiert das System sein Konto automatisch mit einem Flag namens adminCount = 1. Dieses Flag ist Teil eines integrierten Schutzmechanismus.

Das Problem ist: Wenn Sie diesen Benutzer aus der Administratorgruppe entfernen, wird das Flag NICHT automatisch gelöscht. Es bleibt für immer bestehen, es sei denn, Sie entfernen es ausdrücklich.

Der AD-Scan markiert Konten, die diese verbleibende adminCount -Markierung besitzen, aber keine tatsächlichen Administratoren mehr sind. Das kann darauf hindeuten:

• Ein Benutzer, der vorübergehend zum Administrator gemacht wurde und dessen Bereinigung unvollständig war

• Ein mögliches Sicherheitsproblem: Diese Konten können in bestimmten Bereichen noch erhöhte Berechtigungen haben

Was der Scan prüft

Der Scan findet aktivierte Benutzerkonten, bei denen adminCount = 1 das Konto derzeit kein Mitglied einer privilegierten Gruppe ist.

So diagnostizieren Sie das Problem

# Eine Liste aller aktuell privilegierten Benutzer erstellen
$privilegedMembers = @()
@("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators",
  "Account Operators", "Server Operators", "Backup Operators", "Print Operators"
) | ForEach-Object {
  try { $privilegedMembers += (Get-ADGroupMember $_ -Recursive).DistinguishedName } catch {}
}

# Konten mit der verbleibenden adminCount-Markierung finden
Get-ADUser -LDAPFilter "(&(admincount=1)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" `
  -Properties adminCount |
  Where-Object { $_.DistinguishedName -notin $privilegedMembers } |
  Select-Object SamAccountName, Name

So beheben Sie das Problem

Nachdem bestätigt wurde, dass diese Konten keine Administratoren mehr sein sollten, löschen Sie das Flag:

# adminCount für einen einzelnen Benutzer löschen
Set-ADUser -Identity "username" -Clear adminCount

# Oder es auf einmal für alle nicht privilegierten Benutzer löschen
Get-ADUser -LDAPFilter "(&(admincount=1)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" |
  Where-Object { $_.DistinguishedName -notin $privilegedMembers } |
  ForEach-Object {
    Set-ADUser -Identity $_ -Clear adminCount
    Write-Host "adminCount für $($_.SamAccountName) gelöscht"
  }

A-Keine-GPO-für-LLMNR

Was es bedeutet

LLMNR (Link-Local Multicast Name Resolution) ist ein Protokoll, das Windows verwendet, um andere Computer im Netzwerk zu finden, wenn DNS keine Antwort liefert. Es funktioniert, indem eine Frage an alle benachbarten Rechner gesendet wird: „Weiß jemand, wo servername ist?“

Das Problem ist: Ein Angreifer im selben Netzwerk kann auf diese Broadcasts antworten und sich als der Zielserver ausgeben, sodass das Opfer dazu verleitet wird, seine Anmeldeinformationen an den Angreifer zu senden. Dies wird als ein LLMNR-Poisoning -Angriff bezeichnet und ist eine der häufigsten Techniken bei Angriffen auf interne Netzwerke.

LLMNR ist ein veraltetes Protokoll, das moderne Netzwerke nicht benötigen (DNS erledigt alles). Es sollte per Gruppenrichtlinie deaktiviert werden.

Was der Scan prüft

Der AD-Scan sucht nach einer aktivierten und verknüpften GPO die LLMNR deaktiviert, indem die Einstellung EnableMulticast Registrierungswert auf 0.

Warum die Warnung bestehen bleiben kann

1. Die GPO existiert, ist aber nicht verknüpft mit einer OU.

2. GPO ist deaktiviert, auch wenn verknüpft.

3. LLMNR wurde manuell deaktiviert (über die Registrierung oder netsh) aber nicht über Gruppenrichtlinien. Der AD-Scan liest GPO-Dateien, nicht lokale Computereinstellungen.

So diagnostizieren Sie das Problem

Import-Module GroupPolicy
Get-GPO -All | ForEach-Object {
  [xml]$r = Get-GPOReport -Guid $_.Id -ReportType Xml
  if ($r.InnerXml -match "EnableMulticast") {
    Write-Host "GPO '$($_.DisplayName)' - Status: $($_.GpoStatus) - Enthält LLMNR-Einstellung"
  }
}

So beheben Sie das Problem

$gpoName = "LLMNR deaktivieren"
$gpo = Get-GPO -Name $gpoName -ErrorAction SilentlyContinue
if (-not $gpo) { $gpo = New-GPO -Name $gpoName }

Set-GPRegistryValue -Name $gpoName `
  -Key "HKLM\\Software\\Policies\\Microsoft\\Windows NT\\DNSClient" `
  -ValueName "EnableMulticast" -Type DWord -Value 0

# Mit dem Stamm der Domäne verknüpfen, damit es für alle Computer gilt
New-GPLink -Name $gpoName `
  -Target (Get-ADDomain).DistinguishedName `
  -LinkEnabled Yes

Nachdem Sie die GPO verknüpft haben, führen Sie gpupdate /force auf den Computern aus oder warten Sie auf den nächsten Aktualisierungszyklus der Gruppenrichtlinien (typischerweise 90 Minuten).