Skip to main content

Attack paths

An attack path is how an attacker could progress from a starting position toward an asset, one exploited exposure at a time. The CyberOptix CTEM Platform builds them from your assessed exposures, the zones your assets sit in, and the relationships it knows or you have declared between them. The paths are the input to every figure on the Executive Risk Overview.

A path is a simulation of what could happen. It is never a record that something did: what was demonstrated is marked as such on each step, and everything else is modeled.

Where a path starts​

Every path begins at an origin:

  • The internet. An exposure on an asset whose reachability from outside was observed: a probe or a public scan reached it, the provider's topology places it public, or a tester confirmed it. An exposure the platform could not place is not an entry, however it is prioritized; it stays a step an attacker already inside could take. The entry step is that exposure, with its own assessed likelihood, and every such exposure is an entry path of its own.
  • An exposed credential. A principal whose credential appeared in breach data. The attacker is assumed to hold it, with a likelihood that falls as the record ages, and can only use it where the platform knows that principal has access.
  • An insider. A starting position you declare inside the network. Paths from it are kept apart on the page as declared-origin scenarios, never mixed into the internet figure.

What the attacker holds​

The model tracks an attacker state rather than a list of hosts:

HeldGained by
PositionsThe zones the attacker is in: the public zone at the start, then every zone an exploited asset sits in
ExecutionThe assets the attacker has exploited, with the level reached
PrincipalsAccounts and roles obtained from an exploited asset through a known credential reuse or cloud role relationship

A step is available only from what the attacker holds. From a position, the attacker can reach assets the zone reaches, and assets in zones that zone trusts. From an exploited asset, applications adjacent to it. Nothing reachable is assumed exploited: each candidate step is scored.

How a step is scored​

Each step carries:

  • the exposure's conditional likelihood, re-read from the attacker's position. An exposure that is isolated from the internet is read as internally reachable once the attacker is inside its zone;
  • feasibility factors for what the evidence does not carry: the kind of relationship used to get there and whether it was declared or verified, how deep the step is, whether a needed privilege could be confirmed, and whether the exposure was validated;
  • the privilege check where the exposure needs elevated privileges. The step is confirmed only by a relationship that names a held principal on that resource. Holding a credential somewhere is not holding it here; an unconfirmed step is discounted and marked unknown;
  • the yield: what the attacker has afterwards. A validated exposure yields the level the validation demonstrated, up to root level, on the demonstrated basis. An unvalidated one yields user level on the modeled basis. The model never escalates on its own.

The likelihood of a path is the entry's likelihood multiplied by each step's conditional likelihood and feasibility. A path is never more likely than its least likely step.

A step whose reachability from outside was assumed rather than observed is priced as reachable from inside, since a step is read from the attacker's position after prior access: the attacker's position is the fact and the assumption is not.

Every reached state is a path​

The entry alone is a path, with the entry asset as its target. Each further step is a path of its own, with the asset it reached as its target. A path knows the shorter path it continues from, and a state nothing continues from is marked as a chain end. This is what lets the figures treat a path and its continuation as one chain rather than two independent opportunities, and what makes a jewel three steps in priced at three steps.

Relationships you declare and verify​

Some relationships the platform discovers; others you declare: a trust between two zones, a privilege grant from a principal to a resource, a credential reuse, a cloud role assumption. A declaration is priced as declared, below a verified relationship. It becomes verified only through a validation event: a tester or an automated validation records that the hop was demonstrated, with the validated findings that show it. A failed attempt is recorded too and is what verifies a revocation.

Revoking a relationship removes it from the paths at the next build. Declaring the same relationship again revives it without the verification it had.

Bounds and coverage​

The search behind the paths is bounded: how many steps deep, how many candidates it follows from each state, how many paths per entry, and a budget on how much it visits in one build. When a bound is hit the build records it and the Risk Posture page shows coverage as incomplete with the reason. The paths found are then an incomplete enumeration, nothing more: the figures built from them are neither a floor nor a ceiling on the figures a complete search would give.

When paths are rebuilt​

Paths are rebuilt when an assessment changes, when a relationship is declared, verified or revoked, when zone reachability changes, when an exposure is resolved or comes back, and on a periodic sweep. A rebuild that changes nothing writes nothing; a rebuild that changes the paths writes a new snapshot of the figures.

Next​

Last updated on