The Mythic framework remains one of the key tools in a penetration tester’s arsenal. Its modular architecture, containerized deployment, and user-friendly web interface make it a practical choice for Red Team operations. In our previous posts, we have already discussed the intricacies of this framework, from deployment to OPSEC nuances.
Historically, Mythic agents have most often communicated over HTTP(S) channels. This is universal but predictable: modern security tools, from TLS inspection to behavioral analysis, are good at detecting suspicious web traffic. In particular, our colleagues recently published a detailed analysis of Mythic’s network signatures with specific patterns and artifacts in the traffic; essentially, this is a ready-made reference guide for SOC analysts.
But what if we switch to a different transport? TCP support provides room for maneuver. Instead of HTTP headers and typical TLS handshakes, we get L4 sessions with customizable framing.
However, it is important to remember that this is not “invisibility,” but rather a different detection surface. Web patterns disappear, but signs remain on egress controls and based on L4 behavior. Plus, there is an opportunity to fine-tune the exchange protocol, maintain stable sessions for tunneling, and reduce latency when executing commands.
Our Red Team continues to contribute to the development of convenient penetration testing tools: the implementation of native TCP transport for the Xenon agent has already been added to the main branch of the project. Now, penetration testers have an additional communication channel with flexible connection settings and support for typical Mythic functions – task management, file transfer, port forwarding via the new transport.
Important: In the case of Xenon, TCP is primarily used as a P2P/Link transport within the network; external egress in most scenarios is still provided by the agent via HTTP/WS.
What should defenders do?
For the Blue Team, Mythic’s transition to TCP transport is a signal to update the methodology.
We recommend:
— reviewing network traffic monitoring rules,
— adding correlations between network connections and process activity,
— checking the application of egress policies in segments without web proxies,
— expanding hunting for L4 behavior.
