Building Moonbunny: An AI-Assisted, Zero-Trust Command & Control (C2) Framework in Go
← Back to Blog
Building Moonbunny: An AI-Assisted, Zero-Trust Command & Control (C2) Framework in Go

Building Moonbunny: An AI-Assisted, Zero-Trust Command & Control (C2) Framework in Go

Tags:

In modern adversary simulation, the gap between initial access and post-exploitation is often bridged by bloated Command and Control (C2) frameworks that are easily fingerprinted, or brittle custom scripts that fail under pressure. I wanted to build something stealthier and more resilient: a lightweight, secure-by-default C2 framework that gives Red Team operators a clean interface while speaking natively to AI models for autonomous operations.

Enter Moonbunny, an experimental adversary simulation and distributed execution framework I am currently building in Go. While it is strictly a proof-of-concept at this stage, it combines the low-latency performance of gRPC, the post-exploitation flexibility of embedded Lua payloads, and the Model Context Protocol (MCP) for AI-driven orchestration, all wrapped in a zero-trust, OpSec-safe architecture.

Figure 1: Moonbunny Architecture — A single Go binary. Operator tooling (TUI, AI/MCP) connects to the Moonbunny server, which hosts gRPC and MCP endpoints backed by independent Lua engine instances (sharing pkg/lua), enforced by the policy engine. Connected clients (the server’s own execution sessions) interact through these interfaces. Note: The two-engine setup is a current workaround; the planned architecture (proto/lua/lua.proto) defines a LuaVMMService with VM pool management (ResizePool, CleanupIdleVMs) for parallel execution.

Here is a layer-by-layer walkthrough of how Moonbunny is being designed for modern Red Teaming, and the architectural decisions driving it.

The C2 Backbone: Why gRPC and Go?

At its core, Moonbunny relies on a strictly defined, high-performance client-server architecture powered by Go and gRPC. The decision to use gRPC over traditional HTTP REST or custom TCP sockets was driven by both performance and operational security.

Figure 2: gRPC/mTLS Communication Flow — Mutual TLS handshake establishes cryptographic identity before any data flows. Commands arrive via stream, pass through policy enforcement (SP2/SP3 counters), and execute within the server’s embedded Lua engine. Bidirectional streaming enables low-latency command dispatch and real-time telemetry.

  • Bidirectional Streaming & Low Overhead: HTTP/2 multiplexing allows for highly efficient, persistent streaming of commands and telemetry without the noisy overhead of constant HTTP polling.
  • Protocol Buffers: The entire C2 API is defined in proto/moonbunny.proto and proto/lua/lua.proto, generating robust Go bindings (moonbunny.pb.go). This strict typing eliminates entire classes of parser-level vulnerabilities often found in bespoke C2 protocols.
  • Single Binary: Moonbunny is a single Go binary that embeds the gRPC server, MCP server, Lua engine, policy engine, and all configuration handling. The xiaotu CLI is a companion configuration tool — not a deployed component.
  • E2E Reliability: Red team tools must be stable; a crashed server disrupts all operations. The framework includes a comprehensive E2E testing harness (test/e2e/harness_test.go) covering deployment, gRPC, mTLS, Lua access, and MCP telemetry.

_Figure 3: Protocol Definitions & Generated Code — proto/moonbunny.proto defines 5 fully implemented gRPC services; proto/lua/lua.proto defines 4 deferred services (VM pool, function registry, sandbox, debug, event — stubs only, no Go implementation). Generated Go bindings (moonbunny.pb.go, moonbunny_grpc.pb.go) serve the single binary server.

OpSec First: Why mTLS and Cryptographic Policies?

A C2 framework is only as good as its ability to hide in plain sight and resist Blue Team analysis. Moonbunny is threat-modeled to operate in hostile, heavily monitored environments.

Figure 4: mTLS & Policy Enforcement — Self-signed CA generates localhost certs for mutual verification. Policy engine enforces per-execution SP2/SP3 counters (file ops, network connections, timeouts) and FS/network guards; default policy is permissive, with restrictions applied only when explicitly configured.

  • Mandatory mTLS: Relying on standard TLS is no longer enough to evade deep packet inspection or active probing. Moonbunny mandates Mutual TLS (mTLS). This ensures that not only is the traffic encrypted, blending in with standard enterprise microservice traffic, but the server cryptographically verifies the identity of every connected client. This neutralizes rogue sessions and prevents Blue Teams from interrogating the C2 infrastructure (pkg/grpc/mtls_handshake_test.go).
  • Strict Policy Engine: Moonbunny implements a runtime policy engine (pkg/policy/policy.go) mapped to concrete execution limits via pkg/grpc/server_exec_policy.go. The policy engine enforces SP2/SP3 counters — capped file operations, network connection limits, and execution timeouts — plus FS allowlists and network blocks. Policy changes are runtime-only (in-memory overlay), and a compromised client session cannot arbitrarily inject commands or exceed its configured execution limits.

Figure 5: Execution Limits Thwart Abuse — A compromised server cannot bypass per-execution SP2/SP3 counters. File operation caps and network connection limits are enforced at the Lua callback level; exceeding them blocks the operation, records a violation in the audit log, and surfaces an alert to the operator.

Post-Exploitation Programmability via Embedded Lua

Instead of hardcoding every possible post-exploitation module into the Go binary (which massively increases the signature and file size), Moonbunny exposes an embedded Lua runtime (pkg/lua/engine.go).

Figure 6: Lua Script Lifecycle — Scripts are pushed in-memory only (no disk writes), policy-validated (SP2/SP3 counter limits), then executed within the server’s embedded Lua engine. Per-execution enforcement (pkg/lua/enforce.go) applies resource counters (file ops, network connections) and sandbox constraints at the VM callback level. Sandbox mode (dropping dangerous globals such as os, debug, package, and require) is opt-in via the enable_sandbox policy flag — the default policy grants full system access.

This creates a highly flexible plugin ecosystem. Operators can dynamically push lightweight scripts entirely in memory to gather telemetry, establish persistence, or conduct situational awareness. Per-execution resource limits (capped file operations, network connection counters, and execution timeouts) are enforced by the Go engine via pkg/lua/enforce.go; sandbox mode — which restricts OS-level access — is available when enable_sandbox is explicitly enabled in policy (pkg/lua/enforce.go).

The project ships with an initial library of scripts for real-world recon and enumeration:

Figure 7: Built-in Lua Script Categories — Modular, in-memory scripts covering host reconnaissance, container discovery, and network enumeration. Each executes in an isolated Lua VM with structured output.

Autonomous Red Teaming: Why the Model Context Protocol (MCP)?

This is where Moonbunny stops being just another C2 and becomes a forward-looking adversary simulation platform. AI agents are increasingly being used to analyze complex Active Directory environments or suggest privilege escalation paths.

However, granting an LLM unrestricted access to execution environments is a catastrophic operational risk. The decision to use the Model Context Protocol (MCP) solves this problem.

Figure 8: MCP Integration — AI agents interact with Moonbunny exclusively through registered MCP tools. Every tool call passes through the policy engine, ensuring the LLM cannot bypass operator-defined guardrails. The LLM sees only structured data, never raw shell access.

Moonbunny implements an MCP server interface (pkg/mcp/server.go), documented in docs/guides/mcp-interface.md. MCP provides a standardized, heavily restricted protocol where the AI can only invoke explicitly registered tools and queries. The LLM natively and securely requests target telemetry across the Moonbunny botnet, but it only sees and executes what the Lua engine and the Policy engine explicitly allow. This merges intelligent, automated lateral movement with strict, programmatic operator guardrails.

Figure 9: Autonomous AD Enumeration via MCP — AI orchestrates client reconnaissance: discovers connected clients, selects a target, executes a policy-compliant Lua script (BloodHound-style enumeration), receives structured graph data, and surfaces the attack path — all without raw shell access.

Evolving Beyond the Traditional C2 Landscape

When evaluating modern offensive frameworks, Moonbunny carves out a distinct niche. Traditional behemoths like Cobalt Strike offer unparalleled commercial features, but carry hefty licensing fees and highly scrutinized signatures. Popular open-source alternatives like Sliver (also written in Go) or Covenant (.NET) are incredibly robust, yet they largely focus on traditional, monolithic implant designs and operator-driven manual tasking. Similarly, modular platforms like Mythic excel at collaborative, multi-agent operations but require complex setups.

Moonbunny diverges by prioritizing a hyper-lightweight footprint and, crucially, autonomous AI interoperability via the Model Context Protocol. By combining a strictly enforced runtime execution policy with an embedded Lua runtime, it provides the stealth and agility of projects like Havoc or SILENTTRINITY, but uniquely positions itself for the future of LLM-assisted adversary simulation.

The Operator Console: Bubble Tea TUI

Finally, because an operation is only as effective as its interface (and because I love building terminal UIs, as seen in my Gocaster project), Moonbunny includes a rich TUI application (cmd/tui/main.go).

Figure 10: TUI Architecture (Clean Architecture) — The Bubble Tea TUI is a standalone gRPC client. Views (Dashboard, Scripts, Execution, Policy) communicate with Team Server core solely through the gRPC API surface. No direct access to internal packages.

  • It provides a tactile, keyboard-driven “hacker dashboard” to manage active client sessions, review execution policy statuses, and trigger remote Lua payloads (cmd/tui/scripts.go, cmd/tui/execution.go).
  • By adhering to Clean Architecture principles, the TUI is completely decoupled from the team server’s core logic, acting simply as another authenticated gRPC client consuming the primary API.

Figure 11: C2 Framework Landscape — Moonbunny targets the high-OpSec, AI-autonomous quadrant (top-right). Traditional frameworks cluster in the moderate-OpSec, manual-operation zones. Moonbunny prioritizes runtime execution enforcement, minimal footprint, and native AI interoperability via MCP.

Current Status: A Proof of Concept

While Moonbunny successfully demonstrates the synthesis of offensive security engineering, distributed systems, and AI integration, it is important to emphasize that this project is an active work in progress. It is currently at the proof-of-concept stage and is not yet ready for commercial use, production deployment, or live engagements.

By combining Go’s concurrency and gRPC ecosystem with Lua’s dynamic, in-memory execution and MCP’s AI interoperability, it represents my vision for the next generation of adversary simulation tooling. I will be spending the coming months iterating on its core stability, expanding the Lua standard library capabilities, and hardening the policy engine.