Alpha Cyber

Daxin Returns: A 13-Year-Old China-Linked Rootkit That Never Called Home

Symantec found the Daxin kernel rootkit still operational on a Taiwan manufacturing subsidiary in 2026, alongside a previously undocumented backdoor, Stupig, that runs SYSTEM commands from the Windows logon screen before anyone signs in.

Alpha Cyber Research6 min readupdated 23 Jul 2026
  • APT
Daxin Rootkit

Bottom line. Daxin is a China-linked Windows kernel-mode rootkit that Symantec first exposed in 2022, with samples dating to 2013. In 2026 it was found still running on a compromised host at a Taiwan-based subsidiary of a multinational high-tech manufacturer, on the same machine as a newly documented backdoor tracked as Stupig, both with early-2013 compile timestamps and an intrusion that may have gone unnoticed for thirteen years. Daxin does not beacon out: it waits for specific inbound TCP patterns and hijacks existing legitimate connections for encrypted command-and-control, and can multi-hop through compromised hosts to reach machines with no internet access, so there are no IP or domain IOCs to block. Stupig hides in the Windows logon process and gives operators pre-authentication SYSTEM access with no logon audit event. Defending against this is a host-integrity and threat-hunting problem, not a blocklist one.

Background

Daxin is the most advanced malware Symantec had attributed to a China-linked actor when it first published on it in March 2022. It is implemented as a signed Windows kernel driver, an unusual and high-effort choice, and it was built for hardened, segmented environments. Rather than establishing outbound connections to attacker infrastructure, Daxin monitors incoming TCP traffic for specific trigger patterns and hijacks existing legitimate connections to carry its encrypted C2. It can also route commands through a chain of compromised machines (multi-hop), letting operators reach hosts that have no direct internet connectivity. The net effect: conventional network monitoring looking for suspicious outbound connections sees nothing.

In 2026, Symantec’s Threat Hunter Team found Daxin still running on a compromised host at a Taiwan-based subsidiary of a multinational high-tech manufacturer, more than four years after it was first exposed. Telemetry from the machine only began appearing on 12 May 2026, but the artifacts carry early-2013 compile timestamps, implying the tools were never removed and the intrusion may have persisted, undetected, for thirteen years. Nothing about the tools is new; what is new is that they are still operational and were apparently never evicted.

The same host carried a previously unreported backdoor the researchers track as Stupig. It masquerades as kbdus1.dll, mimicking the legitimate kbdus.dll that Windows uses for the US English keyboard layout, and registers itself as a keyboard-layout provider so win32k.sys loads it into winlogon.exe at startup. It returns a valid keyboard-table pointer so the keyboard works normally and nothing looks wrong to an administrator inspecting loaded modules. Once inside winlogon.exe, Stupig watches the logon screen for usernames beginning with a set prefix and executes whatever follows as SYSTEM; typed alone, the prefix opens a SYSTEM command prompt directly on the logon screen, before any user authenticates and without generating a logon audit event. Symantec notes this logon-screen technique is not documented in any known malware family.

Symantec found no code-level overlap between Daxin and Stupig, so there is no technical proof they came from the same developers. What links them is deployment on the same host, complementary functions, similar development practices and identical 2013 compile timestamps. The initial entry point is still being investigated; the leading hypothesis is an outdated Digiwin single sign-on portal running end-of-life Java Development Kit 1.5 and 1.6 (software from 2009 to 2011) left exposed on the subsidiary’s network.

What we observed

Why this intrusion is so hard to see, and where it hides:

  • No outbound C2, so no network IOCs: Daxin never calls home. It waits for specific inbound TCP patterns and rides existing legitimate connections for encrypted C2, which means IP and domain blocklists, beacon hunting and outbound-anomaly detection all miss it.
  • Built for hardened networks: Daxin’s multi-hop capability routes commands through a chain of compromised hosts, so operators can reach internet-isolated machines, exactly the segmented, high-value systems defenders assume are safe.
  • Kernel-level stealth: implemented as a Windows kernel driver, Daxin hides its presence and blends its traffic into normal activity, defeating most host and network monitoring.
  • Stupig hides in the one place nobody watches: by registering as a keyboard-layout provider, it is loaded into winlogon.exe at startup and looks like a normal keyboard DLL, the Windows logon process is not where most security teams hunt.
  • Pre-authentication SYSTEM with no audit trail: Stupig executes SYSTEM commands from the logon screen before anyone signs in and generates no logon event, so authentication-log monitoring shows nothing.
  • Thirteen years of dwell: 2013 compile timestamps on a host only surfaced in 2026 means no alerts is not the same as no compromise, this is a textbook long-dwell nation-state intrusion on a manufacturing supply-chain target.
  • The way in was old and known: the likely entry, an end-of-life SSO portal on unsupported JDK 1.5/1.6, is a reminder that legacy internet-facing software on subsidiaries is where these footholds begin.

Daxin + Stupig: a quiet, long-dwell intrusion

Initial accessEOL SSO portalKernel rootkitDaxin driverPassive C2hijack TCPLogon backdoorStupig / winlogonPre-auth SYSTEMno audit log

Every stage is designed to defeat a specific control: no outbound C2 beats network monitoring, kernel + logon hiding beats host tooling, pre-auth execution beats logon auditing.

Attribution

Symantec attributes Daxin to a China-linked espionage actor, and confidence in that China-nexus is high given the tooling’s sophistication and Symantec’s prior analysis. The intrusion targeted a Taiwan-based manufacturing subsidiary, consistent with strategic espionage interest. The link between Daxin and Stupig is unconfirmed: there is no code-level overlap, only shared host, complementary function, similar development practice and matching 2013 timestamps, so whether the same operators deployed both cannot be stated as fact. The initial access vector (an outdated Digiwin SSO portal on EOL JDK) is the leading hypothesis, not a confirmed finding.

Confidence: 85%.

Thirteen years inside the network, and it never once called out. Daxin doesn’t beacon home, it waits for the right packet and answers.

Tactics, techniques & procedures (MITRE ATT&CK)

Techniques below are drawn directly from the analysed samples/reporting – no technique is asserted without evidence:

TacticTechniqueIDEvidence
Initial AccessExploit Public-Facing ApplicationT1190Suspected entry via an outdated Digiwin SSO portal on end-of-life JDK 1.5/1.6 (leading hypothesis, unconfirmed).
Defense EvasionRootkitT1014Daxin is a Windows kernel-mode driver that hides its presence and blends its traffic into normal network activity.
Command and ControlTraffic SignalingT1205Daxin monitors inbound TCP for specific trigger patterns instead of establishing outbound connections.
Command and ControlProtocol TunnelingT1572Hijacks existing legitimate TCP connections to carry encrypted C&C, blending with traffic already present.
Command and ControlMulti-hop ProxyT1090.003Routes commands through a chain of compromised hosts to reach machines with no direct internet access.
PersistenceBoot or Logon Autostart ExecutionT1547Stupig registers as a keyboard-layout provider so win32k.sys loads it (as kbdus1.dll) into winlogon.exe at startup.
Defense EvasionMasqueradingT1036Stupig poses as kbdus1.dll mimicking the legitimate kbdus.dll and returns a valid keyboard-table pointer so the keyboard works normally.
Credential AccessModify Authentication ProcessT1556Running in winlogon.exe, Stupig executes SYSTEM commands from the logon screen pre-authentication and can steal credentials, with no logon audit event.

Detection

Copy-ready hunting query:

# Daxin + Stupig hunt: host artifacts and behaviour (there are NO network IOCs by design)
# 1) Rogue DLLs loaded into winlogon.exe at startup (Stupig)
index=edr process_name="winlogon.exe" event=image_load (image_loaded="*kbdus1.dll" OR (image_loaded="*\\Keyboard*" AND signed=false) OR image_loaded IN unexpected_module_baseline)
# 2) Keyboard-layout provider registrations pointing at non-standard DLLs
index=edr registry_path="*\\Control\\Keyboard Layouts\\*" registry_value_name="Layout File" NOT registry_value IN ("kbdus.dll",known_good_layout_dlls)
# 3) Pre-authentication SYSTEM process creation from the logon process
index=edr parent_process="winlogon.exe" process_name IN ("cmd.exe","powershell.exe") user="SYSTEM"
# 4) Unexpected / unsigned kernel drivers in System32\drivers (Daxin class)
index=edr event=driver_load (path="*\\System32\\drivers\\*") (signed=false OR driver NOT IN known_good_driver_baseline OR driver="srt64.sys")
# 5) Legacy exposure: inventory internet-facing apps on end-of-life runtimes
index=asset (software="*Digiwin*" OR java_version IN ("1.5","1.6")) exposure="internet-facing"
#
# Reminder: Daxin has no outbound C2. Do NOT rely on beacon/blocklist detection --
# hunt kernel-driver integrity, winlogon module loads and pre-auth SYSTEM activity.

Recommendations

  • Hunt where the attacker hides: monitor module loads into winlogon.exe and keyboard-layout-provider registrations, and treat any new DLL in the logon path as high severity, this is the exact blind spot Stupig exploits.
  • Do not rely on network IOCs: Daxin has no outbound C2, so blocklists and beacon hunting will miss it, lean on kernel-driver integrity, driver allow-listing (WDAC / HVCI), and host telemetry instead.
  • Assume long dwell on legacy and OT-adjacent networks: a 13-year undetected implant means an absence of alerts is not assurance, run proactive compromise assessments and threat hunts, especially on manufacturing subsidiaries and segmented environments.
  • Close the entry surface: retire end-of-life software (JDK 1.5/1.6), replace or isolate outdated SSO and public-facing portals such as the Digiwin instance, and inventory internet-facing legacy apps across all subsidiaries.
  • Watch inside the perimeter: Daxin’s multi-hop reaches isolated hosts through compromised neighbours, so enforce segmentation and monitor east-west and hijacked internal TCP sessions, not just the internet edge.
  • Harden Windows authentication and drivers: enforce driver signing / memory integrity, application control and Credential Guard, and alert on any SYSTEM process spawned by winlogon.exe before user logon.
  • Treat any finding as a nation-state incident: fully scope the intrusion, rotate credentials, and assume additional footholds rather than cleaning a single host.

Keep reading

Related research

SprySocks Rootkit
Threat ReportsTLP:AMBER

SprySOCKS for Windows: FishMonger’s Linux Backdoor Grows a Kernel Rootkit

China-aligned FishMonger (Earth Lusca) has ported its SprySOCKS backdoor to Windows and bolted on a kernel driver, RawWNPF, that hides processes, files, connections and registry keys, and turns any open TCP port into a hidden door and erases itself from every tool you’d use to find it.

6 min readAPT
Sandworm Tor Persistent
Threat ReportsTLP:AMBER

Deep Persistence: How Sandworm Weaponizes Tor for Long-Term Stealth

Sandworm Uses SSH-over-Tor Tunnels for Stealthy Long-Term Persistence Sandworm – the Russian state-sponsored actor linked to GRU Unit 74455 – leveraged SSH-over-Tor tunneling to establish covert, resilient, long-term access inside compromised environments…

2 min readAPT · Persistence

Contact

Talk to someone who has seen this before.

You speak directly to the people doing the work, wherever in the world you operate.

Or email [email protected]