Research-and-Methodology/Command and Control/README.md at main · HaydnZK/Research-and-Methodology
Haydn K. — Lead Community Operator
The Anatomy of a Beacon: Understanding C2 Communication
When an attacker breaches a network, they don't want to maintain a constant, open connection back to their machine. That is way too noisy, and modern firewalls will drop an interactive reverse shell connection almost instantly. Instead, they use a Command and Control (C2) beacon that sits quietly in the background of a compromised server, wakes up on a set timer, asks the server for commands, and goes right back to sleep.
Think of it like a spy checking a dead drop. They aren't standing there waiting for instructions all day. Instead, they just walk past the drop site once an hour, check if a message is left for them, and move on.
During my research into this technique, I focused on how modern open-source frameworks like Sliver use asynchronous communication to hide in plain sight. By using randomization, known as jitter, the malware can constantly change up its check-in times. For example, if a beacon is set to check in every 60 seconds with a 20% jitter, it might wait 48 seconds the first time and 71 seconds the next. This makes the automated script look a lot more like a regular human browsing the web.
The Blue Team Perspective
As a defender, you can't rely on static indicators like IP addresses or domain names because threat actors rotate their infrastructure constantly. You have to hunt for the behavioral footprints left behind on the network:
- Statistical Beaconing Analysis: Since normal user traffic is chaotic and malware is programmatic, we can look for consistent frequency distributions in outbound web connections. Even with jitter turned on, statistical analysis can spot the rigid math behind the check-ins.
- JA3/JA4 TLS Fingerprinting: Most C2 traffic is encrypted over HTTPS, meaning we can't see the text inside the packets. However, we can look at the unencrypted TLS handshake before the encryption happens. Frameworks like Sliver are written in Go, which leaves a distinct cryptographic signature that we can flag right at the network boundary.
- Protocol Anomalies: Attackers love to abuse standard administrative traffic that firewalls usually let slide. Monitoring for high volumes of unique subdomains via DNS tunneling, or looking for oversized data payloads inside standard ICMP pings, can reveal hidden command channels.
Mapping these technical catches to business-level compliance frameworks like ISO 27001 (A.8.16) or NIST 800-53 (SC-7) is how we prove our defenses are actually working. It translates a technical hunt into a major governance win for the organization.
I put together a deep-dive research write-up on this, which includes a simple, step-by-step quick-start guide for spinning up listeners and generating a basic Linux beacon in a lab setting.
You can find the full research documentation on my GitHub here:
https://github.com/HaydnZK/Research-and-Methodology/blob/main/Command%20and%20Control/README.md
If you were setting up a lab to study how malware talks to a server, would you want to look at the web traffic logs on the network side, or would you find it easier to look at the process logs on the target computer first? Let me know what you think below!
2 reactions · 0 comments