Kaspersky's Hunting for Mythic in network traffic

Khushal

Level 13
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
595
3,595
1,169
Kaspersky Researchers highlight that the Mythic post-exploitation framework is increasingly used by attackers for lateral movement and data exfiltration, emphasizing detection methods through network traffic analysis to combat these threats.


1765537365976.png
 
Kaspersky Researchers highlight that the Mythic post-exploitation framework is increasingly used by attackers for lateral movement and data exfiltration, emphasizing detection methods through network traffic analysis to combat these threats.


View attachment 293677
Interesting find – Mythic keeps showing up more and more in real‑world intrusions.

Quick context on Mythic
Mythic is an open‑source, modular post‑exploitation / C2 framework. It’s used after initial compromise for:
  • Lateral movement inside the network
  • Credential theft and privilege escalation
  • Data discovery and exfiltration
  • Running custom payloads (“agents”) over various protocols

Because it’s legitimate open‑source tooling, attackers can:
  • Blend in with red‑team traffic
  • Customize agents and traffic profiles
  • Rotate C2 profiles quickly to evade signatures

Why network‑based detection matters
Kaspersky’s focus on network traffic analysis is important because:
  • Endpoint agents can be disabled or bypassed after compromise.
  • C2 frameworks often try to “live off the land” and look normal on the host.
  • Network patterns (C2 beacons, TLS fingerprinting, URI/headers patterns, timing and packet sizes) are harder to completely hide.

Even when traffic is encrypted (HTTPS), defenders can still:
  • Use TLS fingerprinting (JA3/JA3S, SNI patterns) to hunt for suspicious C2 profiles.
  • Look for unusual beaconing (regular intervals to rare domains/IPs).
  • Spot odd HTTP(S) usage (user‑agent anomalies, rare paths, strange response sizes).
  • Correlate with internal behavior (host suddenly talking out to new infra right after an alert/logon event).

What defenders can practically do
For org/blue‑team environments:
  • Deploy and tune full‑packet capture or at least rich flow logs (NetFlow/IPFIX, Zeek, etc.).
  • Ingest and use the IOCs / patterns from the article (domains, JA3 hashes, URIs, timing patterns) into your SIEM/IDS where possible.
  • Baseline “normal” outbound HTTPS for endpoints and servers, then hunt for outliers.
  • Restrict direct outbound internet access from servers; force traffic through proxies with inspection and logging.
  • Combine EDR telemetry (suspicious processes, LOLBins, privilege escalation) with network anomalies to raise confidence.

For home / small office users
Mythic is more of an APT / targeted attack tool, but general hygiene still helps:
  • Keep OS and software patched.
  • Use a reputable AV/EDR with web protection enabled.
  • Segment critical devices (NAS, servers) from general browsing devices if possible.
  • Monitor router/firewall logs for unknown remote connections if you have the skills.

If you’re interested, I can outline:
  • More concrete hunting ideas (e.g. example queries/logic for SIEM/Zeek/Suricata), or
  • How Mythic compares to other frameworks like Cobalt Strike, Sliver, Brute Ratel from a detection standpoint.
 
The analysis of the network traffic patterns associated with the Mythic framework confirms that while its modularity offers attackers flexibility, its default communication profiles leave distinct, detectable footprints. Despite the encryption, the initial handshake and data structure protocols create a static signature that can be exploited by defenders.

The network telemetry indicates that the "Achilles' heel" of Mythic's communication strategy, across SMB, TCP, and HTTP, is the consistent transmission of the agent's UUID at the beginning of the payload. Specifically, the analysis shows that the data structure follows a rigid pattern: a Base64-encoded string comprising the UUID followed by the AES-256 encrypted JSON blob. In P2P SMB and TCP traffic, this UUID transmission is preceded by a specific header structure (Total Size, Block Count, Block ID) which creates a predictable byte sequence. Regarding the covert channels like Discord and GitHub, the logs show that the API calls themselves, specifically the creation of messages in Discord channels or branches in GitHub repositories, often carry this same Base64 encoded UUID string in plaintext fields before the encrypted payload is processed. This allows for positive identification even when the actual command data is encrypted.

To detect this activity within your environment, I recommend the following hunting strategy.

Implement UUID Pattern Matching

Configure your IDS/IPS to scan for the specific UUID regex pattern `[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}` within the first 100 bytes of SMB pipes and TCP streams, as well as in the arguments of HTTP POST requests.

Monitor Specific API Volume

For encrypted channels where payload inspection is impossible, configure your SIEM to alert on high-frequency, periodic DNS queries or TLS sessions to `discord.com` and `api.github.com`, specifically looking for outlier volume from non-developer workstations.

Inspect TLS Certificates

If you have TLS interception capabilities, or if checking server logs, verify the SSL certificate subjects, default Mythic installations often utilize a self-signed certificate with the Organization Name simply set to "Mythic C2".

While post-exploitation frameworks evolve, the requirement to maintain a stable command channel forces attackers to use predictable protocols. By anchoring your detection logic on these structural necessities rather than ephemeral indicators like IP addresses, you significantly increase the cost of operation for the adversary.
 
  • Like
Reactions: Khushal