Introduction

In this blog post, we will go over the most recurring (and critical) findings that we discovered when auditing the Active Directory environment of different companies, explain why these configurations can be dangerous, how they can be abused by attackers and how they can be mitigated or remediated.

First, let’s start with a small introduction on what Active Directory is.
Active Directory (AD) is a service that allows organizations to manage users, computers and other resources within a network. It centralizes authentication and authorization mechanisms for Windows devices and applications, making it easier for administrators to control access to network resources, enforce security policies, manage device configuration, etc.

Setting up an AD environment can be simple as it can be difficult depending on the organization’s size and requirements. In any case, AD comes with default settings and configurations that can be considered as dangerous and that may not comply with the security policies of your company. Administrators should be aware of these default configurations and take action to secure their environment by implementing best practices and security measures that align with their organization’s needs and risk appetite.

However, it may be difficult to identify these insecure configurations as they are not always well known to administrators. Moreover, new vulnerabilities may be identified later, as in the case of Active Directory Certificate Services (ADCS) where default templates can be abused to escalate privileges.

In the past two years, we reviewed AD environments of about 40 companies. When reviewing these environments, we noticed that some findings were quite recurrent. Some of these misconfigurations (or default settings) can have a significant impact on the security posture of a company and allow attackers to gain access to privileged accounts or to compromise the entire domain.

Let’s look at the 6 most common misconfigurations that could be abused by attackers to gain access to other systems or to compromise the environment.

Misconfigurations

Administrator accounts are allowed for delegation

In Active Directory, accounts can be delegated by default. This means that an application can act on behalf of a user (Kerberos delegation), impersonate a user anywhere within the forest (unconstrained delegation), or only impersonate the user to a specific service on a specific computer (constrained delegation).

If a delegation has been configured and if an attacker has access to the delegated system or account, they could try to impersonate an administrator account and move laterally or compromise the domain.

We found that, in almost all organizations audited, there was at least one privileged account for which the “This account is sensitive and cannot be delegated” setting was not enabled.

To abuse this default configuration, we first need to enumerate delegations. This can be done by using the Active-Directory PowerShell module:

Get-ADUser -LdapFilter "(&(userAccountControl:1.2.840.113556.1.4.803:=16777216)(msDS-AllowedToDelegateTo=*))"

Thanks to the above command, we know that a constrained delegation has been configured on the IIS account. We can now check the other properties of the IIS account:

Get-ADUser iis -Properties msDS-AllowedToDelegateTo

In this case, we can see that a constrained delegation has been configured on the IIS account to access the CIFS service of the WinServ-2022 server (Figure 2).

If we try to access the server using our low-privileged account, Bob, we get an error (Figure 3). This is expected because our account is not allowed to access this server.

As the IIS account is a service account, we can try to kerberoast the IIS account using Rubeus, for example (Figure 4). A kerberoast attack is a technique that attempts to retrieve the hash of an Active Directory account that has a Service Principal Name (also known as a service account). Note that in this example, we use the “rc4opsec” argument to only kerberoast service account that supports RC4 encryption, which is the default setting (we will go more in details in the “AES encryption not enforced on service accounts” section).

In this case, we were able to get the hash of the IIS account and crack the password using “John the Ripper”, which is “Password123”.

After generating the AES256 representation of the password, we can now use Rubeus to request an HTTP ticket to impersonate the domain administrator and gain access to the WinServ-2022 system. In this example, the HTTP ticket will allow us to run command on the WinServ-2022 server:

As mentioned before, we are allowed to impersonate the Administrator account because the “This account is sensitive and cannot be delegated” setting is not enforced by default.

After requesting and injecting the ticket that is used to impersonate the Administrator account in memory, we can access WinServ-2022 with the Administrator account:

This demonstrates that by compromising a poorly configured service account, any user can gain access to another system with domain administrator privileges. This could have been avoided by enabling the “This account is sensitive and cannot be delegated” setting on privileged accounts (e.g., Domain Admins, etc.), because the Administrator credentials would not be forwarded to another computer for authentication purposes.

The following dsquery command can be used to identify any user where the setting is not enabled:

dsquery * DC=LAB,DC=LOCAL -filter "(&(objectclass=user)(objectcategory=person)(!useraccountcontrol:1.2.840.113556.1.4.803:=1048576))

In this example, if this setting was enabled, the attacker would not have been able to gain access to WinServ-2022 as Administrator:

Another option is to add the accounts to the Protected Users group. The Protected Users is a group introduced in Windows Server 2012 R2. The goal of this group is to protect administrators against credential theft by not caching credentials in insecure ways. Adding accounts to this group will not only prevent any type of Kerberos delegations, but will also prevent:

• CredSSO and Wdigest from being used;
• NTLM authentication;
• Kerberos from using RC4 or DES keys;
• Renewal of TGT beyond a 4-hour lifetime.

Microsoft recommends adding a few users to this group first to avoid blocking all administrators in case of a problem. However, it is useless to add computers and service accounts to this group because credentials will always be present on the host machine.

Note that after adding administrators to this group, some organizations have experienced difficulties connecting to servers using RDP (Remote Desktop Protocol). This is because only the Fully Qualified Domain Name (FQDN) is supported when connecting to servers via RDP when the user has been added to the Protected Users group. In fact, when using an IP address to connect to a server with RDP, NTLM authentication is used instead of Kerberos. However, when the FQDN is used, Kerberos authentication will be used.

AES encryption not enforced on service accounts

When a user requests access to a service in Active Directory, a service ticket is created. This service ticket is encrypted using a specific encryption type and sent to the user. The user can then present this encrypted ticket to the server to access the service. There are different encryption types available, such as DES, RC4 and AES. The encryption type is defined by the msDS-SupportedEncryptionTypes attribute. By default, the attribute is not set and the domain controller will encrypt the ticket with RC4 to ensure compatibility. This could allow an attacker to perform a kerberoasting attack, as previously demonstrated.

This means that if AES encryption is not enabled on service accounts and RC4 is not specifically disabled, an attacker could try to request a Kerberos ticket for a specific SPN (Service Principal Name, which is used to associate a service to a specific account) and brute force its password. Then, if someone can retrieve the cleartext password, they will be able to impersonate the account and access all systems/assets to which the service account has access.

If weak encryption types are allowed, an attacker can try to kerberoast a service account without generating too much suspicious activity in the logs, and gain access to other systems within the environment as described above in the “Administrator accounts are allowed for delegation” section.

To identify the value of the msDS-SupportedEncryptionTypes attribute for all service accounts, the following dsquery command can be used:

dsquery * "DC=lab,DC=local" -filter "(&(objectcategory=user)(servicePrincipalName=*))" -attr msDS-SupportedEncryptionTypes samaccountname distinguishedName -limit 0 | FIND /i /v "KRBTGT" | SORT

It is important to note that if the value is blank or equal to 0, it will be interpreted as RC4_HMAC_MD5.

The msDS-SupportedEncryptionTypes attribute on service accounts should be modified to only allow AES instead of legacy protocols such as RC4 or DES. However, for backward compatibility or to validate everything is functional, the value of the attribute can be set to 28. This means that RC4, AES-128, and AES-256 will be allowed. Note that all clients should support AES encryption if systems are not running Windows 2000, Windows XP or Windows Server 2003.

Finally, after making sure everything is working as expected, the value can be modified to 24 to only allow AES-128 and AES-256, as shown on the following screenshot (Figure 11), or to 16 to only allow AES-256.

Alternatively, you can edit the options of the account and check the following boxes (Figure 12). This will update the msDS-SupportedEncryptionTypes attribute.

If the attribute was set to 16 (meaning that only AES-256 is supported), we would not have been able to kerberoast the IIS account using the rc4opsec argument, as shown in Figure 13.

Moreover, if the rc4opsec argument is not used and the service account only allows AES encryption types, a 4769 event will be generated on the domain controller with the encryption type used (Figure 14). In this case, the encryption type is 0x12 (DES_CBC_MD5 and AES 256) which is not expected as the attribute is set to 0x10 (only AES-256).

A Blue team can use these events to identify kerberoasting activities on service accounts.

Finally, deprecated and insecure encryption types can be disabled via a GPO, as follows:

If an attacker tries to request an RC4 ticket for an account where only AES encryption types are allowed, the kerberoast attack will fail:

Note that the /usetgtdeleg parameter is used to request RC4 ticket for AES accounts.

Print spooler is enabled on Domain Controllers

According to Microsoft, the print spooler is an executable that manages the printing process by retrieving the location of the correct printer driver, loading the driver, scheduling the print job, etc.

In the past few years, the print spooler service has been affected by several zero-day vulnerabilities (such as PrintNightmare) allowing low privileged users to escalate their privilege, as the service is running with system level privileges. Many exploits are available, but we will not focus on these vulnerabilities.

The print spooler service can also be abused to gain access to the key of the kingdom, the hash of the KRBTGT account. By gaining access to the hash of this account, attackers will be able to forge Golden Tickets, meaning that they will gain almost unlimited access to the Active Directory domain (domain controllers, devices, files, etc.). An attacker can also perform a Skeleton Key attack to create persistence in the domain, as an example. This malware will inject itself inside the LSASS process and create a master password that will work for any account in the domain.

Indeed, when an unconstrained delegation has been configured on a server and when the print spooler service is running on at least one domain controller, it is possible to get the credentials of the domain controller where the service is running.

During our audits, we identified that more than 25% of organizations had configured unconstrained delegation on one or multiple machine accounts. In addition, the print spooler service was running on at least one domain controller in 75% of organizations.

Let’s see how an attacker could abuse these dangerous configurations.

First, we must find where an unconstrained delegation has been configured. This can be done using the Get-DomainComputer command from PowerView as follows:

Note that unconstrained delegation is enabled by default and required on domain controllers. In this example, WIN-7I6M16HF63I is the Domain Controller (DC).

We have already compromised the WinServ-2022 server where an unconstrained delegation has been configured. Moreover, the print spooler service is running by default on domain controllers. All the conditions are met to try to retrieve the hash of the KRBTGT account, so let’s give it a try!

We can use Rubeus on WinServ-2022 to extract all Ticket Granting Tickets (TGTs) and display any newly captured TGTs:

On our low privilege machine, we can use MS-RPRN, as an example, to force the domain controller to connect to WinServ-2022.

As expected, we captured a new TGT (Figure 20). The response from the DC contains the domain controller’s computer account Kerberos ticket.

We can now import this TGT to impersonate the DC:

Once the ticket has been imported, we can perform a DCSync attack using SharpKatz to get the KRBTGT hash.

We now have the hash of the KRBTGT account (Figure 22), which means that we successfully compromised the domain.

Thanks to the print spooler service running by default on DCs, we were able to trigger the service and make it authenticate to the WinServ-2022 service.

To mitigate this vulnerability, Microsoft recommends disabling the print spooler service on all domain controllers as a security best practice.

One way to identify domain controllers where the print spooler service is running is by using PingCastle, as shown in Figure 23. In this case, only the spooler module was executed and we can see that the service is active on the DC.

As mentioned above, the recommendation is to disable the print spooler service on domain controllers. This can be done using a GPO that will disable the service:

If the print spooler service was disabled, an attacker would not have been able to force the domain controller to connect to WinServ-2022.

Users can create machine accounts

First of all, let’s define what a machine account in Active Directory is. A machine account (or computer account) is an Active Directory object that represents a computer or a device connected to the domain. Like user accounts, machine accounts have different attributes that store information about the device, can be a member of security groups, can have Group Policies applied, etc.

By default, in Active Directory, everyone can create up to 10 machine accounts in the domain. This is due to the ms-DS-MachineAccountQuota attribute. According to the Microsoft documentation, this attribute is “the number of computer accounts that a user is allowed to create in the domain”.

This setting is defined in the Default Domain Controllers Policy.

Moreover, the current value of ms-DS-MachineAccountQuota can be found using this PowerShell command:

Get-ADObject ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota

In this example, the Default Domain Controller Policy Group Policy Object (GPO) and the attribute have not been modified and Authenticated users can create up to 10 computer accounts (Figure 26 and Figure 27).

To create a new machine account, the PowerMad module, written by Kevin Robertson, can be used as follows:

As expected, after creating 10 machine accounts, the user will no longer be able to create new machine accounts:

There is no attribute indicating the number of accounts already created by one specific user. However, the mS-DS-CreatorSID attribute of computer objects is used to determine how many computer accounts have been created by a specific user.

This information can be retrieved by using the Get-MachineAccountCreator command from the PowerMad module:

It is also possible to check who created a specific machine account by using the Active Directory PowerShell module:

Get-ADComputer MyComputer -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}}

The user who created the machine account will be granted write access to different attributes such as msDS-AllowedToActOnBehalfOfOtherIdentity, ServicePrincipalNames, DnsHostName, and so on.

Tools like KrbRelayUp leverage this default setting to escalate privileges to NT\SYSTEM on a local system. An attacker can also change the msDS-AllowedToActOnBehalfOfOtherIdentity to abuse Resource-Based Constrained Delegation, for example.

If a Public Key Infrastructure (PKI) is present in the domain, an attacker can take advantage of the default Machine certificate template to perform a DCSync attack and dump hashes of all users and computers. Let’s take a look at how an attacker can proceed to retrieve the hashes.

After creating a new machine account, an attacker can modify the ServicePrincipalNames and the DnsHostName attributes. First, we remove the service principal names containing the initial DnsHostName and then we set the DnsHostname attribute to the domain controller FQDN, as follows:

After that, an attacker can request a certificate for the machine account using the Machine template and they will get a certificate for the domain controller. This will allow the attacker to retrieve the NT hash of the domain controller machine account.

The hash can then be used to perform a DCSync attack:

By creating a new computer object, editing its properties and abusing the default Machine template, we were able to dump the hashes of all users. The hashes can then be used to perform a “Pass-the-Hash” attack and move laterally to other systems.

This could have been avoided if some mitigation measures had been put in place.

First, computer objects created using the PowerMad tool will be stored in the Computers container as opposed to other computer objects created by IT administrators. Indeed, they should be put in specific OUs as Group Policies can’t be applied on the container. This can be used to identify any objects created by malicious users.

Moreover, it is recommended to create a new group (or a new account) that will be granted the required permissions to create new machine accounts. This way, only members of this group will be allowed to create new computer objects and malicious users will not be able to perform the attack.

This can be done by modifying the Default Domain Controller Policy. To do so, go to Computer configuration > Policies > Windows Settings > Security Settings > User Right Assignment > Add workstations to domain: Remove the ‘Authenticated Users’ group and add the new group or account previously created.

Authenticated users will no longer be able to create new machine accounts, as shown in Figure 36.

Unchanged GPOs are not reprocessed on Domain Controllers

All domain joined systems refresh and apply applicable group policies at specific intervals.

For security policy settings (https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/security-policy-settings), the Group Policy engine works differently and these settings are automatically re-applied every 16 hours even if the GPO has not been changed.

However, by default, most GPO settings are only applied when they are new or when they have been changed since the last time the client requested them. This could allow an attacker to modify a registry key that is normally managed through a GPO to disable specific security measures, for example.

In the following example, a company enforces the Windows Defender Real-Time Protection through a GPO:

If a user tries to download malicious files, Windows Defender will immediately quarantine the files:

If a user can modify the Windows Defender Real-Time Protection registry key, they will be able to download and run malicious tools on the system. In this case, by setting the value to 1, the user disables the Real-Time Protection feature:

As expected, the Real-Time Protection is now disabled and the user can download malicious files:

To mitigate this vulnerability, it is recommended to ensure that registry and security policy settings defined in GPOs are always enforced and re-applied on systems even if the GPO has not changed. This way, any unauthorized changes made locally will be overridden after 5 minutes to 16 hours.

In the Default Domain Controller policy, under Computer Configuration > Administrative Templates > System > Group Policy, configure the following two settings as follows:

1. Configure security policy processing:
   • Process even if the Group Policy objects have not changed: Enabled
   • Do not apply during periodic background processing: Disabled
2. Configure registry policy processing:
   • Process even if the Group Policy objects have not changed: Enabled
   • Do not apply during periodic background processing: Disabled

The following settings can also be re-applied even if they have not been changed:

• Internet Explorer Maintenance
• IP Security
• Recovery Policy
• Wireless Policy
• Disk Quota
• Scripts
• Folder Redirection
• Software Installation
• Wired Policy

Moreover, enabling auditing for registry operations can help your organization identify suspicious changes.

To audit registry key modification, the “Audit object access” policy needs to be enabled using a GPO (Figure 41).

After that, auditing also needs to be enabled on the registry keys that you want to monitor (Figure 42).

In this case, each time the value of a registry key under Windows Defender is modified, an event will be generated in the Event Viewer and can be used by the Blue team to identify suspicious activities.

Modification to registry keys can now be detected by looking at different event IDs (4656, 4657, 4660 and 4663).

In our example, we can see that the value of the DisableRealTimeMonitoring registry key was changed to 1 instead of 0:

Password policy and least privilege

This section includes recommendations related to the password policy of service accounts and the KRBTGT account.

The recommendations included in this section should be adapted to your company policy, specific use cases and risk tolerance.

Service accounts

During the audits, we noticed that most of the time, there is no password policy for service accounts, allowing administrators to set weak passwords that can be easily brute forced. In a few cases, the password for service accounts was even included in their description.

As shown in the “Administrator accounts are allowed for delegation” section, we cracked the IIS account password because weak passwords are allowed as there is no password policy enforced for service accounts. This could have been prevented by configuring a proper password policy.

For example, Microsoft recommends using passwords of at least 25 characters for service accounts and implementing a process for changing them regularly. Moreover, it is also recommended to use a dedicated Organizational Unit to manage this kind of accounts, making it easier to administrators to manage security settings applied to these accounts.

Finally, we also noticed that some organizations tend to use personal administrator accounts as service accounts. This means that if someone achieves to compromise a service account used by an administrator, they will have all privileges associated to this account. As a best practice, service accounts should only be granted the permissions they need.

KRBTGT account

The KRBTGT account is a default account that exists in all Active Directory domains. Its main purpose is to act as the Key Distribution Center (KDC) service account, which handles all Kerberos requests in the domain. As mentioned above, if an attacker achieves to compromise this account, they will be able to forge Golden Tickets and gain access to domain resources.

We noticed that many organizations do not change the KRBTGT password on a regular basis. Based on 25 audits, we found that the KRBTGT password is changed every 1855 days on average, and two organizations did not change the password for more than 5500 days, that’s over 15 years!

This means that an attacker, who was able to compromise the KRBTGT hash and has not been detected yet, can maintain his access for 5 years on average (if they have not created a backdoor yet).

It is recommended to change the password of the KRBTGT account regularly, for example every 6 months or every year.

Note that the password must be changed twice because the password history value for this account is set to 2. This means that the two most recent passwords will be valid for all already existing tickets. Before changing the password for the second time, best practices recommend waiting at least 24 hours to avoid invalidating existing Kerberos tickets and requiring everyone and everything (computers, servers, service accounts, etc.) to re-authenticate.

However, if you suspect that the KRBTGT account has been compromised by an attacker, the password should also be reset. This will prevent anyone who has access to its hash from generating Golden Tickets, for example.

It is important to keep in mind that changing the KRBTGT password will not ensure the security of your organization. If someone managed to get its hash once, they will probably be able to compromise it a second time if no other security measures are implemented.

Conclusion

In this blog post, we went over the most common misconfigurations and default settings discovered when doing Active Directory assessments of different environments. These configurations can have a significant impact on the security of your organization and allow attackers to gain access to the key of your kingdom.

Therefore, it is important to know your environment. Moreover, there should be a security baseline which should always be followed and reviewed regularly.

• Is this configuration still required?
• Is there any potential risk, any new vulnerabilities associated to this service?
• Is there a more secure approach?

These are some of the questions IT administrators must repeatedly ask themselves to maintain a certain security posture.

Moreover, some tools allow you to perform automatic auditing of your AD environment and identify settings that could put your organization at risk:

• PingCastle: It scans your environment to identify security vulnerabilities and weaknesses. It includes checks for stale objects (legacy protocols, never expiring password, etc.), privileges accounts (Kerberoastable admin accounts, delegations, etc.) and anomalies (print spooler, ADCS, audit policy, etc.).
• BloodHound: It allows you to visualize Active Directory attack paths. It can be used to identify potential security vulnerabilities that could be exploited by an attacker with Domain Users privileges to elevate their privileges to Domain Admins, as an example.
• Testimo: It is a PowerShell Module created by EvotecIT that helps you identify security issues as well as other operational issues. It can also generate HTML reports showing the commands executed, their output, a description and links to external resources.

While PingCastle and Testimo are more defender oriented, BloodHound is more attacker oriented.

In addition to performing regular scans, IT administrators should always keep an eye on newly discovered vulnerabilities, as a configuration that is considered safe can be the cause of a disaster a few years later. Indeed, it is important to note that no tool can guarantee complete security for your AD environment.

NVISO can help you identify and remediate vulnerabilities and weaknesses in your environment by performing an adversary emulation assessment which simulate real-world threats, as an example. These assessments will help you improve your security posture and protect your organization from potential threats.

To learn more about how we can help you, feel free to reach out or to check our website.