Defend: contain the research model

You are investigating a simulated incident. Several endpoints are generating encrypted network activity, payload inspection gives little value, and the destination set keeps changing. Your job is to find the malicious behaviour, contain it with minimal collateral damage, and learn what still survives rotation.

How to read this simulation

What the logs actually mean

The simulation feeds you the same telemetry classes a real SOC would see. Each class reveals a different detection surface. The trick is not to trust one signal, but to watch how signals behave when the adversary adapts.

DNS telemetry

Each row shows an endpoint, a query name, a record type, and a response. Look for:

Queries to infrastructure names that do not match normal browsing. A workstation that resolves cdn-04.example, proxy-03.example, and worker-0.example in the same ten-minute window may be following a rotation schedule.
Low query volume but high regularity. Legitimate DNS is bursty and diverse. Repeated lookups for a small set of abstract infrastructure names can indicate a managed connection.
NXDOMAIN followed by immediate success. The simulated model retries across paths; a failed lookup that is immediately replaced by another can reveal weighted path selection.

What DNS cannot tell you: It cannot reveal payload content, command semantics, or whether a destination is malicious by name alone. Names are arbitrary.

Network telemetry

Each row is a connection: source, destination, port, protocol, bytes, duration. Read it for four things:

Destination persistence. One host talking repeatedly to one destination is the classic beacon signal. In this model, that signal is intentionally weakened by path diversity.
Timing distribution. Inter-event gaps that stay inside a narrow band (for example, 45-90 seconds) suggest an automated process, even if the destination changes.
Byte patterns. Consistent small outbound requests followed by occasional larger inbound responses are the heartbeat-plus-burst shape of poll-and-command traffic.
Directionality. Outbound TLS to abstract infrastructure from a process that is not a browser is more interesting than the same traffic from a browser.

TLS telemetry

TLS reveals the client, not the content. Pay attention to:

JA4 fingerprint. A fingerprint that matches a cloud-worker runtime but appears on a workstation process is a process-identity mismatch. In this simulation the fingerprint is consistent across beacons.
SNI. The requested name may be a shared CDN or proxy domain. SNI alone is not evidence; SNI combined with the same JA4 and the same timing distribution is stronger.
Certificate metadata. Wildcard, short-lived, publicly trusted certificates are normal at the edge. They do not distinguish malicious from benign traffic.

Why TLS matters: It survives end-to-end encryption. You do not need plaintext to notice that the wrong process is making the wrong kind of handshake.

Proxy / CDN telemetry

This is what an inspecting proxy or edge log records. Rows include method, path, response size, and a rough event shape. Look for:

POSTs to analytics-shaped paths. Repeated POST /v2/batch events with no surrounding GET traffic to the same host are unusual for a real analytics integration.
High-entropy base64 fields. Fields like sdk_payload containing long base64 blobs inside JSON event structures warrant closer inspection.
Size consistency. Idle polls cluster around a tight byte count; command deliveries produce larger, less frequent responses. That bimodal pattern survives encryption.

Endpoint telemetry

Endpoint telemetry is the hardest for the adversary to change. It includes process name, parent process, user context, and host identity. Ask:

Which process owns the connection? A binary named code-helper.exe or update-agent.exe that initiates encrypted sessions to abstract infrastructure is suspicious when the parent is not a recognised installer.
User context. Activity that moves across users in a coordinated way, or that runs from unlikely accounts, is worth flagging.
Host rarity. A behaviour that appears on only a few hosts in the fleet, while the rest show normal browsing, is a clustering candidate.

Behavioural telemetry

Derived summaries: periodicity scores, path diversity counts, cross-host similarity. These are the outputs of correlation, not raw events. Use them to:

Confirm suspicion. A single endpoint with low periodicity but high path diversity is ambiguous. Several endpoints with similar non-periodic structure is a stronger signal.
Detect rotation. When an individual destination is blocked and the same behavioural pattern reappears elsewhere, the detection has survived infrastructure change.
Avoid chasing hosts. The score tells you whether the behaviour is durable; blocking one destination only tests that.

Decision guide

How to choose an action

Every response has a cost and a consequence. The simulation scores you on accuracy, containment, false positives, evidence preservation, and whether your final detection survives rotation. Aggressive blocking usually loses points.

Action	When to use it	Cost / risk	What the simulation teaches
Isolate endpoint	You have identified a compromised host and need strong containment.	High user disruption. May interrupt business activity.	Isolation works, but if your detection depends only on the destination, the next host may already be using a different path.
Block IP	A single destination is clearly tied to malicious activity.	Low direct cost; easy to rotate around.	Blocking one IP rarely ends the incident. The simulation shows how quickly a path can reroute.
Block domain	A domain is consistently associated with malicious behaviour.	Collateral disruption if the domain is shared with legitimate services.	Shared CDN domains make domain blocking expensive. The simulation penalises collateral damage.
Terminate process	You have pinned malicious activity to a specific process and want to stop execution.	Risk of destroying evidence; may not remove persistence.	Process termination is precise, but it assumes you already understand the endpoint behaviour.
Increase telemetry	You need more evidence before acting.	Resource cost; may generate noise.	Higher fidelity makes correlation easier, but it does not replace a good hypothesis.
Create correlation rule	Multiple endpoints show similar timing, paths, or process behaviour.	Time and tuning. False positives if the rule is too broad.	This is the durable move. A rule based on behaviour survives when destinations change.

Key insight

The best defensive decision in this simulation is usually not the fastest block. It is the one that identifies a property the adversary cannot change easily: endpoint process behaviour, timing distribution shape, or cross-host correlation. Infrastructure identity is the easiest thing for the model to rotate.

Live exercise

Investigate and contain

Pick a difficulty, inspect the telemetry, take actions, and watch the simulated adversary respond. The defender log records what your decisions expose.

Tutorial: step-by-step guide

Welcome to the exercise. Start by selecting an endpoint from the list on the left. In a real incident you would not know which host is compromised, so look for patterns rather than colour.

Open the DNS log card. Look for repeated queries to infrastructure-style names that do not match normal browsing. One or two queries is normal; a rotating set is not.

Now open Network. Check whether the same host makes small outbound connections at regular intervals, even if the destinations change. Timing is harder to rotate than infrastructure.

Open TLS and compare the fingerprint to the process. A non-browser process with a cloud-runtime fingerprint is a process-identity mismatch.

Use the Endpoint log to see which process owns the connection. Suspicious processes often have generic names and no recognised parent installer.

When you are confident, choose an action. Isolation is strong but disruptive. A correlation rule is slower but survives rotation. Finish to see your after-action report.

Endpoints

Select a host to investigate. No risk scores are shown; make the decision from the logs.

Select an endpoint to inspect its telemetry logs.

Actions

Some actions target the selected endpoint; others apply globally.

Score

Try the Attack simulation

Defender Log

Score

Try the Attack simulation

After-Action Report

How did your detection hold up?

Now try the Attack simulation Review the traffic research Read detection surfaces

Leaderboard

Defender rankings

Scores are computed locally for demonstration. They measure performance against a standardised simulation, not competition with other players.