Attack: keep the research model alive
You are configuring a simulated Novich0k research-model deployment. An automated defensive system watches. Choose paths, timing, redundancy, and traffic shape, then adapt as detection pressure rises. The goal is to learn which architectural trade-offs buy the most survival time.
What the defender sees and why
The simulation shows the same detection surfaces a real defender would use. Every choice you make changes how those surfaces fire. The lesson is not to find a perfect configuration, but to understand the trade-offs.
Periodicity detection
The simulated defender measures how regularly events occur. A low timing-variance configuration produces tight inter-event gaps; the defender learns that quickly. A high timing-variance configuration makes the gap distribution wider, but the aggregate number of events per hour may still be stable.
- Low variance: easy periodicity detection. Fast initial alert, but also fast evidence for the defender.
- High variance: harder to detect with a simple interval rule. Cost: command latency becomes unpredictable, and the defender may switch to volume-based detection.
Destination correlation
When one endpoint repeatedly talks to one destination, the defender gets an easy IOC. Path diversity splits traffic across destinations, so no single destination stands out. The research question is whether the destinations themselves share properties: same provider, same registration pattern, similar JA4, or overlapping timing.
- Single destination: fragile. One block ends the channel.
- Multiple destinations with shared metadata: more resilient to simple blocking, but still correlatable.
Path diversity
More proxy/CDN paths mean more destinations to block. But each path costs credits and increases infrastructure footprint. A large footprint can itself become a signal if the defender notices many new, related edge names appearing together.
- Few paths: cheap, but concentrated and easier to enumerate.
- Many paths: harder to block individually, but more observable infrastructure.
Endpoint anomaly
The defender watches which process initiates sessions. A process that claims to be a code helper but sends analytics-shaped traffic with no browser parent is anomalous. You cannot change the endpoint identity without redeploying the simulated implant.
- High connection frequency: makes the anomaly more visible.
- Endpoint population: more endpoints distribute the anomaly, but also create more cross-host correlation if they behave similarly.
Infrastructure reuse
Reusing the same relay or proxy set across rotations is cheap, but it lets the defender carry detections forward. Rotating infrastructure resets destination-based indicators but costs credits and may create a rebalancing event that itself is logged.
- Reuse: efficient, but detection accumulates.
- Rotate often: resets IOCs, but the rotation event can reveal coordination.
Cross-host correlation
This is the strongest and hardest-to-avoid surface. If multiple endpoints share timing, paths, or process behaviour, the defender can detect the campaign without relying on any single destination. The simulated model tries to make individual streams look irregular; the defender recovers correlation by aggregating.
- Similar endpoints: easier to manage, but produce stronger cross-host signal.
- Diverse endpoint profiles: weaker correlation, but more complex to operate and easier to misconfigure.
How to configure and adapt
Every slider and button changes a trade-off. The simulation scores survival time, detection exposure, infrastructure efficiency, and number of adaptations. Maximum randomness is rarely the optimal strategy.
| Control | What it does | Stealth benefit | Cost / risk |
|---|---|---|---|
| Threshold proxies | Number of abstract proxy/CDN entry points. | More paths make destination blocking harder. | Credits and larger observable footprint. |
| Relay nodes | Number of threshold re-encryption relays. | Redundancy keeps the channel alive after node loss. | Credits; more nodes may share metadata. |
| Path diversity | Probability of switching destinations per connection. | Weakens single-destination IOCs. | May increase detectable infrastructure churn. |
| Timing variance | Width of the inter-event gap distribution. | Defeats simple periodicity rules. | Higher latency; volume patterns may still emerge. |
| Connection frequency | How often beacons check in. | Lower frequency reduces visibility. | Lower availability; may look unusual if too low. |
| Endpoint population | Number of simulated compromised endpoints. | Distributes activity across hosts. | More endpoints can strengthen cross-host correlation. |
| Redundancy | Backup paths held ready. | Survives sudden node loss or blocking. | Expensive; unused capacity is wasted budget. |
Rotate relay
Replace one relay with a fresh node. This resets destination and TLS metadata for that slice of traffic. Best used when detection pressure on a specific relay is high. Cost: credits and a rebalancing event that the defender may log.
Add proxy
Increase the number of entry paths. Useful when several destinations have been flagged. Cost: significant credits and a larger footprint. Repeated additions may make the infrastructure look like a fast-flux network.
Change timing
Increase timing variance to break periodicity detection. Cheap and effective against interval-based rules. Does not help against volume or cross-host correlation.
Redistribute endpoints
Move simulated endpoints to different paths. Breaks endpoint-destination pairing but may create a brief window where multiple endpoints share the same new destination, strengthening correlation temporarily.
Reduce activity
Lower check-in frequency. Reduces visibility but also reduces simulated command availability. Use when detection pressure is critical and you need to buy time for a better adaptation.
Switch provider
Move paths to a different abstract provider. Resets provider-based heuristics but is expensive and may cause a short outage. Best used after the defender has clustered several nodes by provider metadata.
Configure, initialise, adapt
Spend your infrastructure credits, start the simulation, and respond to detection pressure. The goal is to keep command availability as long as possible while learning which changes actually reduce risk.
Initialise Research Model
Every choice has a cost. Stay within the credit budget or the simulation cannot initialise.
Detection Pressure
The simulated defender observes the six surfaces above and responds. Pressure rises when your behaviour is regular, concentrated, or shared across endpoints.
Simulation Status
Adapt
Each adaptation costs credits and changes the defender's view. Choose based on which surface is firing highest.
How long did the model survive?
Operator rankings
Scores are computed locally for demonstration. They measure performance against a standardised simulation, not competition with other players.