Attack Path Modeling in Segmented Enterprise Networks
Maps how attackers traverse segmented environments using legitimate credentials, trusted tools, and protocol abuse rather than perimeter bypasses.
Most lateral movement in segmented enterprise networks does not happen by exploiting the perimeter. It happens by walking privilege relationships that already exist - through transitive group membership, over-permissioned service accounts, and constrained delegation that was set up once and never reviewed.
This note maps four lab-recreated AD topologies, runs the same attacker workflow against each, and looks at where the attack succeeded, where it stalled, and what detection coverage existed against it.
Methodology
Four AD topologies were built from real architectural patterns: a flat single-domain layout, a two-domain forest with one-way trust, a hub-and-spoke layout with a central admin domain, and a layered tier model. Each environment was instrumented identically with Elastic + Wazuh.
The attacker workflow used five stages: AS-REP Roasting → Kerberoasting → constrained delegation discovery → privilege-path traversal → Tier-0 asset access. The same scripts and the same telemetry stack across all four environments - only the AD shape changed.
Where the attack succeeded
In six of eight runs, transitive group membership exposed a Tier-0 asset within three hops. The simplest variant was a service account in a "service-admins" group that was, two layers up, a member of "Domain Admins" via nested groups added years earlier and never audited.
AS-REP Roasting succeeded against the default configuration in all four topologies. Two of them used short, dictionary-derived passwords for service accounts; the other two had stronger passwords but still leaked the hash format, allowing offline workflow.
Where detection consistently failed
The most underdetected stage across all environments was constrained delegation abuse. The default Elastic and Splunk rule sets did not flag the Kerberos exchange pattern at all. Custom rules covered it, but only after the workflow had been exercised and explicitly mapped.
This matches a broader pattern: detection coverage drifts toward what teams have already seen. Environments that had previously responded to a Kerberoasting incident had strong rules for it, and weaker rules for everything adjacent.