Skip to main content
Version: Local · In Progress

Attack Path Analysis

Attack path analysis answers a question that no other feature in ThreatWeaver answers: given your current identity configuration, what is the shortest route an adversary could take from compromising a standard user account to owning your most critical systems?

This page covers how ThreatWeaver builds attack graphs from identity data, how to read and investigate attack paths in the UI, how to prioritize remediation across multiple paths, and how identity attack paths intersect with AppSec findings.

What Attack Paths Are and Why They Matter​

An attack path is a chain of accounts, permissions, and trust relationships that an adversary can traverse sequentially to escalate privileges. No single step in the chain needs to be a critical vulnerability — the path becomes dangerous because each step is achievable given the previous one.

A Concrete Example​

Consider this scenario:

  1. An attacker phishes intern@company.com — a low-privilege user with no special rights
  2. That account is a member of the HelpDesk-Tier1 group
  3. HelpDesk-Tier1 is nested inside HelpDesk-All
  4. HelpDesk-All has GenericWrite permissions on a service account called svc-backup
  5. svc-backup has a Service Principal Name (SPN) registered
  6. Any domain user can request a Kerberos service ticket for an account with an SPN
  7. The ticket is encrypted with svc-backup's password hash and can be cracked offline (Kerberoasting)
  8. svc-backup has membership in Domain Admins for legacy reasons

No single step here is a critical misconfiguration in isolation. The danger comes from the chain. Conventional vulnerability scanners would not catch this at all — there is no CVE involved. An identity tool that only looks at individual account attributes would flag svc-backup as a high-risk service account but would not show the full path from intern@company.com to Domain Admin.

ThreatWeaver's attack path engine traverses the full graph of identity relationships to find these chains.

How ThreatWeaver Constructs Attack Graphs​

The attack graph construction runs as part of the identity sync process. After syncing all identities, groups, permissions, and relationships from the connected provider(s), ThreatWeaver runs the attack graph analysis against the data.

Graph Construction Process​

Step 1: Node Population

Every identity, group, role, and resource in the synced data becomes a node in the graph:

  • User accounts (both active and disabled — disabled accounts may have dormant permissions)
  • Service accounts and managed identities
  • Security groups and distribution groups
  • Active Directory OUs and GPO objects
  • Azure roles and role assignments
  • Privileged identity management (PIM) eligible roles
  • High-value target nodes: Domain Controllers, Domain Admin groups, Global Admin roles, Crown Jewel assets (when linked from exposure management)

Step 2: Edge Assignment

Every permission, membership, and trust relationship becomes a directed edge in the graph:

Edge TypeWhat It RepresentsProvider
MemberOfAccount is a member of a groupAD, Azure AD, Okta, Google
HasRoleAccount has a direct role assignmentAzure AD, GCP, AWS
GenericWriteAccount can modify target object's attributesAD
WriteDACLAccount can modify target object's permissionsAD
WriteOwnerAccount can take ownership of target objectAD
AllExtendedRightsAccount has all extended rights including replicationAD
HasSPNAccount has an SPN registered (Kerberoasting target)AD
DONT_REQUIRE_PREAUTHAccount can be AS-REP roastedAD
AdminToAccount has local admin rights on a computerAD (via GPO or direct assignment)
CanRDPAccount can initiate Remote Desktop to a computerAD (via group membership)
TrustedByDomain A trusts Domain B (for cross-domain traversal)AD
CanPSRemoteAccount can initiate PowerShell remotingAD

Step 3: Path Enumeration

With the graph constructed, ThreatWeaver runs a modified Dijkstra-style shortest path algorithm from each low-privilege starting node toward high-value target nodes. "High-value targets" are defined as:

  • Nodes that are Domain Admin, Enterprise Admin, or Schema Admin
  • Azure Global Admin or Privileged Role Admin roles
  • Crown Jewel assets linked from the exposure management module
  • Any node explicitly marked as a high-value target in connector configuration

Paths longer than 8 steps are truncated — paths with more than 8 steps are theoretically possible but rarely practical for real attacks and generate excessive noise.

Step 4: Path Classification

Each path found is classified into one of the supported attack path types based on the edge types traversed:

  • If the path traverses a HasSPN edge and includes cracking → Kerberoasting
  • If the path reaches AllExtendedRights or replication permissions on a DC → DCSync
  • If the path reaches write access to the KRBTGT account → Golden Ticket
  • If the path uses AdminTo edges to traverse machines → Pass-the-Hash
  • If the path traverses DONT_REQUIRE_PREAUTH → AS-REP Roasting
  • If the path includes shared credentials across multiple services → Shared Credentials Lateral Movement
  • If the path reaches Domain Admin through nested group traversal → Nested Group Escalation

Step 5: Severity Rating

Each detected path receives a risk rating:

FactorContribution to Rating
Target node is Domain Admin / Global AdminCritical severity base
Target node is a Crown Jewel assetCritical severity base
Number of steps to reach target (shorter = worse)1-2 steps → Critical, 3-4 → High, 5+ → Medium
Number of entry points (accounts that start this path)More entry points = higher severity
Entry point account type (standard user, guest, external)Standard user = worse than service account
Whether entry point accounts have MFANo MFA = higher severity

Reading an Attack Path in the UI​

Navigate to Identity Security → Attack Paths (/identity/attack-paths) to see the full list of detected attack paths.

Attack Path List View​

The list shows each detected path with:

  • Path Name — A descriptive name generated from the path type and the accounts/groups involved
  • Type — The attack category (Kerberoasting, DCSync, etc.)
  • Risk Rating — Critical / High / Medium
  • Affected Count — How many accounts can serve as entry points for this path
  • Target — What the path leads to (e.g., "Domain Admin", "Crown Jewel: payments-db")
  • Steps — Minimum number of steps from entry to target

Sort by Risk Rating (descending) to see the most dangerous paths first.

Path Detail View​

Clicking any attack path opens the detail view with three panels:

Panel 1: Path Diagram

A step-by-step visual of the attack chain. Each node is color-coded:

  • Blue — User account (entry point)
  • Orange — Group or role (intermediate step)
  • Yellow — Service account (credential extraction target)
  • Red — High-value target (final destination)

Edges between nodes show the permission or relationship being exploited at that step (e.g., MemberOf HelpDesk-Tier1, GenericWrite on svc-backup, HasSPN → Kerberoast).

Panel 2: Step-by-Step Explanation

Below the diagram, each step is explained in plain English:

Step 1: Attacker compromises a user in the "Intern Accounts" OU
        → 47 accounts are entry points for this path

Step 2: Intern accounts are members of HelpDesk-Tier1
        → This group membership is automatic via OU policy

Step 3: HelpDesk-Tier1 is nested inside HelpDesk-All
        → Nested membership grants all of HelpDesk-Tier1's rights

Step 4: HelpDesk-All has GenericWrite on svc-backup service account
        → This was granted to allow helpdesk to reset the service account password

Step 5: svc-backup has an SPN registered (MSSQLSvc/db01.company.com:1433)
        → Any domain user can request a Kerberos service ticket for this SPN

Step 6: Kerberoast — Request ticket, crack offline
        → svc-backup's password is only 12 characters: 'Summer2023!1'
          (detected via password policy age: last changed 2+ years ago)

Step 7: svc-backup is a member of Domain Admins
        → Full domain compromise

Panel 3: Affected Identities

A table of all accounts that serve as valid entry points for this path. Each account shows its email, last login, MFA status, and risk score. Sort by MFA Status = Not Enrolled to find the easiest entry points first.

Prioritizing Remediation​

With multiple attack paths detected, the most common analyst question is: "Where do I start?"

Triage Framework​

Apply these four criteria in order to determine which paths to address first:

1. Target Criticality

Paths leading to Domain Admin, Global Admin, or Crown Jewel assets are always highest priority, regardless of path length. A 5-step path to Domain Admin is more important than a 2-step path to a Medium-criticality asset.

2. Entry Point Count

A path with 200 possible entry point accounts is more dangerous than an identical path with 2 entry points. An attacker has a much higher probability of finding a compromised or phishable account among 200 options.

3. Entry Point MFA Coverage

If all entry point accounts have MFA enrolled and Conditional Access enforces it, the path is significantly harder to exploit (credential theft alone is not enough — the attacker also needs to bypass MFA). Prioritize paths where entry point accounts have no MFA.

4. Path Length

Shorter paths require less attacker skill and less dwell time. A 2-step path (compromised account → direct Domain Admin membership) requires immediate action. A 6-step path through multiple intermediate groups is still serious but allows slightly more time to remediate.

Remediation Strategies by Path Type​

Kerberoasting paths

The root cause is a service account with an SPN that is both weak (crackable password) and over-privileged (has admin rights once cracked).

Fix options (in order of preference):

  1. Remove the service account from Domain Admins entirely. Add it to only the groups it genuinely requires.
  2. If the account must have elevated privileges, set a very long, random password (30+ characters) that makes offline cracking infeasible.
  3. Convert the service account to a Group Managed Service Account (gMSA) — Windows automatically rotates the password every 30 days with a 240-character random value.
  4. If the SPN is not needed, remove it.

DCSync paths

The root cause is an account with replication rights on the domain — rights that no user account should have.

Fix:

  1. Use Get-ObjectAcl in PowerShell with dsacls to identify which accounts have DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain object
  2. Remove these ACEs from any non-DC accounts
  3. Only domain controllers and, in some environments, dedicated ADFS service accounts need these rights

Pass-the-Hash paths

The root cause is admin account credential reuse across multiple machines — the same admin account is a local administrator on many servers.

Fix:

  1. Implement Local Administrator Password Solution (LAPS) — unique random local admin passwords per machine
  2. Disable NTLM authentication in favor of Kerberos where possible (via GPO)
  3. Restrict which admin accounts are members of local Administrators groups via tiered administration (Tier 0/1/2 model)
  4. Enable Credential Guard on Windows 10/11 and Windows Server 2016+ to prevent pass-the-hash

Nested Group Escalation paths

The root cause is accumulated, unreviewed group memberships that create unintended privilege chains.

Fix:

  1. Conduct a group membership audit — use the path diagram to identify the specific nesting chain
  2. Remove unnecessary nested group memberships (in the example above: remove HelpDesk-Tier1 from HelpDesk-All, or remove HelpDesk-All's GenericWrite on the service account)
  3. Implement a quarterly access review process for high-privilege groups
  4. Use Azure AD Privileged Identity Management (PIM) for time-limited, just-in-time admin access instead of permanent group memberships

AS-REP Roasting paths

The root cause is accounts with the DONT_REQUIRE_PREAUTH flag set — often a legacy configuration from old Kerberos clients.

Fix:

  1. Identify all accounts with this flag: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth
  2. Remove the flag from all accounts that do not specifically require it
  3. Ensure flagged accounts (if any must keep the flag) have long, random passwords

Common Attack Patterns in Enterprise Environments​

The following patterns appear repeatedly in real enterprise environments. They represent accumulated technical debt and configuration drift rather than active attacks — but they are the building blocks of most AD compromises.

"The Helpdesk Escalation Chain"​

Pattern: Helpdesk/support teams are granted write or reset permissions on service accounts so they can unlock accounts and reset passwords. Over time, those service accounts accumulate group memberships in IT admin groups. The helpdesk team (which has many members, high turnover, and often weaker credentials) becomes an inadvertent path to admin.

Indicators in ThreatWeaver: Attack paths where GenericWrite, ForceChangePassword, or ResetPassword edges connect large groups (20+ members) to privileged service accounts.

Fix: Apply the principle of least privilege to helpdesk permissions. Helpdesk should have write access only to specific non-admin attributes (e.g., unlock account, reset password for standard users). Never grant helpdesk write access to service accounts in admin groups.

"The Forgotten Service Account"​

Pattern: A service account was created years ago for a specific integration (e.g., monitoring tool, backup software, old SIEM). The integration was replaced or decommissioned, but the account was never deleted. It still has admin rights because "we weren't sure who used it." The password has never changed.

Indicators in ThreatWeaver: Service accounts with no login activity in 180+ days that are members of Domain Admins or other high-privilege groups. Kerberoasting paths involving accounts with very old password change dates.

Fix: Audit all service accounts. For each one: confirm who owns it, what it's used for, and what permissions it actually needs. Disable accounts with no confirmed owner. Delete accounts after a 30-day hold period with no objection.

"The Guest Who Became Admin"​

Pattern: An external contractor was added to an Azure AD group for a project. The project ended, but the contractor account was never deprovisioned. Over time, the group acquired additional permissions through role assignments or app grants.

Indicators in ThreatWeaver: External/guest accounts in groups with elevated Azure roles. Accounts with #EXT# in their UPN that have been inactive for 60+ days but remain enabled with group memberships.

Fix: Implement Azure AD Access Reviews for guest accounts. Set automatic guest account expiration. Use PIM for any elevated permissions granted to contractors.

"The Pass-the-Hash Trap"​

Pattern: A single domain admin account (e.g., domain\admin) is used to manage dozens of servers. The account is a member of local Administrators on every server. An attacker compromises one server, extracts the NTLM hash from memory (via Mimikatz or similar), and uses it to authenticate to every other server without knowing the password.

Indicators in ThreatWeaver: Pass-the-Hash paths where a single admin account has AdminTo edges to a large number of computer objects.

Fix: Implement LAPS. Each machine gets a unique local admin password that ThreatWeaver can detect via LAPS-related AD attributes. Implement tiered administration — Tier 0 accounts (DC management) cannot log into Tier 1 machines (server management), which cannot log into Tier 2 machines (workstations).

"The Nested Group Labyrinth"​

Pattern: Group memberships in Active Directory accumulate over years of organizational changes. A group that was originally for the "IT Operations" team now contains sub-groups from three merged departments, a distribution list repurposed as a security group, and a dozen accounts added directly. One of those sub-groups has admin rights on critical servers, but no one realized the chain reached that far.

Indicators in ThreatWeaver: Nested Group Escalation paths with 5+ steps where the attack surface (number of accounts in the path) is very large but the path is not intentional admin access.

Fix: Use Get-ADGroupMember -Recursive to fully enumerate group memberships. Remove sub-groups that are incorrectly nested. Flatten the group structure. Consider tools like BloodHound for a full AD privilege graph audit (ThreatWeaver's attack path analysis complements BloodHound; they use similar techniques but integrate into the broader exposure management context).

Integration with AppSec Findings​

Attack path analysis in ThreatWeaver operates alongside the AppSec Scanner. When both modules are active, they produce correlated findings that reveal higher-risk scenarios than either module can surface alone.

Correlated Scenario Types​

1. Compromised Application Account as Attack Path Entry Point

The AppSec scanner discovers an authentication bypass or session fixation vulnerability in app.company.com. The service account used by this application (svc-webapi@company.com) is also an entry point in a Kerberoasting path leading to Domain Admin.

Combined signal: An exploitable AppSec finding in an application whose identity is a high-risk attack path entry point. Patching the application without also hardening the service account leaves the path open to other exploitation methods (e.g., credential stuffing). Hardening the service account (removing from Domain Admins, rotating password) reduces the blast radius of the AppSec finding.

Where this surfaces: In the AppSec finding detail view, ThreatWeaver shows a linked "Identity Risk" badge when the application's service account is involved in a detected attack path.

2. SSRF Reaching Internal AD Infrastructure

The AppSec scanner discovers a Server-Side Request Forgery (SSRF) vulnerability that can reach internal endpoints. The exposed endpoint is the domain controller at 10.1.1.10:389.

Combined signal: An SSRF to port 389 (LDAP) on a domain controller is potentially exploitable for LDAP enumeration — an attacker could enumerate AD users, groups, and potentially extract data. The attack path analysis shows that this LDAP exposure is particularly dangerous because several Kerberoastable service accounts are already known.

3. Credential Exposure in Application Findings

The AppSec scanner flags a finding where API responses contain service account credentials in plain text (or in an easily decryptable format). The Identity Security module shows that this service account has Domain Admin rights.

Combined signal: Credential exposure in application + high-privilege service account = immediate Domain Admin access if exploited. This combination should be treated as a Critical finding even if each individual finding rates as High.

How to Review Correlated Findings​

In the AppSec Findings view, findings with identity correlation show an Identity Risk badge on the finding card. Click the badge to open the linked attack path detail directly. In the Attack Paths view, paths with linked AppSec findings show an AppSec badge next to the entry point accounts that have associated AppSec vulnerabilities.

This bi-directional linking is designed for the analyst doing a prioritization review. The goal: instead of working through AppSec findings sorted by CVSS score and identity risks sorted by identity score separately, you see the intersection — the places where both signals overlap — and those combined risks get highest priority.

Frequently Asked Questions​

"We use a dedicated PAM solution — does ThreatWeaver duplicate what it does?"​

No. PAM (Privileged Access Management) tools like CyberArk and BeyondTrust manage, vault, and rotate privileged credentials. They control access at the time of use. ThreatWeaver's identity module provides a read-only posture view — it shows you the state of identity configuration, where attack paths exist, and which accounts are risky. It does not manage credentials or enforce access control at runtime.

The two are complementary. A PAM tool controls privileged access. ThreatWeaver tells you where privileged access is misconfigured, over-granted, or exposed to attack path traversal — including service accounts that PAM may not cover.

"We already run BloodHound internally — do we need ThreatWeaver's attack path analysis?"​

BloodHound is an excellent and deep Active Directory attack path tool. ThreatWeaver's attack path analysis provides a similar capability but integrates it into the broader exposure management context — so that AD attack paths appear alongside CVE data, cloud misconfigurations, and AppSec findings.

If you run BloodHound, ThreatWeaver's value is not duplicating BloodHound but providing a unified risk picture. An analyst using ThreatWeaver can see that the Kerberoastable service account in the attack path also runs on a server with 3 Critical CVEs, and the server has an S3 bucket with a cloud misconfiguration — in one screen.

"How often do attack paths update after we make fixes?"​

Attack paths are recalculated after every identity sync cycle. If you fix a path (e.g., remove an account from Domain Admins), trigger a manual sync in the connector settings and the path will be reassessed within minutes. The path will transition to Resolved status if the fix removes all viable traversal routes to the target node.

"Can ThreatWeaver detect lateral movement that is actively happening?"​

No. ThreatWeaver analyzes identity configuration at a point in time — it does not process authentication logs in real-time or detect active compromise. It shows you where attack paths exist so you can remediate them before an attacker exploits them. For real-time lateral movement detection, you need a SIEM/UEBA tool (Splunk, Microsoft Sentinel, Exabeam) that can analyze authentication log streams.

"What is the difference between attack paths and exposure categories?"​

Exposure categories (stale accounts, no-MFA, over-privileged users) are individual account-level findings. Each finding is about one account.

Attack paths are multi-step chains that connect multiple accounts and groups through a sequence of permissions. An attack path may include accounts that appear in exposure categories, but the path shows how those individual problems chain together into a complete compromise scenario.

Both matter, but attack paths represent a higher level of analyzed risk — they show the operational impact of the individual exposures.