Stagers, Agents, and the Chain Between Them

This is part one of Delivery and Control, a series on C2 infrastructure, implant development, and stager tradecraft. We cover the how and the why, not just commands to paste.

The goal across this series is to build a real understanding of how post-exploitation chains work. How operators communicate with implants, how stagers get shellcode into memory, how C2 profiles blend into normal traffic, and where modern detections actually fire.

In the end you will have a working attack chain!

The Lab: South Park Range

Throughout this series we test against a purpose-built range, not a single throwaway VM. The range runs on Ludus, a self-hosted lab automation platform built for adversarial testing. If you have not set it up yet, do that first: Building the South Park Range with Ludus.

Four machines across three VLANs:

• Windows Server 2022 domain controller (southpark.com)
• Windows 11 workstation, domain joined, Office installed
• Debian redirector sitting between the targets and C2
• Kali running Mythic on its own segment

The targets can only reach the redirector on 80 and 443. The redirector proxies matching URI paths back to Kali. Kali is not directly reachable from the Windows segment. That is the architecture we build and test against throughout this series, the same model you would run on a real engagement.

Ludus handles provisioning, domain join, and snapshots. Deploy, take a clean snapshot, detonate, roll back, iterate. No rebuilding.

---

The Old Model

If you learned offensive security from a pentesting course or through CTF events, you probably started with Metasploit. Run msfvenom, stand up multi/handler, get a Meterpreter session. It works, and understanding it is useful, but it is also the thing every AV vendor has had signatures for since 2012.

Meterpreter is not dead. It is fine for internal assessments where detection is not a concern. But it is not what you reach for when you need to operate in a monitored environment, and it is not how modern C2 frameworks are architected.

In this series we will be introducing you to Mythic as our Command and Control (C2). More on this below!

---

The Moving Parts

A post-exploitation chain has three distinct components. Conflating them causes confusion.

The stager is what runs first on the target. Its only job is to fetch shellcode over the network, get it into memory, and execute it without getting caught. It does not contain the C2 logic. It reaches out to your infrastructure, pulls the agent shellcode down, and disappears. Stagers are disposable. You burn one, you write another. (A loader is a close relative that embeds the payload at compile time instead of fetching it, but the term stager is what we are building throughout this series.)

The agent (also called an implant or beacon, depending on the framework) is what runs after the stager does its job. It is the persistent piece. It calls back to your C2 server on a schedule, receives tasks, executes them, and returns results. The agent contains all the post-exploitation capability: process injection, credential access, lateral movement modules, file operations.

The C2 server is the operator-side infrastructure. It receives callbacks from agents, lets operators issue tasks, and manages sessions. It also defines the communication profile: what the traffic looks like on the wire, what domains it uses, how long agents sleep between check-ins.

---

Why Mythic

Mythic is an open source C2 framework built by @its_a_feature_. It is written in Go and uses a microservices architecture: the C2 server, the database, RabbitMQ, and individual C2 profile containers all run separately and communicate over a message bus.

The key design decision is that agents and C2 profiles are completely decoupled from the framework itself. You install them as separate containers. Want to switch from an HTTP profile to a DNS profile? Swap the container. Want to add a new agent written in Nim? Add the container. The framework does not care.

Mythic ships with a web UI that supports multiple operators, shared callbacks, task history, file management, and credential tracking. It is more infrastructure than a single tool.

---

Standing Up Mythic

Mythic is already installed on the Kali box in the South Park range. If you skipped that post, go back: Building the South Park Range with Ludus. The install steps are there.

If you are running Mythic somewhere else, the short version: Docker, Docker Compose, clone the repo, make, then ./mythic-cli start. Do not run C2 infrastructure on shared hosting or anything tied to your real identity on a real engagement.

The UI is at https://<kali-ip>:7443. For the range that is https://10.X.200.5:7443.

---

Generating a Payload

In the Mythic UI, click Payloads then Generate New Payload.

Walk through the wizard:

1. OS: Windows
2. Agent: Apollo
3. C2 Profile: http
4. Output format: exe (for now; later posts cover shellcode and reflective DLL)

Under the HTTP profile config, set the callback host to the redirector, not Kali directly. In the range that is 10.X.100.10, or c2.redir.ludus if you are using the DNS rewrites. The callback URI needs to match one of the paths the redirector is configured to forward, /l33t for HTTPS. Set a callback interval and jitter. 60 seconds with 20% jitter looks more like legitimate software than a flat 5-second interval.

Click Create. Mythic builds the agent with your parameters embedded and makes it available for download.

---

What the Chain Looks Like

When the payload runs on a target:

1. The executable reads the embedded config: callback URL, sleep interval, kill date
2. It makes an HTTPS request to the redirector (10.X.100.10/l33t)
3. The redirector matches the URI against its rewrite rules and proxies the request to Kali
4. Mythic's HTTP C2 profile container receives the callback and hands it off to the Mythic core over RabbitMQ
5. Mythic registers a new callback in the UI
6. The agent polls at its configured interval, picks up queued tasks, returns results

The target never talks to Kali directly. From the network's perspective, it is making HTTPS requests to what looks like a web server. The redirector is what separates C2 traffic from everything else, forwarding only requests that match the configured URI patterns.

Apollo's traffic is encrypted. The HTTP profile shapes what the conversation looks like on the wire: URI patterns, headers, User-Agent, response bodies. That is C2 profile tradecraft, covered later in the series.

---

What Comes Next

This post covered the concepts and stood up a basic Mythic instance. The rest of the series goes deeper:

• Writing a Stager: a shellcode stager in C that fetches Apollo over the network in chunks and executes it with NT-layer calls
• Injection techniques: process hollowing, early bird, thread hijacking, and when each makes sense
• C2 profiles: customizing the HTTP profile to blend into expected traffic for a target environment
• EDR evasion basics: how modern endpoint detection works and where stagers get caught
• DNS C2: operating over DNS when HTTP is monitored or blocked
• Infrastructure: domain fronting, and hardening the redirector for real engagements

Each post builds on the last. By the end you will have a working stager, a configured Mythic agent, and a clearer mental model of how the whole chain operates and where it breaks.