C2 Frameworks: How Attackers Maintain Persistence

In the 2024 Change Healthcare breach, attackers dwelled inside the network for weeks before deploying ransomware. They weren’t guessing passwords the whole time — they had a C2 framework quietly phoning home, keeping a foothold while operators planned the next move. Understanding how that foothold works is the first step to finding it.

What a C2 Framework Actually Does

A Command and Control (C2) framework is the attacker’s remote management console. Think of it as a reverse RDP session, but designed to evade detection. The implant on the victim machine reaches out to the attacker’s server — not the other way around — which sidesteps most inbound firewall rules.

Popular frameworks include Cobalt Strike, Sliver, and Havoc. They all share the same core loop: beacon calls home on a schedule, receives tasks, executes them, sends results back. The beacon interval is often randomized to defeat simple frequency-based detection.

Here is what a Sliver implant beacon looks like on the attacker’s C2 console after it calls home from a compromised workstation:

[*] Beacon 4f3a1c2d  webdev-ws01  192.0.2.47:49832 -> 192.0.2.200:443
    OS:       Windows 11  (10.0.22631)
    User:     CORP\jsmith
    Process:  svchost.exe (PID 3812)
    Last:     3s ago
    Interval: 45s ± 15s jitter

The implant is running inside svchost.exe — a trusted Windows process. The jitter means it beacons every 30 to 60 seconds, not on a rigid interval. That irregular cadence makes it much harder to flag in network flow data. An attacker seeing this output knows they have a live session under a domain user with workstation access. Next step: privilege escalation or lateral movement.

How Persistence Survives a Reboot

A live session is useless if it dies when the machine restarts. Attackers layer in persistence mechanisms so the implant re-launches automatically. The most common methods on Windows are scheduled tasks, registry run keys, and WMI event subscriptions.

Here is a scheduled task created by an attacker to re-launch a beacon payload dropped at a plausible-looking path:

schtasks /create /tn "\Microsoft\Windows\NetTrace\DiagnosticsHub" \
  /tr "C:\ProgramData\Microsoft\DiagHub\diag.exe" \
  /sc ONLOGON /ru SYSTEM /f

SUCCESS: The scheduled task "\Microsoft\Windows\NetTrace\DiagnosticsHub" has successfully been created.

Notice the task name mirrors a real Windows namespace — NetTrace\DiagnosticsHub — to blend into a crowded task list. The binary lives in ProgramData, a writable directory that doesn’t require admin rights to write to in many configurations. It runs as SYSTEM on every logon.

A defender hunting this should immediately ask two questions: does that binary path exist on other machines, and what does the binary hash match in VirusTotal or your EDR? If diag.exe doesn’t appear in your software inventory, that’s your indicator. Pull the file, detonate it in a sandbox, and trace the C2 callback domain.

Finding the Traffic: What C2 Looks Like on the Wire

Most modern C2 frameworks tunnel over HTTPS to port 443, blending with normal web traffic. Cobalt Strike’s Malleable C2 profiles let operators disguise beacon traffic as Amazon browsing, jQuery requests, or Microsoft update checks. But the underlying pattern still leaks clues.

Running Zeek (a network analysis tool that parses connection metadata) on a PCAP from an infected segment often reveals the pattern:

#fields ts       uid         orig_h       resp_h       resp_p  duration  orig_bytes
1754214001.12  Cxw3fA...  192.0.2.47  192.0.2.200  443     0.21      412
1754214048.33  Czb9kL...  192.0.2.47  192.0.2.200  443     0.19      412
1754214091.55  Cqm2nR...  192.0.2.47  192.0.2.200  443     0.20      412

Three connections to the same external IP, each about 45 seconds apart, each sending exactly 412 bytes. Real user HTTPS traffic is bursty and variable. This is a metronome. The fixed payload size is a dead giveaway — the beacon is sending a check-in heartbeat with no task data, so the packet size stays constant.

From here, a defender pivots to the destination IP. Run it through threat intel (VirusTotal, Shodan, your SIEM’s reputation feeds). Check whether the TLS certificate is self-signed or issued to a recently registered domain. Both are strong C2 indicators. Block the IP, isolate the host, and start your IR process.

What To Do Right Now

Pull the last 30 days of scheduled task creation events from your Windows endpoints — Event ID 4698 in the Security log. Filter for tasks pointing to binaries in ProgramData, AppData\Roaming, or Temp. Those directories are writable without elevation and are a favorite staging ground for C2 persistence. If you find a task you can’t map to a known software deployment, treat it as a compromise until proven otherwise.