Mythic Profiles

Mythic Profiles

Scope

Use this skill for Mythic C2 profile development: profile container layout, C2Profile definitions, parameter modeling, listener/server implementation, P2P versus egress profile decisions, and integration with Mythic payload types.

Use $mythic-implant-development instead when the primary task is implementing an agent/payload type or agent commands. Use this skill when the primary artifact is a C2 profile/listener/transport.

Workflow

1. Classify the profile

   • Egress profile: server-side code receives agent traffic and forwards to Mythic /agent_message.
   • P2P profile: no listening server; parameters define agent-to-agent connection details.
   • Translation-aware profile: coordinate with a translation container if wire format or crypto differs from Mythic messages.

2. Set up the development loop

   • Read references/remote-development.md when the task involves local/remote Mythic development, container iteration, or installed-service workflow.
   • Confirm profile folder name, C2Profile name, and Mythic installed service name align.
   • Use focused container restarts and payload-build smoke tests during iteration.

3. Inspect the repository shape

   • Identify profile language, Docker/container entrypoint, profile definition file, server binary/script, config templates, and any profile-specific utilities.
   • For MythicC2Profiles-style work, treat each top-level profile as a standalone container package.
   • Preserve existing profile naming, parameter names, and build/deploy conventions unless the user asks for a migration.

4. Define or update profile metadata

   • name: stable profile identifier used by payload types.
   • description, author, semver.
   • is_p2p: False for listener/egress profiles, True for P2P profiles.
   • server_binary_path: executable/script that handles traffic for egress profiles.
   • server_folder_path: folder exposed in Mythic UI for server-side files/config.

5. Model C2 parameters

   • Include operator-facing parameters such as callback host/port, interval, jitter, headers, bind address, URI paths, proxy settings, or peer connection fields.
   • Use verifier_regex for format-sensitive values.
   • Use crypto_type=True for Mythic-managed crypto parameters such as AES/HMAC profile keys.
   • Prefer parameter names the payload build function can consume directly through get_parameters_dict().

6. Implement listener/server behavior

   • Accept or receive the profile transport format.
   • Extract the Mythic agent message.
   • Forward to Mythic’s /agent_message endpoint.
   • Return Mythic’s response in the profile’s transport format.
   • Add bounded config validation, useful logs, and no secret-bearing debug output.

7. Integrate with payload types

   • Ensure payload types list the profile name in c2_profiles / supported C2 profiles.
   • Confirm the build function embeds or serializes selected profile parameters into agent configuration.
   • Keep agent wire format and profile server expectations synchronized.

8. Validate

   • Confirm container starts and syncs with Mythic.
   • Confirm profile appears in payload build UI.
   • Build a test payload with the profile selected.
   • Confirm checkin, get-tasking, post-response, file transfer, and error paths as applicable.
   • Document exact commands, config values changed, and validation evidence.

Reference loading

Read only what is needed:

• references/developer-series.md for routing based on the Mythic for Developers playlist topics.
• references/profile-development.md for implementation patterns, profile file anatomy, and validation checklist.
• references/remote-development.md for local/remote container iteration and installed-service workflow.
• references/third-party-service-profiles.md for profiles that broker traffic through external services such as chat/storage/webhook APIs.
• ../mythic-implant-development/references/c2-profile-definition.md for detailed C2Profile class and parameter examples.
• ../mythic-implant-development/references/agent-message-format.md when the transport wraps Mythic agent messages.
• $mythic-translation-containers when profile behavior depends on custom message formats or crypto.
• ../mythic-implant-development/references/p2p-connections.md for SMB/TCP-style P2P routing.

Output requirements

For design/review tasks, return:

• profile type: egress, P2P, or translation-aware
• files changed or files to create
• parameter schema and operator-visible defaults
• server/listener data flow
• payload-type integration points
• validation commands/checks
• risks, assumptions, and unresolved profile-specific questions