Deterring Attackers with Low Effort in Active Directory

Slowing an Adversary’s Attack with Simple Active Directory Hardening


Active Directory Domain Services (AD DS), developed by Microsoft, is a set of services that allow organizations to store directory data such as user accounts, credentials, and other user-specific information.  While AD is a fantastic tool to develop an interconnected network, attackers have targeted AD weaknesses because it contains a plethora of valuable information and potential avenues for privileged access.  After several years of attacking Active Directory environments, I have observed a handful of AD protections that are easily implemented and would slow an attacker’s path.  Each of these hardening activities may not stop an attacker from their objective, but it will likely slow and frustrate a sophisticated attacker.  The more a blue team can slow down an attacker, the more opportunity to detect and to remove the attacker from the environment.


Abusing Active Directory

Before we discuss controls that may frustrate an attacker, we need to understand how attackers are abusing Active Directory.  While there are several ways to abuse AD, three common ways are:

  1. Performing network reconnaissance
    This includes activities such as identifying privileged user accounts and network mapping.

  2. Escalating privileges
    These are activities that often do not require privileged credentials, but allow an attacker to obtain privileged account credentials.  Attacks such as Kerberoasting and AS-REP Roasting are two examples.

  3. Identifying sensitive information and assets
    This activity is usually specific to the targeted organization with the goal of compromising the desired information and/or assets.

In these scenarios, Active Directory can be heavily leveraged to find the information with relative ease.  However, there are ways to slow the progress of these steps and force an attacker to be creative in finding the desired information or gaining privileged credentials.


Frustrating Attackers in Active Directory

There are several techniques that both frustrate and slow down an attacker.  Often, these implementations would force an attacker to attempt techniques that they are not as comfortable with, or require them to be more creative in getting the information that was being targeted.  Either way, this increased the chance that Incident Response could detect me.  A few simple, but effective, hardening techniques that I have seen are:

  1. Denying Active Directory group membership queries
    By default, a standard user in Active Directory can query for groups and users that belong to that group.  However, it is unlikely that someone working in Human Resources will need to query Active Directory group membership.  Restricting this information to users that need access to query Active Directory will slow an attacker’s path.  If restricting all group membership queries is too large of an undertaking, consider restricting the queries of the highly privileged groups such as Domain Admins and Enterprise Admins.  If an attacker needs to locate the privileged user accounts, they will need to be creative instead of performing one simple query from any domain account.

  2. Using non-descript user account names and hostnames
    Active Directory administrators often use a naming convention for user accounts and the hostname of the user's laptop.  However, when the naming convention leverages the name of the employee, identifying specific users and their workstation becomes trivial with Active Directory.  When employee names are used in the account name and hostname, an attacker could simply search LinkedIn for employees that appear to be administrators and likely be able to identify both the user account and workstation easily.  By using a random pattern or obscuring the name in some way, locating the privileged users and their workstation becomes much more difficult.  Security by obscurity is by no means a way of prevention or detection, however, it can be useful to slow an attacker from moving within your Active Directory environment.

  3. Setting fifteen+ character random passwords for service accounts
    This hardening activity may seem obvious, but it is surprising how many organizations have very weak and old passwords set on service accounts.  Attackers target service accounts because they are often overlooked, can be an easy escalation path, and may have the same password for a long period of time.  By setting strong passwords on service accounts, even if an attacker obtains the password hash through a method like Kerberoasting, cracking that password will require much more time and resources.  Additionally, these accounts are likely not being used daily by employees, which allows for strong and random passwords to be set without users needing to remember them.


Final Thoughts

Blue teams often focus heavily on stopping attackers within their environment, and rightly so.  However, while these hardening activities likely will not stop attackers, it will slow an attacker’s progress and provide more opportunities for detection by the Incident Response team.  With the low level of effort required to implement these hardening techniques, the payoff could be massive.

About the Author

Wes Dorman

Wes is a Senior Penetration Tester with Schellman & Company, LLC. Wes specializes in performing technical offensive security assessments such as red teaming, external assessments, web application assessments, and social engineering. With five years of experience in the offensive security field, Wes brings a strong technical background with experience across multiple industries.

More Content by Wes Dorman
Previous Article
Making PCI DSS Compliance Cloud-Native
Making PCI DSS Compliance Cloud-Native

Schellman's David Baca provides an in-depth look at how organizations can use cloud-native tools to meet co...

Next Article
Schellman BRAVO: Serving Our Veterans
Schellman BRAVO: Serving Our Veterans

In partnering with Hire Heroes USA, Schellman BRAVO is an Employee Resource Group committed to serving vete...


First Name
Error - something went wrong!