Knife Cutting the Edge: Disclosing a China-nexus gateway

Since 2023, Cisco Talos has continuously tracked the MOONSHINE exploit kit and the DarkNimbus backdoor it distributes. The exploit kit and backdoor were historically used for delivering Android and iOS exploits. While hunting for DarkNimbus samples, Talos discovered an executable and linkable format (ELF) binary communicating with the same C2 server as the DarkNimbus backdoor, which retrieved a gzip-compressed archive. Analysis revealed that the archive contained a fully featured gateway monitoring and AiTM framework, dubbed “DKnife” by its developer. Based on the artifact metadata, the tool has been used since at least 2019, and the C2 is still active as of January 2026.

During Talos' pivot on the C2 infrastructure associated with DKnife, we identified additional servers exhibiting open ports and configurations consistent with previously observed DKnife deployments. Notably, one host (43.132.205[.]118) displayed port activity characteristic of DKnife infrastructure and was additionally found hosting the WizardNet backdoor on port 8881.

WizardNet is a modular backdoor first disclosed by ESET in April 2025, known to be deployed via Spellbinder, a framework that performs AitM attacks leveraging IPv6 Stateless Address Autoconfiguration (SLAAC) spoofing.

Network responses from the WizardNet server align closely with the tactics, techniques, and procedures (TTPs) documented in ESET’s analysis. Specifically, the server delivered JSON-formatted tasking instructions that included a download URL pointing to an archive named minibrowser11_rpl.zip , which include the Wizardnet backdoor downloader.

Spellbinder’s TTPs, which involve hijacking legitimate application update requests and serving forged responses to redirect victims to malicious download URLs, are similar to DKnife’s method of compromising Android application updates. Spellbinder has also been observed distributing the DarkNimbus backdoor, whose C2 infrastructure previously led to the initial discovery of DKnife. The URL redirection paths ( http[:]//[IP]:81/app/[app name] ) and port configurations identified in these cases are identical to those used by DKnife, indicating a shared development or operational lineage.

Based on artifacts recovered from the DKnife framework, this campaign appears to primarily target Chinese-speaking users. Indicators supporting this assessment include data collection and processing logic explicitly designed for Chinese mail services , as well as parsing and exfiltration modules tailored for Chinese mobile applications and messaging platforms, including WeChat. In addition, code references to Chinese media domains were identified in both the binaries and configuration files. The screenshot below illustrates an Android application hijacking response that targeted a Chinese taxi service and rideshare application.

It is important to note that Talos obtained the configuration files for analysis from a single C2 server. Therefore, it remains possible that the operators employ different servers or configurations for distinct regional targeting scopes. Considering the connection between DKnife and the WizardNet campaign and given ESET’s reporting that WizardNet activity has targeted the Philippines, Cambodia, and the United Arab Emirates, we cannot rule out a broader regional or multilingual targeting scope.

DKnife contains several artifacts that suggest the developer and operators are familiar with Simplified Chinese. Multiple written in Simplified Chinese appear throughout the DKnife configuration files (see Figure 2).

One component of DKnife is named yitiji.bin. The term "Yitiji" is the Pinyin (official romanization system for Mandarin Chinese) for " 一体机 " which means "all-in-one." In DKnife, this component is responsible for opening the local interface on the device to route traffic through a single device in this scenario.

Additionally, within the DKnife code, when reporting user activities back to the remote C2 server, multiple messages are labelled in Simplified Chinese to indicate the types of activities.

DKnife is a full-featured gateway monitoring framework composed of seven ELF components that perform traffic manipulation across a target network. In addition to the seven ELF components that provide the core functionality, the framework comes with a list of configuration files (see Appendix for the full list), self-signed certificates, phishing templates, forged HTTP responses for hijacking and phishing, log files, and backdoor binaries.

The framework is designed to work with backdoors installed on compromised devices. Its key capabilities include serving update C2 for the backdoors, DNS hijacking, hijacking Android application updates and binary downloads, delivering ShadowPad and DarkNimbus backdoors, selectively disrupting security-product traffic and exfiltrating user activity to remote C2 servers. The following sections highlight DKnife’s key capabilities and explain how its seven ELF binaries work together to implement them.

DKnife binaries are 64-bit Linux (x86-64) ELF implants that run on Linux-based devices. One of the components remote.bin imports the library "libcrypto.so.10", indicating it targets CentOS/RHEL-based platforms. Configuration elements such as PPPoE, VLAN tagging, a bridged interface (br0), and adjustable MTU and MAC parameters suggest that DKnife is tailored for edge or router devices running Linux-based firmware.

The Deep Packet Inspection (DPI) logic and modular design of DKnife enable operators to conduct traffic monitoring campaigns ranging from covert monitoring of user activity to active in-line attacks that replace legitimate downloads with malicious payloads. The following sections highlight the framework’s key capabilities including:

In previously published research the DarkNimbus backdoor, analysts noted that some samples communicated with their C2 servers using a custom protocol, leading to the hypothesis that the backdoor operated within an AiTM environment. Talos' discovery of DKnife validates this assessment.

DKnife is designed to work with both Android and Windows variants of DarkNimbus. For the Windows version, the dknife.bin component inspects UDP traffic and sends them to port 8005. When it identifies a request containing the string marker DKGETMMHOST , it constructs and returns a response specifying the C2 server address. The response includes two parameters: DKMMHOST and DKFESN. The DKMMHOST value is read from DKnife’s configuration file ("/dksoft/conf/server.conf"), which contains the line MMHOST URL=[value] . The DKFESN value represents a device identifier that DKnife retrieves from an internal server located at "192.168.92.92:8080".

For the Android variants, the backdoor attempts to a Baidu URL "http[:]//fanyi.baidu[.]com/query_config_dk" to retrieve its C2 information. This URL does not return any response from Baidu itself; rather, it serves as a recognizable trigger for DKnife, which intercepts the request and injects the C2 response.

The DKnife framework relies on two main configuration files to control its DNS-based hijacking and attack logic. The dns.conf file defines the global keyword-to-IP mapping rules and framework parameters used for DNS interception. The perdns.conf file extends this by defining per-target or campaign-specific DNS attack tasks, including timing parameters such as interval and duration for each attack. In the archive we obtained from the C2 server, only perdns.conf was present; it contained a template for setup rather than active attack data.

DKnife supports both IPv4 and IPv6 DNS hijacking:

The private IP address 10.3.3.3 belongs to the local interface created by the yitiji.bin component in DKnife. DKnife uses the local interface for delivering malicious binaries (see the following section). The crafted AAAA response is not an actual public address. When DKnife sees traffic addressed to that crafted IPv6, it checks the last 8 bytes of the address and converts it to the local interface address 10.3.3.3 .

The code also specially tempers the domains associated with mail services. It takes the queried domain, removes any trailing period if present, then splits on “.” and extracts the leftmost label (e.g., “mail.example.com” into “mail”). It then looks up that label in the same per-domain configuration. Once the attack flag is enabled and the cooldown window has elapsed, it immediately injects a configured response to replace the original response.

DKnife can hijack and replace Android application updates by intercepting the update manifest requests. When an Android application sends an APK update manifest request, DKnife intercepts it, consults the configuration file, and selects the corresponding JSON response file to . This response contains a download URL redirecting to the URL of address 10.3.3.3 , which DKnife recognizes and routes to the yitiji.bin created Local Area Network (LAN) to deliver malware instead of the legitimate update APK.

The configuration file /dksoft/conf/url.cfg defines the rules and responses used for traffic blocking, phishing on Android and Windows platforms, executable file ( . exe) hijacking, and credential-phishing page responses. The file follows the format: [Request URL] [Response JSON file] as shown in Figure 11.

Within the /bin/html/dkay-scripts folder of the DKnife archive, there are 185 JSON files configured to hijack applications. The targeted applications are mostly popular Chinese-language services (some only available in China), including news media, video streaming, image editing apps, e-commerce platforms, taxi-service platforms, gaming, and pornography video streaming, among others. An example response used to hijack a Chinese photo editing application update request is shown below:

In addition to Android update hijacking, DKnife also supports hijacking of Windows and other binary downloads. The hijacking rules are set up during initialization. DKnife attempts to read the rules configuration file at /dksoft/conf/rules.aes and decrypts it using a variant of the Tiny Encryption Algorithm (TEA) algorithm employed by Tencent’s older OICQ/QQ login protocols, commonly referred to as QQ TEA . DKnife decrypts the file with a key dianke0123456789 , and saves the decrypted file as rules.conf .

Talos did not obtain the rules.aes file from the archive we downloaded. However, based on the code analysis, rules.conf is the configuration to define what requests to match, what to send back, when to throttle and tracking the response. The rules include the following information:

R elative file name points into “ / dksoft /html/ dkay -script s / ” .

location=

HTTP location use d for 302 re d irects

Minimum se con d s between two injections to the same victim

How long the rule stays acti ve once triggere d

After reading the rules into a data structure in the memory, the rules.conf file is deleted on the device. When an HTTP request’s Host and URI match the configured rule, DKnife evaluates the rule’s duration and interval timers to determine whether to trigger. If the rule fires and the requested filename has a matching extension (e.g., “.exe”, “.rar”, “.zip”, or “.apk”), DKnife forges an HTTP 302 redirect whose Location URL is taken from the rule’s data field.

If the binary download URL matches a specific pattern (“.exe” extension after the query symbol), the file name is replaced with install.exe .

The install.exe file (SHA256: 2550aa4c4bc0a020ec4b16973df271b81118a7abea77f77fec2f575a32dc3444 ) is found in the downloaded archive under path /dkay-scripts/ . It is a RAR self extraction package containing three binaries, that are actually ShadowPad and the DarkNimbus backdoor, which both being reported [ 1 , 2 ] used by China-nexus threat actors. When launched, the legitimate .exe ( TosBtKbd.exe ) sideloads the ShadowPad DLL loader ( TosBtKbd.dll ), which then loads the DarkNimbus DLL backdoor ( TosBtKbdLayer.dll ). That DarkNimbus backdoor calls out to the Cloudflare DNS address 1.1.1.1 , which DKnife intercepts to return the real C2 IP.

The Shadowpad sample has not been previously reported but is very similar to a previously reported sample . Although it uses a different unpacking XOR seed key, it employs the same unpacking algorithm.

The Shadowpad samples (both .exe and .dll ) are signed with two certificates both issued from the signer “四川奇雨网络科技有限公司”. This is a company located in Sichuan Chengdu, China specialised in developing computer software and providing network communication devices, according to publicly available information . Pivoting on this signer, Talos found 17 samples that contain the Shadowpad and DarkNimbus backdoor.

The DKnife traffic inspection module actively identifies and interferes with communications from antivirus and PC-management products. It detects 360 Total Security by searching HTTP headers (e.g., the DPUname header in GET requests or the x-360-ver header in POST requests) and by matching known service domain names. When a match is found, the module drops or otherwise disrupts the traffic with the crafted TCP RST packet. It similarly looks for and disrupts connections to Tencent services and PC-management endpoints.

Recognized Tencent-related domains:

Keywords used to match 360 Total Security-related domains:

DKnife inspects traffic to monitor and report user’s network activity to its remote C2 in real time. Observed telemetry categories include messaging (Signal and WeChat activities including voice/video calls, sent texts, received images, in-app article views), shopping, news consumption, map searches, video streaming, gaming, dating, taxi and rideshare requests, mail checking, and other user actions. Most of the activity reports are triggered by monitoring the request to service/platform domains or URLs. When reporting, the code sends a corresponding embedded message representing the reported activity. For example, Figure 18 shows the code to report Signal messaging activities. The message sent to remote C2 translates to “Using Signal encryption chat APP”.

The table below shows some of the observed telemetry categories and the embedded messages.

微信打语音或视频电话 ( WeChat voice or video calls)

微信发送一条文字消息 ( WeChat send a text message)

微信发送或者接收图片 ( WeChat send or receive picture)

微信打开公众号看文章 (We Chat checking official account and articles)

使用signal加密聊天APP (Use the Signal encrypted-chat app)

查询**商品信息 (Query product information on **)

Query train-ticket information

查询火车票信息 (Query train-ticket information)

查看**地图 (View the map)

****打开时 (When the dating app opens)

DKnife can harvest credentials from a major Chinese email provider and host phishing pages for other services. For harvesting email credentials, the sslmm.bin component presents its own TLS certificate to clients, terminates and decrypts POP3/IMAP connections, and inspects the plaintext stream to extract usernames and passwords. Extracted credentials are

DKnife can also serve phishing pages. The phishing routes are defined in url.cfg , and several phishing templates were discovered under /dkay-scripts/ . All discovered pages submit harvested passwords to endpoints whose paths end with dklogin.html ; however, no dklogin.html file was found in the local script directory.

In addition to the capabilities described above, Talos observed DKnife functions that may target IoT devices. Talos is coordinating with the device vendor on mitigations.

The ELF binary ( 17a2dd45f9f57161b4cc40924296c4deab65beea447efb46d3178a9e76815d06 ) we discovered from hunting is a downloader that downloads and performs initial setup for the DKnife framework. Upon execution, it attempts to load a configuration file from /dksoft/conf/server.conf to set up the C2 server. The server.conf file contains the C2 configuration in the format UPDATE URL=[config] . If the file does not exist, the binary defaults to the embedded C2 URL .

After configuring the C2, the binary retrieves or generates a UUID for the host device based on the MAC addresses of its network interfaces and stores it in /etc/diankeuuid . The UUID follows the format YYYYMMDDhhmmss[MAC1][MAC2] (e.g., 20240219165234000c295de649 ). The updater also stores a 32-character hexadecimal MD5 checksum in /dksoft/conf/ .ini , which is later used to verify updates from the C2 server.

The code establishes persistence by modifying the /etc/rc.local file, a script commonly used to execute commands and scripts after the system boots and initializes services. The updater adds its commands between markers #startdianke and #enddianke . It also copies the currently running executable into the /dksoft/update/ directory and appends a corresponding entry to /dksoft/update/[executable path] auto to ensure the binary runs automatically each time the system starts.

After creating the folders for DKnife deployment, the downloader fetches the DKnife archive from the C2 and launches every binary in /dksoft/bin/ using nohup [filepath] 2>/dev/null 1>/dev/null & . The folder contains seven binaries, each performing a distinct role within the DKnife framework.

The seven implants in DKnife serve the purpose of DPI engine, data reporting, reverse proxy for AitM attack, malicious APK download, framework update, traffic forwarding, and building P2P communication channel with the remote C2. A summary of the components and their roles are listed in the table below:

The main engine of DKnife . I nclu de s logic for deep packet inspection, user activities reporting, binary download hijacking, DNS hijacking , etc .

Perform s as traf fic labelling and relay componen t , receive s traffic from DKnif e and report s to remote C2.

Reverse proxy server module modified from HA Proxy . TLS termination , email decryption , and URL rerouting.

M alicio us Android APK downloader/updat e r. It connects to C2 to download the APKs used for the attack.

Creates a bri dged TAP interf ace on the router to host and route attacker-injected LAN traffic.

Customized N2 N (a P2P) VPN client component that creates a communication channel to remote C2.

Updater and Watchdog to keep the com ponents alive .

The graph below shows how the seven DKnife components work together.

The dknife.bin implant is the main component that acts as the brain of DKnife. It is in charge of all the packet inspection and attack logics, as described in the Key Capabilities section. Upon execution, the implant does some initial setup for the framework. It reads the configuration file /dksoft/conf/wxha.conf to for the sniffing interface ( INPUT_ETH ) and attacker interface ( ATT_ETH ). If the config file is not presented, the default interface for both are eth0 . It also reads configuration files for attacking rules and remote C2.