fawkes

Fawkes is a golang Mythic C2 Agent exclusively written by AI.

Forge Command Augmentation

Fawkes supports Mythic Forge command augmentation, which dynamically extends the agent's capabilities with external tool collections. When Forge is installed alongside Mythic, additional commands automatically appear in the Mythic UI for Fawkes callbacks — no agent rebuild required.

Supported tool collections:

Setup (New Install)

Step 1: Install Forge

Step 2: Add Fawkes to Forge's payload type support

Edit InstalledServices/forge/payload_type_support.json and add the Fawkes entry to the JSON array:

This maps Forge's generic parameter interface to Fawkes's specific command names and parameter names. The field mapping:

• bof_command → Fawkes's inline-execute command (BOF/COFF execution)
• inline_assembly_command → Fawkes's inline-assembly command (.NET assembly execution)
• execute_assembly_command → empty (Fawkes uses inline-assembly for all .NET execution)
• Parameter names must match exactly what Fawkes's agentfunctions define in the "Forge" parameter group

Step 3: Rebuild and restart

Step 4: Register tool sources

Open the Mythic UI and use the forge_register command (available on any callback) to register tool sources. Common sources:

To register a source, run forge_register with commandName set to the plain source name (e.g., Rubeus, not forge_net_Rubeus) and remove set to false.

After registration, Forge downloads the tool binaries and creates augmented commands (e.g., forge_net_Rubeus, forge_bof_nanodump) that appear in the callback's command list.

Step 5: Verify

Existing callbacks automatically see Forge commands — no new payload needed. Test by running a registered tool:

1. Run autopatch or start-clr first (AMSI patching for .NET tools)
2. Select a Forge command (e.g., forge_net_Seatbelt)
3. Enter arguments (e.g., -group=system)
4. Execute — Forge translates the command to inline-assembly with the embedded tool binary

Usage Tips

• For .NET tools (SharpCollection), run start-clr with autopatch first to initialize the CLR and patch AMSI — without this, Windows Defender may block assembly execution
• For BOF tools (Sliver Armory), ensure BOFs are compiled for x64
• No special build parameters are needed — Forge support is built into Fawkes's inline-execute and inline-assembly commands via the "Forge" parameter group
• Forge commands work on existing callbacks without rebuilding the agent
• When issuing Forge commands via the API, include payload_type: "forge" in the createTask mutation — without this, Mythic only searches the callback's own payload type

Injection Techniques

PoolParty Injection

Opus Injection

For detailed variant descriptions, see Injection Technique Details.

Build Options

DLL Export Methods

When building in shared (DLL) or windows-shellcode mode, the dll_exports build parameter controls which DLL exports are included:

Execution methods with full exports:

Binary Inflation

Fawkes supports optional binary inflation at build time. This embeds a block of repeated bytes into the compiled agent, which can be used to increase file size or lower entropy scores.

Two build parameters control this:

• inflate_bytes - Hex bytes to embed (e.g. 0x90 or 0x41,0x42)
• inflate_count - Number of times to repeat the byte pattern

The byte pattern is repeated inflate_count times, so the total added size is length(byte_pattern) * inflate_count.

Quick reference for sizing:

When inflation is not configured, only 1 byte of overhead is added to the binary.

PE Resource Embedding (Windows Only)

Windows PE binaries contain metadata resources — version info, icons, and UAC manifests — that are visible in File Properties, Task Manager, and Explorer. Default Go binaries have none of this metadata, which is a strong detection signal for security tools and analysts.

Fawkes supports embedding PE resources at build time to impersonate legitimate Windows binaries:

Build parameters:

Presets (10 common Windows binaries with real version info): notepad, svchost, cmd, explorer, msiexec, dllhost, rundll32, conhost, taskhostw, RuntimeBroker

Individual fields override preset values. When no PE resource parameters are set, the binary is unchanged from default Go output.

Opsec Features

Artifact Tracking

Fawkes automatically registers artifacts with Mythic for opsec-relevant commands. Artifacts appear in the Mythic UI under the Artifacts tab, giving operators a clear picture of all forensic indicators generated during an engagement.

Tracked artifact types:

Read-only commands (ls, ps, cat, env, etc.) do not generate artifacts.

Credential Vault Integration

Credential-harvesting commands automatically report discoveries to Mythic's Credentials store, making them searchable and exportable from the Mythic UI.

Keylog Tracking

The keylog command integrates with Mythic's Keylogs feature. When keystrokes are returned via stop or dump, they are automatically parsed by window title and sent to Mythic's keylog tracker with user attribution. Keylogs are searchable in the Mythic UI by window title, user, or keystroke content.

Token Tracking

The make-token and steal-token commands register tokens with Mythic's Callback Tokens tracker. This provides visibility into which tokens are associated with each callback, including the impersonated user identity and source process. The rev2self command automatically removes tracked tokens when impersonation is dropped.

TLS Certificate Verification

Control how the agent validates HTTPS certificates when communicating with the C2 server. Configured at build time via the tls_verify parameter:

Certificate pinning prevents MITM interception of agent traffic even if an attacker controls a trusted CA.

TLS Fingerprint Spoofing (JA3)

Go's standard TLS stack produces a distinctive JA3 hash that network security tools can identify as non-browser traffic. The tls_fingerprint build parameter uses uTLS to spoof the TLS ClientHello, producing a browser-matching JA3 fingerprint.

Mutual TLS (mTLS) Client Certificate Authentication

Add client certificate authentication to the HTTP C2 profile. When configured, the agent presents a client certificate during TLS handshake, enabling the C2 server to verify agent identity. This prevents passive HTTPS interception and proxy MITM attacks.

The cert/key are base64-encoded at build time, XOR-encrypted if string obfuscation is enabled, and stored in the AES-256-GCM config vault at runtime. Combines with existing TLS verification modes and JA3 fingerprint spoofing.

Fallback C2 URLs

Multiple C2 callback URLs with automatic failover. If the primary callback host is unreachable, the agent transparently cycles through fallback URLs before applying backoff.

Same port and encryption as primary. Remembers last successful URL. Works with config vault and XOR obfuscation.

Environment Keying / Guardrails

Prevent the agent from executing on unauthorized systems. Configured at build time — the agent silently exits before making any network contact if checks fail. No logging, no artifacts, no C2 traffic.

All patterns are case-insensitive and anchored to match the full value. Multiple keys can be combined — all must pass. Invalid regex patterns fail closed (agent exits). Leave empty to skip a check.

Environmental Key Derivation (env_key_derive): When set, all sensitive C2 config (callback host, UUID, encryption key, URIs, proxy settings, etc.) is AES-256-GCM encrypted at build time using a key derived from the target's environment. At runtime, the agent re-derives the key from its own environment — if it doesn't match (wrong host/domain/user), decryption fails and the agent exits silently. This is stronger than regex matching because the config values are never present in the binary in any form. Requires the corresponding env_key_* values to contain the EXACT target values (not regex patterns). Stacks with obfuscate_strings (XOR layer applied first, then AES-GCM).

C2 String Obfuscation

Enable the obfuscate_strings build parameter to XOR-encode all C2 config strings (callback host, URIs, user agent, encryption key, UUID) at build time with a per-build random 32-byte key. Prevents trivial IOC extraction via strings on the binary. Decoded at runtime. Cross-platform.

BlockDLLs for Child Processes

Enable the block_dlls build parameter to apply PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON to all child processes spawned by the agent (run, powershell commands). Prevents EDR from injecting monitoring DLLs into spawned processes. Uses STARTUPINFOEX with UpdateProcThreadAttribute. Windows only.

Parent PID Spoofing for Subprocesses

Set config -action set -key default_ppid -value <PID> at runtime to make all child processes (run, powershell) appear as children of a legitimate process (e.g., explorer.exe). Defeats parent-child process relationship detection by EDR. Combines with BlockDLLs when both are active. Uses UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_PARENT_PROCESS). Disable with config -action set -key default_ppid -value 0. Windows only (T1134.004).

Auto-Patch ETW/AMSI

Enable the auto_patch build parameter to automatically patch EtwEventWrite and AmsiScanBuffer at agent startup. This prevents ETW-based detection and AMSI scanning before any agent activity occurs — no manual command required. Windows only (no-op on Linux/macOS).

Self-Deletion

Enable automatic binary deletion at startup via the self_delete build parameter. Once the agent starts running, it removes its own file from disk — eliminating the primary forensic artifact.

• Linux/macOS: Uses os.Remove() — the running process continues via the in-memory inode mapping. The file disappears from disk immediately.
• Windows: Uses the NTFS stream rename technique — renames the default :$DATA stream then deletes the file entry. No child process spawned.

The binary is deleted after environment key checks pass but before network activity begins.

Process Masquerading (Linux)

Set the masquerade_name build parameter to change the agent's process name on Linux. Uses prctl(PR_SET_NAME) to modify /proc/self/comm, which is displayed by ps, top, and htop. Max 15 characters.

Useful names: [kworker/0:1], [migration/0], sshd, apache2, [rcu_preempt]

Combined with self-delete, the agent appears as a legitimate kernel thread or service with no file on disk.

Sleep Memory Guard Pages

Enable sleep_guard_pages (requires sleep_mask=true) to apply VirtualProtect(PAGE_NOACCESS) on encrypted vault memory during sleep cycles. After the sleep mask encrypts sensitive data (AES-256-GCM) and zeros originals, guard pages move the vault to dedicated VirtualAlloc'd memory and mark it NO_ACCESS. EDR memory scanners, ReadProcessMemory, WinDbg, and Process Hacker get STATUS_ACCESS_VIOLATION when trying to read the vault. Pages are restored to PAGE_READWRITE on wake before decryption. On Linux/macOS, guard pages use mmap(MAP_ANON) + mprotect(PROT_NONE) — probing triggers SIGSEGV.

The sleep vault key is hardware-bound via HKDF-SHA256: a random seed is mixed with a SHA-256 hash of the machine's CPU brand string and UUID. If someone extracts the vault blob from a memory dump and attempts decryption on different hardware, the key derivation produces a different key.

Call Stack Spoofing

Enable stack_spoof to spoof the sleeping thread's call stack, defeating EDR thread-scanning tools (Hunt-Sleeping-Beacons, Moneta, CrowdStrike).

• Windows (requires indirect_syscalls=true): A dedicated native thread performs NtDelayExecution with fake return addresses pointing to kernel32!SleepEx, kernel32!BaseThreadInitThunk, and ntdll!RtlUserThreadStart — the standard thread initialization chain that EDR expects.
• Linux amd64: A child process is created via clone(CLONE_VM) with its own 291-byte machine code stub in anonymous mmap'd memory. The child calls nanosleep directly via raw syscall — no Go runtime or agent code addresses appear on the sleeping thread's stack. Signal handlers are reset to SIG_DFL in the child, and PR_SET_PDEATHSIG ensures the child dies when the parent exits.
• macOS arm64: A native pthread is spawned with a 140-byte ARM64 machine code stub in anonymous mmap'd memory. The thread uses __ulock_wait/__ulock_wake for synchronization with the Go runtime and calls nanosleep via raw syscall — the sleeping thread's stack shows only the anonymous stub and kernel frames, no Go runtime or agent code.

Custom HTTP Headers

All headers defined in the Mythic HTTP C2 profile configuration are applied to every request. Beyond User-Agent (always supported), operators can add headers like Accept-Language, Referer, Cookie, or X-Forwarded-For to blend C2 traffic with legitimate web traffic patterns.

Domain Fronting

Set the host_header build parameter to override the HTTP Host header. This enables domain fronting: route traffic through a CDN (e.g., CloudFront, Azure CDN) while the Host header targets your actual C2 domain. To network defenders, the traffic appears to go to the CDN's IP address.

Proxy Support

Set the proxy_url build parameter to route agent traffic through an HTTP or SOCKS proxy. Useful for operating in corporate networks with mandatory proxy servers.

Examples: http://proxy.corp.local:8080, socks5://127.0.0.1:1080

Authenticated proxies: Set proxy_user and proxy_pass for Basic authentication. For enterprise proxies requiring Windows domain authentication, also set proxy_domain (e.g., CORP) to enable NTLM authentication. The NTLM handshake (Type1→Type2→Type3) is performed automatically during the CONNECT tunnel establishment.

System proxy detection (Windows): When proxy_url is not set, the agent queries WinHTTP for system proxy settings including PAC/WPAD auto-detection.

Build Path Stripping (-trimpath)

All builds use Go's -trimpath flag to strip local filesystem paths from the compiled binary. Without this, paths like /home/user/project/... and /go/pkg/mod/... leak into the binary through panic traces and runtime metadata. Combined with -s -w (symbol stripping) and empty -buildid, this minimizes forensic information in the binary. Garble builds already handle this; -trimpath covers non-garble builds.

YARA Post-Build Scanning

After compilation, the built payload is automatically scanned against a set of YARA rules that model common defender detection patterns. Results are shown in the Mythic build output as an informational step — the scan never fails the build.

Detection categories scanned:

• Go binary identification and symbol leaks
• Leaked build/development paths
• Mythic/C2 framework string indicators
• Windows injection API names
• Credential access API names
• Defense evasion API patterns
• Persistence mechanism strings
• Plaintext C2 configuration

This helps operators understand detection risk and choose appropriate opsec options (garble, obfuscate_strings, etc.) before deploying.

Supported C2 Profiles

HTTP Profile

The HTTP profile calls back to the Mythic server over the basic, non-dynamic profile. This is the default egress profile — the agent polls Mythic for tasking over HTTP/HTTPS.

Malleable features:

• URI randomization: get_uri and post_uri support tokens that are resolved per-request:
  • {rand:N} — N random hex characters (e.g., /api/{rand:8} → /api/a3f82b1c)
  • {int:M-N} — random integer in range (e.g., /v{int:1-3}/status → /v2/status)
• Content-Type cycling: Set the content_types build parameter to a comma-separated list (e.g., application/json,text/plain,application/x-www-form-urlencoded). The agent cycles through them round-robin. Default: application/x-www-form-urlencoded.
• User-Agent rotation: Set the user_agent_pool build parameter to a newline-separated list of User-Agent strings. The agent rotates through them per-request, eliminating the static UA fingerprint. Default: single Chrome 134 UA.
• Exponential backoff: On consecutive C2 failures, the agent doubles its sleep interval (capped at 5 minutes). Normal interval is restored on successful contact.
• TLS fingerprinting: Spoof browser JA3 fingerprints (chrome, firefox, safari, edge, rotate, random).
• HTTP/2 multiplexing: Automatic h2 negotiation over HTTPS. Multiplexes requests on a single connection, matching browser behavior. Transparent h1 fallback.
• Forward secrecy: ECDH X25519 key rotation every N check-ins (key_rotation_interval). Derives fresh AES-256 keys via HKDF-SHA256, zeroes old keys. Limits blast radius of key compromise.
• Replay protection: Monotonic sequence numbers in every message (inside encrypted envelope). Prevents captured request/response replay.
• Mutual TLS (mTLS): Client certificate authentication prevents passive interception and proxy MITM (T1573.002).
• Domain fronting: Set host_header to override the HTTP Host header.
• Automatic failover: Configure fallback_hosts for resilient C2.

TCP P2P Profile

The TCP profile enables peer-to-peer (P2P) agent linking for internal pivoting. A child agent listens on a TCP port or Windows named pipe and waits for a parent agent to connect via the link command. All tasking and responses are routed through the parent's egress channel (HTTP), so the child never contacts Mythic directly.

Architecture:

Build parameters:

When tcp_bind_address or namedpipe_bind_name is set, the agent starts in P2P listener mode instead of HTTP egress mode.

Usage workflow (TCP):

1. Build a child agent with the TCP C2 profile and tcp_bind_address set (e.g., 0.0.0.0:7777)
2. Deploy the child to an internal host (no internet access required)
3. From an egress agent (HTTP profile), run: link -host <child_ip> -port 7777
4. Mythic creates a new callback for the child — all tasking flows through the egress agent
5. To disconnect: unlink -connection_id <uuid>

Usage workflow (Named Pipe):

1. Build a child agent with the TCP C2 profile and namedpipe_bind_name set (e.g., msrpc-f9a1)
2. Deploy the child to an internal Windows host
3. From an egress agent, run: link -connection_type namedpipe -host <child_ip> -pipe_name msrpc-f9a1
4. The connection uses SMB (port 445), blending with normal Windows file sharing traffic
5. To disconnect: unlink -connection_id <uuid>

Encryption: AES-256-CBC with HMAC-SHA256 (same as HTTP profile). Wire protocol uses 4-byte length-prefixed framing over TCP or named pipe.

Relink support: If a parent disconnects (e.g., via unlink or parent agent dies), the child agent caches its checkin data and waits for a new parent connection. When a new egress agent runs link, the child automatically re-registers with Mythic as a new callback. No manual intervention needed.

Multiple children: An egress agent can link to multiple TCP and named pipe children simultaneously. Each child operates independently with its own callback.

OPSEC notes: Named pipe connections use SMB (port 445) and generate fewer network-level indicators than raw TCP, but Sysmon Event ID 17/18 (PipeEvent) and ETW events from Microsoft-Windows-SMBClient will be logged if configured.

Discord C2 Profile

The Discord profile uses a Discord bot and channel as a covert C2 transport. The agent communicates with Mythic by posting encrypted messages to a Discord channel, where a server-side bot relays them to Mythic via gRPC push C2.

Architecture:

How it works:

1. Checkin: Agent posts an encrypted checkin message to the Discord channel. The server-side bot picks it up, forwards to Mythic, and posts the response back to the channel. The agent polls until it finds the response.
2. Tasking: Agent sends a get_tasking request via Discord. With push C2, tasks may also be pushed independently to the channel. The agent collects all matching messages per poll cycle.
3. Responses: Agent posts task output to the channel. Large responses (>1950 chars) are sent as file attachments.

Build parameters:

Encryption: AES-256-CBC with HMAC-SHA256 (same scheme as HTTP profile). Sensitive configuration (bot token, channel ID) is encrypted in memory after initialization using AES-256-GCM vault.

Push C2 support: The Discord C2 server uses Mythic's push C2 (persistent gRPC stream). Tasks may arrive asynchronously between poll cycles. The agent implements:

• Pre-poll sweep to catch pushed tasks from previous cycles
• Catch-up polling (3 additional polls after first match) for rapid task delivery
• PostResponse retry on transient failures

Rate limiting: Respects Discord API rate limits with automatic retry and exponential backoff (up to 5 retries). The User-Agent is hardcoded to DiscordBot (https://github.com, 1.0) as required by the Discord API.

Setup prerequisites:

1. Create a Discord bot at discord.com/developers
2. Enable the bot's Message Content intent
3. Add the bot to a server with permissions: Send Messages, Read Message History, Attach Files, Manage Messages
4. Note the bot token and target channel ID
5. Configure the Discord C2 server container with the same bot token and channel ID in its config.json

Known limitations:

• "Last Checkin" in Mythic shows as "Streaming Now" while the push C2 stream is active (inherent to push C2 mode). After ~180s of agent inactivity, Mythic shows the real last activity timestamp.
• Discord API rate limits may introduce latency during high-frequency tasking
• Bot token is a critical OPSEC asset — compromise exposes the C2 channel
• Message size limit: ~1950 chars inline, larger payloads use file attachments

Thanks

Everything I know about Mythic Agents came from Mythic Docs or stealing code and ideas from the Merlin and Freyja agents.

After that, it's been exclusively feeding Claude PoC links and asking for cool stuff. Crazy right?

Techniques and References

• Threadless Injection - CCob's ThreadlessInject (original C# implementation) and dreamkinn's go-ThreadlessInject (Go port)
• sRDI (Shellcode Reflective DLL Injection) - Merlin's Go-based sRDI implementation, originally based on Nick Landers' (monoxgas) sRDI
• PoolParty Injection - SafeBreach Labs PoolParty research (original C++ PoC) - Variant details
• Opus Injection - Callback-based injection techniques - Variant details
• Phoenix icon from OpenClipart