Anomalieën

A-LAPS-Niet-geïnstalleerd

Wat het betekent

Elke Windows-computer heeft een ingebouwd lokaal Administrator-account. Standaard heeft dit account vaak overal hetzelfde wachtwoord, of een wachtwoord dat nooit verandert. Als een aanvaller één machine compromitteert, kan die hetzelfde wachtwoord opnieuw gebruiken om toegang te krijgen tot alle andere.

LAPS (Local Administrator Password Solution) lost dit op door automatisch een uniek, willekeurig gegenereerd wachtwoord op elke computer in te stellen en dit veilig op te slaan in Active Directory. Alleen geautoriseerde beheerders kunnen het ophalen.

Wat de scan controleert

De AD-scan zoekt naar bewijs dat LAPS is ingesteld in je Active Directory. Specifiek controleert hij of de benodigde LAPS-gegevensvelden bestaan in je AD-configuratie. Als dat niet zo is, betekent dit dat LAPS nooit is geïnstalleerd.

Waarom de waarschuwing kan blijven bestaan

• Alleen via Intune beheerde LAPS: Als je Microsoft Intune gebruikt om LAPS-wachtwoorden in de cloud te beheren (zonder de on-premises AD te configureren), kan de AD-scan dit niet detecteren. De scan kijkt alleen naar je lokale Active Directory.

• LAPS is gedeeltelijk geïnstalleerd: De LAPS-installatie is mogelijk gestart, maar niet voltooid.

Hoe te diagnosticeren

# Controleer of LAPS is ingesteld in je Active Directory
Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext `
  -Filter "name -like 'ms-Mcs-AdmPwd' -or name -eq 'ms-LAPS-Password'" |
  Select-Object Name, whenCreated

Als dit geen resultaten oplevert, is LAPS niet geïnstalleerd.

Hoe op te lossen

Voor Windows Server 2019 en later (aanbevolen): Moderne LAPS is ingebouwd in Windows. Schakel het in via Groepsbeleid:

1. Open gpmc.msc (Groepsbeleidsbeheer)

2. Bewerk of maak een GPO die is gekoppeld aan je computer-OE's

3. Navigeer naar: Computer Configuration > Administrative Templates > System > LAPS

4. Configureer de LAPS-instellingen (inschakelen, wachtwoordcomplexiteit instellen, enz.)

Voor oudere omgevingen: Download Legacy LAPS van Microsoft en voer de schema-uitbreiding uit:

Update-LapsADSchema

Opmerking: Als je lokale beheerderswachtwoorden beheert via een andere tool (CyberArk, alleen-Intune LAPS, enz.), neem dan contact op met de Stoïk-ondersteuning om dit te documenteren als een geaccepteerde uitzondering.

A-LAPS-Gekoppelde-Computers

Wat het betekent

Wanneer iemand een computer toevoegt ("joint") aan het Active Directory-domein, wordt die persoon de maker van het computerobject in AD. Standaard krijgt de maker speciale rechten op dat object.

Het probleem is: wanneer LAPS is geïnstalleerd, wordt het lokale beheerderswachtwoord opgeslagen op datzelfde computerobject. Als de maker nog steeds de juiste rechten heeft, kan die het LAPS-wachtwoord lezen, zelfs als die geen beheerder is. Dit betekent dat een gewone gebruiker die ooit een pc aan het domein heeft gekoppeld, het lokale beheerderswachtwoord voor die machine zou kunnen ophalen.

Wat de scan controleert

Voor elke ingeschakelde computer met LAPS uitgerold, controleert de AD-scan twee dingen:

1. Is de persoon die de computer heeft gekoppeld nog steeds de "eigenaar" van het computerobject? Eigenaren kunnen zichzelf elke machtiging geven, inclusief het lezen van het LAPS-wachtwoord.

2. Heeft de maker nog steeds expliciete rechten op het computerobject, zoals All Extended Rights (waarmee het LAPS-wachtwoord kan worden gelezen), WriteDacl (waarmee machtigingen kunnen worden gewijzigd), WriteOwner (waarmee het eigendom kan worden teruggenomen), of GenericWrite?

De waarschuwing wordt geactiveerd als een van beide voorwaarden waar is.

Waarom de waarschuwing kan blijven bestaan

Dit is de meest voorkomende bron van verwarring: het wijzigen van de eigenaar is slechts de helft van de oplossing.

Veel beheerders wijzigen de eigenaar naar "Domain Admins" en verwachten dat de waarschuwing verdwijnt. Maar de AD-scan controleert ook op resterende machtigingen (zogeheten ACE's, of Access Control Entries) die aan de oorspronkelijke maker zijn toegekend. Deze machtigingen blijven bestaan, zelfs na het wijzigen van de eigenaar, en moeten afzonderlijk worden verwijderd.

Hoe te diagnosticeren

# Lijst computers waarbij de maker nog steeds risicovolle machtigingen heeft
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

Hoe op te lossen

Je moet beide van deze acties uitvoeren voor elke getroffen computer:

1. Wijzig de eigenaar naar Domain Admins

2. Verwijder de expliciete machtigingen van de maker

Het volgende script doet beide 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

  # Stap 1: Wijzig eigenaar naar Domain Admins
  $domainAdmins = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN", "Domain Admins")
  $acl.SetOwner($domainAdmins)
  $modified = $true

  # Stap 2: Verwijder expliciete machtigingen die aan de maker zijn toegekend (en verweesde SID's)
  $toRemove = @($acl.Access | Where-Object {
    -not $_.IsInherited -and
    ($_.IdentityReference.Value -eq $creatorSid.Value -or
     $_.IdentityReference.Value -match '^S-1-5-21-')  # Verweesde SID's (verwijderde accounts)
  })

  foreach ($ace in $toRemove) {
    $acl.RemoveAccessRuleSpecific($ace)
    Write-Host "$($comp.Name): Verwijderd [$($ace.ActiveDirectoryRights)] voor $($ace.IdentityReference)"
  }

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

Tip: Voer eerst het diagnostische commando uit om de lijst met getroffen computers te bekijken voordat je de oplossing toepast.

A-NoServicePolicy

Wat het betekent

Serviceaccounts zijn accounts die door toepassingen en services worden gebruikt (bijv. SQL Server, back-upagents) om zich te authenticeren in Active Directory. In tegenstelling tot gewone gebruikersaccounts zijn serviceaccounts waardevolle doelwitten: ze hebben vaak verhoogde rechten en hun wachtwoorden worden zelden gewijzigd.

Een Fine-Grained Password Policy (PSO) is een speciale wachtwoordregel die je kunt toepassen op specifieke groepen accounts. De AD-scan verwacht dat je serviceaccounts onder een PSO vallen die wachtwoorden van ten minste 20 tekens, waardoor ze veel moeilijker te kraken zijn.

Wat de scan controleert

De AD-scan zoekt naar ten minste één wachtwoordbeleid (GPO of PSO) dat een minimale wachtwoordlengte van 20 tekens of meer.

Waarom de waarschuwing kan blijven bestaan

1. toepast. Het scanaccount heeft geen rechten om de PSO te lezen.

2. Wachtwoordbeleid is opgeslagen in een beveiligd deel van AD dat standaard alleen door Domain Admins kan worden gelezen. Als de scan wordt uitgevoerd met een account met minder rechten, kan die de PSO simpelweg niet zien, ook al bestaat deze wel. De PSO bestaat maar de minimale lengte is lager dan 20

3. (bijv. 12 of 15 tekens).

Hoe te diagnosticeren

# Lijst alle Fine-Grained Password Policies en hun instellingen
Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, MinPasswordLength, @{N="AppliedTo"; E={$_.AppliesTo -join ", "}}, Precedence

Als dit niets oplevert, bestaat er geen PSO of heeft het account dat het commando uitvoert niet de rechten om die te zien. Probeer het opnieuw uit te voeren met een Domain Admin-account.

Hoe op te lossen

Als de PSO bestaat maar de scan kan deze niet zien: Voer de AD-scan uit met een Domain Admin-account.

Als er geen PSO bestaat: Maak er een en wijs die toe aan je serviceaccounts:

# Maak een wachtwoordbeleid voor serviceaccounts
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

# Wijs het toe aan een beveiligingsgroep met je serviceaccounts
Add-ADFineGrainedPasswordPolicySubject `
  -Identity "Service Accounts - Strong Password" `
  -Subjects "SG_ServiceAccounts"

Opmerking: Het aanmaken van een PSO dwingt niet meteen wachtwoordwijzigingen af. Bestaande wachtwoorden blijven werken totdat ze verlopen of handmatig worden gereset. Op dat moment geldt de nieuwe minimale lengte van 20 tekens.

A-AuditDC

Wat het betekent

Auditbeleid bepalen welke gebeurtenissen worden gelogd op je domeincontrollers. Zonder goede auditing kunnen aanvallen zoals diefstal van inloggegevens, ongeautoriseerde groepswijzigingen of misbruik van replicatie (DCSync) plaatsvinden zonder enig spoor in de logs achter te laten.

De AD-scan verifieert dat je domeincontrollers zo zijn geconfigureerd dat de belangrijkste beveiligingsgebeurtenissen worden gelogd.

Wat de scan controleert

De scan kijkt naar 13 specifieke audit-subcategorieën die via Groepsbeleid op alle domeincontrollers moeten zijn ingeschakeld:

Categorie	Wat het logt
Kerberos Authentication Service	Inlogpogingen via Kerberos
Kerberos Service Ticket Operations	Aanvragen van service tickets (detecteert Kerberoasting)
Beheer van computeraccounts	Computer-aanmeldingen/-wijzigingen in AD
Beheer van beveiligingsgroepen	Wijzigingen in groepslidmaatschap
Beheer van gebruikersaccounts	Aanmaken, verwijderen en wachtwoordresets van gebruikers
DPAPI-activiteit	Gebruik van de Data Protection API (toegang tot inloggegevens)
Procesaanmaak	Nieuwe processen gestart (detecteert kwaadaardige tools)
Aanmelden / Afmelden	Interactieve en externe aanmeldingen
Speciale aanmelding	Aanmeldingen met verhoogde rechten
Wijziging van authenticatiebeleid	Wijzigingen in authenticatie-instellingen
Gebruik van gevoelige bevoegdheden	Gebruik van gevoelige machtigingen
Uitbreiding van het beveiligingssysteem	Wijzigingen in de beveiligingssubsystemen

Waarom de waarschuwing kan blijven bestaan

1. Instellingen toegepast via auditpol rechtstreeks op de DC worden niet gedetecteerd. De AD-scan leest Groepsbeleid-bestanden, niet de lokale DC-configuratie. Je moet een GPO gebruiken.

2. Conflicterende GPO's: Eén GPO schakelt de instelling in, maar een andere GPO met hogere prioriteit schakelt deze uit.

3. GPO niet gekoppeld aan de OU Domain Controllers: De GPO bestaat, maar is gekoppeld aan een andere OU.

Hoe te diagnosticeren

# Controleer het effectieve auditbeleid op een domeincontroller
auditpol /get /category:*

Als de lokale instellingen er correct uitzien maar de waarschuwing blijft bestaan, controleer dan of de instellingen uit een GPO komen (niet uit een lokale overschrijving):

# Controleer welke GPO's zijn gekoppeld aan de OU Domain Controllers
Get-GPInheritance -Target "OU=Domain Controllers,$($(Get-ADDomain).DistinguishedName)"

Hoe op te lossen

1. Open gpmc.msc (Groepsbeleidsconsole)

2. Maak of bewerk een GPO die is gekoppeld aan OU=Domain Controllers

3. Navigeer naar: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

4. Schakel Succes en Mislukking in voor alle hierboven vermelde subcategorieën

5. Voer uit gpupdate /force op alle domeincontrollers

Verifieer de oplossing:

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

A-BadSuccessor

Wat het betekent

Windows Server 2025 introduceerde een nieuw type serviceaccount genaamd dMSA (Delegated Managed Service Account). Er werd een beveiligingsfout ontdekt waarbij een gewone gebruiker met bepaalde machtigingen op een Active Directory-map (een Organizational Unit, of OU genoemd) een dMSA kon aanmaken en deze kon gebruiken om volledige beheerdersrechten op het domein te verkrijgen.

Deze aanval is alleen mogelijk wanneer:

• Je minstens één Windows Server 2025 domeincontroller

• Een KDS Root Key bestaat (vereist voor beheerde serviceaccounts)

• Een niet-beheerdersgebruiker het recht heeft om objecten in een OU aan te maken

Wat de scan controleert

De AD-scan zoekt naar niet-geprivilegieerde gebruikers of groepen die machtigingen hebben om dMSA-objecten aan te maken of te beheren in een willekeurige OU, zoals CreateChild, GenericAll, WriteDacl, of WriteOwner.

Waarom de waarschuwing kan blijven bestaan

• De oplossing moet worden toegepast op elke getroffen OU, niet slechts op één.

• Machtigingen die zijn geërfd van bovenliggende OU's blijven van toepassing op onderliggende OU's.

• Aangepaste beheerdersgroepen worden mogelijk niet door de scan als "geprivilegieerd" herkend.

Hoe te diagnosticeren

# Controleer de vereisten
Get-KdsRootKey  # KDS Root Key moet bestaan voordat de aanval mogelijk is

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

# Vind OU's met risicovolle delegaties
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
          Rechten    = $_.ActiveDirectoryRights
        }
      }
  } | Format-Table -AutoSize

Hoe op te lossen

Verwijder voor elke gemarkeerde OU de risicovolle machtigingen van niet-beheerders:

$ouDN = "OU=Servers,DC=yourdomain,DC=com"  # Vervang door je OU
$path = "AD:$ouDN"
$acl = Get-Acl -Path $path

# Verwijder risicovolle rechten voor een specifieke groep
$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

Wat het betekent

Wanneer een gebruiker aan een geprivilegieerde groep in Active Directory wordt toegevoegd (zoals Domain Admins), markeert het systeem automatisch zijn account met een vlag genaamd adminCount = 1. Deze vlag maakt deel uit van een ingebouwd beschermingsmechanisme.

Het probleem is: wanneer je die gebruiker uit de admin-groep verwijdert, wordt de vlag NIET automatisch gewist. Hij blijft voor altijd bestaan, tenzij je hem expliciet verwijdert.

De AD-scan markeert accounts die deze achtergebleven adminCount markering hebben, maar geen echte beheerders meer zijn. Dit kan wijzen op:

• Een gebruiker die tijdelijk beheerder was en waarbij de opschoning onvolledig was

• Een mogelijk beveiligingsrisico: deze accounts kunnen nog steeds verhoogde rechten hebben in bepaalde gebieden

Wat de scan controleert

De scan vindt ingeschakelde gebruikersaccounts waarbij adminCount = 1 maar het account momenteel geen lid is van een geprivilegieerde groep.

Hoe te diagnosticeren

# Stel een lijst samen van alle huidige geprivilegieerde gebruikers
$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 {}
}

# Zoek accounts met de achtergebleven adminCount-vlag
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

Hoe op te lossen

Nadat je hebt bevestigd dat deze accounts geen beheerders meer zouden moeten zijn, wis je de vlag:

# Wis adminCount voor één gebruiker
Set-ADUser -Identity "username" -Clear adminCount

# Of wis het in één keer voor alle niet-geprivilegieerde gebruikers
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 gewist voor $($_.SamAccountName)"
  }

A-NoGPOLLMNR

Wat het betekent

LLMNR (Link-Local Multicast Name Resolution) is een protocol dat Windows gebruikt om andere computers op het netwerk te vinden wanneer DNS geen antwoord heeft. Het werkt door een vraag uit te zenden naar alle nabijgelegen machines: "Weet iemand waar servername is?"

Het probleem is: een aanvaller op hetzelfde netwerk kan reageren op deze broadcasts door te doen alsof hij de doelserver is, waardoor het slachtoffer wordt misleid om zijn inloggegevens naar de aanvaller te sturen. Dit wordt een LLMNR-poisoning aanval genoemd en is een van de meest gebruikte technieken tijdens aanvallen op interne netwerken.

LLMNR is een verouderd protocol dat moderne netwerken niet nodig hebben (DNS regelt alles). Het moet worden uitgeschakeld via Groepsbeleid.

Wat de scan controleert

De AD-scan zoekt naar een ingeschakelde en gekoppelde GPO die LLMNR uitschakelt door het EnableMulticast registerwaarde naar 0.

Waarom de waarschuwing kan blijven bestaan

1. GPO bestaat maar is niet gekoppeld aan geen enkele OU.

2. GPO is uitgeschakeld, zelfs als deze gekoppeld is.

3. LLMNR is handmatig uitgeschakeld (via register of netsh) maar niet via Groepsbeleid. De AD-scan leest GPO-bestanden, niet de instellingen van de lokale machine.

Hoe te diagnosticeren

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) - Bevat LLMNR-instelling"
  }
}

Hoe op te lossen

$gpoName = "LLMNR uitschakelen"
$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

# Koppel aan de domeinroot zodat het van toepassing is op alle computers
New-GPLink -Name $gpoName `
  -Target (Get-ADDomain).DistinguishedName `
  -LinkEnabled Yes

Nadat de GPO is gekoppeld, voer gpupdate /force uit op machines of wacht op de volgende Groepsbeleid-verversingscyclus (meestal 90 minuten).