Dies ist der erste Teil einer Serie, in der unsichere Standardeinstellungen in Active Directory untersucht werden. Dieser Teil behandelt die Pre-Windows 2000 Compatible Access-Gruppe. Was ist das? überhaupt Welche Risiken gibt es? Und was kann man dagegen tun?
Für diese Übung habe ich eine brandneue Preview von Windows Server 2025 mit Active Directory eingerichtet, um sicherzustellen, dass wir die neueste (und hoffentlich beste) Version haben. Dann werde ich PingCastle verwenden, um Fehlkonfigurationen zu finden und zu versuchen, sie zu beheben. Diese Standardeinstellungen sind in vielen Umgebungen üblich, die nicht speziell gehärtet wurden. Wenn das AD aus irgendeinem Grund grundlegend überarbeitet wird, ist es entscheidend, diese Schwachstellen von Anfang an anzugehen.
Posts in dieser Serie
Was ist Pre-Windows 2000 Compatible Access?
Active Directory, wie wir es kennen, wurde mit Windows 2000 eingeführt. Zuvor gab es bereits ähnliche Funktionalitäten, aber sie waren viel begrenzter. Ein Unterschied besteht darin, dass es keine hierarchische Struktur war, sondern flach. Das bedeutet, dass jeder alle Attribute jedes Objekts lesen konnte. Active Directory begrenzt dies. Ein normaler User kann nicht mehr sensible Attribute anderer User lesen, wie das pwdLastSet-Attribut. Das Problem war und ist, dass einige Anwendungen Zugriff auf diese Informationen benötigen. Deshalb führte Microsoft die Pre-Windows 2000 Compatible Access-Gruppe ein, die wieder Leseberechtigungen für alle Attribute aller Objekte gewährt. Und um sicher zu gehen, wurden Authentifizierte Users dieser Gruppe hinzugefügt. Und das ist immer noch der Standard im Windows Server 2025, etwa 25 Jahre nach Windows 2000.
Welche Risiken gibt es?
PingCastle meldet diese Schwachstelle nur als informativ. Ich finde das ein wenig zu niedrig, denn wenn Authenticated Users nicht in dieser Gruppe sind, kann es für Angreifer sehr ärgerlich sein. Wie bereits gesagt, ist eines der interessanten Attribute, das ein Angreifer nicht mehr lesen kann, pwdLastSet. Das bedeutet, es wird für Angreifer viel schwieriger, Konten mit alten und möglicherweise schwachen Passwörtern zu finden. Deshalb empfehle ich wirklich, diese Schwachstelle zu beheben.
Es gibt jedoch einen wichtigen Punkt! Da dies eine Standard-Schwachstelle in AD ist, verlassen sich einige Tools auf diese „Funktionalität“. Deshalb sollte dies nicht einfach schnell an einem Freitagnachmittag geändert werden. In großen Umgebungen könnte es sogar ganz unmöglich sein, dies zu ändern. Es wird viel Testarbeit erforderlich sein und spezifische Konten müssen erneut zu dieser Gruppe hinzugefügt werden.
Wie kann man es beheben?
Die Lösung ist einfach: Einfach die Authenticated Users aus der Pre-Windows 2000 Compatible Access-Gruppe entfernen. Zumindest wenn die Umgebung leer ist wie meine. Wie oben gesagt, wird dies abhängig von der Größe der Umgebung viel Testarbeit erfordern. Aber lassen wir uns schauen, was passiert. Unten können wir die Informationen sehen, die ein normaler User über einen anderen User in der Standardeinstellung erhalten kann.
PS C:\Users\alice> Get-ADUser bob -Properties *
AccountExpirationDate :
accountExpires : 9223372036854775807
AccountLockoutTime :
AccountNotDelegated : False
AllowReversiblePasswordEncryption : False
AuthenticationPolicy : {}
AuthenticationPolicySilo : {}
BadLogonCount : 0
badPasswordTime : 0
badPwdCount : 0
CannotChangePassword : False
CanonicalName : vidrasec.lab/Users/bob
Certificates : {}
City :
CN : bob
codePage : 0
Company :
CompoundIdentitySupported : {}
Country :
countryCode : 0
Created : 4/19/2024 12:35:21 AM
createTimeStamp : 4/19/2024 12:35:21 AM
Deleted :
Department :
Description :
DisplayName : bob
DistinguishedName : CN=bob,CN=Users,DC=vidrasec,DC=lab
Division :
DoesNotRequirePreAuth : False
dSCorePropagationData : {12/31/1600 4:00:00 PM}
EmailAddress :
EmployeeID :
EmployeeNumber :
Enabled : True
Fax :
GivenName : bob
HomeDirectory :
HomedirRequired : False
HomeDrive :
HomePage :
HomePhone :
Initials :
instanceType : 4
isDeleted :
KerberosEncryptionType : {}
LastBadPasswordAttempt :
LastKnownParent :
lastLogoff : 0
lastLogon : 0
LastLogonDate :
LockedOut : False
logonCount : 0
LogonWorkstations :
Manager :
MemberOf : {}
MNSLogonAccount : False
MobilePhone :
Modified : 4/19/2024 12:35:21 AM
modifyTimeStamp : 4/19/2024 12:35:21 AM
msDS-User-Account-Control-Computed : 0
Name : bob
nTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=vidrasec,DC=lab
ObjectClass : user
ObjectGUID : 00045a31-db0a-43a2-81b3-030b71475f3e
objectSid : S-1-5-21-3820918346-3820853946-976116511-1105
Office :
OfficePhone :
Organization :
OtherName :
PasswordExpired : False
PasswordLastSet : 4/19/2024 12:35:21 AM
PasswordNeverExpires : False
PasswordNotRequired : False
POBox :
PostalCode :
PrimaryGroup : CN=Domain Users,CN=Users,DC=vidrasec,DC=lab
primaryGroupID : 513
PrincipalsAllowedToDelegateToAccount : {}
ProfilePath :
ProtectedFromAccidentalDeletion : False
pwdLastSet : 133579857214640950
SamAccountName : bob
sAMAccountType : 805306368
ScriptPath :
sDRightsEffective : 0
ServicePrincipalNames : {}
SID : S-1-5-21-3820918346-3820853946-976116511-1105
SIDHistory : {}
SmartcardLogonRequired : False
State :
StreetAddress :
Surname :
Title :
TrustedForDelegation : False
TrustedToAuthForDelegation : False
UseDESKeyOnly : False
userAccountControl : 512
userCertificate : {}
UserPrincipalName : bob@vidrasec.lab
uSNChanged : 16438
uSNCreated : 16433
whenChanged : 4/19/2024 12:35:21 AM
whenCreated : 4/19/2024 12:35:21 AM
Nachdem alle Konten aus der Pre-Windows 2000 Compatible Access-Gruppe entfernt wurden, konnten nur sehr begrenzte Informationen über den User Bob eingesehen werden. Bei mir hat es circa 10 Minuten gedauert bis diese Einstellung wirksam wurde. Dies ist die Ausgabe des Get-ADUser-Befehls nach der Änderung (und 10 Minuten warten):
PS C:\Users\alice> Get-ADUser bob -Properties *
AccountExpirationDate :
accountExpires :
AccountLockoutTime :
AuthenticationPolicy : {}
AuthenticationPolicySilo : {}
BadLogonCount :
CannotChangePassword : False
CanonicalName :
Certificates : {}
City :
CN : bob
codePage : 0
Company :
CompoundIdentitySupported : {}
Country :
countryCode : 0
Created :
Deleted :
Department :
Description :
DisplayName : bob
DistinguishedName : CN=bob,CN=Users,DC=vidrasec,DC=lab
Division :
EmailAddress :
EmployeeID :
EmployeeNumber :
Fax :
GivenName : bob
HomeDirectory :
HomeDrive :
HomePage :
HomePhone :
Initials :
instanceType :
isDeleted :
KerberosEncryptionType : {}
LastBadPasswordAttempt :
LastKnownParent :
LastLogonDate :
LogonWorkstations :
Manager :
MemberOf : {}
MobilePhone :
Modified :
Name : bob
nTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=vidrasec,DC=lab
ObjectClass : user
ObjectGUID : 00045a31-db0a-43a2-81b3-030b71475f3e
objectSid : S-1-5-21-3820918346-3820853946-976116511-1105
Office :
OfficePhone :
Organization :
OtherName :
PasswordLastSet :
POBox :
PostalCode :
PrimaryGroup : CN=Domain Users,CN=Users,DC=vidrasec,DC=lab
primaryGroupID : 513
PrincipalsAllowedToDelegateToAccount : {}
ProfilePath :
ProtectedFromAccidentalDeletion : False
SamAccountName : bob
sAMAccountType : 805306368
ScriptPath :
sDRightsEffective : 0
ServicePrincipalNames : {}
SID : S-1-5-21-3820918346-3820853946-976116511-1105
SIDHistory : {}
State :
StreetAddress :
Surname :
Title :
userCertificate : {}
UserPrincipalName : bob@vidrasec.lab
Fazit
Meiner Meinung nach ist dies eine sehr wichtige Sicherheitsmaßnahme. Besonders wenn das AD komplett neu aufgebaut werden muss, sollte damit begonnen werden! Am Anfang ist dies noch einfach zu implementieren.
Wer mehr zu diesem Thema lesen möchte, findet viele großartige Informationen in diesem Beitrag: https://www.semperis.com/blog/security-risks-pre-windows-2000-compatibility-windows-2022/
Ich werde weiterhin empfohlene Sicherheitsmaßnahmen für Active Directory erklären. Bei weiteren Fragen oder Interesse an einem Active Directory Audit oder Penetrationstest, wie immer, einfach kontaktieren!