Zimperium zLabs reveals DroidLock, a new Android malware acting like ransomware that can hijack Android devices, steal credentials via phishing, and stream your screen via VNC.
This weekโs cyber stories show how fast the online world can turn risky. Hackers are sneaking malware into movie downloads, browser add-ons, and even software updates people trust. Tech giants and governments are racing to plug new holes while arguing over privacy and control. And researchers keep uncovering just how much of our digital life is still wide open.
The new Threatsday Bulletin
Cybersecurity researchers have disclosed details of a new fully-featured Windows backdoor called NANOREMOTE that uses the Google Drive API for command-and-control (C2) purposes.
According to a report from Elastic Security Labs, the malware shares code similarities with another implant codenamed FINALDRAFT (aka Squidoor) that employs Microsoft Graph API for C2. FINALDRAFT is attributed to a
As enterprises refine their strategies for handling Non-Human Identities (NHIs), Robotic Process Automation (RPA) has become a powerful tool for streamlining operations and enhancing security. However, since RPA bots have varying levels of access to sensitive information, enterprises must be prepared to mitigate a variety of challenges. In large organizations, bots are starting to outnumber
In 2025, we engineered a truly new era of modern DAST.
We unlocked next-gen assessments with โinfiniteโ payloads, eliminated the trade-off between broad attack surface visibility and deep application testing, and found the ultimate balance between human ingenuity and machine intelligence with our AI Researcher, Alfred. The result? A modern DAST product that delivers unmatched innovation and accuracy in the AppSec space.ย
Read on for our highlights of the year and a look at the top vulnerabilities we found
Detectify: DAST + ASMย
The AppSec space is moving decisively past the idea that โknowing what you haveโ and โtesting what you haveโ are separate problems. Weโve long argued that attack surface discovery & mapping is the first, non-negotiable phase of dynamic testing. If you fail here, the subsequent phasesโcrawling, fuzzing, and verificationโare useless for the assets you missed.
In 2025, we saw the โtraditionalโ DAST modelโwhere you manually configure scan profiles for known assetsโstruggle to keep up with decentralized, multi-cloud environments. Vulnerabilities often arise at the interfaces between microservices and cloud components, areas that static lists of IPs often miss.
By combining DAST withAttack Surface Management (ASM), we reinvented DAST as a method applied to the entire attack surface, not just a tool for isolated apps. This approach allows us to feed context into the scanner, ensuring that we arenโt just finding assets, but understanding their technology stack to be able to recommend which ones you should be deep testing.ย
We shipped a great number of features this year, focusing on depth, accuracy, and โbreaking the illusion of coverage.โ
Next-gen Assessment: API Scanning with Dynamic Payloads
APIs are the connective tissue of the modern web, and traditional scanners relying on finite wordlists simply canโt cover the complexity of custom endpoints. This year, we introduced Dynamic Payloads, a fuzzing engine capable of generating over 922 quintillion unique payloads for a single vulnerability type (like prompt injection).
How does it work? We introduced the concept of a โseed numberโโa value that deterministically generates a specific subset of payloads from an โinfiniteโ list. This allows us to run massive, randomized fuzzing campaigns while ensuring every scan is reproducible.
Smart Fuzzing: The system uses Machine Learning to identify which โseedsโ are most effective at finding bugs, prioritizing them for future scans.
Response Comparison: The engine analyzes anomaliesโlike a 403 flipping to a 200 or unexpected content length changesโto detect logic flaws without needing prior knowledge of the APIโs internal workings.
Weโve significantly enhanced our API Scanner since its launch, rolling out new updates to streamline the automation of security testing. This includes supporting a wider variety of APIs, particularly those utilizing modern OAuth flows, and dramatically improving our coverage for broken authentication issues, such as weak JSON Web Token (JWT) implementations.
Our research found a startling stat: organizations are missing 9 out of 10 of their complex, content-rich web applications when selecting targets for deep scanning. To solve this, we launched Asset Classification.
This feature mimics hacker reconnaissance by analyzing response data to categorize assets. We look for specific indicators of โcomplex web appsโ:
Status Codes & Body Length: Filtering for 200 OK and bodies >100 characters.
Interaction Points: Identifying login forms, input fields, and even cookie consent forms.
Tech Stack: Analyzing headers (like CSP) and frameworks.
Based on this โcomplexity score,โ Detectify now provides Intelligent Scan Recommendations, telling you exactly which assets warrant a full DAST assessment and which can be monitored lightly. This ensures you arenโt wasting time configuring scans while leaving your business-critical apps exposed.
A clean scan report should mean you are secure, not that your WAF successfully blocked the scanner. This year, we released Scan Interference Detection.
We now actively verify if our scanner is being throttled or blocked by sending specific โwafcheckโ payloads (e.g., /x?wafcheck=โฆ) and comparing the response to a clean request. If we detect interference, we flag it immediately so you can whitelist our improved scanner IPs. This transparency ensures your results reflect the true state of your application, not the configuration of your firewall.
Vulnerabilities and threats
Our scanning engine is powered by a unique combination of automated crawling and human ingenuity. This year, that combination got even smarter with Alfred, our fully autonomous AI security researcher. It has revolutionized how we build security tests for CVEs, delivering over 450 validated tests with a 70% โzero manual adjustmentโ rate during the first six months.
Since Q4, Alfred sources both vulnerabilities and active threat actor data. This allows it to prioritize actively weaponized CVEs those being used right now by APTs and cybercriminals. This shift ensures that Detectify customers are tested against the vulnerabilities that have the highest probability of being exploited in the wild, often within hours of disclosure.
2025 was a year where โlegacyโ misconfigurations collided with modern framework failures. From the panic of new RCEs in React to the relentless exploitation of edge devices, the threat landscape was unforgiving. Thanks to the combined power of our Crowdsource community, internal research team, and Alfredโs enhanced threat intelligence, we were able to weaponize tests for these critical issues (often within hours of disclosure).
Here are the vulnerabilities that defined the year, selected by our researchers for their severity, ubiquity, and the sheer panic they caused in the security community.
This CVSS 10.0 vulnerability demanded attention as it exposed Reactโs Server Components to unauthenticated remote code execution, affecting millions of modern websites. It generated Log4Shell-levels of panic and was immediately weaponized by China-nexus state actors to compromise web infrastructure globally.
With a CVSS 10.0 severity, this misconfiguration in Adobe Experience Manager allowed unauthenticated attackers to execute code via the exposed Struts2 โDevMode.โ It is clear example of how a single forgotten debug endpoint can lead to total system takeover in high-value enterprise environments.
CVE-2025-25257: FortiWeb SQL Injection (CVSS 9.8)
This critical SQL injection vulnerability allowed unauthenticated attackers to execute commands as root on Fortinetโs Web Application Firewalls. It stands out because it compromised the very device meant to protect the network, turning the shield into a weapon for attackers.
CVE-2025-53770 & CVE-2025-53771: The โToolShellโ Chain (SharePoint) (CVSS 9.8 and 6.5)
This chained vulnerability allowed attackers to bypass authentication via header spoofing (53771) and subsequently execute arbitrary code (53770) on on-premise SharePoint servers. Nominated for its ubiquity and severity, the โToolShellโ chain was rapidly adopted by ransomware gangs to breach internal networks and encrypt entire file repositories.
This vulnerability from early in the year allowed unauthenticated attackers to hijack VPN sessions, continuing the relentless trend of edge exploitation. It was exploited as a zero-day by suspected espionage groups (UNC5221), who used it to deploy webshells before a patch was even available.
Detectify vs. Competitors
The DAST market is crowded, and on the surface, many tools look identical. But dig a little deeper, and the differences in philosophy become clear.
Some platforms are built for the SOC (casting a wide, shallow net to gather compliance data and potential risks across infrastructure). Others, like Detectify, are more focused on AppSec and uniquely designed to go broad and deep, source the latest CVEs and non-CVE threats, prove exploitability with payloads, and fit seamlessly into your workflows.
In 2025, we published a transparentDetectify vs. Competitors blog series to help you navigate these differences. Whether you need the broad compliance reporting of a platform giant or the hacker-driven precision of a modern DAST, we believe you should choose the tool that fits your teamโs DNA.
Need a framework to decide? We also released theDAST Buyerโs Guide 2026. It moves beyond simple feature checklists and evaluates the market across 8 technical criteriaโfrom discovery capabilities to developer workflow. Use it to answer the only question that matters: what do you need to do?
Explore Detectifyโs 2025 Year in Review: From "infinite" API payloads and AI-driven research to the top vulnerabilities of the year. See the future of modern DAST.
Threat actors frequently employ post-exploitation frameworks in cyberattacks to maintain control over compromised hosts and move laterally within the organizationโs network. While they once favored closed-source frameworks, such as Cobalt Strike and Brute Ratel C4, open-source projects like Mythic, Sliver, and Havoc have surged in popularity in recent years. Malicious actors are also quick to adopt relatively new frameworks, such as Adaptix C2.
Analysis of popular frameworks revealed that their development focuses heavily on evading detection by antivirus and EDR solutions, often at the expense of stealth against systems that analyze network traffic. While obfuscating an agentโs network activity is inherently challenging, agents must inevitably communicate with their command-and-control servers. Consequently, an agentโs presence in the system and its malicious actions can be detected with the help of various network-based intrusion detection systems (IDS) and, of course, Network Detection and Response (NDR) solutions.
This article examines methods for detecting the Mythic framework within an infrastructure by analyzing network traffic. This framework has gained significant traction among various threat actors, including Mythic Likho (Arcane Wolf) ะธ GOFFEE (Paper Werewolf), and continues to be used in APT and other attacks.
The Mythic framework
Mythic C2 is a multi-user command and control (C&C, or C2) platform designed for managing malicious agents during complex cyberattacks. Mythic is built on a Docker container architecture, with its core componentsย โ the server, agents, and transport modulesย โ written in Python. This architecture allows operators to add new agents, communication channels, and custom modifications on the fly.
Since Mythic is a versatile tool for the attacker, from the defenderโs perspective, its use can align with multiple stages of the Unified Kill Chain, as well as a large number of tactics, techniques, and procedures in the MITRE ATT&CKยฎ framework.
Pivoting is a tactic where the attacker uses an already compromised system as a pivot point to gain access to other systems within the network. In this way, they gradually expand their presence within the organizationโs infrastructure, bypassing firewalls, network segmentation, and other security controls.
Collection (TA0009) is a tactic focused on gathering and aggregating information of value to the attacker: files, credentials, screenshots, and system logs. In the context of network operations, collection is often performed locally on compromised hosts, with data then packaged for transfer. Tools like Mythic automate the discovery and selection of data sought by the adversary.
Exfiltration (TA0010) is the process of moving collected information out of the secured network via legitimate or covert channels, such as HTTP(s), DNS, or SMB, etc. Attackers may use resident agents or intermediate relays (pivot hosts) to conceal the exfiltration source and route.
Command and Control (TA0011) encompasses the mechanisms for establishing and maintaining a communication channel between the operator and compromised hosts to transmit commands and receive status updates. This includes direct connections, relaying through pivot hosts, and the use of covert protocols. Frameworks like Mythic provide advanced C2 capabilities, such as scheduled command execution, tunneling, and multi-channel communication, which complicate the detection and blocking of their activity.
This article focuses exclusively on the Command and Control (TA0011) tactic, whose techniques can be effectively detected within the network traffic of Mythic agents.
Detecting Mythic agent activity in network traffic
At the time of writing, Mythic supports data transfer over HTTP/S, WebSocket, TCP, SMB, DNS, and MQTT. The platform also boasts over a dozen different agents, written in Go, Python, and C#, designed for Windows, macOS, and Linux.
Mythic employs two primary architectures for its command network:
In this model, agents communicate with adjacent agents forming a chain of connections which eventually leads to a node communicating directly with the Mythic C2 server. For this purpose, agents utilize TCP and SMB.
In this model, agents communicate directly with the C2 server via HTTP/S, WebSocket, MQTT, or DNS.
P2P communication
Mythic provides pivoting capabilities via named SMB pipes and TCP sockets. To detect Mythic agent activity in P2P mode, we will examine their network traffic and create corresponding Suricata detection rules (signatures).
P2P communication via SMB
When managing agents via the SMB protocol, a named pipe is used by default for communication, with its name matching the agentโs UUID.
Although this parameter can be changed, it serves as a reliable indicator and can be easily described with a regular expression. Example:
[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}
For SMB communication, agents encode and encrypt data according to the pattern: base64(UUID+AES256(JSON)). This data is then split into blocks and transmitted over the network. The screenshot below illustrates what a network session for establishing a connection between agents looks like in Wireshark.
Commands and their responses are packaged within the MythicMessage data structure. This structure contains three header fields, as well as the commands themselves or the corresponding responses:
Total size (4 bytes)
Number of data blocks (4 bytes)
Current block number (4 bytes)
Base64-encoded data
The screenshot below shows an example of SMB communication between agents.
The agent (10.63.101.164) sends a command to another agent in the MythicMessage format. The first three Write Requests transmit the total message size, total number of blocks, and current block number. The fourth request transmits the Base64-encoded data. This is followed by a sequence of Read Requests, which are also transmitted in the MythicMessage format.
Below are the data transmitted in the fourth field of the MythicMessage structure.
The content is encoded in Base64. Upon decoding, the structure of the transmitted information becomes visible: it begins with the UUID of the infected host, followed by a data block encrypted using AES-256.
The fact that the data starts with a UUID string can be leveraged to create a signature-based detection rule that searches network packets for the identifier pattern.
To search for packets containing a UUID, the following signature can be applied. It uses specific request types and protocol flags as filters (Command: Ioctl (11), Function: FSCTL_PIPE_WAIT(0x00110018)), followed by a check to see if the pipe name matches the UUID pattern.
Agent activity can also be detected by analyzing data transmitted in SMB WriteRequest packets with the protocol flag Command: Write (9) and a distinct packet structure where the BlobOffset and BlobLen fields are set to zero. If the Data field is Base64-encoded and, after decoding, begins with a UUID-formatted string, this indicates a command-and-control channel.
Below is the KATA NDR user interface displaying an alert about detecting a Mythic agent operating in P2P mode over SMB. In this instance, the first ruleย โ which checks the request type, protocol flags, and the UUID patternย โ was triggered.
It should be noted that these signatures have a limitation. If the SMBv3 protocol with encryption enabled is used, Mythic agent activity cannot be detected with signature-based methods. A possible alternative is behavioral analysis. However, in this context, it suffers from low accuracy and a high false-positive rate. The SMB protocol is widely used by organizations for various legitimate purposes, making it difficult to isolate behavioral patterns that definitively indicate malicious activity.
P2P communication via TCP
Mythic also supports P2P communications via TCP. The connection initialization process appears in network traffic as follows:
As with SMB, the MythicMessage structure is used for transmitting and receiving data. First, the data length (4 bytes) is sent as a big-endian DWORD in a separate packet. Subsequent packets transmit the number of data blocks, the current block number, and the data itself. However, unlike SMB packets, the value of the current block number field is always 0x00000000, due to TCPโs built-in packet fragmentation support.
The data encoding scheme is also analogous to what we observed with SMB and appears as follows: base64(UUID+AES256(JSON)). Below is an example of a network packet containing Mythic data.
The decoded data appears as follows:
Similar to communication via SMB, signature-based detection rules can be created for TCP traffic to identify Mythic agent activity by searching for packets containing UUID-formatted strings. Below are two Suricata detection rules. The first rule is a utility rule. It does not generate security alerts but instead tags the TCP session with an internal flag, which is then checked by another rule. The second rule verifies the flag and applies filters to confirm that the current packet is being analyzed at the beginning of a network session. It then decodes the Base64 data and searches the resulting content for a UUID-formatted string.
Below is the NDR interface displaying an example of the two rules detecting a Mythic agent operating in P2P mode over TCP.
Egress transport modules
Covert Egress communication
For stealthy operations, Mythic allows agents to be managed through popular services. This makes its activity less conspicuous within network traffic. Mythic includes transport modules based on the following services:
Discord
GitHub
Slack
Of these, only the first two remain relevant at the time of writing. Communication via Slack (the Slack C2 Profile transport module) is no longer supported by the developers and is considered deprecated, so we will not examine it further.
The Discord C2 Profile transport module
The use of the Discord service as a mediator for C2 communication within the Mythic framework has been gaining popularity recently. In this scenario, agent traffic is indistinguishable from normal Discord activity, with commands and their execution results masquerading as messages and file attachments. Communication with the server occurs over HTTPS and is encrypted with TLS. Therefore, detecting Mythic traffic requires decrypting this.
Analyzing decrypted TLS traffic
Letโs assume we are using an NDR platform in conjunction with a network traffic decryption (TLS inspection) system to detect suspicious network activity. In this case, we operate under the assumption that we can decrypt all TLS traffic. Letโs examine possible detection rules for that scenario.
Agent and server communication occurs via Discord API calls to send messages to a specific channel. Communication between the agent and Mythic uses the MythicMessageWrapper structure, which contains the following fields:
message: the transmitted data
sender_id: a GUID generated by the agent, included in every message
to_server: a direction flagย โ a message intended for the server or the agent
id: not used
final: not used
Of particular interest to us is the message field, which contains the transmitted data encoded in Base64. The MythicMessageWrapper message is transmitted in plaintext, making it accessible to anyone with read permissions for messages on the Discord server.
Below is an example of data transmission via messages in a Discord channel.
To establish a connection, the agent authenticates to the Discord server via the API call /api/v10/gateway/bot. We observe the following data in the network traffic:
After successful initialization, the agent gains the ability to receive and respond to commands. To create a message in the channel, the agent makes a POST request to the API endpoint /channels/<channel.id>/messages. The network traffic for this call is shown in the screenshot below.
After decoding the Base64, the content of the message field appears as follows:
A structure characteristic of a UUID is visible at the beginning of the packet.
After processing the message, the agent deletes it from the channel via a DELETE request to the API endpoint /channels/{channel.id}/messages/{message.id}.
Below is a Suricata rule that detects the agentโs Discord-based communication activity. It checks the API activity for creating HTTP messages for the presence of Base64-encoded data containing the agentโs UUID.
Below is the NDR user interface displaying an example of detecting the activity of the Discord C2 Profile transport module for a Mythic agent within decrypted HTTP traffic.
Analyzing encrypted TLS traffic
If Discord usage is permitted on the network and there is no capability to decrypt traffic, it becomes nearly impossible to detect agent activity. In this scenario, behavioral analysis of requests to the Discord server may prove useful. Below is network traffic showing frequent TLS connections to the Discord server, which could indicate commands being sent to an agent.
In this case, we can use a Suricata rule to detect the frequent TLS sessions with Discord servers:
alert tcp any any -> any any (msg: "NetTool.PossibleMythicDiscordEgress.TLS.C&C"; flow: to_server, established; tls_sni; content: "discord.com"; nocase; threshold: type both, track by_src, count 4, seconds 420; reference: url, https://github.com/MythicC2Profiles/discord; classtype: ndr3; sid: 9000106; rev: 1;)
Another method for detecting these communications involves tracking multiple DNS queries to the discord.com domain.
The following rule can be applied to detect these:
Below is the NDR user interface showing an example of a custom rule in operation, detecting the activity of the Discord C2 Profile transport module for a Mythic agent within encrypted traffic based on characteristic DNS queries.
The proposed rule options have low accuracy and can generate a high number of false positives. Therefore, they must be adapted to the specific characteristics of the infrastructure in which they will run. Threshold and count parameters, which control the triggering frequency and time window, require tuning.
GitHub C2 Profile transport module
GitHubโs popularity has made it an attractive choice as a mediator for managing Mythic agents. The core concept is the same as in other covert Egress communication transport modules. Communication with GitHub utilizes HTTPS. Successful operation requires an account on the target platform and the ability to communicate via API calls. The transport module utilizes the GitHub API to send comments to pre-created Issues and to commit files to a branch within a repository controlled by the attackers. In this model, the agent interacts only with GitHub: it creates and reads comments, uploads files, and manages branches. It does not communicate with any other servers. The communication algorithm via GitHub is as follows:
The agent posts a comment (check-in) to a designated Issue on GitHub, intended for agents to report their results.
The Mythic server validates the comment, deletes it, and posts a reply in an issue designated for server use.
The agent creates a branch with a name matching its UUID and writes a get_tasking file to it (performs a push request).
The Mythic server reads the file and writes a response file to the same branch.
The agent reads the response file, deletes the branch, pauses, and repeats the cycle.
Analyzing decrypted TLS traffic
Letโs consider an approach to detecting agent activity when traffic decryption is possible.
Agent communication with the server utilizes API calls to GitHub. The payload is encoded in Base64 and published in plaintext; therefore, anyone who can view the repository or analyze the traffic contents can decode it.
Analysis of agent communication revealed that the most useful traffic for creating detection rules is associated with publishing check-in comments, creating a branch, and publishing a file.
During the check-in phase, the agent posts a comment to register a new agent and establish communication.
The transmitted data is encoded in Base64 and contains the agentโs UUID and the portion of the message encrypted using AES-256.
This allows for a signature that detects UUID-formatted substrings within GitHub comment creation requests.
Another stage suitable for detection is when the agent creates a separate branch with its UUID as the name. All subsequent relevant communication with the server will occur within this branch. Here is an example of a branch creation request:
Therefore, we can create a detection rule to identify UUID-formatted strings within branch creation requests.
The screenshot below shows how the NDR solution logs all suspicious communications using the GitHub API and subsequently identifies the Mythic agentโs activity. The result is an alert with the verdict Trojan.Mythic.HTTP.C&C.
Analyzing encrypted TLS traffic
Communication with GitHub occurs over HTTPS; therefore, in the absence of traffic decryption capability, signature-based methods for detecting agent activity cannot be applied. Letโs consider a behavioral agent activity detection approach.
For instance, it is possible to detect connections to GitHub servers that are atypical in frequency and purpose, originating from network segments where this activity is not expected. The screenshot below shows an example of an agentโs multiple TLS sessions. The traffic reflects the execution of several commands, as well as idle time, manifested as constant polling of the server while awaiting new tasks.
Multiple TLS sessions with the GitHub service from uncharacteristic network segments can be detected using the rule presented below:
alert tcp any any -> any any (msg:"NetTool.PossibleMythicGitHubEgress.TLS.C&C"; flow: to_server, established; tls_sni; content: "api.github.com"; nocase; threshold: type both, track by_src, count 4, seconds 60; reference: url, https://github.com/MythicC2Profiles/github; classtype: ndr3; sid: 9000111; rev: 1;)
Additionally, multiple DNS queries to the service can be logged in the traffic.
This activity is detected with the help of the following rule:
The screenshot below shows the NDR interface with an example of the first rule in action, detecting traces of the GitHub profile activity for a Mythic agent within encrypted TLS traffic.
The suggested rule options can produce false positives, so to improve their effectiveness, they must be adapted to the specific characteristics of the infrastructure in which they will run. The parameters of the threshold keywordย โ specifically the count and seconds values, which control the number of events required to generate an alert and the time window for their occurrence in NDRย โ must be configured.
Direct Egress communication
The Egress communication model allows agents to interact directly with the C2 server via the following protocols:
HTTP(S)
WebSocket
MQTT
DNS
The first two protocols are the most prevalent. The DNS-based transport module is still under development, and the module based on MQTT sees little use among operators. We will not examine them within the scope of this article.
Communication via HTTP
HTTP is the most common protocol for building a Mythic agent control network. The HTTP transport container acts as a proxy between the agents and the Mythic server. It allows data to be transmitted in both plaintext and encrypted form. Crucially, the metadata is not encrypted, which enables the creation of signature-based detection rules.
Below is an example of unencrypted Mythic network traffic over HTTP. During a GET request, data encoded in Base64 is passed in the value of the query parameter.
After decoding, the agentโs UUIDย โ generated according to a specific patternย โ becomes visible. This identifier is followed by a JSON object containing the key parameters of the host, collected by the agent.
If data encryption is applied, the network traffic for agent communication appears as shown in the screenshot below.
After decrypting the traffic and decoding from Base64, the communication data reveals the familiar structure: UUID+AES256(JSON).
Therefore, to create a detection signature for this case, we can also rely on the presence of a UUID within the Base64-encoded data in POST requests.
The screenshot below shows how the NDR platform detects agent communication with the server over HTTP, generating an alert with the name Trojan.Mythic.HTTP.C&C.
Communication via HTTPS
Mythic agents can communicate with the server via HTTPS using the corresponding transport module. In this case, data is encrypted with TLS and is not amenable to signature-based analysis. However, the activity of Mythic agents can be detected if they use the default SSL certificate. Below is an example of network traffic from a Mythic agent with such a certificate.
For this purpose, the following signature is applied:
alert tcp any any -> any any (msg: "Trojan.Mythic.HTTPS.C&C"; flow: established, from_server, no_stream; content: "|16 03|"; content: "|0B|"; distance: 3; within: 1; content: "Mythic C2"; distance: 0; reference: url, https://github.com/its-a-feature/Mythic; classtype: ndr1; sid: 9000114; rev: 1;)
WebSocket
The WebSocket protocol enables full-duplex communication between a client and a remote host. Mythic can utilize it for agent management.
The process of agent communication with the server via WebSocket is as follows:
The agent sends a request to the WebSocket container to change the protocol for the HTTP(S) connection.
The agent and the WebSocket container switch to WebSocket to send and receive messages.
The agent sends a message to the WebSocket container requesting tasks from the Mythic container.
The WebSocket container forwards the request to the Mythic container.
The Mythic container returns the tasks to the WebSocket container.
The WebSocket container forwards these tasks to the agent.
It is worth mentioning that in this communication model, both the WebSocket container and the Mythic container reside on the Mythic server. Below is a screenshot of the initial agent connection to the server.
An analysis of the TCP session shows that the actual data is transmitted in the data field in Base64 encoding.
Decoding reveals the familiar data structure: UUID+AES256(JSON).
Therefore, we can use an approach similar to those discussed above to detect agent activity. The signature should rely on the UUID string at the beginning of the data field. The rule first verifies that the session data matches the data:base64 format, then decodes the data field and searches for a string matching the UUID pattern.
Below is the Trojan.Mythic.WebSocket.C&C signature triggering on Mythic agent communication over WebSocket.
Takeaways
The Mythic post-exploitation framework continues to gain popularity and evolve rapidly. New agents are emerging, designed for covert persistence within target infrastructures. Despite this evolution, the various implementations of network communication in Mythic share many common characteristics that remain largely consistent over time. This consistency enables IDS/NDR solutions to effectively detect the frameworkโs agent activity through network traffic analysis.
Mythic supports a wide array of agent management options utilizing several network protocols. Our analysis of agent communications across these protocols revealed that agent activity can be detected by searching for specific data patterns within network traffic. The primary detection criterion involves tracking UUID strings in specific positions within Base64-encoded transmitted data. However, while the general approach to detecting agent activity is similar across protocols, each requires protocol-specific filters. Consequently, creating a single, universal signature for detecting Mythic agents in network traffic is challenging; individual detection rules must be crafted for each protocol. This article has provided signatures that are included in Kaspersky NDR.
Kaspersky NDR is designed to identify current threats within network infrastructures. It enables the detection of all popular post-exploitation frameworks based on their characteristic traffic patterns. Since the network components of these frameworks change infrequently, employing an NDR solution ensures high effectiveness in agent discovery.
Kaspersky verdicts in Kaspersky solutions (Kaspersky Anti-Targeted Attack with NDR module and Kaspersky NGFW)
An advanced persistent threat (APT) known as WIRTE has been attributed to attacks targeting government and diplomatic entities across the Middle East with a previously undocumented malware suite dubbed AshTag since 2020.
Palo Alto Networks is tracking the activity cluster under the name Ashen Lepus. Artifacts uploaded to the VirusTotal platform show that the threat actor has trained its sights
Interpreting the vast cybersecurity vendor landscape through the lens of industry analysts and testing authorities can immensely enhance your cyber-resilience.
A high-severity unpatched security vulnerability in Gogs has come under active exploitation, with more than 700 compromised instances accessible over the internet, according to new findings from Wiz.
The flaw, tracked as CVE-2025-8110 (CVSS score: 8.7), is a case of file overwrite in the file update API of the Go-based self-hosted Git service. A fix for the issue is said to be currently in the
Cybersecurity researchers at Blackpoint Cyber discovered a new, evasive CastleLoader malware variant using Python and ClickFix social engineering to deliver RATs and info-stealers directly from memory.
Google on Wednesday shipped security updates for its Chrome browser to address three security flaws, including one it said has come under active exploitation in the wild.
The vulnerability, rated high in severity, is being tracked under the Chromium issue tracker ID "466192044." Unlike other disclosures, Google has opted to keep information about the CVE identifier, the affected component, and
On December 4, 2025, researchers published details on the critical vulnerability CVE-2025-55182, which received a CVSS score of 10.0. It has been unofficially dubbed React4Shell, as it affects React Server Componentsย (RSC) functionality used in web applications built with the React library. RSC speeds up UI rendering by distributing tasks between the client and the server. The flaw is categorized as CWE-502 (Deserialization of Untrusted Data). It allows an attacker to execute commands, as well as read and write files in directories accessible to the web application, with the server process privileges.
Almost immediately after the exploit was published, our honeypots began registering attempts to leverage CVE-2025-55182. This post analyzes the attack patterns, the malware that threat actors are attempting to deliver to vulnerable devices, and shares recommendations for risk mitigation.
A brief technical analysis of the vulnerability
React applications are built on a component-based model. This means each part of the application or framework should operate independently and offer other components clear, simple methods for interaction. While this approach allows for flexible development and feature addition, it can require users to download large amounts of data, leading to inconsistent performance across devices. This is the challenge React Server Components were designed to address.
The vulnerability was found within the Server Actions component of RSC. To reach the vulnerable function, the attacker just needs to send a POST request to the server containing a serialized data payload for execution. Part of the functionality of the handler that allows for unsafe deserialization is illustrated below:
A comparison of the vulnerable (left) and patched (right) functions
CVE-2025-55182 on Kaspersky honeypots
As the vulnerability is rather simple to exploit, the attackers quickly added it to their arsenal. The initial exploitation attempts were registered by Kaspersky honeypots on December 5. By Monday, December 8, the number of attempts had increased significantly and continues to rise.
The number of CVE-2025-55182 attacks targeting Kaspersky honeypots, by day (download)
Attackers first probe their target to ensure it is not a honeypot: they run whoami, perform multiplication in bash, or compute MD5 or Base64 hashes of random strings to verify their code can execute on the targeted machine.
In most cases, they then attempt to download malicious files using command-line web clients like wget or curl. Additionally, some attackers deliver a PowerShell-based Windows payload that installs XMRig, a popular Monero crypto miner.
CVE-2025-55182 was quickly weaponized by numerous malware campaigns, ranging from classic Mirai/Gafgyt variants to crypto miners and the RondoDox botnet. Upon infecting a system, RondoDox wastes no time, its loader script immediately moving to eliminate competitors:
Beyond checking hardcoded paths, RondoDox also neutralizes AppArmor and SELinux security modules and employs more sophisticated methods to find and terminate processes with ELF files removed for disguise.
Only after completing these steps does the script download and execute the main payload by sequentially trying three different loaders: wget, curl, and wget from BusyBox. It also iterates through 18 different malware builds for various CPU architectures, enabling it to infect both IoT devices and standard x86_64 Linux servers.
In some attacks, instead of deploying malware, the adversary attempted to steal credentials for Git and cloud environments. A successful breach could lead to cloud infrastructure compromise, software supply chain attacks, and other severe consequences.
Risk mitigation measures
We strongly recommend updating the relevant packages by applying patches released by the developers of the corresponding modules and bundles.
Vulnerable versions of React Server Components:
Bundles and modules confirmed as using React Server Components:
next
react-router
waku
@parcel/rsc
@vitejs/plugin-rsc
rwsdk
To prevent exploitation while patches are being deployed, consider blocking all POST requests containing the following keywords in parameters or the request body:
#constructor
#__proto__
#prototype
vm#runInThisContext
vm#runInNewContext
child_process#execSync
child_process#execFileSync
child_process#spawnSync
module#_load
module#createRequire
fs#readFileSync
fs#writeFileSync
s#appendFileSync
Conclusion
Due to the ease of exploitation and the public availability of a working PoC, threat actors have rapidly adopted CVE-2025-55182. It is highly likely that attacks will continue to grow in the near term.
We recommend immediately updating React to the latest patched version, scanning vulnerable hosts for signs of malware, and changing any credentials stored on them.
Huntress is warning of a new actively exploited vulnerability in Gladinet's CentreStack and Triofox products stemming from the use of hard-coded cryptographic keys that have affected nine organizations so far.
"Threat actors can potentially abuse this as a way to access the web.config file, opening the door for deserialization and remote code execution," security researcher Bryan Masters said.
ReversingLabs (RL) researchers have identified a sophisticated supply chain campaign involving 19 malicious Visual Studio Code (VS Code) extensions. The campaign, which has been active since February 2025 and was uncovered on December 2, 2025, leverages the trust inherent in the developer ecosystem by hiding malware within the dependency folders of otherwise functional extensions. The [โฆ]
Login
Latest Hacking News
The Hacker News
WeLiveSecurity
