Checking Status of Risky Items in Active Directory – Part 2 - Sensitive Objects Modification/Creation (PrimaryGroupIDs and GPO Modifications)

First of all, I would like to express my gratitude to the many of you who have used the SmartProfiler Active Directory Security Console and offered valuable feedback on how to enhance the program's algorithm and help secure the Active Directory environment. Thank you!

In Part 1 of this blog series, we discussed why it is crucial to verify the status of the AdminSDHolder container from several angles and ensure that it is secure. The topic of "Sensitive Objects Modification/Creation" will be the main emphasis of Part 2.

It's important to realise that after Active Directory deployment, a few critical items shouldn't be handled by anybody, not even an administrator. An attacker can still access Active Directory by using these sensitive items, nevertheless. Many Active Directory administrators, in my experience, rely primarily on auditing and event logs when looking for compromise. While auditing and event logs might be helpful when looking for a compromise, they are ineffective in the following two situations:

• The sensitive items would be altered by an attacker using a programme that can do so secretly from the Active Directory Auditing and Event Log subsystem.
• Second, what if Active Directory or domain controllers did not have the necessary audits implemented?

The manipulation of sensitive objects is a sign that an attack has either already been carried out or is now underway. You'll examine any sensitive object creations or modifications made from an object or component's initial default state. For instance, the "guest" is disabled when a new domain controller is introduced. Similar to this, whenever a new domain controller is set up, its computer account is always added to the Domain Controllers OU. Before you can properly determine if an Active Directory has been hacked or not, you need be aware of the default state of a sensitive object.

An attacker would constantly look for a backdoor to Active Directory. The real problem with Active Directory’s design is that an authenticated user has “READ” permission to query information about “99%” of objects in Active Directory and if anonymous access to Active Directory is enabled then a user can read objects without authentication. If I need to access Active Directory, I will experiment with low-level or system attributes connected to important objects. I would try to change the value of an attribute on an important Active Directory object such as Domain Controller or fiddle with the attributes to grant privileged access to a non-domain user.

The Sensitive Objects that an Active Directory Administrator should review are listed below:

• Modification to Sensitive Group Policy Objects.
• Modification to PrimaryGroupID of Users, Computer accounts and domain controllers.
• Domain Controllers were moved out of default OU.
• Normal Users and Computer accounts with Privileged SIDs in sIDHistory.
• Krbtgt account with Resource-based constrained delegation.Privileged Groups membership was modified in last 7 days.
• IMPORTANT: Recently created and deleted privileged accounts with AdminCount=1
• Recent GPOs created and deleted.

Modification to Sensitive Group Policy Objects

When an Active Directory domain is set up, two default GPOs are created: the Default Domain Policy (DDP) and the Default Domain Controllers Policy (DDCP). In an Active Directory system, the DDP and DDCP are regarded as sensitive GPOs since the former applies to all domain objects and the latter to all domain controllers. The Microsoft Active Directory team has implemented required and recommended settings to both policies.

If you need to apply any settings to users and computer accounts, you will essentially need to establish distinct Group Policy Objects for each of your business divisions. Modifying the Default Domain Policy, which is applicable to all users and machines, is never a smart idea. DDP and DDCP must never be altered. However, an attacker is able to change DDP and DDCP GPOs with the right permissions. There are a great number of potential attacks that can stem by modifying DDP and DDCP.

In Active Directory, a GPO is a powerful object. You can control all computers and domain controllers in an Active Directory environment by utilizing Group Policy's extensive set of settings. To change a GPO's settings, all you need is write access and by default, every user has access to read GPOs.

By altering DDCP, an attacker can push a malicious schedule task to all domain controllers or use other malicious code to set up services on domain controllers, create user accounts, and gain access to privileged groups. Given how many user and machine settings GPOs can affect in the Active Directory environment, there are a wide range of potential attacks that could result from misuse of GPOs.

In today's Internet world, you have a lot of mitigation tactics at your disposal to prevent attacks, but there are also tools and utilities that are easily accessible that an attacker can use to push through an attack. A publicly accessible script called New-GPOImmediateTask.PS1, for instance, can be used to automatically create a schedule task by altering the ScheduledTasks.XML file of a GPO. It can also be used to change user rights in the GptTmpl.inf file.

Make sure the default GPOs haven't undergone any recent changes. Adversaries may temporarily change domain policy, perform malicious action(s), and then undo the modification to get rid of any red flags. You can use the PowerShell script below to see if the DDP or DDCP in your domain has recently been modified:

$DaysInactive = 1
$time = (Get-Date).Adddays(- ($DaysInactive))

$STR = "AD Domain, Default Domain GPO Modified Last Date, Domain Controller GPO Modified Last Date"
$STR

$AnyGap = "No"
$Error.Clear()
$DDModifiedLastDate = ""
$DCModifiedLastDate = ""
$ThisDomain = "Micorosft-Assessment.Com"
$AllGPOs = Get-GPO -All -Server $ThisDomain | Select-Object DisplayName, ModificationTime
IF ($Error.Count -eq 0)
{
?? ?ForEach ($Item in $AllGPOs)
?? ?{
?? ??? ?$ModTimeDDP = $Item.ModificationTime
?? ??? ?$ModTimeDDC = $Item.ModificationTime
?? ??? ?
?? ??? ?$DDModifiedLastDate = $ModTimeDDP
?? ??? ?$DCModifiedLastDate = $ModTimeDDC
?? ??? ?
?? ??? ?$GPOName = $Item.DisplayName
?? ??? ?
?? ??? ?IF ($GPOName -eq "Default Domain Policy" -or $GPOName -eq "Default Domain Controllers Policy")
?? ??? ?{?? ??? ??? ?
?? ??? ??? ?IF ($GPOName -eq "Default Domain Policy")
?? ??? ??? ?{
?? ??? ??? ??? ?IF ($Time -lt $ModTimeDDP)
?? ??? ??? ??? ?{
?? ??? ??? ??? ??? ?$TotNo = "WARNING: Modified"
?? ??? ??? ??? ??? ?$AnyGap = "Yes"
?? ??? ??? ??? ?}
?? ??? ??? ?}
?? ??? ??? ?IF ($GPOName -eq "Default Domain Controllers Policy")
?? ??? ??? ?{
?? ??? ??? ??? ?IF ($Time -lt $ModTimeDDC)
?? ??? ??? ??? ?{
?? ??? ??? ??? ??? ?$TotNo = "WARNING: Modified"
?? ??? ??? ??? ??? ?$AnyGap = "Yes"
?? ??? ??? ??? ?}
?? ??? ??? ?}
?? ??? ??? ?
?? ??? ?}
?? ??? ?
?? ?}
}
$AnyGap
$STR = $ThisDomain + "," + $DDModifiedLastDate + "," + $DCModifiedLastDate
$STR        

For the Default Domain Policy and Default Domain Controllers Policy, the script verifies the ModificationTime attribute. AnyGap = Yes in the output indicates that these GPO objects have recently undergone modification.

Note: While DDP and DDCP are undoubtedly sensitive GPOs, you should check all GPOs to make sure they haven't been changed in the last ten days.

Modification to PrimaryGroupID of Users, Computer accounts and domain controllers.

To control access to resources inside and outside of Active Directory, such as when connecting POSIX systems, users' and computer accounts' PrimaryGroupID is used.?The most well-known attack to date, DCShadow, can alter a user's PrimaryGroupID.

NOTE: One of the attacks that DCShadow uses to change the PrimaryGroupID ignores the Windows Event Subsystem and auditing.

The ATTRIBUTE system in Active Directory is crucial for any action that needs to be taken on an object. If an attribute on an object says "1," and "1" means "DO IT," then Active Directory components will simply carry out the action. The catch is that it makes no difference if the action was requested by an administrator or a regular user. Active Directory will verify the "value" of the associated attribute and object as follows if it receives a request:

• Object: Object Name, Class, Object current Status.
• Object’s current system level: IsCriticalSystem, UserAccountControl, PrimaryGroupID attributes
• Action: Modify, delete, add
• Attribute: Action attribute value

For example, I would change the UserAccountControl value of a domain controller computer account to something different than "532480" and make sure it is inconsistent if I wanted to ensure that an Active Directory domain controller is not regarded as an Active Directory domain controller. An inconsistent domain controller will not take part in replication because its UserAccountControl value will cause its PrimaryGroupID to change.

Similarly, the Active Directory gives each user a PrimaryGroupID when they are added to a group. The user's permissions and access to resources in other environments are decided using user's primaryGroupID. In a PrimaryGroupID attack, the attacker modifies a user account's PrimaryGroupID to grant the user privileged access. These rights give the attacker access to any resource or setting with more rights than they previously had.

By default, all users, computer accounts and domain controllers will have a default PrimaryGroupID associated as below:

• User accounts: 513
• Computer accounts: 515
• Domain Controllers: 516

In order to ensure that objects with modified PrimaryGroupID are found and fixed, it is crucial to run a scan on a regular basis. Primary group ID attacks are a growing threat to Active Directory.

It's also important to note that the Active Directory GUIs do not display the users' or computers' current PrimarGroupID. You must determine whether the users', computers', and domain controllers' PrimarGroupIDs have been altered as part of the Active Directory assessment or by running a PowerShell script.

Domain Controllers were moved out of default OU.

Nobody should move the location of the domain controller computer accounts; otherwise, the "controlled" settings from the Default Domain Controllers Group Policy will not apply and the domain controllers will be in an inconsistent state. Domain Controllers must always be in the Domain Controllers OU. As long as you have adequate permissions for the target Ou, moving an object from one Ou to another is simple.

There are some unique settings that are applied from DDCP and are created especially for domain controllers. An attacker can move a domain controller computer account to an OU that has a GPO linked and that GPO contains malicious code that will be pushed to domain controllers. Although many Active Directory administrators and architects are unaware of this kind of attack, it is one of the simplest. You move the domain controller computer account to another OU, and the GPO completes the remaining work on your behalf!

You must make sure that every domain controller is in their default OU in every Active Directory domain. To get all domain controllers, use the Get-ADDomainController command. After that, check the DistinguishedName to make sure the reported path is "OU=Domain Controllers, DC=Domain>,DC=net>".

Using SmartProfiler for identifying Sensitive Modification/Creation

The free SmartProfiler for Active Directory Security Console can scan for sensitive changes and send you an email if there are any problems.

Sensitive changes can be added to a Scheduling Profile with the name "Sensitive Changes Profile". Once the profile is created, you can schedule it to run on a regular basis and receive alerts if SmartProfiler discovers any problems with sensitive AD Tests.

Each test in SmartProfiler comes with a vendor link. The ANSSI framework, for instance, advises checking for test "Kerberos-pre authentication disabled" and ANSSI ID is: vuln1_kerberos_properties_preauth_priv.

Use SmartProfiler for Active Directory without any restrictions, and give us your insightful feedback so we can enhance the programme and make it available to everyone so they can use it to safeguard their Active Directory and Azure AD environments.

We will continue to concentrate on "Sensitive Objects Modification/Creation" and cover the remaining topics in Part 3. "Legacy authentication protocols and security descriptors" will also be covered in Part 3.

Thanks for reading.