The discovery of the Daxin rootkit and the associated Stupig unauthorized access mechanism on the network of a Taiwan-based subsidiary of a multinational high-tech manufacturer in 2026 serves as a stark wake-up call for the industry. Initially documented by Symantec over a decade ago, Daxin is not a relic of the past—it is an active, evolving threat vector capable of maintaining stealthy persistence within critical infrastructure environments.
For SOC analysts and IR responders, this incident highlights a terrifying reality: a kernel-mode rootkit has been operational for potentially 13 years without detection. The presence of Daxin signifies a "super-user" level of compromise where the attacker owns the operating system kernel itself, rendering standard user-mode security controls blind. This post provides a technical breakdown of the threat and actionable detection logic to hunt for this stealthy adversary in your environment.
Technical Analysis
Threat Overview: Daxin is a sophisticated Windows kernel-mode rootkit linked to China-based threat actors. Its primary capability is deep stealth, allowing it to hide files, registry keys, and processes. The recent discovery of Stupig alongside Daxin indicates the attackers have updated their toolkit to facilitate unauthorized access, likely bypassing modern authentication controls.
Attack Chain & Mechanism:
- Initial Compromise: While the specific entry vector in the 2026 incident is under investigation, historical campaigns associated with Daxin utilize exploits for edge servers and supply chain compromises.
- Privilege Escalation & Persistence: The malware deploys a kernel-mode driver (
.sys). This driver loads early in the boot process, modifying the kernel's data structures to hook system calls and hide its own presence. - Covert C2: Daxin is known for hijacking legitimate network ports (often port 443 or 80) to blend in with normal HTTPS/HTTP traffic, making network detection significantly harder.
- Access Mechanism (Stupig): This new component likely serves as a backdoor or web shell component, granting the attackers remote control capabilities that are obfuscated within the noise of legitimate manufacturing traffic.
Affected Platforms:
- Windows-based systems (Server and Workstation)
- Specific targeting observed in: Manufacturing and High-Tech sectors
Exploitation Status:
- Status: Confirmed Active Exploitation (2026)
- CVE: No specific CVE is associated with this specific campaign; it relies on the deployment of the rootkit binary itself rather than a software vulnerability.
Detection & Response
Detecting a kernel-mode rootkit like Daxin from user-mode logs (EDR/Sysmon) is notoriously difficult because the rootkit actively filters the data returned to those applications. However, we can detect the loading mechanisms and the anomalies introduced during the boot sequence or network communication.
The following rules focus on the precursors: the loading of unauthorized kernel drivers and the suspicious network behavior associated with port hijacking.
SIGMA Rules
---
title: Potential Kernel-Mode Rootkit Driver Load
id: a1b2c3d4-5678-90ab-cdef-1234567890ab
status: experimental
description: Detects the loading of unsigned or improperly signed kernel drivers, a common technique for deploying rootkits like Daxin. Defenders should verify that SignatureStatus remains valid.
references:
- https://attack.mitre.org/techniques/T1543/003/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1543.003
- attack.privilege_escalation
- attack.t1068
logsource:
category: driver_load
product: windows
detection:
selection:
Signed|contains: 'false'
condition: selection
falsepositives:
- Legacy hardware drivers
- Development environments with test-signed drivers
level: high
---
title: Suspicious Service Installation via Sc.exe
id: b2c3d4e5-6789-01ab-cdef-2345678901bc
status: experimental
description: Detects the creation of new services using sc.exe with paths outside standard Windows directories, indicative of backdoors like Stupig or rootkit loaders.
references:
- https://attack.mitre.org/techniques/T1543/003/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.persistence
- attack.t1543.003
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\\sc.exe'
CommandLine|contains: 'create'
filter:
CommandLine|contains:
- 'C:\\Windows\\'
- 'C:\\Program Files\\'
- 'C:\\Program Files (x86)\\'
condition: selection and not filter
falsepositives:
- Legitimate software installation
- IT administration scripts
level: medium
---
title: Anomalous Network Port Hijacking
id: c3d4e5f6-7890-12bc-def0-3456789012cd
status: experimental
description: Detects non-browser or non-IIS processes listening on standard web ports (80/443), which could indicate Daxin port hijacking for C2.
references:
- https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.command_and_control
- attack.t1071
logsource:
category: network_connection
product: windows
detection:
selection:
DestinationPort:
- 80
- 443
Initiated: 'false'
filter_main_browsers:
Image|endswith:
- '\\chrome.exe'
- '\\firefox.exe'
- '\\msedge.exe'
- '\\iexplore.exe'
filter_main_servers:
Image|endswith:
- '\\httpd.exe'
- '\\nginx.exe'
- '\\svchost.exe'
condition: selection and not filter_main_browsers and not filter_main_servers
falsepositives:
- Legitimate backup agents
- Custom internal web applications
level: high
KQL (Microsoft Sentinel / Defender)
This hunt query looks for driver load events where the signature status is not valid, combined with process creation events that might indicate the installation of the Stupig backdoor.
// Hunt for unsigned drivers loaded in kernel mode
DeviceEvents
| where ActionType == "DriverLoad"
| extend SignatureStatus = coalesce(tostring(AdditionalFields.SignatureStatus), "Unknown")
| where SignatureStatus != "Valid"
| project Timestamp, DeviceName, InitiatingProcessAccountName, FileName, SHA256, SignatureStatus
| union (
// Hunt for suspicious service creation often used by access tools
DeviceProcessEvents
| where FileName =~ "sc.exe"
| where ProcessCommandLine contains "create" and ProcessCommandLine contains "binPath="
| extend ServicePath = extract(@"binPath\s*=\s*([^"]*?)(?:\s|")", 1, ProcessCommandLine)
| where ServicePath !startswith "C:\Windows" and ServicePath !startswith "C:\Program Files"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, ServicePath
)
| order by Timestamp desc
Velociraptor VQL
Since EDR can be blinded by rootkits, live forensics using VQL to query kernel structures directly (or verifying the driver list against known baselines) is critical. This artifact hunts for drivers that are not signed by Microsoft.
-- Hunt for non-Microsoft signed kernel drivers
SELECT
Name as DriverName,
Device as DeviceName,
Image as DriverPath,
DriverProvider as Publisher,
DriverDate as Date
FROM drivers()
WHERE DriverProvider !~ "Microsoft"
AND NOT Name =~ "kdnic" -- Exclude known benign false positives if necessary
AND NOT Name =~ "Wdf01000"
Remediation Script (PowerShell)
WARNING: Daxin is a kernel-mode rootkit. Removal via script while the OS is running is often futile because the rootkit can intercept the removal commands. The only reliable remediation is to boot into a trusted environment (e.g., WinPE or a separate forensic OS) and image the drive, or wipe and re-image the machine. The script below is for triage to identify the compromise, not for cleaning.
# Daxin/Stupig Triage Script
# Run with elevated privileges. Note: Results may be hidden if Rootkit is active.
Write-Host "[+] Checking for drivers with invalid signatures..."
Get-WindowsDriver -Online -All |
Where-Object { $_.Provider -ne "Microsoft" -and $_.ClassName -eq "System" } |
Select-Object Driver, Provider, Date, Version | Format-Table -AutoSize
Write-Host "[+] Checking for unsigned drivers via pnputil..."
$drivers = pnputil /enum-drivers
$drivers | Select-String "Original Name","Provider","Date" | Out-Host
Write-Host "[+] Checking for hidden services created recently..."
Get-WmiObject Win32_Service |
Where-Object { $_.State -eq "Running" -and $_.StartMode -eq "Auto" -and $_.PathName -notmatch "Windows" } |
Select-Object Name, PathName, StartName, InstallDate | Format-Table -AutoSize
Write-Host "[!] If this script returns nothing unexpected but you suspect infection, the rootkit may be hiding results."
Write-Host "[!] Immediate remediation requires isolation and offline reimaging."
Remediation
If Daxin is suspected or confirmed:
- Immediate Isolation: Disconnect the affected host from the network immediately to prevent lateral movement via the Stupig component.
- Do Not Trust the OS: Do not attempt to "clean" the system while it is running online. A kernel-mode rootkit has higher privileges than your AV/EDR and can lie to it.
- Acquire Memory Image: Capture a full memory dump (if possible) before shutdown for forensic analysis to identify the rootkit's hooks.
- Re-image the Host: Wipe the drive and reinstall the operating system from a known-good, gold-image source. This is the only way to guarantee removal.
- Credential Reset: Assume all credentials cached on that machine (domain admin, service accounts) are compromised. Force a reset enterprise-wide.
- Network Telemetry Review: Look for the port hijacking behavior (non-standard processes on 443/80) in NetFlow/PCAP data to identify other potentially compromised hosts.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.