Eine kleines Vor-Vorwort 😉

So, jetzt ist nach den spannenden Wochen Enden November & Anfang Dezember tatsächlich etwas Zeit vergangen. Vor & während Weihnachten und Jahreswechsel war privat noch viel los, daher hat dieser Artikel etwas länger gebraucht. Aber ich denke, dass die Feiertage gut genutzt waren und es ein super Jahresauftakt ist – also, viel Spaß beim Lesen!

Vorwort

Vor einiger Zeit habe ich den Artikel Sichere Active Directory mithilfe „PingCastle“ veröffentlicht und vor kurzen mit 1-2 Details aktualisiert.

In der Zwischenzeit habe ich ein paar weitere Erfahrungen gesammelt und habe – vor allem bei einer neu installierten Active Directory – ein Vorgehen erarbeitet, um diese abzusichern. Dieses Vorgehen lässt sich natürlich auch auf bestehende ADDS anwenden, hier muss allerdings genauer geprüft werden, ob es Auswirkungen auf den produktiven Betrieb hat bzw. diese so gering, wie möglich zu halten.

PingCastle | Ausgangslage – 60/100

Ein neues ADDS (“TEST.adloc”) wurde installiert, es gibt einen Domain-Controller mit einer Festplatte (für das Betriebssystem selbst) und einen Admin-Account (der “Administrator”; sog. “SID-500-Account“).
Mit der aktuellen PingCastle-Version (v3.xx; Download über den seit Jahresbeginn neuen Hersteller “Netwrix”) wurde eine erste Analyse durchgeführt mit folgendem Ergebnis: 60/100.

In der Detailansicht dann:

---

Ablauf für die Absicherung

Ich gehe nach folgendem Ablauf vor:

1. Microsoft Security Baseline
2. PingCastle
   • Scored-Findings
   • Informative-Findings
3. opt. weiteres Tool
4. Windows Defender Firewall (WDFW) a.k.a. Hostbased-Firewall (HBFW)

Wenn man einen Blick in das “Group Policy Management” wirft, sieht man auch, dass dies sehr leer aussieht und es nur die beiden Standard-GPOs gibt:

• Default Domain Controllers Policy
• Default Domain Policy

Bevor ich richtig beginne, werde ich diese beiden GPOs erstmal sichern optional könnte ich sie auch nach meiner Namenskonvention für GPOs umbenennen, wobei zur besseren Hervorhebung ihres Sonderstatus direkt eine Ausnahme der Namenskonvention gemacht werden müsste:

• Z_DefaultDomainControllerPolicy_v0.0
• Z_DefaultDomainPolicy_v0.0

Im Rahmen der Absicherung werden weitere GPOs angelegt, die dann entsprechend einer sinnvollen GPO-Reihenfolge verwendet werden. Dabei ist mein Ziel, dass die beiden Original-GPOs inhaltlich unverändert bleiben.

Microsoft Security Baseline

Die aktuellste Version der Baseline lässt sich auf der Microsoft-Webseite herunterladen. Hier sollten nur die ausgewählt werden, die tatsächlich benötigt werden.

Für den Artikel habe ich also diese genommen:

• Windows Server 2025 Security Baseline – 2506
• Windows 11 v25H2 Security Baseline
• Microsoft Edge v139 Security Baseline

Nach dem Download wurden die ZIP-Dateien in den Ordner “C:\ADMINS-TOOLS” entpackt. Anschließend werden diese Vorlagen importiert.

Import: Windows Server 2025 – 2506

Im Ordner “Windows Server 2025 Security Baseline – 2506” gibt es den Unterordner “Scripts”, dort wird das PowerShell-Skript “Baseline-ADImport.ps1” mit administrativer Berechtigung ausgeführt.

---

Import: Windows 11 v25H2

Im Ordner “Windows 11 v25H2 Security Baseline” gibt es den Unterordner “Scripts”, dort wird das PowerShell-Skript “Baseline-ADImport.ps1” mit administrativer Berechtigung ausgeführt.

---

Import: Microsoft Edge v139

Im Ordner “Microsoft Edge v139 Security Baseline” gibt es den Unterordner “Scripts”, dort wird das PowerShell-Skript “Baseline-ADImport.ps1” mit administrativer Berechtigung ausgeführt.

---

Import-Summary

Nach erfolgreichem Import sind alle neuen GPOs im GP-Editor verfügbar – dabei sind die “Internet Explorer”-GPOs aber nur einmal importiert worden, was auch ausreicht.

---

Verlinkung

Damit diese GPOs auch angewandt werden, müssen sie natürlich noch verlinkt werden. Hierbei verlinke ich sie in dieser Reihenfolge (Verarbeitungsreihenfolge von unten nach oben; siehe Verarbeitungsreihenfolge der GPOs) in diese OUs:

• ROOT
  1. MSFT Windows Server 2025 v2506 – Domain Security
  2. (*) Default Domain Policy
• Account:
  1. MSFT Internet Explorer 11 – User
  2. MSFT Windows 11 25H2 – User
• Server
  1. MSFT Windows Server 2025 v2506 – Defender Antivirus
  2. MSFT Edge Version 139 – Computer
  3. MSFT Internet Explorer 11 – Computer
  4. MSFT Windows Server 2025 v2506 – Member Server Credential Guard
  5. MSFT Windows Server 2025 v2506 – Member Server
• Clients
  1. MSFT Edge Version 139 – Computer
  2. MSFT Internet Explorer 11 – Computer
  3. MSFT Windows 11 25H2 – BitLocker
  4. MSFT Windows 11 25H2 – Defender Antivirus
  5. MSFT Windows 11 25H2 – Credential Guard
  6. MSFT Windows 11 25H2 – Computer
• Domain Controllers
  1. MSFT Edge Version 139 – Computer
  2. MSFT Internet Explorer 11 – Computer
  3. MSFT Windows Server 2025 v2506 – Defender Antivirus
  4. MSFT Windows Server 2025 v2506 – Domain Controller Virtualization Based Security
  5. MSFT Windows Server 2025 v2506 – Domain Controller
  6. (*) Default Domain Controllers Policy

(*) -> Diese beiden waren original schon in den OUs; ich habe sie für die bessere Übersicht und Nachvollziehbarkeit mit aufgelistet.

Besonderheit 1: Domain Security

Die GPOs sind inhaltlich fast gleich:

• MSFT Windows Server 2025 v2506 – Domain Security
• MSFT Windows 11 25H2 – Domain Security

In meinem Fall habe ich die striktere GPO (links; Windows Server) verwendet bzw. verlinkt.

Besonderheit 2: Domain Controller – AppLocker

Im nachfolgenden Kapitel wird mittels “PingCastle” ein HTML-Report erstellt. Damit dieser für die Einrichtung bzw. für das Schreiben dieses Artikels nicht jedesmal erst auf ein anderes Gerät kopiert werden muss, wurde eine Einstellung angepasst, sodass der Edge-Browser auf dem Domain Controller gestartet werden kann.

Security-Warnung beim öffnen des HTML-Reports bzw. beim Starten des Edge-Browsers:

AppLocker-Einstellung von

geändert zu

Die Einstellung ist im GPO-Pfad zu finden:

Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > Executable Rules

Abschluss

Anschließend sollte ein Neustart der Domain-Controller gemacht werden, um sicherzugehen, dass alle Settings übernommen werden.

PingCastle | Zwischenstand 1 – 55/100

Nachdem die Microsoft Security Baseline angewandt wurde, verbleibt immer noch ein Rest-Risikowert von 55/100.

In der Detailansicht dann:

PingCastle

Nach den Microsoft Security Baselines hat der PingCastle-Check trotzdem noch ein paar Schwachstellen gefunden, die nun behoben werden müssen.
Hier wird unterschieden zwischen
– Scored-Findings
– Informative-Findings

Scored-Findings

Die Scored-Findings sind im Detail:

• STALE OBJECTS
  • Non-admin users can add up to 10 computers to a domain
  • The subnet declaration is incomplete (1 IP of DC not found in declared subnets)
  • Number of accounts which have never expiring passwords
• PRIVILEGED ACCOUNTS
  • Presence of Admin accounts which do not have the flag “This account is sensitive and cannot be delegated”
  • The Recycle Bin is not enabled
  • The group “Schema Admins is not empty”
• ANOMALIES
  • LAPS doesn’t seem to be installed
  • Policy where the password length is less than 8 Characters
  • The audit policy on domain controllers does not collect key events
  • Last AD backup has been performed x day(s) ago
  • The number of DCs is too small to provide redundancy: 1 DC

STALE | Non-admin users can add up to 10 computers to a domain

Standardmäßig steht das AD-Attribut “” auf 10, somit kann jeder Standard-Benutzer bis zu 10 Geräte hinzufügen. Dieses Attribut sollte also auf 0 geändert werden. Das kann per PowerShell-Befehl durchgeführt werden:

Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Properties 'ms-DS-MachineAccountQuota'
Set-ADObject -Identity (Get-ADDomain).DistinguishedName -Replace @{'ms-DS-MachineAccountQuota' = 0}
Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Properties 'ms-DS-MachineAccountQuota'

oder per GUI im Attribut-Editor der ADU&C-Console:

Es gibt hier dann noch die Möglichkeit, dass bewusst das Hinzufügen für spezielle User bzw. Gruppen zu erlauben, das wird in einem separaten Artikel mal erläutert.

STALE | The subnet declaration is incomplete (1 IP of DC not found in declared subnets)

Hierfür wird in “AD Sites and Services” im Ordner “Subnets” ein neues Subnetz passend zum IP-Adressbereich der Domain Controller hinzugefügt. Existieren Domain Controller in mehreren Subnetzen, müssen diese auch angelegt werden.

STALE | Number of accounts which have never expiring passwords

Hierbei wird der Standard-Administrator-Account (ich nenne ihn gerne auch “Default-Admin” oder “Root-Admin” oder “SID-500-Admin”) bemängelt. Für den gilt leider bei Installation weniger konsequente Sicherheitsmerkmale, in diesem Fall:
Das Passwort läuft nie ab – eingestellt “per Haken” in den Account-Einstellungen

PRIVILEGED ACCOUNTS | Presence of Admin accounts which do not have the flag “This account is sensitive and cannot be delegated”

Hierbei wird erneut der Standard-Administrator-Account bemängelt, in diesem Fall:
Der Account kann nicht für Kerberos-Delegation verwendet werden – einstellbar “per Haken” in den Account-Einstellungen

PRIVILEGED ACCOUNTS | The Recycle Bin is not enabled

Unglücklicherweise habe ich den RecycleBin in meiner TEST-AD aktiviert ohne dass die Screenshots erfolgreich in diesem Artikel eingefügt wurden. Daher verweise ich an der Stelle einfach auf diesen Artikel: AD-RecycleBin / AD-Tombstone .

PRIVILEGED ACCOUNTS | The group “Schema Admins is not empty”

Diese AD-Gruppe muss nur dann einen Account beinhalten, wenn aktuell Änderungen am Schema durchgeführt werden. Da dies sehr selten passiert (bspw. bei der Einrichtung von LAPS oder beim Schema-Update), sollte diese Gruppe also immer leer sein. Optimal ist dann noch ein zusätzliches Monitoring, falls ungewollte Änderungen passieren.
Bei einer frisch installierten Active Directory ist hier der Root-Admin hinterlegt, welcher also entfernt wird.

ANOMALIES | LAPS doesn’t seem to be installed

Bei LAPS gibt es derzeit noch zwei Versionen, wobei die ältere demnächst bei neueren Windows-Versionen nicht mehr nutzbar sein soll. Dazu habe ich in der Vergangenheit auch schon zweit Artikel verfasst:

• AD-Security: Verwendung von LAPS
• AD-Security: Windows-LAPS

Microsoft hat selbst eine mittlerweile überarbeitete und relativ übersichtliche Anleitung dazu: Get started with Windows LAPS and Windows Server Active Directory | Microsoft Learn

Die Grundvoraussetzungen sind mittlerweile in Windows Server und Windows Client enthalten, sodass nur noch ein paar Einstellungen vorzunehmen sind:

1. Schema-Update (reicht einmal für den kompletten AD-Forest aus)
2. Geräte-Erlaubnis zum Aktualisieren des LAPS-Passwords
3. Prüfen, wer das Recht zum Auslesen auf der Geräte-OU hat
4. Erlaubnis zum Auslesen des LAPS-Passwords
5. Erlaubnis zum Zurücksetzen bzw. Auslaufen des LAPS-Passwords
6. GPO-Anlage um LAPS-Einstellungen zu verteilen

Hier der genannte Ablauf:

Schema-Update

Der Account, welcher das Schema-Update durchführen soll, muss dafür temporär in der Gruppe der “Schema-Admins” sein. Danach in einer administrativen PowerShell diesen Befehl ausführen:

Update-LapsADSchema

Ergebnis:

Aktualisieren des Passwords

Hierzu wird folgender PowerShell-Befehl auf der OU mit Geräten (Clients oder Server) ausgeführt:

Set-LapsADComputerSelfPermission -Identity 300_SERVER

Sollte es mehr als eine OU mit dem selben Namen geben, muss der LDAP-Pfad (bzw. der sog. “DistinguishedName”) angegeben werden. Zudem kann überlegt werden, ob diese Berechtigung auch einfach direkt auf der kompletten AD angewandt werden soll, dann stattdessen diesen PowerShell-Befehl verwenden:

Set-LapsADComputerSelfPermission -Identity "DC=TEST,DC=adloc"

Die untere Variante hat den Vorteil, dass, egal in welcher OU sich ein Gerät befindet, es immer in der Lage ist, sein LAPS-Password zu setzen.

Prüfen, wer das Recht zum Auslesen auf der Geräte-OU hat

In der Microsoft-Anleitung folgt dieser Schritt erst später, ich finde es gut, vorher schon mal zu prüfen, was gesetzt ist; das geht ganz einfach mit diesem Befehl:

Find-LapsADExtendedRights -Identity "OU=300_SERVER,OU=000_TIER,DC=TEST,DC=adloc"

Nach Umsetzung der nächsten beiden Schritte:

Erlaubnis zum Auslesen des LAPS-Passwords

Hierfür ist es meines Erachtens sinnvoll, eine AD-Gruppe anzulegen, die das Recht erhalten soll; danach mittels diesem PowerShell-Befehl das Recht auf die OU vergeben:

Set-LapsADReadPasswordPermission -Identity "OU=300_SERVER,OU=000_TIER,DC=TEST,DC=adloc" -AllowedPrincipals @("TEST\LAPS-PWD-01-Readers")

Erlaubnis zum Auslesen des LAPS-Passwords

Hierfür ist es meines Erachtens sinnvoll, eine AD-Gruppe anzulegen, die das Recht erhalten soll; danach mittels diesem PowerShell-Befehl das Recht auf die OU oder die gesamte AD vergeben:

Set-LapsADResetPasswordPermission -Identity "OU=300_SERVER,OU=000_TIER,DC=TEST,DC=adloc" -AllowedPrincipals @("TEST\LAPS-PWD-02-Expirers")

Hinweis/Tipp:
Wenn man aus Security-Gründen die Berechtigung zwischen Teams (bspw. ein Team für die Clients und ein anderes Team für die Server bzw. DCs) aufteilen will, sollte für’s Lesen und Zurücksetzen natürlich separate Gruppen verwendet werden.

GPO-Anlage um LAPS-Einstellungen zu verteilen

Für Geräte, die sog. “hybrid-joined” sind, also sowohl im AD als auch in EntraID aufgenommen wurden, bietet sich es an die Einstellungen per Intune mit Windows LAPS configuration service provider (CSP) durchzuführen; in der Regel betrifft das dann nur die Windows Clients.
Für Geräte die ausschließlich im AD aufgenommen wurden, gibt es die Möglichkeit über die klassische GPO.

Ich habe die GPO “A-C-PO-AT-SY-LAPS_v1.0” angelegt und für die Einstellung “” noch die passende LAPS-Gruppe “LAPS-PWD-03-Decryptors”.

ANOMALIES | Policy where the password length is less than 8 Characters

Normalerweise sollte das aufgrund der verlinkten Microsoft Security Baseline GPO “MSFT Windows Server 2025 v2506 – Domain Security” bereits erledigt sein. Falls es aufgelistet ist, dann unbedingt die Verarbeitungsreihenfolge der GPOs prüfen. Hier sollte es so aussehen, dass die Originale “Default Domain Policy” als erstes ausgeführt wird – und somit ganz unten stehen muss:

---

ANOMALIES | The audit policy on domain controllers does not collect key events

Standardmäßig wird auf einem Windows-System (Client, Server, Domain-Controller) nicht alle möglichen Ereignisse geloggt/auditiert, daher wird dies hier bemängelt. Es gibt dabei eine sehr detaillierte Handlungsempfehlung:

Be aware that there are two places for audit settings.
For “Simple” audit configuration:
in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policies
For “Advanced” audit configuration:
in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration

Ich erstelle dafür die GPO “A-C-PO-WS-SS-XX_AUDIT-SETTINGS_v1.0” und verlinke sie ganz oben direkt unter den Domain-Name mit Prio 1 (also letzte Ausführung in der Reihenfolge).

Alle möglichen Audit-Optionen werden auf “Success” und “Failure” gestellt:

---

ANOMALIES | Last AD backup has been performed x day(s) ago

Manchmal kann es je nach eingesetzter Drittanbieter-Backuplösung passieren, dass für das AD trotzdem kein Backup vorliegt, das ist bspw. der Fall, wenn der Drittanbieter die gesamte Domain-Controller-VM sichert aber kein sog. “application aware”-Backup durchführt – d.h. die Anwendung weiß nichts vom durchgeführten Backup.

In diesem Fall der Domain-Controller-VM einfach eine zweite Festplatte geben (bspw. mit selber Größe der Betriebssystemplatte) und dorthin das Backup legen. Sofern zwei Domain-Controller-VMs vorhanden sind, kann man die Sicherungen auch “über Kreuz” machen, d.h.:

• DC01 –[sichert auf]-> DC02, Backup-Volumen als Share bereitgestellt
• DC02 –[sichert auf]-> DC01, Backup-Volumen als Share bereitgestellt

Sofern nicht schon geschehen, muss das Server-Feature “Windows Server Backup” per GUI oder per PowerShell installiert werden.

Install-WindowsFeature -Name Windows-Server-Backup -IncludeManagementTools
Get-WindowsFeature -Name Windows-Server-Backup

Oder alternativ:

dism /online /enable-feature /featurename:Windows-Server-Backup
Get-WindowsFeature -Name Windows-Server-Backup

Danach kann ein Einmal-Backup per PowerShell bzw. Backup-CLI erstellt werden:

wbadmin start systemstatebackup -backuptarget:b:

---

Mit dem PowerShell-Befehl kann das letzte Backup der Active Directory ausgelesen werden:

REPADMIN /showbackup *

---

Über die “Windows Server Backup”-Console kann dann noch ein vollständiger Backup-Zeitplan erstellt werden. Hierbei kann entweder auf die Backup-Platte oder bspw. (wie oben genannt) auf die freigegebene Backup-Platte des anderen Domain-Controllers oder möglicher anderer Netzwerkfreigaben (bspw. ein NAS) gewählt werden.

---

Hinweis/Tipp:
Am besten auf beiden Domain-Controllern die Sicherung (auf separates Volume oder Netzwerk-Share) einrichten und mit ca. 30 Minuten Versatz laufen lassen. Sollte es also auf dem DC01 mal nicht klappen, übernimmt der DC02 die Sicherung des Active Directories.
Trotzdem an ordentliches Monitoring denken! 😉

ANOMALIES | The number of DCs is too small to provide redundancy: 1 DC

Erfahrene IT-Administratoren setzen für ein Active Directory sowieso mehr als einen Domain-Controller auf. Falls also diese Meldung kommt, sollte entweder geprüft werden, warum weitere DCs nicht erkannt werden oder (was meistens eher der Fall ist) einfach ein zweiterer Domain-Controller eingerichtet werden. Die Details dazu würden hier den Rahmen sprengen, es gibt bereits Artikel dazu:

• HowTo: Hinzufügen eines Windows Server Core DomainControllers zu einer AD
• Domain-Controller Upgrade
• Windows Server 2025 – Konfiguration als Domain-Controller

PingCastle | Zwischenstand 2 – 00/100

Nachdem nun auch die Scored-Findings behoben wurden, liegt der Risikowert bei xx/100.

In der Detailansicht dann:

Jetzt können noch die Informative-Findings behoben werden.

Informative-Findings

Die Informative-Findings sind im Detail:

• STALE OBJECTS
  • It is possible for scripts engine used by hackers to connect directly to the internet
  • The GPO are not pushing recommended configuration for Terminal Services
  • Not all possible Defender ASR mitigations are in Block or Warn mode
  • Some script extensions, used in pishing, can be directly run by double clicking on it
  • Kerberos Armoring
    • Verify Kerberos Armoring is enabled on clients (…)
    • Verify Kerberos Armoring is enabled on DCs (…)
  • Presence of Service accounts without AES support
• PRIVILEGED ACCOUNTS
  • OU without the accidental deletion protection have been found
• ANOMALIES
  • The PowerShell audit configuration is not fully enabled
  • Authenticated Users can create DNS records
  • Anonymous Binding to the rootDse is enabled
  • DsHeuristics has not been set to enable the mitigation for CVE-2021-42291
  • The PreWin2000 compatible group contains “Authenticated Users”
  • No GPO has been found which implements NetCease
  • No password policy for service accounts found (MinimumPasswordLength >=20)

STALE | It is possible for scripts engine used by hackers to connect directly to the internet

Hierbei geht es darum, dass die typischen Script-Engines:

• wscript.exe
• mshta.exe
• cscript.exe
• conhost.exe
• runScriptHelper.exe

aus Sicht des Betriebssystems uneingeschränkt ins Internet dürfen und somit Schadcode herunterladen dürften. Um das zu verhindern, werden mittels ausgehende Firewall-Regeln, alle IP-Ranges blockt, außer die typischen internen IP-Adressbereiche:

• 0.0.0.0 – 9.255.255.255
  • 10.0.0.0 – 10.255.255.255
• 11.0.0.0 – 126.255.255.255
  • 127.0.0.0 – 128.0.0.0
• 128.0.0.1 – 172.15.255.255
  • 172.16.0.0. – 172.31.255.255
• 172.32.0.0 – 192.167.255.255
  • 192.168.0.0 – 192.168.255.255
• 192.169.0.0 – 255.255.255.255

Die benötigten Regeln können in eine GPO zusammengefasst werden.
Hier exemplarisch mit der GPO “A-C-PO-WS-SS-WDFW-OUT-BLOCK_wscript_mshts_cscript_conhost_RunScriptHelper_v1.0“:

Anstelle von “Program => Any” sollte dann natürlich der Pfad zur jeweiligen Script-Engine stehen. Im Detail sind dann diese Firewall-Regeln enthalten:

Verlinkt wird diese GPO auf alle OUs, in denen Computer-Konten enthalten sind; sowie in der Verarbeitungsreihenfolge der jeweiligen OU nach ganz oben geschoben.

STALE | The GPO are not pushing recommended configuration for Terminal Services

Hier wird empfohlen, dass aus Sicherheitsgründen die Remotezugriffe via RDP dahingehend eingeschränkt werden, dass

• Drucker nicht umgeleitet werden
• Zeitlimit für
  • Idle-Sessions (wenn also keine Interaktion stattfindet)
  • getrennte Sessions

Hierfür wird die GPO “A-C-PO-AT-WC-RDS-RDSH_v1.0” angelegt und die entsprechenden Einstellungen gesetzt:

---

Diese GPO wird auf alle OUs, in denen Computer-Konten enthalten sind, verlinkt; sowie in der Verarbeitungsreihenfolge der jeweiligen OU nach ganz oben geschoben.

STALE | Not all possible Defender ASR mitigations are in Block or Warn mode

Es gibt ein paar ASR (Attack Surface Reduction) Regeln, die das System weiter härten. Exakte Details verweist das PingCastle-Finding selbst:

• https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#per-asr-rule-alert-and-notification-details
• https://blog.palantir.com/microsoft-defender-attack-surface-reduction-recommendations-a5c7d41c3cf8
• [MITRE]Mitre Att&ck – Mitigation – Active Directory Configuration

Die wichtige Info für mich war aus diesem Finding:

• die Abstufungen:
  • Wert “1” = Block Modus
  • Wert “2” = Audit Modus
  • Wert “6” = Warn Modus
• Die GUIDs, die ich verwenden sollte
  • d3e037e1-3eb8-44c8-a917-57927947596d
  • 01443614-cd74-433a-b99e-2ecdc07bfc25
  • 33ddedf1-c6e0-47cb-833e-de6133960387
  • c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb
  • d1e49aac-8f56-4280-b9ba-993a6d77406c

Auf diese Basis ist dann die GPO “A-C-PO-AT-WC-MDA-MDEG-ASR_v1.0” angelegt worden:

---

STALE | Some script extensions, used in pishing, can be directly run by double clicking on it

Von “.ps1”-Dateien ist man es gewohnt, dass diese im Notepad oder PowerShell-Editor geöffnet werden, sobald man ein Doppelklick darauf macht. Bei den älteren Script-Dateitypen (.js, .jse, .vbs, .vbe, .vb, .wsh, .wsf) wird aber standardmäßig mittels der zugehörigen Script-Engine die Datei ausgeführt.

Um das zukünftig zu verhindern, wird die GPO “A-C-PR-CPS-FO_BlockDoubleClickRunForScript_v1.0” angelegt und auf alle OUs mit Computer-Konten verlinkt & dort in der Verarbeitungsreihenfolge ganz nach oben geschoben.

---

Hier am Beispiel der Endung “.js”:

---

STALE | Kerberos Armoring

Kerberos Armoring is an optimization of the Kerberos protocol. It avoids the pre-authentication steps and thereby prevents pre-authentication attacks.
It is supported only starting Windows Server 2012 DC and Windows 8 workstations.
If Kerberos Armoring is requested for other operating systems (such as Windows 7 or Linux), the Kerberos authentication protocol may refuse to work.

PingCastle-Finding “Kerberos Armoring”

Das “Kerberos Armoring” gibt es somit sowohl für den Kerberos-Client und für den Kerberos-Server (bzw. das sog. “KDC – Kerberos Distribution Center”

ACHTUNG!
Unbedingt vorher von allen Domain-Controllern einen SnapShot machen, falls etwas schiefgeht und die Anmeldung an Clients/Adminstations oder gar den Domain-Controllern selbst nicht mehr funktionieren sollte!

Für die Kerberos-Clients können zwei GPOs angelegt werden, sodass man für die Aktivierung (gerade, wenn es produktive ADs betrifft) etwas flexibler ist:

• S-C-PO-AT-SY-Kerberos_Armoring_v1.0
• C-C-PO-AT-SY-Kerberos_Armoring_v1.0

---

Für den Kerberos-Server (das sind die Domain-Controller) reicht dann eine GPO aus:

• S-C-PO-AT-SY-Kerberos_Armoring-on-DC_v1.0

---

Sofern der Betrieb mit beiden GPOs problemlos verläuft, kann die Stufe auf den DCs verstärkt werden:

---

STALE | Presence of Service accounts without AES support

Laut Finding wird hier der Account “Administrator” bemängelt:

---

Konten werden aufgelistet, wenn:

1. nach der ersten Installation des Windows Server 2008 Domänencontrollers keine Kennwortänderung erfolgt ist, um AES-Geheimnisse zu initialisieren, oder
2. sie über einen SPN verfügen und das Konto nicht dafür gekennzeichnet ist, AES zur Verschlüsselung zu verwenden (msDS-SupportedEncryptionTypes).

Also in diesem Fall

1. Das Kennwort des ursprünglichen “Administrator”-Accounts ändern
2. Beim “Administrator”-Account die Checkboxen bei “This account supports Keberos AES XXX encryption” setzen:

---

Hinweis:
Bei gMSA-Accounts muss die Einstellung manuell im LDAP-Attribut “msDS-SupportedEncryptionTypes” gemacht werden

PRIVILEGED ACCOUNTS | OU without the accidental deletion protection have been found

In der Regel wird hier eine OU bemängelt: Die OU “Domain-Controllers” ist nicht gegen versehentliches Löschen geschützt.

Mittels PowerShell lassen sich (gerade in einer bestehenden AD) alle OUs auflisten, die nicht geschützt sind:

Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | format-table Name,ProtectedFromAccidentalDeletion

Und anschließend umstellen, sodass sie geschützt sind:

Get-ADOrganizationalUnit -filter {name -like "*"} -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

---

ANOMALIES | The PowerShell audit configuration is not fully enabled

Hier kann ganz einfach die Audit-GPO “A-C-PO-WS-SS-XX_AUDIT-SETTINGS_v1.0” aus dem Schritt “ANOMALIES | The audit policy on domain controllers does not collect key events” erweitert werden:

---

ANOMALIES | Authenticated Users can create DNS records

Genauer technischer Hintergrund:

Technical explanation:

When a computer is joined to a domain, a DNS record is created in the DnsZone to allow the computer to update its DNS settings.
By design, Microsoft choose to grant to the group Authenticated Users (aka every computers and users) the right to create DNS records.
Once created, only the owner keeps the right to edit the new object.

The vulnerability is that specific DNS records can be created to perform man-in-the-middle attacks.
One example is to create a wildcard record (a record with the name “*”), a failover DNS record or anticipating the creation of a DNS record with the right permissions.

Die Empfehlung ist hier also von “Authenticated Users” auf “Domain Computers” umzustellen:

---

Sofern ein DHCP-Server eingesetzt wird, muss dieser aber auch berechtigt werden, die DNS-Einträge für die Geräte anzupassen, denen er IP-Adresse vergeben hat – insbesondere bei Geräten, die (noch) nicht in der AD sind, können die DNS-Einträge sonst nicht erstellt werden (ein Gerät, welches nicht in der AD ist, ist folglich auch nicht in der AD-Gruppe “Domain Computers”).

ANOMALIES | Anonymous Binding to the rootDse is enabled

Um nur noch Binds zu ermöglichen, welche authentifiziert sind, muss mittels des Tools “ADSI-Edit” in der Configuration eine Ergänzung durchgeführt werden.

Hierzu den “ADSI-Edit” starten und auf den Naming Context “Configration” verbinden, dann im Pfad “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=TEST,DC=adloc” das Attribut “msDS-Other-Settings” bearbeiten und die Zeile hinzufügen:

DenyUnauthenticatedBind=1

Hier als Screenshot:

---

ANOMALIES | DsHeuristics has not been set to enable the mitigation for CVE-2021-42291

Eine LDAP-Sicherheitslücke aus dem Jahr 2021, welche immer noch händisch behoben werden muss. Typischerweise ist das Attribut hierfür leer und muss mit einer Zahlenkombination aufgefüllt werden, welche in verschiedenen Artikeln genauer beschrieben wird:

• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e5899be4-862e-496f-9a38-33950617d2c5
• https://support.microsoft.com/en-au/topic/kb5008383-active-directory-permissions-updates-cve-2021-42291-536d5555-ffba-4248-a60e-d6cbc849cde1
• [MITRE]T1187 Forced Authentication

Also einfach hierzu den “ADSI-Edit” starten und auf den Naming Context “Configration” verbinden, dann im Pfad “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=TEST,DC=adloc” das Attribut “dSHeuristics” bearbeiten und den Wert hinzufügen: 00000000010000000002000000011

Entsprechend ändert sich die Findings-Tabelle:

---

ANOMALIES | The PreWin2000 compatible group contains “Authenticated Users”

Hierfür in die “AD Users and Computers”-Konsole gehen und in der AD-Gruppe “Pre-Windows 2000 Compatible Access” die “Authenticated Users” entfernen. In der Regel sollte die Gruppe “Pre-Windows 2000 Compatible Access” leer sein.

---

ANOMALIES | No GPO has been found which implements NetCease

Technischer Hintergrund hierzu:

By default, Windows computers allow any authenticated user to enumerate network sessions to it.
This means an attacker could enumerate network sessions to a file share hosting home directories or a Domain Controller to see who’s connected to SYSVOL (to apply Group Policy) and determine which workstations each user and admin account is logged into.
Bloodhound uses this capability extensively to map out credentials in the network.

Disabling Net Session Enumeration removes the capability for any user to enumerate net session info.

PingCastle-Finding “NetCease”

Lösungsweg ist:

1. Das PowerShell-Skript https://github.com/p0w3rsh3ll/NetCease ausführen
2. Eine GPO erstellen, welche einen Registry-Wert setzt:
   • Pfad: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity\
   • Item: SrvsvcSessionInfo

Hier ein Screenshot der GPO “A-C-PR-WS-RY_NetCease_NetSessionHardening_v1.0” aus meiner Umgebung:

---

ANOMALIES | No password policy for service accounts found (MinimumPasswordLength >=20)

Die Passwort-Richtlinien mögen für Benutzeraccounts und ggfs. für Administratoren-Accounts in Ordnung sein aber für Benutzeraccounts, die als Service-Account fungieren, sollte das Password mindestens 20 Zeichen lang sein.

Während die Passwort-Richtlinien per GPO für alle Accounts gleich sind, können mit den sog. “PSO = Password Setting Objects” sehr feingranulare Richtlinien eingestellt werden.

Im Active Directory die AD-Gruppe “PSO-04-SeviceAccounts” anlegen, hier kommen später alle Benutzer-Konten rein, welche als Service-Account verwendet werden sollen.
Anschließend das Tool “Active Directory Administrative Center” starten und auf der linken Seite in den AD-Pfad “Name-der-AD (local) > System > Password Settings Container” gehen, dort dann eine neue Richtlinie anlegen und nach eigenen Vorstellungen (und eben mind. 20 Zeichen Passwort-Länge) anlegen, dabei die AD-Gruppe “PSO-04-SeviceAccounts” hinterlegen:

PingCastle | Endstand – 00/100 inkl. Informative-Findings

Jetzt sollten Dashboard und Matrix folgendes anzeigen:

---