In the previous post Part 1 I introduced a way to detect a malicious actor account in the access control list of the domain root. In this post I will show you how to identify persistence and privilege creep on a domain via Group Policy permissions.

Group Policies controls your environment and settings so any control over a GPO linked to a scope of management that covers any computer or user gives the attacker an extremely powerful tool and possibilities to pursue the objectives.

The most obvious locations where you should have monitoring turned on and absolute control of are:

• Domain root
• Domain Controllers organizational unit

Any accounts having control over group policies at these locations owns the domain! These accounts are Tier 0 accounts and should be treated as the same.

If you are not familiar with the Tier Model and Active Directory you must read up on it. For more information on the Tier Model see https://aka.ms/tiermodel

Objectives

• Detect defense evasion via Group Policy Modification (MITTRE ATT&CK T1484)

• Identify gaps in the principle of least privilege NIST AC-6 (5)

GROUP POLICY OBJECTS

Group Polices are objects in Active Directory and has access control list like all the objects in Active Directory.

What are the default permissions of a GPO you might wonder? Here’s the default permissions the group policy gets at creation, this is the value of the DefaultSecurityDescriptor attribute in the Schema of Active Directory:

Dn: CN=Group-Policy-Container,CN=Schema,CN=Configuration,DC=contoso,DC=com
defaultSecurityDescriptor: D:P(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;CO)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED); 

Ok, conclusions on this. The creator of the GPO will get full control and so does the Domain Admins, Enterprise Admins and System. Authenticated users can apply and read the GPO’s by default. The forests domain controllers are assured read access on new GPOs.

ADVANCED HUNTING

Let’s hunt for misconfigurations on GPO’s linked to the Domain Controller OU.

To do that we add the parameter -GPO to ADACLScan.ps1

We want only to see critical permissions.

.\ADACLScan.ps1 -b "OU=Domain Controllers,DC=contoso,DC=com" -GPO -Criticality Critical | ft

The result contains a lot of expected permissions but also missing out an important part of the security decscriptor… The Owner.

Time to filter out expected permissions and include the owner

.\ADACLScan.ps1 -b "OU=Domain Controllers,DC=contoso,DC=com" -GPO -Criticality Critical -SkipDefaults -SkipBuiltIn -Owner | ft

We just identified an attempted Defense Evasion (MITTRE ATT&CK ID:T1484).

The account CONTOSO\APT29 can perform malicious GPO modifications like Scheduled Task, Disabling Security Tools, Remote File Copy, Create Account, Service Execution and more.

Remediation action

Replace the owner on WSUS Patch Schedule 1 with Domain Admins.

Let us continue analyzing the ACL.

WSUS Admins is a group and we need to know what accounts are members and the nested groups. Add -RecursiveFind to the command.

.\ADACLScan.ps1 -b "OU=Domain Controllers,DC=contoso,DC=com" -GPO -Criticality Critical -SkipDefaults -SkipBuiltIn -Owner  -RecursiveFind | ft

We got two admins, Alice and Bob, but who is joe?

It is our disgruntled employee Joe! There is a risk that Joe might take retaliatory actions by disrupting the business or stealing information.

Joe is a member of the SCCM Admins that are nested in to the WSUS Admins group. We do not consider the SCCM Admins as “Tier 0” admins and it should not have control over Domain Controllers.

What we got here is an example of privilege creep. We are not enforcing the principle of least-privilege NIST AC-6 (5) and we should look into our access management process to identify the gap in the process that led to this problem.

Remediation action

1. Remove SCCM Admins from WSUS Admins.
2. Monitor for security group managent events in the security log on the domain controllers.

DETECTION

Besides assessing your GPO’s ACL, you should monitor for changes to group policy objects and privileged groups. Here’s some examples of security events that are generated in your domain controller’s security log.

4662 - Audit Success - Directory Service Access

Changing permissions on a group policy object

5136 - Audit Success - Directory Changes

Modifying the security descriptor on a group policy object. This one is followed up with a Type: Value Deleted event.

4728 - Audit Success - Security Group Management

Adding a member to a global security group.

Summary

We identified two examples of misconfiguration’s in the security descriptor on group policy objects.

First, we identified the persistence created with the account CONTOSO\APT29. Where the adversaries tried to maintain access, with the intention of escalating privileges on the domain and avoid detection throughout their compromise. The problem was the incorrect ownership in the security descriptor on a GPO linked to the domain controller OU.

Secondly, we identified the privilege creep created by inappropriate nesting of security groups. The user joe, a disgruntled employee, had unintentional control over the domain controllers.

Conclusion

Create a clear picture of your current security posture and make sure your SIEM create incidents for modifications of sensitive ACL’s and groups.