> 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/de/anleitungen-zur-behebung-von-schwachstellen/ad-scan-vulnerability-remediation-guide/anomalies.md). # 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 ```powershell # 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: ```powershell 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 ```powershell # 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: ```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 # 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 ```powershell # 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: ```powershell # 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 ```powershell # 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): ```powershell # 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: ```powershell 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 ```powershell # 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: ```powershell $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 ```powershell # 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: ```powershell # 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 ```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) - Enthält LLMNR-Einstellung" } } ``` #### So beheben Sie das Problem ```powershell $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). --- # 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/de/anleitungen-zur-behebung-von-schwachstellen/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.