Active Directory is a nearly ubiquitous service for storing account information like usernames and passwords—and for governing access to servers, services, accounts, and other information on Windows systems. Given its access to highly sensitive credential materials and its deep levels of insight into access rights across a domain, it’s an attractive target for adversaries seeking to compromise credentials, perform reconnaissance, escalate privileges, and exfiltrate data.
In this blog, we’re going to briefly describe from a very high-level some of the common threats that target Active Directory services and offer some equally high-level guidance on security strategies to defend against these and other threats.
Threats to Active Directory
Active Directory is a common target because it houses resources that adversaries need to launch successful campaigns. Active Directory manages the hosts, users, applications, roles, and privileges in an environment and is open to any domain user. By compromising a domain user and obtaining the right permissions, an attacker can leverage Active Directory to perform reconnaissance, move laterally, compromise credentials, access hosts, elevate permissions, and establish persistence.
Adversaries can go after Active Directory using trusted applications and established protocols, often without needing to drop overtly malicious binaries or leverage other conspicuous behaviors. As the skill level of the adversary increases, so too does the difficulty of detecting this type of activity, because the behavior of an experienced adversary typically mirrors legitimate business workflows.
We’re not going to waste a lot of words rehashing research that’s just a mouse-click away. However, we will list a few exemplary Active Directory threat techniques to demonstrate the diversity of threats you’ll need to consider when developing a strategy for protecting Active Directory. The following MITRE ATTACK™ techniques and sub-techniques should serve as a good launch point for deeper research into Active Directory threats.
T1558: Steal or forge a Kerberos Ticket
Kerberos is a common authentication protocol that uses a cryptographic ticketing system to validate the identity of clients and users as they attempt to access services across a network. Put very simply, in Kerberos, users and services need tickets to prove their identities. Kerberos is the default authentication system for Windows environments that leverage Active Directory Domain Services. Since Kerberos plays a significant role in dictating access across Windows domains, adversaries have developed a wide array of techniques designed to steal or forge Kerberos tickets, and these necessarily involve Active Directory because Active Directory and domain controllers play a critical role in the generation and distribution of tickets.
There are two different types of Kerberos tickets, and while a nuanced description of each is out of scope for this article, it’s important to note that those tickets are generated by a domain service known as a Key Distribution Center (KDC). The KDC is located on domain controllers within the Local Security Authority Subsystem Service (LSASS) process. Due to how tickets are generated and how often they are needed, domain controllers are frequently a target for ticket-based attacks.
T1556.001: Modified Authentication Processes: Domain Controller Authentication
One often talked-about method of subverting authentication controls on a Windows domain is a technique called “Skeleton Key,” whereby an adversary with administrative privileges can write a malicious patch into the LSASS and generate a new password for everyone on the domain, enabling them to authenticate to any account using that domain controller.
T1207: Rogue Domain Controller
By setting up a rogue domain controller, adversaries can gain access to—and even modify—sensitive Active Directory data. DCShadow is an attack method that adversaries can leverage to simulate a domain controller and write changes into Active Directory.
T1003.006: OS Credential Dumping: DCSync
DCSync is fundamentally similar to DCShadow, although it involves an adversary impersonating a domain controller in order to trick other domain controllers into sharing password hashes.
Security strategies
What we shared in the previous section is just a small, high-level sample of potential threats against Active Directory. As an attack surface, Active Directory rates highly enough to have its own Mitigation page in the MITRE ATT&CK framework.
MITRE’s mitigation page is just one of the many amazing resources available that you can and should reference as you approach defending your Active Directory deployment. Here are a few steps you can take right away to protect Active Directory in your environment.
Review, monitor, and secure high-privilege accounts.
Accounts with higher privileges enjoy deeper access to sensitive and potentially valuable information. Since attackers frequently target these accounts, they deserve careful monitoring.
It’s a good idea to set up privileged access groups through Azure Active Directory if you’ve joined your on-prem Active Directory deployment to Azure Active Directory. You can configure alerts and notifications related to these users and groups through Privileged Identity Management in Azure Active Directory. Include domain admins, enterprise admins, security admins, and others with elevated privileges—and make sure to receive an alert whenever an account is added to a privileged group. Having data available and easily accessible helps keep these security groups in check.
Deploying Microsoft’s Local Administrator Password Solution (LAPS) is another good idea. LAPS will mitigate pass-the-hash attacks by regularly changing passwords on managed machines. TrustedSec also offers an open source local password management solution called Shared Host Integrated Password System, which fits the same use case.
Secure domain controllers
Block your domain controllers from accessing the internet with group policy objects (GPO) and your firewall whenever possible. Install as little software as possible on your domain controller, including endpoint and patch management solutions. Taking the time to manually update your domain controller with the latest security patches can be a good firebreak in the case of a supply chain attack or other attack that uses endpoint management software as an attack vector.
Ensure your domain controllers are backed up. Perform those backups on a regular basis. Last but certainly not least, make sure you exercise or test your ability to recover those backups semi-regularly.
Monitor for compromise
Follow Microsoft’s recommendations for audit policy on your domain controllers. These guidelines are a helpful starting point when configuring your enterprise auditing policies, because they prioritize the most important audit events and compare that configuration to the default Windows configuration. In some cases, the Windows default auditing level does not include events that are relevant to Active Directory security (e.g., Kerberos ticket operations).
If your license allows, take advantage of the Microsoft Defender for Identity sensor. Defender for Identity monitors for threatening activity on your Active Directory domain controllers and uses built-in threat-detection capability to monitor for credential compromise, reconnaissance, domain dominance, lateral movement, and data exfiltration. Alerts and evidence generated by Defender for Identity are integrated directly into the Microsoft 365 Defender Dashboard, giving you an opportunity to review this threat data alongside threats from the rest of your environment.
In fact, we simulated Kerberoasting and DCSync attacks in an environment protected by Defender for Identity to demonstrate just what those native alerts look like:
Kerberoasting
DCSync
Take advantage of your SIEM, if you have one, so that you can expedite potential investigations by cataloguing all of your Active Directory and other authentication logs in a central location.
Make it harder to compromise end users and hosts
Implement a password policy that includes strict enforcement of multi-factor authentication wherever possible. This should be a given in most environments, but if you haven’t revisited it in a while, NIST has good guidance on setting password policy requirements.
Consider implementing Azure Active Directory within your environment. By setting up a “hybrid domain,” you can more easily implement single-sign-on and/or multi-factor authentication for other applications that don’t otherwise support those features. Microsoft documentation provides a good guide.