Disposable Tooling: Generating Mythic C2 Agents End-to-End With LLMs

Executive Summary

Building a working agent for a command-and-control framework like Mythic has traditionally been a multi-day engineering exercise: you have to wire up RabbitMQ-based RPC messaging, a Docker container for the server-side logic, builder and tasking-handler code, and the implant itself. This research asks a blunt question — can a modern coding LLM take a single-paragraph specification and produce a complete, deployable Mythic agent with no human writing code? The short answer is yes, but only once the model is wrapped in enough scaffolding to keep it honest.

Naked prompting fails: the models hallucinate RPC methods, miss packages, mangle the key-exchange flow, and emit code that looks clean but never checks in. The breakthrough is a tiered build-and-test harness (nicknamed “Oracle”) that forces the model to validate its work against a mock server, then a live Mythic deployment, then an independent QA sub-agent — before it is allowed to declare success. With that loop in place, the author generated functional stage-0 agents in Python, Go, Zig, C#, and Rust in roughly one-and-a-half to two hours each. The strategic takeaway for defenders: cheap, throwaway, per-engagement implants are now realistic, and static signatures age out faster than ever.

From Apfell to Mythic

Mythic grew out of the Apfell project and matured into a framework that deliberately separates agent development from the C2 architecture itself. That separation is what makes the experiment tractable: an agent author can focus on the implant and its tasking logic while the framework handles transport and orchestration. The goal of the research was to push that decoupling to its logical extreme — have a language model carry an agent all the way from an initial spec to a deployed payload without a human touching the source.

What a Mythic Agent Actually Requires

A complete Mythic agent is more than the binary that lands on a target. The moving parts the model has to get right include:

• Mythic RPC messages — the RabbitMQ-based plumbing that lets framework components talk to one another.
• A Docker image — the containerized server-side application that consumes those RPC messages.
• Builder code — Python/Go that receives RPC build requests from operators and produces the payload.
• Tasking-handler code — the layer that turns operator commands into instructions the implant understands.
• The agent itself — the implant that runs on target, whether freshly compiled or a patched pre-compiled binary.

Obligatory Disclaimer

The author is candid that this is experimentation, not a controlled study. The work used a coding agent (primarily Opus-class models, later ported to GPT-5.x “Cyber” variants) with the harness evolving continuously throughout. Many variables changed along the way, so the results should be read as a directional demonstration rather than a benchmark. OpenTelemetry logging was added to capture each run for later analysis.

First Attempts: Just Vibes

The naive starting point was a plain-English specification handed straight to the model — name the agent, target Windows on x86/x64, support EXE/DLL/shellcode output formats, and implement a fixed command set, with an explicit instruction not to ask follow-up questions. Paraphrasing the requested capabilities, the agent was asked to provide:

• ls — list directory contents
• cd — change the working directory
• pwd — print the working directory
• shell — run commands through cmd.exe
• download — pull a file from target back to Mythic
• upload — push a file from Mythic to the target
• execute — run a program via the Windows CreateProcess API
• stage — load and run a second-stage implant

The output looked plausible and compiled, but it did not work. Failures clustered around the same themes: missing packages in the Docker build, wrong paths, invented RPC methods that do not exist in Mythic, and a misread of how key exchange is supposed to flow. The lesson was that surface-level correctness is the easy part; the model needed a way to actually run its agent and feel the failures.

When All Else Fails, Try Markdown

The first real improvement came from giving the model structured reference material rather than more prose in the prompt. The author built a mythic-implant-development Skill — essentially a curated Markdown knowledge base describing how Mythic agents are put together — and included a concrete proof-of-concept (a Swift example) so the model had a known-good shape to imitate.

With the Skill in place the model produced an agent that actually compiled and was close to functional, needing only minor manual fixes. Progress — but “a human still has to step in” is not the same as “prompt to deployment,” so the next step was to automate the testing the human was doing by hand.

Introducing a Supporting Harness

The core idea is to give the model a fast, deterministic way to test its own work and feed failures back into the next iteration. The harness was split into two stages of increasing fidelity.

Stage 1 — Mock Mythic Server

A lightweight mock server runs locally and lets the agent be validated at the protocol level — crypto, key negotiation, and command handling — without the cost of a full deployment. The trick that makes this work is decoupling the agent’s business logic from OS-specific APIs, so the protocol behavior can be exercised on its own.

Stage 2 — Live Mythic Deployment

Once the protocol layer holds up, the agent is deployed for real: a Windows 11 workstation as the target and an Ubuntu 24.04 host running Mythic. The model is handed credentials and SSH access and drives full integration testing through the Mythic API — check-in, key exchange, and a tasking round-trip against an actual server.

The Oracle Framework

Tying the stages together is “Oracle” — a project layout plus a CLAUDE.md instruction set that enforces a tiered testing pipeline the model is not allowed to short-circuit. In broad strokes the tiers work like this:

1. Tier 1 — fast local validation: build for the local OS/arch, run unit tests (agent logic, crypto, serialization, config parsing) and protocol tests against the mock server, lint, and confirm check-in plus key exchange. A hard rule forbids “fake” tests that don’t actually invoke the agent’s own code, and Tier 1 may not be skipped. On failure, fix and re-run Tier 1 before going further.
2. Tier 2 — remote validation against a real Mythic server: only attempted once Tier 1 passes. Upload a debug build, deploy to a target, and verify check-in, key exchange, and a tasking round-trip for every supported command type (SOCKS/port-forwarding being the allowed exceptions where the lab can’t test them). Any failure sends the model back to Tier 1.
3. Tier 3 — QA validation of a release candidate: only after Tiers 1 and 2 pass. A release build is deployed and an independent quality-assurance sub-agent tests it end-to-end and returns a PASS/FAIL with detailed reasoning. A FAIL forces a fix and a full re-run from Tier 1.

The author reports this collapsed agent development from a multi-week effort into a matter of hours.

Improving the Feedback Loop

Even with the tiers defined, the model needed better tooling to observe what happened when an agent ran on a target and inside the Mythic server. Two purpose-built tools tightened that loop.

LabKit — the debugging harness

LabKit is a Go-based, gRPC client/server tool that runs the agent on the Windows target and gives the model controlled execution: launching the process, managing it, capturing stdout/stderr for debugging, and verifying clean termination. Instead of guessing why an implant misbehaved, the model gets the actual output back.

Mythicd — the server wrapper

On the server side, Mythicd wraps Mythic so the model can deploy Docker images and pull container logs through a controlled interface rather than improvising over raw SSH. That replaces a fragile, open-ended access path with something predictable the harness can rely on.

The QA sub-agent as Tier 3

Tier 3 is handled by a separate quality-assurance sub-agent running with a clean context window, which matters: it judges the release build from an end-user perspective without being anchored to the assumptions the building agent made. It is given the original design summary, the implemented feature list, and the full command set, plus access to a pre-deployed instance on the Mythic server. Notably it is denied write/edit tools — its only job is to test and return a verdict, never to “fix” the code it is evaluating. It uses LabKit and a Mythic CLI to exercise the agent, then returns PASS or FAIL with detailed justification. A FAIL kicks the primary agent back to Tier 1.

The result

With the full loop running, agents came together in roughly two hours each including the repeated check cycles, and basic stage-0 functionality worked end-to-end. Crucially, the same harness produced working agents across very different languages — Python, Go, Zig, C#, and Rust — suggesting the approach generalizes rather than being tuned to one toolchain.

Porting to GPT-5.4-Cyber

To test portability, the Oracle harness was adapted to run under Codex with GPT-5.4-Cyber. The changes were mostly mechanical — rename CLAUDE.md to AGENTS.md, swap the .claude directory for .codex, and convert the QA sub-agent definition to TOML. The first attempt succeeded, producing a working agent (complete with its own generated logo) and confirming the harness is not tied to a single model or vendor.

Along Came GPT-5.5-Cyber

With a newer model, the author ran five agents in parallel, each in a different language. They came together in about one-and-a-half to two hours apiece. The code quality is explicitly described as non-maintainable — but that is the entire point of disposable tooling, where an implant is meant to be used for a single engagement and discarded rather than maintained.

The Future

The author’s closing argument is a defensive one. If a unique, single-use implant can be produced in a couple of hours, then static signatures and YARA rules — which rely on artifacts being reused across targets — degrade in value much faster. The expectation is that adversaries are already experimenting with LLM-generated disposable implants, and the next post in the series will focus on the evasion angle. Publishing the technique early is framed as a way to get defenders thinking about it before it becomes routine.

Key Takeaways

• Naked prompting is not enough — LLMs produce plausible, compilable Mythic agents that fail at runtime on RPC methods, key exchange, packaging, and paths.
• The unlock is a tiered build-and-test harness (mock server → live deployment → independent QA) that the model is forbidden to skip.
• An independent QA sub-agent with a clean context and no edit rights catches what the building agent rationalizes away.
• The harness is model- and vendor-portable: it ran across Opus-class models and GPT-5.x “Cyber” variants with mostly mechanical config changes.
• It is also language-agnostic, producing working agents in Python, Go, Zig, C#, and Rust.
• End-to-end generation lands around 1.5–2 hours per agent, making genuinely disposable, per-engagement implants realistic.
• Disposable tooling erodes the value of static signatures and YARA rules that assume artifact reuse.

Defensive Recommendations

• Shift weight from static to behavioral detection. Per-engagement implants defeat hash- and signature-based matching; invest in behavioral analytics, EDR telemetry, and anomaly detection that key on actions rather than artifacts.
• Hunt on C2 behavior, not binaries. Mythic and similar frameworks have characteristic check-in cadence, key-exchange, and tasking patterns — build detections around protocol behavior and beaconing rather than the implant file.
• Tighten egress and proxy inspection. Disposable agents still have to call home; enforce egress filtering, TLS inspection where feasible, and alerting on unusual outbound destinations and JA3/JA4 fingerprints.
• Watch for staging and second-stage loads. A stage-style command that pulls and executes a follow-on payload is a high-value detection point even when the first stage is novel.
• Instrument process and command-execution telemetry. CreateProcess, cmd.exe spawning, and file upload/download flows are language-independent behaviors that survive across regenerated agents.
• Assume signature gaps and red-team for them. Have your own team generate novel tooling to validate that detections fire on behavior, not on known samples.
• Track AI-assisted tradecraft as a threat trend. Treat fast, throwaway, LLM-built implants as a near-term reality in threat models and tabletop exercises rather than a future hypothetical.

Conclusion

The headline result is not that an LLM can write code — it is that a disciplined harness can turn an unreliable code generator into a repeatable pipeline that ships working C2 agents from a one-paragraph brief. The scaffolding (tiered testing, a mock protocol server, controlled execution and log tooling, and an independent QA gate) is what converts “looks right” into “checks in and tasks correctly.” For defenders, the implication is concrete: when a unique implant costs an afternoon, detection has to live in behavior and infrastructure, because the artifacts will keep changing.

Original text: “Disposable Tooling: Building LLM-Generated Mythic Agents from Prompt to Deployment” by Adam Chester at SpecterOps.