Building a Live Attack Graph: From Static PDFs to Replayable Context
Sina Khoraman
Software Engineer
Most penetration tests produce a ton of shell output, notes, screenshots, half-remembered SSH-inception tunnels and a final report of everything. That is so 2016.
We can’t rely on a single, static snapshot of a company’s IT security anymore. Instead, we need to build an ever-changing, real-time model of the IT environment and the responsible personnel. We want to showcase what changed, what exists, what talks to what, who is responsible for what, which paths lead to NTDS.dit, and replay it all over again.
Imagine a purple team seeing a DCShadow attack unfold in real-time within a live graph, observing exactly how it alters the data flow.
All of this results in a centralized, interconnected system represented as a time-traveling graph, and this could be categorized as:
The Data Plane: Captures observations, evidence, entities, relationships, timestamps and origin.
The Control Plane: Decides what to test next, tracks competing hypotheses, assigns work and manages the mission.
1. The Data Plane: Capturing Chain of Custody & Context
In the Data Plane, we record every single execution and its implications. Every terminal, browser, burp suite session and more, will be gathered into an ingestion pipeline. The data from these sessions will contain endpoints, services, packets, and also, more abstract objects such as permissions, identities, trust boundaries and resources will be ingested.
This is not a simple task, and adding to that, we also need provenance and several sources for higher confidence scores. Because raw security data is unstructured and noisy, every claim ingested into the model requires a strict chain of custody:
Provenance: If a permission node exists in the graph, you can trace it all the way down the chain to find what, when, who, and how that specific claim was ingested.
Source Linking: Command executions are persisted as source events. Ingestion links those events directly to the entities and relationships they produced. Findings can link back to action executions and reports can then reference real graph IDs instead of invented intermediate steps.
Why a Temporal Graph?
Compared to a normal static graph, our temporal graph answers the critical question: “How did we get here?” This also provides auditability. Every timestamped node becomes part of a replayable investigation. The UI can move a playhead through the graph, revealing the engagement exactly as it unfolded over time.
2. The Control Plane: From Chatbots to Mission Managers
If the Data Plane constructs the model, but the Control Plane decides what to do with it.
Most AI-agent systems today are simple chatbots. They have tools, prompts, and an MCP server, but they lack an actual control plane. The planner shouldn't merely generate the next command, it should manage the entire mission and roadmap.
That means coordinating agents, assigning work, modifying the roadmap, rejecting stale updates and using the Data Plane graph as its source of operational context.
This creates a fundamentally better collaboration model for humans and agents:
The human doesn't need to infer the agent’s internal state from a noisy chat log.
The agent doesn't need to reconstruct the mission from messy transcripts or raw user queries.
Both operate over the exact same explicit control plan. The mission, the roadmap, and the vision are what we are looking for, not just the next command to review.
3. Hypotheses as First-Class Control Plane Objects
Penetration testers do not work only from known facts; they rely heavily on hypotheses. For example:
This service account may be overprivileged.
Access tokens for testing that also work in the staging environment.
Hosts that have access to and bridge multiple network segments.
Today, these insights usually live in chat messages, notes or inside the penetration tester's head, making them hard to rank, test, delegate or reject.
By making hypotheses first-class objects in the Control Plane, we give the system a clean way to model uncertainty:
The two are connected by evidence relationships because we do not want speculative ideas polluting the confirmed graph. But we do want speculative ideas to be visible, testable, and ranked.
Modeling Potential Nodes & Explainable Trust
Potential nodes are also a way to model expected but unconfirmed objects. For example, if an application exposes /api/login, the system might hypothesize an admin route, an identity provider, a session store or a privilege boundary. Those should not be treated as discovered assets but they are useful planning nodes.
Hypotheses require trust relationships, not just a simple confidence score. The graph should contain confirmed objects. But penetration testers also need to reason about hidden or potential objects: an unseen admin panel, an assumed path, a likely credential reuse pattern or a suspected route between network segments. The penetration testers get the benefit of speculative reasoning without losing the integrity of the evidence graph.
Trust relationships should also be explainable. This is because a hypothesis needs to be trusted based on specific graph evidence, weakened by specific failed actions, or blocked by untested assumptions.
Conclusion: Reimagining Security Testing
By combining a time-traveling Data Plane with a hypothesis-driven Control Plane, we move beyond passive scanning into true operational intelligence.
At NRDSNIPE, we utilize time-traveling graphs to their fullest extent, providing the explainable trust and deep operational context needed to fundamentally improve security testing.