From Platform to Runtime
Part 1 covered the foundational decisions behind CATM: memory-safe languages, multi-tenant architecture, validated cryptography, IP ownership. Those were the structural choices.
This post is about one of the subsystems those decisions made possible: the polymorphic task dispatch layer at the core of CATM Red Team Core, the manual C2 module inside the CATM platform. Same question as Part 1 (“why build it ourselves?”), but answered through the lens of a single runtime decision and what it does for operators in the field.
If you treat OPSEC as the aftermarket mod, you get a generic beacon with hand-rolled evasion bolted on. If you treat OPSEC as the engine, every task type compiles to bytecode for a runtime that exists nowhere outside this build of this beacon. The trade-off is real engineering work upfront. The payoff is operational longevity.
The OPSEC Bar Has Moved
The industry’s default model puts evasion, TTPs, and capability extension on the end customer. Teams without dedicated capability developers depend on community work or factor R&D time into the engagement schedule, and commercial red teams measured against KPIs spend half their week justifying those hours to leadership. Custom OPSEC tooling is real engineering work, and it competes directly with billable engagements.
Meanwhile the bar keeps moving. Buyers want adversary emulation that does not get signatured by a junior analyst on day two. The detection stacks they are running already catch the obvious. Expecting every red team to also run a capability development shop on the side is not realistic, and that gap is where CATM Red Team Core fits.
Virtualized BOF execution is one concrete example of what that philosophy ships as. Every modern framework encrypts. Few of them virtualize. The encryption is table stakes. The dispatch layer is the moat.
Three Ways to Ship a BOF
Most published approaches to BOF OPSEC fit one of three categories:
| Approach | Wire | Memory during BOF execution |
|---|---|---|
| Transport encryption only | COFF rides inside an encrypted channel; loader parses it on arrival | Beacon reachable to memory scanners during the BOF run |
| Transport plus per-BOF Beacon re-masking (Securify's BOFRyptor, IBM X-Force's "Put on a Mask") | COFF rides inside an encrypted channel | Beacon re-encrypted while the BOF executes |
| Polymorphic dispatch (CATM Red Team Core) | Bytecode rides inside an encrypted envelope; no COFF format on the wire | Polymorphic runtime hosts the BOF; no Beacon-shaped exposure surface to re-mask |
The next section explains how the third row actually works.
How It Works
CATM Red Team Core’s task dispatch is not a wire format. It is a polymorphic instruction layer. Every task type, native commands, post-exploitation operations, injected payloads, is compiled to bytecode for a runtime that exists nowhere outside the beacon. The agent does not parse Windows headers off the wire. It interprets bytecode generated specifically for this build of this beacon.
The instruction encoding is regenerated per build. Signaturing one operator’s beacon teaches the defender nothing about the next. Reversing the encoding for one engagement does not generalize. Detection stacks built to fingerprint native code patterns lose their primary signal source against a runtime that doesn’t produce those patterns. Encryption protects what the runtime is doing today. The runtime itself protects against tomorrow’s defender knowing how to look.
When an operator submits a BOF, the server encrypts it under a per-task ephemeral key and hands it to the same dispatch layer. On the wire, it is indistinguishable from every other task. No COFF headers in transit, no symbol names, no section markers. On the endpoint, the agent decrypts the envelope and routes the payload to an in-process BOF loader. The COFF parsing happens entirely in memory, governed by the same runtime that handles every other task. The entire lifecycle completes without touching disk or spawning a child process.
The BOF loader implements the full Beacon API surface. Your team’s existing BOF library, whether from TrustedSec’s collection, Outflank’s C2-Tool-Collection, or your own custom tooling, works out of the box. Compile with x86_64-w64-mingw32-gcc, hand it to CATM Red Team Core, and it runs. No porting, no rewrite.
Beyond compatibility, CyberDagger ships its own first-party post-exploitation library. Purpose-built BOFs and native implementations designed for the platform from the ground up. These are not community ports or wrappers. They are tooling built to take full advantage of the polymorphic runtime, per-build dispatch, and in-process evasion. Your team gets a ready-to-use post-ex toolkit on day one, and anything you bring from the broader ecosystem plugs in alongside it.
Why This Matters for Your Engagement
Operational Longevity
Per-build runtime, not just per-build payload. Other frameworks rebuild the loader, but the runtime executing the tasks is the same across every engagement. CATM Red Team Core regenerates the instruction encoding per build. Signaturing one beacon teaches the defender nothing about the next. What worked against this operator’s implant has no carryover to the next operator’s implant.
No native code on the wire. The persistent execution surface in memory is bytecode for the runtime, not loadable Windows modules. Tasks travel as bytecode for a runtime that does not exist in the analyst’s reverse-engineering toolkit. Even if the transport layer is compromised, there is nothing to fingerprint that resembles Windows code.
One dispatch layer for every task type. BOFs, native commands, and injected payloads all travel through the same polymorphic runtime. Defenders cannot distinguish task types at the network layer or at the memory layer. The bof command is server-side syntactic sugar. On the wire, it is the same task as every other task.
Encryption is the floor. Every modern framework encrypts. CATM Red Team Core ships per-task ephemeral keys on top of the polymorphic runtime, so even the bytes encoding the bytecode rotate per delivery. There is no static pattern to match across executions and no architectural pattern to match across builds.
No Beacon-shaped exposure during BOF execution. Published techniques like Securify’s BOFRyptor and IBM X-Force’s “Put on a Mask” address a known problem: loading a BOF forces the surrounding Beacon to be reachable to memory scanners during the BOF run. CATM Red Team Core does not have a Beacon-shaped exposure surface to begin with. The runtime that hosts the BOF is the same polymorphic bytecode interpreter that hosts every other task type, so there is no separate Beacon to re-mask while the BOF executes.
Higher-Fidelity Threat Emulation
CATM Red Team Core’s polymorphic runtime lets your operators emulate APT-level sophistication without building custom tooling for every engagement. Per-build instruction encoding means your implant does not match last month’s signatures. Per-task encryption means your post-ex traffic does not match last week’s PCAP. The runtime itself is the differentiator. The tradecraft is built into the platform so your operators can focus on the objective, not the plumbing.
When the engagement report lands, the finding is not “we found your C2 because the BOF delivery was unencrypted.” The finding is about whether the client’s detection stack can handle an adversary operating at this level. That is the assessment they are paying for.
Driving Purple Team Value
Here is the truth that underpins every serious red team engagement. The goal is not to win. The goal is to make the blue team better.
A red team that gets burned on day one teaches the SOC nothing except that they can detect commodity tooling. A red team that survives for weeks, executes the full kill chain, and then sits down with the blue team to walk through exactly what happened and exactly where detection gaps exist: that is the engagement that moves the needle.
CATM Red Team Core’s OPSEC depth directly enables this. When your operators can maintain persistent access long enough to exercise realistic adversary behavior, lateral movement, credential harvesting via virtualized BOFs, privilege escalation, the post-engagement purple team debrief becomes dramatically more valuable. You are not discussing how the SOC found the beacon. You are discussing the twelve TTPs you executed that the detection stack missed, ranked by business impact, with specific telemetry sources and detection logic for each one.
Your existing BOFs just work. Beacon API compatible. Standard mingw cross-compilation. Drop in your BOF library on day one. Your team’s institutional knowledge and custom tooling carry forward. CATM Red Team Core just makes them harder to catch.