Mythic C2 Activity at Internet Scale

1. Executive summary

Censys has published an internet-wide measurement of hosts exposing the open-source Mythic command-and-control (C2) framework, identifying 131 unique hosts across 307 service hits as of 11 September 2026, 115 of which still carry Mythic's default self-signed TLS certificate (O=Mythic / O=Mythic C2). Mythic is a legitimate, actively maintained red-team framework, but its default deployment leaves multiple trivially fingerprintable artefacts, and the source documents at least one cluster that has been hardened and dressed to look like a CDN edge node, with a custom domain, custom Rust implants and a Discord-based transport. No CVE, CVSS score or CISA-KEV entry applies to this item — this is adversary-infrastructure exposure intelligence, not a vulnerability disclosure, and the VERIFIED REFERENCE DATA resolved no scored entries. The bottom-line risk to EMEA financial services is egress exposure: any internal host beaconing to this infrastructure is a potential post-compromise C2 channel, and the framework's agent-agnostic design means host-based detection alone is unreliable. All findings here are single-sourced to Censys; the intent assessments are explicitly couched by the publisher and should be treated as inference, not fact.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. This is threat-intelligence reporting on third-party infrastructure exposure; it describes no incident at a client, no third-party service a client consumes, and no supply-chain relationship. Mapping it to DORA Art. 17–19 or NIS2 Art. 23 would be compliance-checkbox padding, since the trigger would be "a threat exists on the internet", which is true of every advisory.

One contingent point, stated without citation: if a client's own estate is subsequently found hosting Mythic components (mythic_nginx, mythic_rabbitmq, mythic_server) or beaconing to the infrastructure in §5, that finding — not this report — is the trigger event, and the client's own incident-management and reporting chain would then apply. That determination is theirs to make on the facts of the finding.

3. Technical analysis & attack chain

What Mythic is

Mythic is an open-source, collaboratively maintained C2 framework, created as the successor to the earlier macOS-focused Apfell project. It is language-agnostic and cross-platform, ships as a Docker deployment, and presents a browser-based operator UI. Its architecture is deliberately modular: the core framework is separated from agents, C2 profiles, wrappers and services, all of which are shared and supported by the Mythic community. This lets an operator combine agents for different platforms with different transport profiles without modifying the core. The documentation is thorough and public, which is precisely what makes it usable by both authorised red teams and threat actors.

Documented capabilities

Per the source, Mythic provides:

• Remote command execution via an interactive task queue and shell access across platforms.
• Multi-agent, multi-operator support with a browser UI, role-based access control and shared campaign context.
• Modular transport profiles — HTTP/HTTPS, WebSocket, TCP, SMB named pipes and DNS — switchable without redeploying agents.
• File staging and transfer with upload/download task tracking.
• Credential access and post-exploitation via agent-side modules: keylogging, screenshot capture, token impersonation and LSASS interaction (Windows agents).
• Lateral movement through SMB pipe-based agent pivoting and SOCKS proxy chaining.
• Payload generation with configurable obfuscation, sleep jitter and kill-date parameters.

The agent-agnostic design is the key defensive problem: because operators can deploy known and unknown agents, host-based detection of the implant is unreliable. Identifying the server side is the more durable layer.

Default deployment fingerprints

Mythic's default install emits artefacts that are directly observable in internet scan data:

Population profile (as of 2026-09-11)

• 131 unique hosts, 307 total service hits.
• Port distribution: 7443 on 99 hosts (20.5%) — many operators never change the default web UI port; 80 on 51 hosts; 443 on 40; 8081 on 14; 9443 on 9; 31337 on 6. The source notes these are aggregated open ports on matched hosts, not a distinct count of Mythic profile listeners.
• ASN: DigitalOcean 14 hosts (10.45%), combined AWS services 11 (8%), Microsoft Azure 8 (6%), Mauritius Telecom (ASN 23889) 7 hosts across Beau Bassin-Rose Hill (3) and Quatre Bornes (4), Iceland's 1984 ehf (AS 1984) 5 hosts.
• Geolocation: United States 42 (32%), Hong Kong 11 (8%), China 10 (8%), Germany 7 (5%), Mauritius 7 (5%), Netherlands and Singapore 6 each.
• OS: of hosts where the OS was identified, 98.5% run Linux; a single Windows host was the outlier.
• Co-location: 10 of the 131 hosts run an additional C2 framework — 6 also expose Sliver, 6 expose Adaptix C2, 1 exposes Havoc, 1 exposes FRP (Fast Reverse Proxy). Some hosts combine multiple.

Cluster A — probable shared lab or training fleet

Three hosts (68[.]178[.]202[.]150, 68[.]178[.]205[.]17, 192[.]169[.]176[.]54) share an identical nine-port fingerprint: 22, 53, 80, 500, 4321, 7443, 8001, 8081, 31337. All three carry the same self-signed certificate: C=UK, ST=England, L=Birmingham, O=demo, OU=cyber. Mythic, Sliver and Adaptix C2 appear across all three; Havoc is additionally present on 192[.]169[.]176[.]54. Reverse DNS is GoDaddy's generic auto-assignment (*.host.secureserver.net) and no custom domain is configured on any of the three.

Censys assesses this as a shared lab or training fleet rather than an operational deployment: four C2 frameworks on a single IP, an O=demo certificate, no custom domain, and an identical nine-port fingerprint across three adjacent hosts on the same provider. Operational infrastructure typically isolates tools across hosts and keeps a narrow port footprint — this profile is the inverse. This is an inference, not a confirmed fact, and the source itself cautions that maliciousness and intent cannot be divined from co-location or its absence.

Cluster B — hardened, operational-looking deployment

Four hosts (65[.]87[.]7[.]11, 194[.]26[.]192[.]117, 142[.]93[.]52[.]11, 170[.]64[.]183[.]242) run Mythic and nothing else. They share:

• The same JARM on port 7443: 1dd40d40d00040d00042d43d000000831b6af40378e2dd35eeac4e9311926e
• The same nginx/1.25.5 banner
• The same login page body hash
• Two of them (65[.]87[.]7[.]11 and 194[.]26[.]192[.]117) share an SSH host key

The cluster carries a custom domain, telemetry-update[.]services, served on port 443 with a spoofed Server: NetDNA-cache/2.2 header and Content-Type: application/javascript; charset=utf-8 on 404 responses. That combination mimics a CDN edge node. The split is deliberate: agent traffic goes to port 443, operator traffic to port 7443.

Staging server and tooling development

The host 65[.]87[.]7[.]11:4444 is publicly accessible and shows active tool development:

• Eleven sequential Windows PE builds of a payload family named "nyx": nyx-v5.exe through nyx-v15.exe.
• Rust source for a second family, "fys2": fys2_config.rs, fys2_src.tar.gz.
• A /serve/ subdirectory holding current build outputs staged for victim download.
• Seven Discord diagnostic scripts — discord_check.py, discord_diag.py, discord_probe.py and four more — indicating Discord is a production C2 transport, not an experiment.
• Steganography scripts: stego_roundtrip.py, discord_fix2/stego.py.
• A ChaCha encryption test: chacha_stage_test.py.
• Mythic tasking scripts: mythic_task.py, mythic_whoami.py, mythic_shell.py.

Censys' assessment is that the single-framework footprint should not be read as limited capability: the operator is iterating custom Rust implants across eleven builds, running a Discord transport with steganographic staging, and using Mythic as the operator-side framework behind a domain built to blend with Windows telemetry traffic.

Confidence caveats

All of the above is single-sourced to Censys. The scan data (certificate subjects, JARM, banners, port fingerprints, ASN/geo distribution) is directly observed and reproducible via the queries in §4. The interpretation — that Cluster A is a training fleet and Cluster B is operational — is Censys' couched assessment and is not corroborated by a second vendor. No threat actor or group is named or attributed in the source material, and no MITRE ATT&CK profile is provided; treat any attribution as unconfirmed and do not assign one. The presence of a host in this dataset does not establish malicious use — Mythic is legitimately used in authorised penetration tests and red-team engagements.

4. Mitigation & containment

There is no vendor patch for this item. Mythic is a legitimate open-source framework; the remediation is detection, egress control and internal discovery, not version pinning. If Mythic is found running in your estate without authorisation, treat it as a compromise, not a misconfiguration.

P1 — within 24 hours

1. Add the seven IPs and the domain from §5 to egress blocklists and DNS sinkholes; alert on any hit rather than silently dropping.
2. Hunt egress/TLS metadata for sessions to TCP/7443 presenting a self-signed ECDSA-SHA384 certificate with subject O=Mythic or O=Mythic C2, and for any certificate chain containing CN=operators → CN=multiplayer.
3. Search container inventory and orchestration telemetry for the container names mythic_nginx, mythic_rabbitmq, mythic_server. These indicate unauthorised tooling deployment or an unsanctioned engagement.
4. Search proxy logs for responses on port 443 carrying Server: NetDNA-cache/2.2 with a 404 status and Content-Type: application/javascript; charset=utf-8. NetDNA is a legacy CDN brand; a live CDN edge node presenting this header on a non-CDN-owned host is a strong signal.
5. Review egress for Discord API/WebSocket traffic originating from servers with no business need for it — the source identifies Discord as a production C2 transport for the Cluster B operator.

P2 — within 72 hours

6. Run the Censys queries and cross-reference the returned host list against your egress telemetry: - host.services.threats.name: "Mythic" or web.threats.name: "Mythic" - host.services.cert.parsed.subject_dn: "O=Mythic"
7. Deploy the YARA and Sigma rules in §6.
8. Review egress policy for non-standard high ports — 7443, 8081, 9443, 31337, 4444 — from server subnets. Legitimate business traffic on these ports should be enumerated and everything else denied.
9. If any internal host is confirmed communicating with the §5 infrastructure: isolate it, preserve volatile evidence, and invoke incident response. Do not assume the implant is detectable by signature — Mythic's agent-agnostic design means the server-side indicator is the reliable one.

P3 — within 7 days

10. Retrospective hunt over at least 90 days of egress, proxy and TLS-inspection logs for the JARM value and certificate fingerprints in §5.
11. Inventory any sanctioned red-team or penetration-test engagement that uses Mythic, and confirm it is documented, scoped and expected. Unsanctioned Mythic in your estate is the finding that matters.
12. Threat-hunt for the nyx and fys2 payload families and for steganographic staging artefacts on endpoints and file shares.

5. Indicators of compromise

All indicators below are single-sourced to Censys; verify before enforcement. Network indicators are defanged.

Note on the JARM value: it is a 64-character JARM fingerprint, not a SHA-256 file hash. It is labelled jarm deliberately; do not ingest it into file-hash matching.

ipv4  68[.]178[.]202[.]150
ipv4  68[.]178[.]205[.]17
ipv4  192[.]169[.]176[.]54
ipv4  65[.]87[.]7[.]11
ipv4  194[.]26[.]192[.]117
ipv4  142[.]93[.]52[.]11
ipv4  170[.]64[.]183[.]242
domain  telemetry-update[.]services
jarm  1dd40d40d00040d00042d43d000000831b6af40378e2dd35eeac4e9311926e
certificate  O=Mythic
certificate  O=Mythic C2
certificate  CN=operators
certificate  CN=multiplayer
filename  nyx-v5.exe
filename  nyx-v6.exe
filename  nyx-v7.exe
filename  nyx-v8.exe
filename  nyx-v9.exe
filename  nyx-v10.exe
filename  nyx-v11.exe
filename  nyx-v12.exe
filename  nyx-v13.exe
filename  nyx-v14.exe
filename  nyx-v15.exe
filename  fys2_config.rs
filename  fys2_src.tar.gz
filename  discord_check.py
filename  discord_diag.py
filename  discord_probe.py
filename  stego_roundtrip.py
filename  discord_fix2/stego.py
filename  chacha_stage_test.py
filename  mythic_task.py
filename  mythic_whoami.py
filename  mythic_shell.py
path  /serve/

Behavioural indicators

The source describes several observable behaviours for which no atomic value is published. These belong in telemetry, not in a blocklist.

6. Detection

The YARA rule below targets the operator tooling artefacts observed on the staging server. It is written against the exact filenames and strings published by Censys; it will match the operator's source and script files, not the compiled implants, for which no byte-level artefacts are available.

rule AT_Mythic_Operator_Tooling_Artefacts
{
    meta:
        author      = "Adverse Trace"
        date        = "2026-09-15"
        reference   = "https://censys.com/blog/mythic-c2/"
        description = "Detects operator-side tooling artefacts associated with the Mythic C2 staging server reported by Censys (nyx/fys2 payload families, Discord transport, steganography and Mythic tasking scripts)."
        tlp         = "AMBER"

    strings:
        $a1 = "mythic_task.py" ascii
        $a2 = "mythic_whoami.py" ascii
        $a3 = "mythic_shell.py" ascii
        $a4 = "discord_check.py" ascii
        $a5 = "discord_diag.py" ascii
        $a6 = "discord_probe.py" ascii
        $a7 = "stego_roundtrip.py" ascii
        $a8 = "chacha_stage_test.py" ascii
        $a9 = "fys2_config.rs" ascii
        $a10 = "fys2_src.tar.gz" ascii
        $a11 = "telemetry-update.services" ascii
        $a12 = "NetDNA-cache/2.2" ascii
        $a13 = "nyx-v" ascii

    condition:
        uint16(0) == 0x5A4D or 3 of them
}

The Sigma rules below cover the two highest-fidelity network behaviours: egress to the identified infrastructure, and the spoofed CDN header.

title: Egress to Known Mythic C2 Infrastructure (Censys September 2026)
id: 8f3c1a72-4d5e-4b90-9c11-7a2e6f0b3d84
status: experimental
description: Detects network connections to IP addresses and the domain associated with Mythic C2 infrastructure reported by Censys on 2026-09-15.
author: Adverse Trace
date: 2026/09/15
references:

    - https://censys.com/blog/mythic-c2/
tags:

    - attack.command_and_control
    - attack.t1071.001
logsource:
    category: network_connection
    product: windows
detection:
    selection_dst_ip:
        DestinationIp:

            - '68.178.202.150'
            - '68.178.205.17'
            - '192.169.176.54'
            - '65.87.7.11'
            - '194.26.192.117'
            - '142.93.52.11'
            - '170.64.183.242'
    selection_dst_host:
        DestinationHostname|endswith: 'telemetry-update.services'
    condition: 1 of selection_*
falsepositives:

    - Authorised red team or penetration test activity using this infrastructure
level: high

title: Spoofed NetDNA CDN Header on Non-CDN Host
id: 2b7d94e0-6a13-4c88-b5f2-9e0d1c4a7f36
status: experimental
description: Detects HTTP responses carrying the legacy NetDNA CDN Server header with a 404 status and JavaScript content type, a pattern used by Mythic C2 infrastructure to masquerade as a CDN edge node.
author: Adverse Trace
date: 2026/09/15
references:

    - https://censys.com/blog/mythic-c2/
tags:

    - attack.command_and_control
    - attack.t1071.001
    - attack.t1036
logsource:
    category: proxy
detection:
    selection_header:
        cs-header|contains: 'NetDNA-cache/2.2'
    selection_status:
        sc-status: 404
    selection_type:
        cs-content-type|contains: 'application/javascript'
    condition: selection_header and selection_status and selection_type
falsepositives:

    - Legacy NetDNA or MaxCDN infrastructure still in production (expected to be rare)
level: medium

7. Sources

• Censys — Mythic C2 Activity at Internet Scale, https://censys.com/blog/mythic-c2/, published 2026-09-15. (Primary and sole source; the related-source extract supplied is the same publication.)

8. Adverse Trace position

This is exposure intelligence, not a vulnerability, and we will not manufacture a severity score for it: the VERIFIED REFERENCE DATA resolved no CVE, no CVSS vector and no CISA-KEV entry, and none exists for a legitimate open-source framework being deployed on the public internet. The operational severity for a client is conditional and binary — if egress telemetry shows an internal host talking to the infrastructure in §5, that is a high-severity post-compromise C2 channel; if it does not, this is context that improves your hunting, not an incident. The genuinely notable finding is Cluster B: a Mythic deployment with a custom domain, a spoofed CDN header, an eleven-iteration custom Rust implant family and a Discord transport is not a default install, and the server-side fingerprints (JARM, certificate subject, port split between 443 and 7443) are the durable detection surface given Mythic's agent-agnostic design. We flag clearly that every finding here is single-sourced to Censys, that the lab-versus-operational assessments are the publisher's own couched inference, and that no actor attribution is available — no group is named and no MITRE profile is provided, so any attribution would be unconfirmed. Client impact for EMEA financial services is concentrated in egress hygiene and internal tooling discovery rather than patching. Next, we will monitor for corroborating vendor reporting on the nyx and fys2 families, re-run the Censys host queries at 30 days to track whether the Cluster B infrastructure rotates, and push the §6 rules to client detection pipelines on request.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.