This is part six of a seven part series. Check out part 1 Kerberos authentication explained for links to the others.
In part five of this series, we explored how the replication of Configuration naming context (NC) allows for the GoldenGMSA trust attack. Exploring what else is stored in Configuration we find the AD Schema, and this post explores how this schema replication allows a child domain to modify the schema and thereby compromise objects in the parent domain, just as if you were a Schema Admin (a group only existing in the root/parent domain of AD).
Content
Active Directory Schema attack theory
Schema change trust attack – from child to parent
Mitigation and detection
Part 6 conclusion
Active Directory Schema attack theory
According to Microsoft: “The Microsoft Active Directory schema contains formal definitions of every object class that can be created in an Active Directory forest. The schema also contains formal definitions of every attribute that can exist in an Active Directory object”.
One of these attributes is the defaultSecurityDescriptor which “is used to provide default protection on the object if there is no security descriptor specified during the creation of the object”.
Anyone with rights to modify the defaultSecurityDescriptor schema attribute will therefore be able to define ACLs on any newly created objects in the parent domain. Abusing the Schema Admins privileges are commonly known, and possible attacks depend on the object affected. Some examples of these backdoors on different objects are:
Groups
Add members
Users
Reset password
Write SPN, then perform Kerberoasting
Disable Kerberos preauthentication, then perform AS-REP Roasting
Group Policy Objects
Add user logon script and link to Domain Admin OU
Add user to Administrators via Restricted Groups and link to Domain Controllers container
Other than changing the defaultSecurityDescriptor, it is also possible to remove the confidential flag of attributes, more information is available here.
Schema change trust attack – from child to parent
Looking at the Schema container, stored in the Configuration NC, we find that the child domain is not granted rights, but SYSTEM is granted ‘Full control’:
As seen in the previous posts, the Configuration NC is replicated to child domains, which means we can modify the schema.
As shown in the previous posts, ADSIEdit.msc is run with SYSTEM privileges on a child DC. With SYSTEM privileges it would seem possible to modify Configuration Schema objects in the child domain and wait for replication to the parent domain, but modifying a defaultSecurityDescriptor attribute returns the error:
Operation failed. Error code: 0x202b
A referral was returned from the server.
0000202B: RefErr: DSID-030A08E3, data 0, 1 access points
ref 1:
‘9f360445-857a-4815-8f3d-cad43c41272d._msdcs.root.local’
Instead, we found it possible to modify the ACL of the Schema container. The right “Write property (defaultSecurityDescriptor)” is granted to the CHILD\Administrator user on the Schema container and inherited to all classSchema objects:
The right is here seen with ldp.exe:
The ACL is then replicated to the parent domain, and we can then modify defaultSecurityDescriptor of objects in the parent domain. Next, we identify the original defaultSecurityDescriptor:
The original defaultSecurityDescriptor is appended with an ACE string granting ‘GenericAll’, to the SID of the user CHILD\child-user, here we also give the ‘Server’ argument pointing to the parent domain root.local:
Inspecting the User schema class attribute from the root domain, we see the change was successful:
Any new user objects in the parent domain will now have a DACL granting CHILD\child-user the right Full Control:
As explained earlier, this attack can do much more than affect new user objects.
Mitigation and detection
We believe no mitigations exist against this attack because the mitigation would be to prevent replication of Schema in the Configuration NC which we do not believe is possible.
We did not find a way for a parent domain to detect modification of the Schema container ACL. We believe this is because replication is not triggering the SACL. However, detection of this attack may be detected by explicitly setting SACLs on all Schema objects to detect writes to attributes that can be used for compromises, such as ‘defaultSecurityDescriptor’ and ‘searchFlags’.
Part 6 conclusion
In this post, we explained and demonstrated the Schema change trust attack, which allows a child domain to compromise newly created objects in a parent domain. A way of defending against this attack is by using detections.
This is the last post of this series exploring an intra-forest trust attack (within a forest), in part 7 we explore an inter-forest trust attack (between forests) where a trusted forest can be compromised by a trusting forest.