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

• Nirmal@DynamicPacks.net
• April 8, 2024
• No Comments

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 and covering all other Risky Items in Active Directory.

It’s important to realize 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 tool 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.

NOTE: 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. I will experiment with low-level or system attributes connected to important objects if I need to access Active Directory. I would essentially try to alter the value of an attribute on a important object in Active Directory.

What are common Risky Items in Active Directory?

Several aspects of Active Directory (AD) can pose security risks if not properly managed or secured. Here are some common risky items in Active Directory:

1. Weak Password Policies: Inadequate password policies, such as short or easily guessable passwords, can make user accounts vulnerable to brute-force attacks and unauthorized access.
2. Stale User Accounts: Unused or inactive user accounts that are not regularly monitored or disabled pose a security risk as they may be exploited by attackers to gain unauthorized access to the network.
3. Privileged Accounts: Accounts with elevated privileges, such as domain administrators or service accounts, are lucrative targets for attackers. Compromised privileged accounts can lead to widespread damage and unauthorized access to critical systems and data.
4. Overly Permissive Permissions: Excessive permissions granted to users, groups, or service accounts can result in unauthorized access to sensitive data, resources, or administrative functions.
5. Unsecured Group Policies: Misconfigured or insecure Group Policy Objects (GPOs) can lead to unintended consequences such as security policy bypass, exposure of sensitive information, or unauthorized system changes.
6. Lack of Monitoring and Auditing: Inadequate logging and monitoring of AD activities can hinder the detection of security incidents, unauthorized access attempts, or changes to critical configurations.
7. Outdated Software and Patch Management: Failure to regularly update and patch AD infrastructure components, including domain controllers and supporting systems, can leave the environment vulnerable to known security vulnerabilities and exploits.
8. Misconfigured Trust Relationships: Improperly configured trust relationships between domains or forests can create security weaknesses that attackers may exploit to gain unauthorized access or escalate privileges across trust boundaries.
9. Insufficient Backup and Recovery Procedures: Inadequate backup and disaster recovery mechanisms for AD can result in data loss, prolonged downtime, and difficulty restoring the directory to a known secure state in the event of a security incident or system failure.
10. Insecure LDAP and Kerberos Configurations: Weak LDAP and Kerberos authentication configurations, such as allowing insecure authentication protocols or using weak encryption algorithms, can expose AD to credential theft, replay attacks, and man-in-the-middle attacks.

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

Status of Risky Items in Active Directory: 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.

NOTE: 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.

NOTE: 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 = 10
$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: DDP and DDCP are sensitive GPOs for sure, but you should check all GPOs to ensure they have not been modified.

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
• Normal Users and Computer accounts with Privileged SIDs in sIDHistory.
• Attribute: Action attribute value

For example, I would change the UserAccountControl value 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.

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!

If your domain controllers are moved out of the default organizational units, you will see an email notification from SmartProfiler if the Smart Scheduler for Active Directory is configured.

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>”.

Below Active Directory Assessment Dashboard shows risky items status.

We will cover rest of the topics in Part 3 of this article series.

Using SmartProfiler for identifying Sensitive Modification/Creation

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. SmartProfiler follows all recommendations highlighted by ANSSI, Microsoft and MITRE.