Detecting Mythic C2: Server, Agent and Network Hunting for Defenders

Mythic is an open source command and control (C2) platform built for red teams, and the same plug-in design that makes it flexible for testers makes it hard to catch with a single signature. MITRE ATT&CK records it as software S0699 and notes that deployed Mythic servers have been seen in potentially malicious infrastructure, and in 2025 Hunt.io reported APT36 delivering Poseidon, a Mythic agent, against Indian government and defence targets. Because Mythic ships without agents or transports and loads them from separate projects, every deployment can look different on the wire and on the host. This guide covers how the platform is built, what defenders can see at each layer (internet-facing server, network channel, endpoint agent), how to hunt and contain it, and how to tell an authorised red team from an intruder. It is written for SOC analysts, detection engineers and threat hunters.

This is an independent guide from NHI Mgmt Group, based on Mythic's public documentation and source repositories as of November 2026. It is not sponsored or reviewed by the Mythic maintainers or SpecterOps, and it covers detection only.

Key takeaways

• Detect the layers, not the brand. Mythic is a server plus interchangeable agents and C2 profiles, so durable detections target behaviours such as regular callbacks, peer-to-peer named pipes and in-memory .NET execution rather than one file hash.
• Defaults are the cheapest catch. Team Cymru found that about 90% of internet-facing Mythic servers kept the default web port 7443 and most kept the default TLS certificate with issuer O=Mythic, which internet scanning data can find.
• The default HTTP profile is noisy if unchanged. Its builder defaults to a 10 second callback with 23% jitter and an Internet Explorer 11 user agent string, both unusual on a modern estate.
• Agents decide host artefacts. Apollo (Windows, C#), Poseidon (Go) and others behave differently, so pair network hunts with endpoint telemetry for process injection, assembly loading and credential access.
• Deconfliction is a control. Authorised red teams use Mythic too, so register every test's infrastructure and agent hashes before it starts, or the SOC will either chase the tester or dismiss a real intruder as the tester.

How Mythic is built and why it matters for detection

Mythic's README describes it as a cross-platform post-exploitation red teaming framework built with Go, Docker, docker-compose and a browser user interface, controlled through a mythic-cli binary. The core repository hosts no agents (called payload types) and no C2 profiles. Operators install each from its own GitHub project, and each runs in its own container that talks to the core over RabbitMQ. For a defender this has three consequences:

• No single agent signature: the Windows agent Apollo is C# on .NET Framework 4.0, Poseidon is written in Go, and other public agents use other languages. A rule for one agent misses the rest.
• No single wire format: ATT&CK lists HTTP (T1071.001), SMB peer-to-peer (T1071.002), DNS (T1071.004), WebSocket and TCP (T1095), SOCKS tunnelling (T1572), domain fronting (T1090.004) and fallback URL lists (T1008) among Mythic's capabilities.
• Configurable transforms: ATT&CK notes transform functions that encode or randomise C2 data (T1132), and the Apollo README lists Base64, NetBIOS and XOR message transforms plus a malleable HTTPX profile.

The general theory of C2 detection is in the Command and Control (C2) Guide and timing analysis is in the Beaconing and C2 Detection Guide. This page applies both to Mythic specifically.

Component reference

Where Mythic shows up

Mythic is a legitimate tool. Its README states it is meant for authorised assessments and research, and Apollo was written for SpecterOps training. Most deployments you meet will be red teams. The evidence of misuse is still real:

• ATT&CK S0699: cites Recorded Future reporting that deployed Mythic servers were observed as part of potentially malicious infrastructure.
• Team Cymru (September 2022): counted 76 internet-facing Mythic servers, about 2% of observed C2 framework share, found one Mythic-linked domain appearing to target the Pakistani Ministry of Foreign Affairs on infrastructure tied to an earlier Sliver campaign, and noted low-confidence links to e-crime operators through a reused login panel image and shared E-Tag values.
• Hunt.io (July 2025): reported APT36 using Poseidon, which it describes as a Go backdoor built on Mythic, as a second-stage payload delivered by Linux .desktop files disguised as PDF documents, with cron persistence and payloads under ~/.local/share/ and /dev/shm/.

The lesson matches the Sliver, Havoc and Brute Ratel C2 Frameworks Detection Guide: open source frameworks lower the cost for intruders, and the same operator often runs several frameworks on shared infrastructure.

Network detection

Most organisations will first see Mythic as an agent calling out. Work through the channels below, starting with egress HTTP and DNS because they cover the most deployments.

Operators change every default in the HTTP profile, so treat those values as a bonus, not a baseline. Timing analysis survives most changes: score each host and destination pair on connection count, interval regularity and bytes per session. Mythic supports custom chunk sizes for file transfer (T1030), so exfiltration may appear as many equal-sized POST bodies rather than one large upload. DNS hunting detail is in the DNS Logging and Detection Guide and tunnelling in the T1572 Protocol Tunnelling Defensive Guide.

Endpoint detection by agent behaviour

Agents are where the damage happens, and EDR sees them even when the channel is encrypted. The Apollo README is a useful catalogue of what a capable Mythic agent does, and each capability maps to telemetry you should already collect.

For Linux agents such as the Poseidon samples Hunt.io described, watch for execution from /dev/shm or hidden paths in user home directories, new cron entries (T1053.003) written by a user session, and .desktop files arriving by email or download (T1204.002). On macOS, apply the same logic to LaunchAgents and unsigned binaries in user-writable paths. Supporting detail sits in the Sysmon Guide, the T1055 Process Injection Defensive Guide and the Golden Ticket, Silver Ticket and DCSync Guide.

Hunting Mythic servers with internet scanning data

Finding servers before they call into your network is cheap, and it feeds blocklists and threat intelligence. Team Cymru's 2022 research shows which defaults leak:

1. Port 7443 with a login page: search scan datasets for HTTP titles and favicons of the Mythic login panel on 7443 and nearby ports.
2. Default certificate: query for TLS certificates whose issuer organisation is Mythic.
3. Shared configuration: pivot on E-Tag headers and certificate hashes to link servers run by the same operator.
4. Co-located tooling: Team Cymru saw the reNgine reconnaissance framework beside Mythic, so look for other offensive tooling on the same host or netblock.
5. Enrich and decide: compare candidate IPs against your red team register, then block, alert or share through your intelligence channels.

Expect undercounting. Operators who set ALLOWED_IP_BLOCKS, change the port, replace the certificate or front the server with a redirector disappear from these searches.

Building and rolling out detections

1. Confirm telemetry first. Check that proxy, DNS, firewall flow, EDR process and network events, Sysmon pipe events and PowerShell 4104 logs reach the SIEM with host names that join across sources.
2. Stand up a lab Mythic with your red team. Under written rules of engagement, have the red team run the default HTTP profile and an SMB link between two lab hosts so analysts see real traffic and host events. Use the Purple Team Exercise Plan Template.
3. Write rules in audit mode. Start with low-noise rules: IE11 user agent from modern endpoints, workstation-to-workstation named pipes, non-DC replication requests, CLR loads into unusual processes. Run them for two weeks and record the false positive rate.
4. Add the timing model. Score beacon regularity per host and destination, suppress known update services and monitoring agents, and set thresholds from the lab run.
5. Promote to alerting in rings. Move rules with under one false positive per week to production alerting, keep the rest as hunting queries, and link each rule to a runbook.
6. Re-test each quarter. Ask the red team to change profiles, transforms and agents. Rules that only caught defaults will fail, which tells you where to invest.
7. Roll back cleanly. Keep every rule in version control with an owner. If a rule floods the queue, revert to the previous version or demote it to a hunt query rather than deleting it.

Decision guidance: red team or intruder

Small organisations without a red team should still assume Mythic can appear, focus on EDR coverage and outbound filtering, and buy managed detection that names framework coverage in its service description. Large organisations should keep a red team register the SOC can query in real time, as set out in the Red Team Rules of Engagement Template.

Response and containment

• Isolate, do not just block: network-contain the host through EDR so peer-to-peer children lose their parent, then hunt for hosts that only spoke SMB to it.
• Expect fallback: after blocking the first domain, watch the host for the next destination before you reimage, and add each new one to blocklists.
• Preserve memory: Apollo runs much of its tasking in memory, so capture a memory image before shutdown.
• Reset what the agent touched: any credential used with make_token, any account visible to dcsync and any token on the host must be rotated.
• Sweep for the delivery path: on Linux, remove the cron entry and dropper; on Windows, find the loader before you trust the clean-up.

The full process is in the Incident Response Guide.

Where identity fits

A Mythic agent turns a single foothold into identity abuse: Apollo includes token impersonation, credential tracking, Mimikatz execution and DCSync. Service accounts with domain replication rights, local administrator passwords reused across hosts and long-lived API keys in user profiles are what an operator harvests after the first callback. Restrict replication rights to domain controllers, rotate local admin passwords per host, and keep machine credentials out of user-readable files. See the Identity Threat Hunting Guide.

Detection and measurement

• Coverage: percentage of Mythic capabilities from the ATT&CK S0699 list with at least one tested detection (target 80% or more).
• Time to detect in purple tests: minutes from first callback to alert for each profile tested.
• Telemetry completeness: share of endpoints sending Sysmon pipe events and PowerShell 4104 logs.
• Default-indicator hit rate: number of detections that only fire on unchanged defaults, which should fall as rules mature.
• Deconfliction speed: time to confirm or rule out a red team source when an alert fires.

Framework mapping

Common failure patterns

• Signature-only coverage: a hash or YARA rule for one Apollo build misses Poseidon, a rebuilt Apollo and every other agent.
• Ignoring internal traffic: SMB peer-to-peer chains mean only one host talks to the internet, so egress-only monitoring sees one alert instead of the whole chain.
• Blanket red team allowlists: suppressing alerts for "the pentest" by tool name hides any intruder who uses the same tool in the same month.
• Blocking without watching: blocking the first domain and closing the ticket, while the agent moves to its fallback list.
• Testing only defaults: purple exercises that only run the default profile give false confidence about real operators.

Practitioner checklist

• Map your detections to every technique listed for ATT&CK S0699 and record the gaps.
• Collect Sysmon Event IDs 8, 10, 17 and 18, PowerShell 4104 and directory replication auditing on Windows.
• Deploy EDR or auditd on Linux and macOS, and alert on execution from /dev/shm and new user cron entries.
• Build a beacon-timing hunt over proxy and flow logs and run it weekly.
• Hunt Internet Scanning Data for Defenders sources for Mythic panels and default certificates each month and feed results to blocklists.
• Keep a red team register of infrastructure, agent hashes, scope and window that the SOC can query.
• Run a purple exercise with non-default Mythic profiles at least twice a year.
• Write a containment runbook that isolates peer-to-peer children and captures memory before reimaging.
• Restrict directory replication rights and rotate local administrator passwords per host.

Standards and references

• MITRE ATT&CK: Mythic (S0699)
• Mythic: Documentation
• Mythic: Project repository and README
• Mythic C2 Profiles: HTTP profile repository
• Mythic Agents: Apollo repository
• MITRE D3FEND: Network Traffic Analysis
• Team Cymru: Mythic case study, assessing common offensive security tools
• Hunt.io: APT36 expands beyond military targets

Related NHI Mgmt Group resources: Command and Control (C2) Guide · Beaconing and C2 Detection Guide · Cobalt Strike Abuse Detection Guide · Sliver, Havoc and Brute Ratel C2 Frameworks Detection Guide · Purple Teaming Guide