Microsoft’s Active Directory (AD) is one of the most widely used directory services on the market, being used in almost every industry. AD is used in Microsoft Windows domain environments to organize and manage users, computers, groups, privileges, passwords, applications, databases, and many other resources across the domain(s). If not administered properly, an insecure AD can lead to a full domain compromise, including all data, services, and intellectual properties that keep an organization in business.

Often, AD security will be ignored in favor of new firewalls, email spam filters, endpoint detection & response (EDR), and other security hardware and services. However, these solutions do not always stop advanced adversaries. Once an advanced attacker managers to bypass an organization’s suite of security products, AD is often not organized in a manner that effectively slows the attack path or brings the attack to a halt. AD security is crucial at thwarting attackers or insider threats, which is where an AD Audit can help.

What is an AD Audit?

An AD Audit takes a closer look at analyzing relations and privileges between user, computer, and group objects as it relates to the security posture of the domain. Many data compromises can be attributed to poor hygiene or misconfigurations of the domain. The goal of the AD Audit is to identify misconfigurations and areas of improvement, while providing organizations with a roadmap on how to bolster the security of their AD domain. Ultimately, the goal is to make privilege escalation and persistence much more difficult for adversaries on your network. Ideally, a secure directory would:

  • Reduce the attack surface available to adversaries
  • Restrict initial access vectors
  • Minimize lateral movement
  • Limit the amount of time an adversary goes undetected

What does an AD Audit look like?

In contrast to a penetration test, which can generate malicious traffic and potentially disrupt production systems, an AD audit, outside of the initial data collection, mostly involves offline data analysis. To perform an AD audit, LBMC utilizes a mixture of proprietary, commercial, and free open-source software.

Much of our tooling requires visibility within the environment to be effective. While we can identify many issues with standard Domain Users level privileges, certain insights may only be identified with higher levels of privilege. Ideally, our data collection tools should be executed under the highest level of privilege and visibility available on the targeted domain(s).

In the event that unapproved equipment cannot be plugged into an internal network or privileged access cannot be granted to outside members of the organization, most of the needed data collection can actually be facilitated by internal information technology staff.

How is an AD Audit different than a penetration test?

Traditional penetration tests will often encapsulate the full attack lifecycle, from initial access to post exploitation, while mainly focusing on the attack paths and vulnerabilities available during the point in time assessment. Similar to a penetration test, an AD Audit can identify attack paths and privilege escalation opportunities in a more passive fashion. However, no actual exploitation occurs during an AD Audit.

While some of the findings from a penetration test may overlap with those from an AD Audit, the AD Audit is more targeted in scope. The main goal of the AD Audit is to provide more granular recommendations regarding how privileged access and directory management can be improved according to best practices. Neither a penetration test nor an AD Audit is a substitute for the other.

What types of things does an AD Audit find?

Our AD Audit process can uncover systemic findings and issues that typically go unnoticed. Large AD deployments can have layers upon layers of complexity, which we comb through to identify flaws that an attack might abuse to obtain access, escalate privilege, move laterally, or retain persistence across long periods of time. Some of these findings, for example, can include but are not limited to:

  • Lack of KRBTGT Account Password Rotation – Not rotating the KRBTGT account password every six (6) months can allow attackers to retain persistence for extensive periods of time. Get more information on Kerberos and related attacks.
  • Excessive RDP or local administrator privileges for large groups – Excessive Remote Desktop (RDP) or local administrator privileges can allow privilege escalation or lateral movement across a network.
  • Excessive Object write permissions for large groups – Excessive object write permissions for large groups, such as the Domain Users group, can be abused by attackers to escalate privilege or modify AD objects.
  • Service Principal Names with excessive permissions – All authenticated users and computers can query Service Principal Names (SPNs) and can request their associated service account’s Kerberos ticket. Since this ticket is inherently vulnerable to password recovery attacks, SPN service accounts should be limited to least privilege.
  • LAPS – Microsoft’s Local Administrator Password Solution (LAPS) automatically manages the local administrator password, so that local administrator password reuse does not occur.
  • Privileged account separation – User-level accounts are typically exposed to more systems and are at greater risk of compromise. If an attacker can gather user credentials, a lack of privileged account separation could grant instant control of the network.
  • Weak password policies – Weak passwords can lead to account compromise, whether through password guessing attacks or password recovery attacks.
  • Excessive Privileged account sessions across non-administrator systems – Privileged accounts should be guarded against exposure. They should only be used to administer the domain controllers and key pieces of infrastructure.
  • Service Accounts – Service accounts typically require high levels of privilege, so they should belong to the “Protected Users” security group and have access only to the systems that require the service account. Group managed service accounts (GMSAs) should also be used to handle password management for service accounts.
  • RBAC – Role Based Access Control (RBAC) should be used to grant privileges for users and administrators based on their job classification and function. Least privilege and “deny all” should be default.

Is your AD environment vulnerable?

LBMC is here to help and answer any questions you might have. If you’re considering an AD Audit, our experts can help you identify potential security vulnerabilities related to your environment and create an actionable roadmap for protecting your internal domain. Contact our team today!

Content provided by Andrew Kerley, Manager at LBMC.