Daxin resurfaces in Taiwan alongside new Stupig backdoor

Symantec and Carbon Black’s Threat Hunter Team, in research reported by The Hacker News on 16 July 2026, describe a Taiwan-based subsidiary of a multinational high-tech manufacturer that has been carrying the Daxin kernel-mode rootkit — first documented by Symantec in March 2022 and attributed then to a China-linked threat actor — alongside a previously unreported backdoor the researchers have named Stupig. Both artifacts pulled from the host carry compilation timestamps in early 2013. Telemetry from the compromised host began 12 May 2026.

What runs at the kernel layer

Daxin’s on-disk name is srt64.sys. It is a Windows kernel-mode driver, and its whole design point is that it does not do what a backdoor is usually built to do. There is no outbound beacon. There is no callback to attacker-controlled infrastructure. It sits inside the network stack and watches incoming TCP for specific patterns, and when it sees them, it hijacks whatever legitimate session the packet was riding on and uses that session for encrypted C2. Symantec’s 2022 writeup called this out as the reason conventional network monitoring did not fire on the family: the observed traffic on the wire is the same traffic that would be there without the rootkit. The 2026 sample does not depart from that model.

The rootkit also supports multi-hop routing through chains of infected hosts. An operator that has landed on one machine in an environment can chain through a second and third to reach a machine that has no route to the internet — the kind of segmentation that would, on paper, keep a workstation from ever talking to attacker infrastructure. Daxin is not evading the segmentation. It is riding sessions the segmented host is already permitted to open.

What runs at the identity layer

Stupig — filenames a.dll or kbdus1.dll, depending on sample — does the same trick at the logon screen. It registers as a keyboard-layout provider, the same interface Windows uses to load real IME support, and gets loaded into winlogon.exe before any user session exists. Once loaded, it watches the logon prompt for a username that begins with the literal string stupig. If a command string follows the prefix, Stupig executes it as SYSTEM. If nothing follows, it spawns a SYSTEM command prompt. From the auditing side, no user has signed in, so no logon event fires, and the resulting activity attributes to winlogon.exe itself.

Symantec, quoted in the research: “By hiding inside the Windows logon process and registering as a keyboard-layout provider, Stupig gives operators SYSTEM-level command execution and credential theft before a user signs in.”

Whether the same operators deployed both tools cannot be confirmed, the report says. Their functions are complementary — the identity-layer foothold on the logon screen and the network-layer foothold in the kernel driver — but that is an inference, not evidence of a single hand.

The way in

The suspected initial access is worth naming plainly, because it is the least exotic detail in the report. The compromised environment was running an outdated Digiwin single sign-on portal on a Java Development Kit from the 1.5 or 1.6 release — 2009 to 2011 vintage, end-of-life for over a decade. Whatever bug the operator used to land initial code, the exposed surface was a JVM that stopped receiving security patches around the time the Daxin sample was compiled.

What to actually do

For a Windows environment, the immediate audit is: enumerate every DLL loaded by winlogon.exe on every host, and confirm each one is a keyboard-layout DLL that ships with Windows or with a keyboard vendor you actually deploy. kbdus1.dll is not a Windows-shipped file. Anything that names itself after a kbd* layout but does not match a signed catalog you can account for is worth pulling.

On the network side, the point is not that Daxin is undetectable — it is that the detection has to look at endpoint kernel behaviour, not at flow logs. If EDR does not have visibility into driver loads and kernel object manipulation on Windows Server hosts that terminate legitimate TCP sessions, the resulting gap is where the family lives.

For anything still running a public-facing Digiwin SSO portal on the same JDK generation — or any Java web-app fronted by a JVM last patched fifteen years ago — the fix is retirement of the software, not another advisory. The wiring is still running because the wiring was left alone; that is the same story at the network, identity, and application layers, and it is the reason 2013-vintage tradecraft still works in 2026.

Full technical detail and indicators of compromise live in the Symantec/Carbon Black research linked from The Hacker News writeup.