C2 Server Detection Lab: Sliver, Chisel and frp Beacons
A C2 server hides in ordinary traffic, so you find it by pattern, not by port. In this lab you review synthetic proxy, flow and process logs for a fictional company, spot beaconing and reverse tunnels of the kind that frameworks and tunnel tools produce, tell them from update and telemetry traffic, and make 11 scored calls on detections, egress and containment.
Practise the wider hunt in the Detection Lab, sort the resulting alerts with Case Triage, and see the egress side in the Agent Egress Containment Lab. Everything here is invented and contains no tool commands.
You are Priya Nair, a SOC analyst at Northgate Logistics. A threat hunt has pulled synthetic proxy, flow and process log excerpts from a few workstations and a server. Over 11 scored decisions you read the evidence like a defender: recognise beaconing, separate it from legitimate update and telemetry traffic, spot reverse tunnels and port forwards, then choose detections, egress controls, containment and evidence handling. Everything is invented (addresses are from the documentation ranges, domains are example.com) and nothing here explains how to operate any tool.
This is the guided version: a yellow flash shows where to click and a bar says what to do. Switch to Free play any time.
GuidedPress the highlighted Start button. You can edit the names above first, or keep the samples.
Make it yours
Replace the sample names so the scenario and the debrief you export are about your organisation.
Loading…
Sample report · illustrative data
Sample result: C2 detection review
Example run of an 11-decision review of invented proxy, flow and process logs for a fictional company.
Scoring
- Score
- 74% (example)
- Band
- Solid, with blind spots
- Decisions at full marks
- 6 of 11
- Weakest area
- Separating legitimate update traffic from beacons
Per-decision outcome
| Decision | Choice | Outcome |
|---|---|---|
| Is this beaconing? | Fixed interval, constant size, no user present | Full marks |
| Jitter | Looked for a narrow band, not an exact clock | Full marks |
| Update and telemetry traffic | Suppressed all regular traffic | Low: removed the signal |
| Long-lived outbound connection | Suspected a tunnel from a server | Full marks |
| Authorisation | Accepted a verbal explanation | Low: no record |
| Containment | Isolated, kept powered on, preserved evidence | Full marks |
Debrief
C2 hides in standard protocols, so detect behaviour: regular timing inside a band, constant small sizes, a process with no network history, outbound sessions from hosts that should not have them, and unusual TLS client fingerprints. Baseline legitimate software, require a change record for any tunnel, layer detections, restrict egress and preserve evidence before you rebuild.
Made-up example data. Your own run uses your inputs. Downloads of the full report need Pro.
TL;DRWhat this is
5 points
- A scenario lab where you are a SOC analyst reviewing synthetic proxy, flow and process log excerpts at a fictional company, looking for command and control (C2) beaconing and reverse tunnels.
- You make 11 scored decisions: recognising beacon timing and jitter, separating it from update and telemetry traffic, finding the owning process, using TLS metadata, reading long-lived outbound tunnels, detecting behaviour of tunnel and reverse-proxy tools, checking authorisation, layering detections, egress controls, containment and evidence.
- It draws on MITRE ATT&CK pages for Application Layer Protocol (T1071), Protocol Tunneling (T1572), Proxy (T1090) and Encrypted Channel (T1573), and on the public Chisel and frp project descriptions.
- The log excerpts are invented and use documentation addresses and example.com. The lab shows what defenders see; it contains no commands for any tool and no real indicators.
- Defensive and educational only.
Frequently asked questions
What is a C2 server?
A command and control (C2) server is infrastructure an attacker uses to communicate with compromised systems. MITRE describes adversaries using standard application-layer protocols so that C2 traffic blends with normal traffic (Application Layer Protocol, T1071). Defenders find it through patterns in that traffic and the processes behind it.
What is a C2 framework and how is it detected?
A C2 framework is software that provides the server side and the implant side of that communication. This lab does not teach any framework's use. Detection is behavioural: regular check-in timing, uniform small payloads, a process with no network history making connections, unusual TLS client fingerprints and long-lived outbound sessions. Names like Sliver in the lab title are search terms; the lab teaches behaviour that is common across tools.
How does C2 detection work for beaconing?
Analysts look at connection timing per process and destination: a narrow band of intervals, constant sizes and activity when nobody is at the keyboard. Legitimate updates and telemetry also look regular, so you baseline known software by signed process, destination and owner. The lab practises that separation. MITRE's T1071 detection notes mention beacon-like intervals and unbalanced traffic.
What is a Chisel tunnel and what does it look like to a defender?
Its project describes Chisel as "a fast TCP/UDP tunnel, transported over HTTP, secured via SSH", with automatic reconnects and reverse port forwarding. To a defender that is a long-lived outbound connection that looks like web traffic, plus repeated reconnects and new forwarding on a host. Detect the behaviour, not the file name. The lab shows no commands.
How are frp and reverse proxies used against defenders?
Its project describes frp as a fast reverse proxy that exposes a local server behind a NAT or firewall to the Internet; a client inside connects out to a server on a public address. Open-source reverse proxies have legitimate uses, so check authorisation and change records. MITRE's Proxy page (T1090) describes adversaries using proxies to avoid direct connections to their infrastructure.
How do I do command and control detection when traffic is encrypted?
Use metadata and context: destination, timing, sizes, TLS client fingerprint, certificate chain and, above all, which process made the connection. MITRE's Encrypted Channel page (T1573) points to unexpected outbound TLS from processes that do not normally connect and asymmetric volumes, and lists TLS inspection as a mitigation.
Sources
Read on 2026-11-08. Lines in the feedback marked “PlayCISO practice” are our own reasoning, not a statement by any source. The scenarios are fictional and use made-up data.
- MITRE ATT&CK T1071: Application Layer Protocol (blending C2 into standard protocols; detection notes on beacon-like intervals)
- MITRE ATT&CK T1572: Protocol Tunneling (tunnelling inside another protocol; asymmetric flows and forwarding)
- MITRE ATT&CK T1090: Proxy (proxies to avoid direct connections; allow and block lists, TLS inspection)
- MITRE ATT&CK T1573: Encrypted Channel (unexpected outbound TLS, atypical ports, TLS inspection)
- Chisel project README (project description: TCP/UDP tunnel over HTTP secured via SSH; read via raw.githubusercontent.com)
- frp project README (project description: reverse proxy for servers behind NAT or firewall; read via raw.githubusercontent.com)
More security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.