Can we predict what an attacker does next?
Can we predict what an attacker does next?
Concept: Temporal Cybersecurity & Network World Models
Context: Smart India Hackathon 2026 · PS 26153
The Problem
Most network security systems are built around a familiar question:
Is something malicious happening right now?
Our problem asked us to think one step further:
Given everything happening in the network right now, what is the attacker likely to do next?
That difference sounds small, but it changes almost everything.
An attack is not a collection of independent events. Reconnaissance can lead to exploitation. Exploitation can lead to persistence or lateral movement. The network itself changes as those actions happen.
If we wanted to forecast attacker behaviour, we first needed the model to understand the state of the network at a point in time, and how that state evolves.
That became the central idea behind CyberWorld, our SIH 2026 project for PS 26153, AI based Network Attack Forecasting from Network Traffic Data.
The First Model Failed
Our first instinct was to treat this primarily as a model-selection problem.
We built a first version.
It did not work the way we wanted.
In fact, one of our early versions was beaten by Logistic Regression.
That was painful, but it forced us to ask a much better question:
What exactly are we giving the model to learn from?
Instead of immediately reaching for a larger or more complicated architecture, we went back to the data and the representation.
This became one of the biggest lessons of the project:
Better ML does not always start with a better model. Sometimes it starts with a better representation of the problem.
Turning Network Traffic into World States
We were working with roughly 700 GB of networking data.
Treating that data as independent rows loses something fundamental: time.
We wanted every point in the sequence to describe the network as a state.
So we moved toward two-second network states.
Each state represents observable network behaviour during a small temporal window. Flows, packet behaviour, timing and communication relationships are transformed into features that can be consumed consistently by the modelling pipeline.
The live system follows the same idea. Traffic is captured passively from a SPAN or mirror interface, converted into flow and behavioural features, and aggregated into two-second windows.
The result is a sequence of network states:
S(t-4) → S(t-3) → S(t-2) → S(t-1) → S(t)
The goal is no longer to classify one row.
The goal is to understand the trajectory.
36+ Experiments to Understand the Data
Before arriving at the final architecture, I ran 36+ experiments around LSTM-based approaches.
The purpose was not simply to collect metrics.
I wanted to understand what the data was actually capable of teaching us.
Which temporal relationships mattered?
Which features carried useful information?
What should be represented explicitly?
What was the model learning, and what was it simply memorising?
Those experiments changed how I thought about the problem.
The bottleneck was not just the choice between one neural network and another. We needed a representation that reflected what a network actually is.
A network is not a table.
It is a graph that changes over time.
From Tables to Temporal Graphs
For each network state, we represented the observed communication structure as a graph.
Hosts → Nodes
Communication → Edges
Network state → Graph snapshot
Time → Evolving graph
The communication graph captures who is talking to whom, while the edge representation captures observable properties of those flows.
Our TGNE-TA/BiTA stage learns a compact representation of that graph and maps the host state into a 12-dimensional latent representation.
That representation is then combined with 15 temporal/network attributes, giving Branch A a 27-dimensional representation of the current host state.
This was a major conceptual shift.
Instead of asking the model to infer network structure from a flat vector, we explicitly gave it structure.
The Final Architecture
The final live path is a dual-branch forecasting system followed by the DeepOP decoder.
SPAN / MIRROR TRAFFIC
│
▼
Packet + Flow Telemetry
│
▼
2-second windows
│
▼
Temporal Graph
│
▼
TGNE-TA / BiTA
│
12-D latent H
│
+ 15 temporal attributes
│
27-D representation
┌────┴────┐
▼ ▼
Branch A Branch B
LSTM WDT
│ │
│ ├── Future latent states
│ │
▼ ▼
Current risk Future trajectory
+ ATT&CK + future state
stage
└────┬────┘
▼
DeepOP / CWA
│
▼
Future ATT&CK sequence
Branch A: What is happening now?
Branch A is a multi-task LSTM.
It looks at the current sequence and jointly estimates:
- near-term compromise risk
- MITRE ATT&CK technique
- attack gradation/severity stage
The model uses temporal attention over the sequence, allowing the current prediction to incorporate relevant information from previous network states.
This branch answers:
Where are we in the attack right now?
Branch B: What happens next?
Branch B is the World Dynamics Transformer.
Rather than directly predicting an attack label, it operates in the learned latent space and performs an autoregressive rollout of future latent network states.
For the live configuration, the temporal contract uses:
- 2-second state windows
- 5 historical steps
- up to 8 forecast steps, corresponding to roughly 16 seconds of forward horizon
The important idea is that the model is not trying to magically predict an ATT&CK label from a single observation.
It first tries to model how the state itself evolves.
H(t)
│
▼
H(t+1)
│
▼
H(t+2)
│
▼
...
│
▼
H(t+K)
That gives the downstream decoder a predicted trajectory rather than an isolated prediction.
DeepOP: Turning Future States into Attack Forecasts
The future latent states are passed to the DeepOP decoder.
DeepOP uses Causal Window Attention (CWA) to reason over the predicted sequence without allowing future information to leak backward.
Its job is to translate the predicted evolution of the network into a sequence of likely MITRE ATT&CK techniques/stages.
So the overall system becomes:
Observed network
↓
Current state representation
↓
Current risk + current ATT&CK stage
↓
Predicted future states
↓
Predicted future ATT&CK sequence
This is the distinction that mattered most to us.
We were not satisfied with:
“There is an attack.”
We wanted to move toward:
“This is where the attack appears to be now, and based on how the network state is evolving, these are the stages that may follow.”
Building for a SOC, Not Just a Model
A prediction is not very useful to a security operator if it arrives as an unexplained number.
We therefore also built an explainability layer around the inference pipeline.
The system can surface information such as:
- temporal attention over recent observations
- feature attributions
- gradient-based attribution
- causal campaign context
- an operator-oriented narrative
The idea is simple:
The system should help an analyst understand why a prediction deserves attention, not just display a score.
This is especially important in a forecasting system, where an operator needs to understand the evidence behind a predicted trajectory.
The Network Behind the Model
A major part of making this possible was the networking infrastructure I built for the project.
Instead of feeding the ML pipeline purely fabricated rows, we built an actual isolated enterprise-style cyber range using ContainerLab.
I built and simulated an isolated enterprise-style network with segmented users, servers and DMZ infrastructure, routing and firewall layers, workloads, and an isolated external attacker environment.
Traffic is mirrored to a passive sensor.
The sensor observes the network without sitting inline in the forwarding path, turning real packets from the simulated environment into the telemetry consumed by the rest of CyberWorld.
That separation was important.
The network environment could behave like a network, while the telemetry pipeline could observe it like a real SOC sensor would.
And because the system is discovery-first, the topology is built from observed communication rather than simply drawing a hardcoded attacker diagram.
The Engineering Problem Behind the ML Problem
One of the things I appreciated most about this project was how tightly the ML and systems sides were connected.
The model depends on the representation.
The representation depends on the telemetry.
The telemetry depends on the network.
And the network needs to generate behaviour that is meaningful enough for the model to learn from.
The pipeline became:
ContainerLab
↓
Real network traffic
↓
Passive packet capture
↓
Flow tracking + behavioural features
↓
2-second temporal states
↓
Temporal graph representation
↓
Latent network state
↓
Current-state prediction
↓
Future-state rollout
↓
ATT&CK forecasting
↓
SOC explanation
A failure anywhere upstream can make the model look broken downstream.
That is exactly what happened to us more than once.
The Part That Doesn't Show Up in the Architecture Diagram
The architecture is clean now.
The process was not.
A few days before the hackathon, Vyom Khanna had been working on the ML side for days.
Research papers.
Experiments.
Training runs.
Changing the model.
Breaking things.
Trying again.
At one point, after barely sleeping, Vyom's eyes were visibly swollen.
He was still working.
There was always another experiment to run, another result to understand, another part of the representation that could be improved.
Then, on submission day, the model pipeline broke.
The hackathon was around 11 AM.
At 6 AM, I was still fixing the networking/backend side of the system.
There was no elegant research workflow at that point. It was just debugging, testing, and trying to get the entire pipeline into a state where we could actually present it.
And that was the story of the team as a whole.
Someone was working on the frontend.
I was handling the networking and ContainerLab side.
Everyone had a different part of the system, but none of those parts mattered unless they could come together.
What I Learned
The biggest lesson I took away from CyberWorld was not a particular architecture.
It was a way of thinking about ML problems.
When a model performs badly, the first question does not always have to be:
“What model should I try next?”
Sometimes it should be:
“Is the problem represented correctly?”
Our journey went roughly from:
700 GB of network data
↓
2-second network states
↓
36+ LSTM experiments
↓
Temporal graph representation
↓
12-D latent network states
↓
Current-state multi-task prediction
↓
Future latent-state rollout
↓
MITRE ATT&CK forecasting
↓
Explainable predictions
The model got better when our understanding of the problem got better.
That was the part I did not expect to learn when we started.
And Then We Qualified
After weeks of experiments, research papers, broken models, integration issues, late nights and last-minute fixes, Team Git Push and Pray qualified through the SIH 2026 internal round at TIET.
The qualification matters.
But for me, CyberWorld matters because it was one of the biggest ML/DL projects I have worked on so far.
It forced me to move beyond simply training a model and into the much harder questions:
What should the model see?
How should a changing system be represented?
How do we model what happens between observations?
How do we turn a prediction into something a human can actually use?
There is still a lot we want to improve.
But that is also what makes the next stage exciting.
Git Push and Pray made it through the internal round.
Now we get to see how far we can take CyberWorld.