Active Directory Machine Account Quota (ms-DS-MachineAccountQuota): Der Standardwert, der jedem Benutzer erlaubt, einen Computer hinzuzufügen

Active Directory Machine Account Quota (ms-DS-MachineAccountQuota): Die Grundlagen

Das Active Directory Machine Account Quota — das Attribut ms-DS-MachineAccountQuota, gespeichert direkt am Domänenobjekt — steht standardmäßig auf 10, und zwar in jeder Domäne. Das bedeutet: Jeder authentifizierte Domänenbenutzer kann ohne jegliche delegierten administrativen Rechte von Haus aus bis zu zehn neue Computerkonten der Domäne hinzufügen. Das gilt seit der Einführung des Attributs mit Windows 2000 Server und ist bis heute der Auslieferungswert neu erstellter Domänen — sofern ein Administrator ihn nicht explizit gehärtet hat.

Ein Microsoft-Ingenieur dokumentierte diesen Standardwert bereits 2005 unverblümt im firmeneigenen TechNet-Blog: „Most of you know the limit of 10 times authenticated users can join machines to a domain" („Die meisten von Ihnen kennen das Limit von 10, mit dem authentifizierte Benutzer Rechner einer Domäne hinzufügen können") und beschrieb ms-DS-MachineAccountQuota als die Eigenschaft des Domänenobjekts, die dies steuert und über ADSI Edit bearbeitet werden kann. Microsofts aktuelle Referenz zur Sicherheitsrichtlinie für das zugehörige Benutzerrecht Add workstations to domain (SeMachineAccountPrivilege) bestätigt dieselbe Zahl von der Rechte-Seite: „A user who is assigned this user right can add up to 10 workstations to the domain" („Ein Benutzer mit diesem Recht kann bis zu 10 Workstations der Domäne hinzufügen") — und dass dieses Recht auf Domänencontrollern standardmäßig der Gruppe Authenticated Users zugewiesen ist.

Warum der Standardwert allein nicht die ganze Geschichte erzählt

Es gibt einen zweiten, vom Kontingent unabhängigen Pfad, den man kennen sollte, bevor man dies „behebt": Microsofts eigene Dokumentation weist darauf hin, dass „users can also join a computer to a domain if they have the Create Computer Objects permission for an organizational unit (OU) or for the Computers container" („Benutzer können einem Computer auch dann der Domäne hinzufügen, wenn sie die Berechtigung Create Computer Objects für eine Organisationseinheit (OU) oder den Computers-Container besitzen"), und dass Benutzer mit dieser delegierten Berechtigung „can add an unlimited number of devices to the domain regardless of whether they have the Add workstations to domain user right" („eine unbegrenzte Anzahl von Geräten der Domäne hinzufügen können, unabhängig davon, ob sie das Benutzerrecht Add workstations to domain besitzen"). Das Kontingent auf null zu setzen bewirkt bei einem Konto, das bereits über delegierte Create Computer objects-Rechte auf einer OU verfügt, gar nichts — beide Mechanismen müssen gemeinsam überprüft werden. Genau deshalb taucht diese Einstellung noch Jahre nach ihrer ersten Dokumentation immer wieder in gängigen Reviews von Active-Directory-Sicherheitsfehlkonfigurationen auf.

Warum ein Self-Service-Computerkonto ein Fußabdruck ist

Ein Computerkonto ist kein Spielzeugobjekt. Es ist ein vollwertiges Sicherheitsprinzipal mit eigener SID und einem Passwort, das der Ersteller wählt (oder ein Tool generiert) — standardmäßig landet es im CN=Computers-Container und gehört dem Ersteller, nicht den Domain Admins. Für sich genommen trägt es keine besonderen Privilegien. Was es tatsächlich liefert, ist eine domänen-gejointe Identität, die der Angreifer vollständig kontrolliert — genau die fehlende Voraussetzung für mehrere Delegation-Abuse-Techniken, die an anderer Stelle in diesem Katalog bereits behandelt werden, allen voran der Missbrauch von Resource-Based Constrained Delegation (RBCD) und die breitere Angriffsfläche von Computerobjekten.

Um dieses Konto zu erstellen, braucht es nichts weiter als einen Standard-Domänenbenutzer und ein Kontingent über null. Öffentliche Tools machen daraus eine Zeile Code, dokumentiert unter anderem in Community-Referenzen wie der MachineAccountQuota-Seite von The Hacker Recipes:

# Impacket — Erstellung eines Computerkontos über SAMR
addcomputer.py -computer-name 'PWN01$' -computer-pass 'P@ssw0rd123!' \
  -dc-host dc01.corp.local corp.local/lowpriv:'Password1'

# Powermad — dasselbe Ergebnis über LDAP von einem domänen-gejointen Windows-Host
New-MachineAccount -MachineAccount PWN01 -Password (ConvertTo-SecureString 'P@ssw0rd123!' -AsPlainText -Force)

bloodyAD und Certipy account create bieten dieselbe Primitive über LDAP für Operatoren, die ein plattformübergreifendes Tool bevorzugen. Keines davon erfordert erhöhte Rechte — nur das Standard-ms-DS-MachineAccountQuota von 10.

Die Angriffskette: Von einem kostenlosen Computerkonto zum Delegation Abuse

Schritt 1 — Prüfen, ob das Kontingent ausnutzbar ist

Eine schnelle anonyme oder authentifizierte LDAP-Abfrage gegen das Domänenobjekt liefert den aktuellen Wert:

ldapsearch -x -H ldap://dc01.corp.local -D 'corp\lowpriv' -w 'Password1' \
  -b 'DC=corp,DC=local' -s base '(objectClass=domain)' ms-DS-MachineAccountQuota

Ist der zurückgegebene Wert größer als null und unterliegt das abfragende Konto keiner weiteren Einschränkung, ist die Self-Service-Computererstellung verfügbar.

Schritt 2 — Ein vom Angreifer kontrolliertes Computerkonto erstellen

Mit einem der oben genannten Tools verbraucht der Angreifer eine Einheit seines eigenen Kontingents, um ein Maschinenkonto zu erstellen. Diese einzelne Aktion erzeugt eine Maschinen-SID mit bekanntem Passwort — eine Identität, die einen Moment zuvor noch nicht existierte und die von Domain Admins weder bereitgestellt noch geprüft oder genehmigt wurde.

Schritt 3 — Übergang zu Delegation Abuse

Das neu erstellte Computerkonto ist für sich genommen nicht privilegiert — aber es wird zur kontrollierten Identität, über die RBCD- und NTLM-Relay-Ketten laufen. Bei Relay-Szenarien werden Coercion-Techniken (z. B. im Stil von PetitPotam mit erzwungener Authentifizierung) genutzt, um die NTLM-Authentifizierung eines Opfers an LDAP/LDAPS eines Domänencontrollers zu relayen; Impackets ntlmrelayx.py kann dann mit der Option --delegate-access über diese relayte Session ein Computerkonto erstellen und im selben Schritt msDS-AllowedToActOnBehalfOfOtherIdentity am relayten Ziel konfigurieren, sodass das neue Computerkonto beliebige Benutzer gegenüber diesem Ziel via S4U2Self/S4U2Proxy imitieren kann — eine einzelne relayte Authentifizierung wird so zu dauerhaftem RBCD-Zugriff. Die vollständige Mechanik von RBCD selbst sowie die breitere Palette an Möglichkeiten, wie Attribute und ACLs eines Computerobjekts missbraucht werden, sind in den beiden oben verlinkten Artikeln behandelt; das Machine Account Quota ist die Einstellung, die den Angreifern überhaupt erst das kontrollierte Computerobjekt liefert, das diese Ketten benötigen.

Erkennung

# Aktueller Kontingentwert
Get-ADObject (Get-ADDomain).DistinguishedName -Properties ms-DS-MachineAccountQuota

# Über den Self-Service-Kontingentpfad erstellte Computerobjekte (mS-DS-CreatorSID befüllt)
Get-ADComputer -Filter * -Properties ms-DS-CreatorSID |
    Where-Object { $_.'ms-DS-CreatorSID' } |
    Select-Object Name, DistinguishedName, ms-DS-CreatorSID

Legitimes Provisioning baselinen

Legitime Provisioning-Tools laufen in der Regel unter dedizierten Dienstkonten, die Maschinen nach einem vorhersehbaren Zeitplan in eine bekannte OU joinen. Jedes 4741-Ereignis, bei dem der SubjectUserName ein normales Endbenutzerkonto ist oder das resultierende Computerobjekt außerhalb dieser OU landet, verdient einen Blick — unabhängig vom Volumen.

Remediation

1. Das domänenweite Kontingent auf null setzen. Das ist die wirkungsvollste Einzelmaßnahme:

   Set-ADDomain -Identity corp.local -Replace @{'ms-DS-MachineAccountQuota'='0'}
   

   Mit der obigen Get-ADObject-Abfrage verifizieren.

2. Das Benutzerrecht „Add workstations to domain" neu zuweisen. Gemäß Microsofts eigener Sicherheitsrichtlinien-Empfehlung: aus der Default Domain Controllers Policy von Authenticated Users entfernen und SeMachineAccountPrivilege nur einer dedizierten Provisioning-Gruppe gewähren. Das Kontingent allein schließt diese Tür nicht — das Benutzerrecht ist das zweite Tor, und Microsofts eigene Anleitung stuft es als „moderate vulnerability" ein, wenn es bei Authenticated Users belassen wird.

3. Create Computer objects eng delegieren. Nur auf einer dedizierten Computer-OU gewähren, nur an das Konto oder die Gruppe, die tatsächlich Maschinen provisioniert (Imaging-Dienstkonto, SCCM, Intune Hybrid Join) — nie an Authenticated Users oder Domain Users. Diese delegierte Berechtigung umgeht das Kontingent vollständig, daher zählt der Scope mehr als die Zahl.

4. Bei Event ID 4741 in Kombination mit befülltem mS-DS-CreatorSID alarmieren, insbesondere wenn Computerobjekte außerhalb der erwarteten Provisioning-OU landen.

5. Nach Domänenmigrationen oder Neuaufbauten erneut prüfen. ms-DS-MachineAccountQuota wird pro Domänenobjekt gesetzt; eine neu heraufgestufte oder migrierte Domäne führt den Standardwert von 10 wieder ein, sofern er nicht erneut explizit gehärtet wird.

Die Behebung verifizieren

Nachdem das Kontingent auf null gesetzt und das Benutzerrecht neu zugewiesen wurde, bestätigen Sie, dass die Änderung tatsächlich greift, indem Sie einen Domain-Join von einem Standard-, nicht-delegierten Testkonto versuchen — er sollte mit einem Zugriff-verweigert-Fehler fehlschlagen. Führen Sie die Get-ADObject-Abfrage aus dem Erkennungsabschnitt erneut aus, um den gespeicherten Wert zu bestätigen, da eine Verzögerung bei der GPO-Verteilung eine Änderung sonst angewendet erscheinen lassen kann, bevor sie jeden Domänencontroller erreicht hat.

🚨 Gefahr: Domain Admins, und jedes Konto mit separat delegierten Create Computer objects-Rechten, sind nie durch das Kontingent begrenzt. Es auf 0 zu setzen ist notwendig, aber nicht ausreichend — kombinieren Sie es mit den oben genannten Änderungen am Benutzerrecht und an der Delegation.

Diese Einstellung ist genau die Art von Ein-Attribut-Prüfung, die in ein wiederkehrendes Active-Directory-Sicherheitsaudit gehört statt in eine einmalige Behebung, da sie bei jeder neu erstellten oder migrierten Domäne still auf ihren Standardwert zurückfällt.

Wie EtcSec dies erkennt

EtcSecs Active-Directory-Audit markiert ein über null liegendes ms-DS-MachineAccountQuota als Machine Account Quota Elevated Above Default und verfolgt Ausnutzungsbedingungen separat als Machine Account Quota Abuse, wobei der aktuelle Kontingentwert mit Delegation- und Computerobjekt-Findings wie Computer RBCD und RBCD Abuse korreliert wird — so wird die Kette von „jeder Benutzer kann einen Computer hinzufügen" bis „jeder Benutzer kann ein privilegiertes Prinzipal auf einem Zielhost imitieren" als ein einziger Angriffspfad sichtbar gemacht statt als vier unabhängige Findings.