Phase 05 · Attack-path analysis
Attack Paths
Severity per finding understates risk when weaknesses compose. These illustrative paths show how several moderate synthetic findings combine to cross a trust boundary that no single finding crosses alone. Each path is a narrative model — the diagrams are non-executable and contain no reproduction detail.
AP-01 — Portal exposure to synthetic tenant administration
Three individually moderate weaknesses combine so that a standard lab account reaches an administrative workflow across a tenant boundary.
Path model
Internet-Facing
Standard lab account authenticates to the synthetic portal (WEB-01).
↳ Public → authenticated session
Application
Long-lived session remains valid well beyond policy, extending opportunity window.
↳ Session assurance weakened
Application
Administrative workflow accepts the request because authorization is UI-enforced.
↳ User → administrative capability
Identity
Broad test-role entitlement means the accepted action carries wide effect.
↳ Tenant → cross-tenant effect
Prerequisites
- A valid low-privilege lab account on the synthetic portal
- Knowledge of the administrative workflow route (obtainable from client-side code)
- No server-side authorization assertion on the target operation
Contributing findings
- EH-006Medium
Weak session timeout policy on synthetic portal
- EH-001Critical
Broken access control in synthetic admin workflow
- EH-002High
Overly broad permissions assigned to synthetic test role
Detection opportunities
- Alert on administrative endpoint access by non-privileged roles
- Anomaly detection on session age at the time of a sensitive action
- Audit review of role-to-entitlement drift in the identity service
Business impact
Cross-tenant administrative action in the lab model would represent a platform-level trust failure rather than a single-tenant issue.
Remediation breakpoints
- Server-side deny-by-default authorization on every admin operation (EH-001)
- Least-privilege rebuild of the test role (EH-002)
- Idle/absolute session limits plus step-up re-authentication (EH-006)
Residual risk after fixes
AP-02 — API abuse to synthetic account enumeration
Missing throttling plus verbose errors and banner disclosure make low-cost guessing against lab accounts practical and quiet.
Path model
Internet-Facing
Banner and version disclosure confirms the lab gateway technology (API-01).
↳ Reconnaissance
Internet-Facing
Verbose error contract distinguishes valid from invalid identifiers.
↳ Unauthenticated information disclosure
Identity
Absent rate limiting allows sustained low-noise guessing against lab identities.
↳ Anonymous → candidate credentials
Prerequisites
- Unauthenticated network reachability to the lab API gateway
- Distinguishable responses between valid and invalid identifiers
- No throttling or alerting on repeated failures
Contributing findings
- EH-010Low
Exposed version and banner information on lab gateway
- EH-011Low
Verbose error messages reveal internal structure on lab API
- EH-005Medium
Missing rate-limit control on lab authentication endpoint
Detection opportunities
- Threshold and velocity alerting on authentication failures per source and per identity
- Detection of uniform error-response probing patterns
- Monitoring for first-seen client fingerprints at high request rates
Business impact
Reliable enumeration of valid lab identities is the entry condition for most account-takeover scenarios and inflates downstream fraud risk.
Remediation breakpoints
- Per-identity and per-source rate limits with progressive delay (EH-005)
- Uniform generic error contract (EH-011)
- Banner suppression as a build default (EH-010)
Residual risk after fixes
AP-03 — Retired integration identity to internal data tier
A forgotten service account combined with broader-than-designed segmentation shortens the route from a workload foothold to tenant data.
Path model
Internal
Retired integration worker (SVC-03) retains an enabled identity with old credentials.
↳ Unowned non-human identity
Application
Reporting workload subnet reaches the data tier on a broader range than designed.
↳ Application tier → data tier
Internal
Synthetic tenant records in DB-01 become reachable with weak attribution in logs.
↳ Service access → sensitive data
Prerequisites
- A stale, enabled lab service account with unrotated credentials
- Application subnet reachability to the data tier beyond the documented port
- Audit coverage that does not attribute privileged actions to an actor
Contributing findings
- EH-009Medium
Stale synthetic service account remains enabled
- EH-003High
Overly permissive network path between synthetic application and data tiers
- EH-012Low
Insufficient logging of privileged actions in lab admin console
Detection opportunities
- Alert on authentication by identities with no recent legitimate usage
- Flow logging with alerts on unexpected tier-to-tier ports
- Audit events that record actor, source, and before/after state
Business impact
Access to the synthetic data tier through an unowned identity would be both high impact and slow to detect, since no team monitors the account.
Remediation breakpoints
- Disable and own every non-human identity, with enforced expiry (EH-009)
- Tighten segmentation to required service ports (EH-003)
- Structured privileged-action audit logging (EH-012)