> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/cyber-best-practices/nl/gidsen-voor-het-verhelpen-van-kwetsbaarheden/ad-scan-vulnerability-remediation-guide/anomalies.md). # 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 ```powershell # 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: ```powershell 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 ```powershell # 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: ```powershell #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 ```powershell # 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: ```powershell # 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 ```powershell # 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): ```powershell # 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: ```powershell 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 ```powershell # 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: ```powershell $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 ```powershell # 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: ```powershell # 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 ```powershell 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 ```powershell $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). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/cyber-best-practices/nl/gidsen-voor-het-verhelpen-van-kwetsbaarheden/ad-scan-vulnerability-remediation-guide/anomalies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.