Microsoft Active Directory Security Part 2: Decoding Active Directory Attack Paths to High-Value Targets

An attacker who reaches a low-privilege Active Directory account is rarely the incident. The incident happens when that attacker follows an attack path, through group memberships, trust relationships, and stale permissions, in the lateral movement that ends at a domain controller. A previous entry in this series mapped the Active Directory attack surface those paths are built from. This one shows how attackers plan and traverse them, and where lateral movement security picks up once visibility ends.

At a glance

• An attack path is the permission chain from a low-privilege account to a domain controller.
• Lateral movement, MITRE ATT&CK TA0008, is an attacker moving hop by hop toward a privileged target.
• Mapping a path shows where the danger sits, not when an attacker is on it.
• Deception supplies that signal: decoys inside real AD relationships alert on contact.
• Acalvio is a Leader and Outperformer in the GigaOm Radar for Deception Technology, four consecutive years, most recently 2026.

Microsoft Active Directory is the directory service most enterprises use to manage users, computers, groups, and access across a Windows domain. It stores every account, permission, and trust relationship the organization runs on, which is also what makes it valuable to an attacker: compromise a single low-privilege account and the rest of the environment inside Active Directory Protection is reachable through the relationships AD already tracks.

Adversaries look at Active Directory as a graph, not as a relational database of users, computers, and groups. Active Directory manages several objects, among them users, computers, groups, ACEs, and GPOs. Users John, Frank, and Joe are members of various groups, such as Domain Users, Everyone, Helpdesk, IT Admin, and Domain Admin, and Figure 1 illustrates how those relationships form the graph an attacker actually navigates.

Once inside the domain, even at low privilege, an attacker’s first move is usually reconnaissance. John, a compromised low-privilege user, would use BloodHound or native PowerShell commands to enumerate users, groups, and admin relationships on that computer, mapping the same trust and permission graph defenders rely on to secure it. Because these are legitimate administrative tools running legitimate-looking queries, this activity blends into ordinary Windows events and rarely stands out on its own.

An attack path is the specific sequence of accounts, group memberships, and systems that connects a starting point, such as John’s low-privilege account, to a high-value target such as the Domain Admin group. Using various techniques, an attacker would move from one computer to the next, for example from John’s session to Frank’s account, then from Frank’s group memberships into IT Admin and on to Domain Admin, following whichever chain of trust gets there with the fewest steps. Figure 2 shows one such path end to end. Identifying all attack paths and prioritizing them for mitigation is an important first step of Microsoft Active Directory security assessment, since the same underlying graph can produce many possible paths to the same target.

Lateral movement in Active Directory is the process of using one compromised account or system to authenticate to the next, moving deeper into the domain until an attacker reaches a privileged target such as a domain controller.

An attack path is the map: the graph of trusts and permissions an attack path assessment reveals before anyone touches it. Lateral movement is the walk itself, tracked by MITRE ATT&CK as Lateral Movement, TA0008. Lateral movement security and lateral movement cybersecurity both depend on catching that walk while it is happening, not on redrawing the map after the fact. Catching it while it happens is where detection has to take over from mapping.

A Kerberoasting attack involves using a tool such as Rubeus to request and extract a service ticket for a Kerberoastable account, then cracking that ticket’s password hash offline with JohnTheRipper or hashcat. Because the cracked service account often becomes the credential an attacker uses for the next hop, Kerberoasting is frequently the first step in a longer lateral movement chain rather than the objective on its own. An attacker might chain this into a path such as John, Helpdesk, a Kerberoastable service account, Domain Admin, or reach the same service account through an entirely different group membership. Kerberos service ticket requests are ordinary, constant activity in any domain, which is exactly why flagging them as abnormal produces a large volume of false positives for a SOC to work through.

Mapping an attack path shows where a domain is exposed; it does not show when an attacker starts moving along that path.

Deception-based detection along the attack path

Deception-based detection places decoy users, computers, and service accounts, including Kerberoastable decoys, directly inside the real Active Directory relationships an attacker’s attack path traverses, so any interaction with one produces a high-confidence alert.

These decoys and breadcrumbs deploy automatically; hand-built decoys cannot keep pace with machine-speed reconnaissance. The approach is additive, running alongside EDR, SIEM, and identity tooling rather than replacing any of it. Because an alert fires on engagement rather than after behavior is correlated, it shortens the gap between an attacker’s foothold and a SOC response, and each decoy also removes a usable hop before that alert lands.

Detecting living-off-the-land movement

Living-off-the-land movement uses native Windows and AD utilities the attacker never had to introduce, so identifying it by which tool ran strains quickly, since the same PowerShell or WMI command is ordinary administrator activity everywhere else in the domain.

Deception does not depend on tool identification at all. A decoy account or credential has no legitimate reason to be touched, so the interaction itself is the signal, regardless of whether the attacker used PowerShell, WMI, or a built-in admin utility to reach it.

Why engagement-based alerts cut false positives

Anomaly-based tools ask whether a behavior looks statistically unusual, and Kerberos service ticket requests happen constantly in a healthy domain, so alerting on their pattern alone strains under normal traffic and produces a high volume of alerts for analysts to triage.

An engagement-based alert asks a different question: did anything touch an asset that has no legitimate use at all? A Kerberoastable decoy account is never queried by real administrators or service processes, so a single request against it is a high-confidence signal on its own. Analysts then spend triage time on alerts that already carry intent, not on separating routine ticket requests from the rare hostile one.