Skip to content

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

  1. Internet-Facing

    Standard lab account authenticates to the synthetic portal (WEB-01).

    Public → authenticated session

  2. Application

    Long-lived session remains valid well beyond policy, extending opportunity window.

    Session assurance weakened

  3. Application

    Administrative workflow accepts the request because authorization is UI-enforced.

    User → administrative capability

  4. 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

LowRated after the breakpoint controls are in place and evidence reviewed.

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

  1. Internet-Facing

    Banner and version disclosure confirms the lab gateway technology (API-01).

    Reconnaissance

  2. Internet-Facing

    Verbose error contract distinguishes valid from invalid identifiers.

    Unauthenticated information disclosure

  3. 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

LowRated after the breakpoint controls are in place and evidence reviewed.

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

  1. Internal

    Retired integration worker (SVC-03) retains an enabled identity with old credentials.

    Unowned non-human identity

  2. Application

    Reporting workload subnet reaches the data tier on a broader range than designed.

    Application tier → data tier

  3. 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)

Residual risk after fixes

MediumRated after the breakpoint controls are in place and evidence reviewed.

Responsible testing