Backdoor.Daxin, the kernel-mode rootkit Symantec once called the most advanced tool ever tied to a China-linked espionage actor, has been found running again
Continue reading
Backdoor.Daxin, the kernel-mode rootkit Symantec once called the most advanced tool ever tied to a China linked espionage actor, has been found running again — this time inside a Taiwan-based manufacturing subsidiary, more than four years after researchers first exposed it.
Sitting on the same machine was something nobody had catalogued before: a backdoor named Stupig that hijacks the Windows logon screen itself, letting an attacker run commands as SYSTEM before a single user has authenticated.
The timestamps on both tools trace back to February 2013, and the host had no telemetry history before May 2026 a gap that, if the intrusion is indeed that old, would put the actor's access at over a decade.
Symantec's Threat Hunter Team picked up the activity in May 2026, after the compromised host began reporting telemetry for the first time on record. That detail matters: a host with zero prior telemetry doesn't mean the intrusion started in May 2026, it means visibility started then.
Everything before that point potentially years of it is a blind spot.
Given that both malware samples carry compile and signing timestamps from early 2013, and given the Daxin actor's documented habit of settling into a network and staying quiet for years at a stretch, Symantec's assessment is that the compromise may have gone undetected for as long as thirteen years.
Two tools were pulled from the host.
Backdoor.Daxin (srt64.sys) is a digitally signed kernel-mode driver installed in the Windows drivers directory identical to the sample Symantec dissected in 2022, right down to its January 2013 compile date.
Backdoor.Stupig (a.dll, later renamed kbdus1.dll) had never been seen before and matched no known malware family in similarity analysis.
Symantec first documented Daxin publicly in early 2022, though samples traced back to 2013 — the same era these new artifacts date from. What set it apart wasn't stealth alone; plenty of malware hides well.
What set it apart was how it talked to its operators.
Rather than beaconing out to a command-and-control server the way almost everything else does, Daxin's driver watches incoming TCP traffic for a specific pattern and hijacks legitimate, already-established connections to smuggle encrypted commands through them. Network monitoring built to catch outbound C2 traffic simply has nothing to catch.
The malware also chains through infected hosts, letting operators reach machines with no direct route to the internet — a capability normally reserved for red teams and the most patient state actors.
Symantec attributed the original Daxin campaigns to a China-linked group running long-term espionage against governments and other strategically valuable targets.
That style of stealthy, multi-hop, patience-first tradecraft sits in the same family as the traffic-manipulation tricks documented in BPFDoor, a Linux/Solaris backdoor that similarly slips past firewalls by operating below the layer most defenses inspect — different platform, same philosophy of making the network itself unable to see you.
The most likely way in was an outdated Digiwin single sign-on portal running Java Development Kit 1.5 and 1.6 — installations dating from 2009 to 2011. Both JDK versions passed end-of-life years ago (2009 and 2013, respectively), meaning the portal had been running on unsupported, unpatched Java for the better part of a decade before this activity was noticed.
This is a familiar failure mode: sophisticated malware gets the headlines, but the door it walked through was left open by ordinary technical debt. Unpatched, end-of-life software sitting on internet-facing services remains one of the most reliable ways into a network precisely because it doesn't require a zero-day just time and a target that never got around to the upgrade.
Stupig earns its place in this report on technical merit alone. It achieves persistence by registering itself as a keyboard-layout provider, which causes win32k.sys to load it into winlogon.exe at system startup — the same process responsible for showing the logon screen and authenticating users.
Because the DLL still returns a valid KBDTABLES pointer, the keyboard layout keeps working normally, and nothing about the loaded module looks suspicious to a process listing or a curious administrator.
Once it's running inside winlogon.exe, Stupig watches for usernames typed at the logon screen that begin with the string "stupig." Anything typed after that prefix gets executed as SYSTEM on the secure desktop — the same isolated desktop Windows uses for UAC prompts and Ctrl+Alt+Del.
Type just the prefix with nothing after it, and Stupig spawns a SYSTEM-level command prompt directly on the logon screen, before anyone has signed in. The real LsaLogonUser function still gets called afterward, so the system reports a routine failed login.
No anomalous audit event fires — just one more failed logon for an oddly named account, buried among the normal noise.
The malware also installs inline hooks on SspiCli!LsaLogonUser and Advapi32!CredUnprotectA using VirtualProtect, ZwAllocateVirtualMemory, and memcpy, giving it a second capability: intercepting credentials as they pass through winlogon.exe. A call to LoadLibraryA referencing "msyun.dll" points to a companion payload that investigators did not recover.
Stupig's story took a turn on May 28, 2026, when the original file (a.dll) was first detected. Four days later, on June 1, a renamed copy — kbdus1.dll — turned up in the System32 directory, deliberately positioned to resemble the legitimate Windows keyboard layout library kbdus.dll, which lives in the same folder and differs by a single character. That's not an accident; it's a filename engineered to survive a quick visual scan.
Whether the attackers planted the renamed copy in direct response to the May 28 detection, or whether it had been sitting there since the original infection as a redundant fallback, is not established.
Either explanation is plausible, and Symantec found no evidence pointing definitively to one over the other. What is worth noting is that both scenarios describe an operator still actively managing the intrusion in 2026 — this isn't malware left running on autopilot.
No code-level relationship between Daxin and Stupig has been established, and Symantec is explicit about that.
What exists instead is circumstantial but suggestive: the two tools were deployed on the same host, their functions complement each other (kernel-level network stealth on one side, pre-authentication SYSTEM access and credential theft on the other), and their compile timestamps fall a few weeks apart in early 2013.
Development-practice similarities in the code led Symantec's researchers to a working hypothesis that Stupig's author had familiarity with Daxin's source — but this is an analytic assessment, not a confirmed attribution, and readers should treat it accordingly.
Compile timestamps can be altered, though the more probable explanation here is that they weren't, and simply reflect two tools built close together by the same team.
The victim in this case was a Taiwan-based subsidiary of a multinational high-tech manufacturer.
Daxin's original 2022 disclosure documented use against government, telecommunications, transportation, and manufacturing targets — a spread that has one thing in common: strategic value to China, not any single industry vertical.
Taiwan's advanced manufacturing base in particular has absorbed sustained attention from Chinese intrusion activity across multiple separate campaigns and actors, a pattern laid out in detail in coverage of Flax Typhoon's operations against Taiwanese critical infrastructure and manufacturing, and one with roots going back well over a decade to earlier campaigns like Taidoor malware, which targeted Taiwanese organizations long before Daxin's own 2013 compile dates.
Manufacturing has become an especially attractive target industry-wide, independent of any single actor's motives — a dynamic visible in incidents like the Nucor steel breach, which underscored how much value sits inside manufacturers' networks and how attractive that makes them to intruders willing to play a long game.
The headline risk here isn't that Daxin exists — Symantec already knew that. It's that finding it live in 2026 means the operation behind it never stopped; it just stopped being visible.
That distinction matters enormously for defenders. Malware that gets caught and presumably remediated in 2022, then resurfaces on a different host four years later with identical functionality, tells you the actor's other footholds were never found, or the network segment in question simply wasn't being watched closely enough to notice.
This fits a broader pattern documented across multiple China-linked operations that prioritize patience over speed — the kind of long-horizon access strategy also seen in Volt Typhoon's positioning inside critical communications infrastructure, where the value of an intrusion isn't in what it does today but in the option it preserves for later.
Daxin's traffic-hijacking C2 and multi-hop reach into isolated segments were built for exactly that kind of standing access, and Stupig — if it is genuinely tied to the same actor — extends that same philosophy down to the pre-authentication layer, giving operators a way back in even if credentials get rotated or the primary backdoor gets pulled.
It's also a reminder that Chinese state-linked cyber activity isn't a single monolithic campaign but an ecosystem of distinct actors and toolsets operating in parallel, from long-dwell espionage groups to the blended espionage-and-cybercrime model documented in analysis of Brass Typhoon (APT41).
Daxin's operators appear to sit firmly in the pure-espionage camp: no ransomware, no data-leak site, no monetization play visible in over a decade of activity — just access, maintained.
| Technique | ID | Status |
|---|---|---|
| Boot or Logon Autostart Execution: Winlogon Helper DLL | T1547.004 | Confirmed — Symantec's own reporting explicitly ties Stupig's persistence mechanism to this technique, while noting it uses a previously undocumented registry loading path |
| Input Capture: Credential API Hooking | T1056.004 | Hypothesis — inferred from Stupig's inline hooks on LsaLogonUser and CredUnprotectA; not an ID cited directly in source reporting |
| Rootkit | T1014 | Hypothesis — inferred from Daxin's kernel-mode driver architecture, consistent with its original 2022 classification |
Defenders should not expect Daxin to show up in outbound C2 monitoring — that's the entire point of its design. Instead, look for:
File hashes (SHA-256):
This report distinguishes confirmed findings from Symantec's Threat Hunter Team from analytic hypotheses in two places: the code-level relationship between Daxin and Stupig (unconfirmed, treated as a working hypothesis based on circumstantial evidence) and several MITRE ATT&CK technique mappings not explicitly cited in source reporting (marked as hypothesis mappings inferred from documented behavior).
The estimate that the intrusion may have persisted for up to thirteen years is Symantec's own assessment based on compile timestamps and the actor's known persistence patterns, not a confirmed dwell time.
No CVSS scores, affected software versions beyond those named in source reporting, or additional indicators of compromise have been added beyond what Symantec's Threat Hunter Team published.
Chinese-speaking TA4922 expands into Europe, deploying new Atlas RAT malware in phishing campaigns targeting organizations across sectors.
| Subvert Trust Controls: Code Signing | T1553.002 | Hypothesis — inferred from the digitally signed srt64.sys driver, which would help it pass Windows driver-signature enforcement |
| Masquerading: Match Legitimate Name or Location | T1036.005 | Hypothesis — inferred from Stupig's rename to kbdus1.dll, mimicking the legitimate kbdus.dll in the same directory |
