Post cover image

August 7, 2026

From Attack Paths to Runtime Proof

Introduction

By Abhinav (TheKillChainGuy)

12 min read

MAPPING THE BREACH · PART II

Introduction

In Part I, we made the case for treating cloud security as a graph problem. An internet-facing workload, a vulnerable application, an over-privileged identity, an exposed data store, and a forgotten trust relationship look like five independent findings in five different dashboards. Put them in the same graph, and they become something far more important: an attack path.

The graph answers a powerful question: could an attacker get from here to there? During an incident, that question is no longer enough. The SOC needs to know whether the attacker actually traversed the path — and, more precisely, which edges we can prove they traversed.

That is where runtime detection changes attack-path analysis. Static attack paths model possibility. Runtime telemetry adds evidence. The result is what I think of as runtime-validated attack paths: paths in which configuration, identity, network, and workload relationships are continuously enriched with evidence of what is actually happening inside the environment. That distinction turns attack-path management from a prioritisation technique into an incident-response capability.

The timing matters. Adversary tradecraft has compressed the response window to almost nothing: the average time from initial access to lateral movement fell to 29 minutes in 2025, the fastest observed breakout took 27 seconds, and in one intrusion data exfiltration began within four minutes of initial access. In the same dataset, 82% of detections were malware-free — intrusions moving through authorised pathways and trusted systems, blending into normal activity. Against an adversary who looks like a legitimate user and finishes in minutes, a graph that is recomputed nightly and read like a report is not a control. It has to participate in the defence.

None

1. A real breach, drawn as a graph

One of the clearest public examples remains the 2019 Capital One incident. A server-side request forgery weakness reachable through a misconfigured web application firewall allowed an attacker to query the EC2 instance metadata service, retrieve the temporary credentials of the IAM role attached to that instance, and use them to enumerate and read objects from S3 — ultimately exposing records relating to roughly 106 million people. The unauthorised access occurred in late March 2019; the company determined that an intrusion had occurred on 19 July, after receiving an external tip, and disclosed it publicly on 29 July.

Rather than replaying the exploit, what matters from a defensive-architecture perspective is the shape of the path — and the fact that every hop in it is now a formally catalogued technique.

None

MITRE ATT&CK models each of these steps explicitly. Access to the metadata API for credential collection is T1552.005 (Unsecured Credentials: Cloud Instance Metadata API), a Credential Access technique whose documentation cites a cloud metadata API being used in a high-profile compromise. Enumerating the estate is T1580 (Cloud Infrastructure Discovery); enumerating objects inside storage is T1619 (Cloud Storage Object Discovery), whose canonical example is the ListObjectsV2 call. Reading the objects themselves is T1530 (Data from Cloud Storage).

That separation is instructive. To a vulnerability scanner, the first problem is an application weakness. To IAM tooling, the second is an over-privileged role. To a data-security product, the third is sensitive information in a bucket. Three teams, three backlogs, three severities. To the attacker, they were simply the next three edges.

2. The problem with a purely static path

Suppose our security graph had identified this path before the intrusion: Internet → Web workload → IAM role → S3 bucket → PII. That is valuable, but it is predictive. The graph is saying: if this workload is compromised, its identity could reach sensitive storage.

During an incident, that statement needs to be updated continuously. Suppose the platform now observes suspicious inbound activity reaching the workload; then an unexpected process interacting with the instance metadata endpoint; then the workload's role beginning to enumerate buckets and objects; then abnormal object reads and outbound transfer. The topology has not changed at all. The IAM policy has not changed. But the path has changed state — from potential to observed. That is a fundamentally different security object, and it deserves different treatment in the queue, in the interface, and in the response playbook.

None

3. Give every edge an evidence state

Traditional attack graphs are binary: an edge either exists or it does not. For incident investigation, I would extend the model so that every edge carries an evidence state alongside its structural definition.

None

The states are not merely labels; they are a promotion ladder with defined evidence requirements for each transition. That makes the model auditable — an analyst can always ask why an edge sits at State 3 rather than State 2, and get a concrete answer in the form of the signal that promoted it.

None

A graph with evidence states is no longer displaying topology. It is maintaining an evidence-weighted hypothesis of attacker movement.

4. Runtime happens at four layers, not one

The word "runtime" is often reduced to "put an agent on the container." That is far too narrow for cloud incident response. A cloud attack crosses several execution planes, and each produces a different kind of evidence about a different kind of edge.

Layer 1 — Application and network runtime

The first opportunity is the workload itself: unusual inbound requests, unexpected child processes, reverse shells, newly written executables, suspicious outbound connections, DNS lookups to known-bad infrastructure, process injection, and container escape attempts. Modern sensors increasingly use eBPF to observe process, filesystem, and network activity from inside the kernel rather than relying on application logs, establishing a behavioural baseline against which deviations — an unexpected child process, an unusual connection — can be flagged without static signatures. This layer answers: what happened inside the workload?

Layer 2 — Cloud control-plane runtime

Once the attacker holds cloud credentials, the interesting telemetry stops being a syscall and becomes an API call. Cloud audit logs are the endpoint telemetry of the control plane, and the signals that matter are calls such as sts:, iam:, s3:ListBuckets, s3:ListObjects, s3:GetObject, and ec2:Describe*. This layer answers: what did the compromised identity do?

Layer 3 — Identity runtime

This is where cloud investigation gets genuinely interesting. A role definition is static; role usage is runtime. Consider an application role that normally performs a single GetObject against one bucket, and then suddenly issues ListBuckets, ListObjects against a second bucket, and GetObject against a third. The IAM policy has not changed. The posture score has not changed. The identity's behaviour has. This is precisely why identity cannot live exclusively inside CIEM — identity activity belongs in threat detection. The graph should therefore carry both Role CAN_ACCESS Bucket (permission) and Role ACCESSED Bucket @ timestamp (evidence).

Layer 4 — Data runtime

The final hop is usually the one that determines whether this is an incident or a breach, because access to a bucket is not the same as access to its data. The investigative questions are specific: which objects were enumerated, which were actually read, how many, by which principal, from where, was that normal for this identity, was the data sensitive, what volume moved, and did the access follow suspicious credential activity? Evaluating storage events in isolation loses all of that; correlating them with identity context and preceding authentication activity is what makes them meaningful.

None

5. Correlation is the actual detection problem

Each individual event in this class of attack is explainable. A web server makes network requests — normal. A role reads an S3 bucket — normal. An application lists several resources — possibly normal. A workload starts a shell — sometimes normal. Value appears only when the observations are connected in time.

None

Cloud detections should increasingly score sequences of behaviour rather than individual events.

This is not a theoretical preference; the major providers have already moved this way. Amazon GuardDuty's Extended Threat Detection, generally available since December 2024, correlates signals across multiple data sources, resource types, and time within an account to produce a single "attack sequence" finding rather than a scatter of isolated alerts. Those findings carry critical severity — a level AWS had previously reserved entirely — and include an incident summary, an event timeline, mapping to MITRE ATT&CK tactics and techniques, and remediation guidance. Coverage has since expanded to EKS clusters and to EC2 and ECS. The documented scenarios are precisely the shape discussed here: credential compromise followed by data exfiltration, and unusual enumeration followed by suspicious object reads from unexpected locations.

The operational argument for sequence scoring is just as strong as the detection argument. SOC teams are not short of alerts; they are short of conclusions. Survey data puts average daily alert volumes in the thousands, with roughly 40% never investigated and a majority of teams admitting they have ignored alerts that later proved significant; false positives remain the single most cited detection challenge. Adding a ninth isolated detector to that queue does not help. Collapsing five related detections into one evidence-weighted path does.

6. Feeding runtime signals back into the graph

This is the architecture I find most interesting. Part I described the graph as assets, identities, vulnerabilities, configurations, and relationships. Part II adds one more input: runtime observations. The telemetry itself becomes part of the graph, attached to the edges it illuminates. That yields three concrete benefits.

  1. Attack-path validation. Paths with observed runtime activity rise above paths that merely exist on paper.

  2. Investigation. Analysts can walk backwards from the affected data to the initial foothold along recorded edges instead of reconstructing the chain from four consoles.

  3. Blast-radius prediction. Once part of the path is confirmed, the static graph can answer where the attacker could go next.

That third point is the crux. Runtime detection tells us where the attacker is. Attack-path analysis tells us where the attacker can go. The combination is substantially more useful than either alone — and neither discipline produces it on its own.

A practical validation engine

Conceptually, the correlation logic is not exotic:

IF vulnerable_or_exposed(workload)
AND suspicious_runtime_activity(workload)
AND identity_used_by(workload, role)
AND unusual_cloud_api_activity(role)
AND role_can_access(role, sensitive_asset)
THEN attack_path.status = "runtime_validated"
attack_path.confidence += correlation_weight

Notice what this does not do. It does not replace graph analysis with alerts. It updates the graph with evidence. A more developed model computes a path confidence as the sum over observed edges of the evidence strength, the confidence of the contributing signal, and the tightness of temporal correlation between adjacent hops:

PathConfidence = Σ ( evidence_strength × signal_confidence × temporal_correlation )
OperationalRisk = AttackPathRisk × PathConfidence

Two structurally identical paths can now receive completely different priorities. Path A exists but has never been exercised. Path B exists and its first four edges were observed in the last six minutes. The queue should not treat them as equals, and with this model it does not have to.

7. Detection engineering for the path, not the indicator

For this class of breach, I would build detections around transitions between graph nodes rather than isolated indicators. Five are worth specifying.

Detection 1 — Workload to metadata

Alert when a workload with no legitimate reason to touch the metadata endpoint suddenly does, especially when preceded by suspicious application activity. This is the hop MITRE catalogues as Credential Access, and ATT&CK now publishes a corresponding detection strategy covering access attempts to the metadata endpoint from virtual machines and containers, explicitly including request-forgery exploitation patterns [17]. Hardened metadata services that require a session token raise the bar considerably and should be treated as the primary preventive control [18] — but the detection still matters, because requiring a token is not the same as every workload in the estate actually enforcing it.

Detection 2 — Credential to discovery

Detect a workload role performing resource discovery outside its behavioural profile:

Role usually: GetObject(bucket-A)
Role suddenly: ListBuckets
ListObjects(bucket-B)
DescribeInstances
GetCallerIdentity

Every call here is legitimate and every one of them will appear in normal operations somewhere in the estate. The sequence, performed by this identity, is not.

Detection 3 — Discovery to sensitive data

Correlate unusual enumeration with access to sensitive objects. The rule should not fire merely because an object was read; it should fire on the conjunction:

new_identity_behaviour
AND unusual_object_enumeration
AND sensitive_bucket
AND high_read_volume
AND suspicious_preceding_activity

Detection 4 — Identity and location mismatch

A particularly valuable correlation is a workload identity being exercised from a context inconsistent with that workload's normal execution pattern. If a role bound to a specific application appears in activity that does not match where and how that application runs, the credential itself should immediately become a node in the investigation graph. This detection is especially important given how much intrusion activity now arrives through valid credentials and trusted pathways rather than malware [2].

Detection 5 — Attack-path completion

Finally, stop treating the previous four as separate alerts. Correlate Initial Access, Credential Access, Discovery, Collection, and Exfiltration into a single investigation. The unit presented to the analyst should be the attack path, not five detection-rule names.

8. From alert queue to graph investigation

Consider the difference in analyst experience. The traditional SOC receives four rows: a suspicious process, an unusual IAM API call, an S3 anomaly, an outbound connection. Four different tools, four different severities, four different owners — and the analyst's first job is the archaeological one of working out whether they are related at all. Given documented investigation loads, they frequently never get that far.

The graph-native SOC receives one object instead:

ACTIVE ATTACK PATH confidence 0.94
internet-facing workload
| suspicious runtime exec OBSERVED 10:02:13
workload IAM role
| abnormal API discovery SUSPICIOUS 10:02:22
customer-data bucket
| abnormal object access CONFIRMED 10:03:01
sensitive objects
observed edges ………. 4 / 5
critical asset reached .. yes
remaining blast radius .. 7 resources
highest-value cut ……. revoke workload role

That interface answers the questions an analyst actually has: what happened, where did it start, which identity was compromised, what did it touch, what could it touch next, and which edge should I break first. The underlying detections have not changed. Their presentation has, and presentation is what determines whether a 29-minute breakout is caught in time.

9. Runtime validation changes remediation too

Part I introduced choke points — the nodes and edges through which a disproportionate number of paths flow. Runtime evidence makes them more valuable still, because it tells you which side of the choke point the attacker is already on.

Suppose the attacker has traversed workload to role to storage, and the graph predicts three further reachable targets: a production database, a secrets manager, and a CI/CD pipeline. The response does not need to shut down the environment. It needs to identify the smallest defensive action that collapses the attacker's reachable graph — revoking or restricting the compromised role, invalidating active credentials, isolating the workload, denying a specific storage path, removing a trust relationship, restricting egress, or blocking the source infrastructure.

None

The same graph that prioritised remediation before the breach now scopes containment during it. That reuse is the practical payoff of building the graph as shared infrastructure rather than as a feature of one dashboard.

10. Runtime evidence must decay

One architectural property deserves more attention than it usually gets: runtime evidence is perishable in a way that configuration evidence is not. A vulnerable route may persist for months. A malicious process might live for seconds. A set of temporary credentials might remain useful for minutes or hours. Evidence attached to a graph edge must therefore carry a timestamp and a decay function, so that a signal observed thirty seconds ago and the same signal observed thirty days ago are not treated as equivalent.

None

Decay also gives the model a safe way to cool down. Without it, every historical observation accumulates forever and eventually every edge looks hot, which is simply alert fatigue rebuilt inside the graph. With it, the graph understands both structure and time — and a high-risk static path becomes genuinely urgent at the moment current evidence begins illuminating its edges.

11. Where different architectures start

It is tempting to ask which platform detects this class of attack. That is the wrong question, because all mature platforms detect it in some form. The better question is what evidence a given architecture collects natively, and where it needs help. Four archetypes are worth distinguishing, because most real products are a blend of them and their starting point predicts their blind spot.

None

There is no winner in that table, and picking one would miss the point. Each archetype begins at a different layer of Figure 4, and the architecture we ultimately want is the one that closes all four. What a buyer should evaluate is not the detection catalogue, but the joins: whether workload evidence can be related to the identity that the workload assumed, whether that identity's API activity can be related to the data it touched, and whether all of it lands on the same graph the exposure team already uses. The joins are where these products actually differ.

12. The architecture becomes a loop

Put the pieces together, and the platform stops being a pipeline that terminates in a dashboard. It becomes a loop.

None

The final step is the one most often skipped. After containment, recompute the graph and verify that the path is gone. Not that the ticket is closed, not that the alert stopped firing — that the traversal no longer resolves. This is the difference between a graph that is merely visualised and a graph that participates in defence.

13. From "could happen" to "is happening"

Attack-path analysis began as a way to reduce vulnerability noise. That was necessary work, and Part I argued for it at length. But it is not where the idea ends. Once runtime telemetry becomes part of the graph, one architecture supports exposure management, threat detection, investigation, and response — and the same model answers a different question at each phase of an incident.

None

Do not just map the paths an attacker could take. Continuously prove which paths are becoming real.

Part I moved us from findings to paths. Part II moves us from paths to evidence. The graph was always the right data structure; runtime telemetry is what finally makes it a live one.