mythic-implant-development
Audited by Socket on Sep 4, 2026
7 alerts found:
Securityx4Malwarex3SUSPICIOUS. The skill is internally consistent as Mythic implant-development guidance and its cited install sources are mostly official, so it does not look like credential theft or supply-chain malware. However, it equips an AI agent with offensive C2/implant development and covert networking capabilities, making the overall security risk high despite low evidence of direct malicious payload delivery in the skill text itself.
This fragment is high-risk because it automatically creates an operator task for a newly registered agent callback and explicitly instructs the agent to run a shell command (whoami) without additional gating in the shown logic. Combined with indications of wrapper payload handling and custom RPC exposure, the dependency appears to provide offensive C2 automation capabilities rather than benign functionality. While further behaviors (exfiltration/persistence) are not shown, the command-execution tasking alone strongly indicates malicious/dual-use intent.
This module’s described behavior is a controller-driven SOCKS5 CONNECT TCP tunneling proxy: it dials arbitrary destinations specified by SOCKS5 requests, relays bidirectional stream bytes via base64 within controller messages, and provides connection status/teardown signaling. While base64 is not inherently malicious, the combination of arbitrary network dialing and bidirectional tunneling through a C2-style controller interface is a strong high-risk indicator typical of remote-access/post-exploitation tooling. Because the actual code is not included here, additional security properties (authentication, allowlists, resource limits, and safe error handling) cannot be verified from this excerpt alone.
The provided fragment describes encrypted Mythic C2 agent communications, including a custom key exchange mechanism that repeatedly returns staging_translation responses containing raw enc_key/dec_key and next_uuid until checkin. While the AES-CBC + HMAC and RSA-OAEP details are standard cryptographic concepts, the explicit C2 framing, session/callback orchestration, and agent state persistence guidance make this highly indicative of malicious remote control infrastructure rather than benign software.
The provided fragment is configuration/documentation for a C2-capable agent/server architecture, including untrusted agent/operator-supplied metadata (User-Agent/Host) and described server-side forwarding of agent messages to a central Mythic orchestration endpoint over HTTPS, with responses returned to the agent. No explicit malicious implementation (e.g., credential theft, persistence, payload execution, or obfuscation) is shown in the excerpt, but the capability category is inherently high-risk. Further review of the actual server forwarding implementation and any IO/IOC/file-hosting logic is required to determine whether it is purely legitimate security tooling or actively malicious.
This fragment describes a Mythic-style translation container workflow centered on custom key exchange (EKE), repeated staged message packaging (staging_translation until checkin) with raw encryption key material and payload bytes, and persistent storage of arbitrary bytes between staging steps. No direct proof of additional malware behaviors (e.g., exfiltration or execution) is present because the implementation is truncated/missing, but the documented capabilities are highly consistent with C2/agent orchestration. Treat this as a high-risk, dual-use component requiring full code review of the unseen implementation of fromC2Format/toC2Format and the storage/response handling logic.
This module fragment is strongly indicative of offensive C2/orchestration behavior: it uses Mythic RPC calls to manage backend artifacts and, critically, creates an agent task that executes a shell command (shown as whoami) bound to a runtime agent callback, then records responses. Even if intended for legitimate red-team use, in a general software supply-chain context this is inherently high-risk. The snippet provides no evidence of obfuscation, but missing context prevents confirmation of authorization/guardrails.