What happened on July 15, 2026? The Symantec and Carbon Black Threat Hunter Team reported that Daxin malware had resurfaced on a compromised Windows host inside a Taiwan based high tech manufacturer. The same machine also carried a previously undocumented implant called the Stupig backdoor. Daxin hid its command channel by taking over legitimate TCP sessions, while Stupig could execute commands with SYSTEM level authority from the Windows logon screen before a user signed in.

This guide explains what Daxin is, how its kernel networking works, why Stupig changes the defensive picture, which facts remain uncertain, and how security teams can approach detection, containment, forensics, and recovery.

What is Daxin Malware?

Daxin malware is a sophisticated Windows kernel driver backdoor built for long term access to protected networks. Symantec first documented it publicly in 2022 after finding evidence that a China linked espionage group had used it against governments, telecommunications, transportation, manufacturing, and other strategically important targets.

Calling it ordinary Windows malware does not capture the full picture. It behaves like both backdoor malware and a kernel-mode rootkit. The driver works deep inside Windows, where it can inspect network packets before normal applications see them. This position gives it a level of control that many user mode security tools were never designed to observe directly.

A conventional backdoor often calls an external server and waits for instructions. That pattern creates a trail. A defender may see repeated connections, unusual domains, rare IP addresses, or a process that should not be using the network. Daxin takes a quieter path. It watches traffic that is already arriving at the infected system and looks for secret patterns that tell it when to wake up.

Why the 2026 Discovery Matters

The new case matters because the sample found in 2026 was reported as identical to the implant described four years earlier. In other words, the operation did not necessarily need a flashy redesign. The old tool still offered enough stealth and control to remain useful inside a modern enterprise.

The compromised host had no telemetry on record before May 12, 2026. Both malicious files carried compile timestamps from early 2013. That combination creates an unsettling possibility: the attackers may have maintained access for years before the endpoint became visible to the monitoring system.

Still, timestamps are not a calendar of attacker activity. They can be changed, copied, or preserved when an old component is reused. The responsible conclusion is narrower. A very old implant was active in 2026, the available telemetry began late, and a long dwell time is plausible. Claiming that the attackers definitely remained inside the same network for 13 uninterrupted years would go beyond the published evidence.

This is the kind of ambiguity that defines serious cyber espionage investigations. Analysts often reconstruct a story from fragments rather than watching the first intrusion happen in real time. The lesson is simple: the date an alert appears is not always the date the compromise began.

“Finding it active in 2026 indicates the operation behind it never went away; it went quiet.”

How Daxin Malware Works Inside Windows

A driver positioned below ordinary applications

Daxin malware arrives as a Windows kernel driver. The 2026 file, srt64.sys, was installed under %SystemRoot%\System32\drivers and was digitally signed. A signature can help a driver pass Windows loading checks, but it should never be treated as proof that the code is safe.

During initialization, the analyzed family unpacked its main payload in kernel memory and located internal Windows networking structures. Symantec documented its interaction with the Network Driver Interface Specification, commonly called NDIS. This is the layer that helps Windows network drivers exchange packets with the rest of the operating system.

NDIS hooks and a private network stack

The driver searched for TCP/IP related NDIS structures and replaced selected packet handling functions with its own routines. Researchers documented modifications involving structures such as NDIS_OPEN_BLOCK, NDIS_M_DRIVER_BLOCK, and NDIS_MINIPORT_BLOCK. The goal was not merely to spy on traffic. It was to decide which packets should continue to Windows and which packets should be diverted into the implant.

This behavior fits the practical meaning of a Windows rootkit. A rootkit hides or controls system activity by intercepting trusted operating system functions. In Daxin's case, the same low level position also supported a custom TCP/IP implementation capable of handling ARP, IPv4, TCP, UDP, and DNS related traffic.

Think of a building with one official mailroom. Every package is supposed to be logged and delivered through that desk. Daxin quietly installs a second mailroom inside the wall. Normal packages still reach the official desk, but specially marked packages disappear into the hidden room before anyone records them.

TCP Connection Hijacking and Covert C2 Communication

The defining feature of Daxin malware is its approach to TCP connection hijacking. The driver inspects incoming packets for specific strings or byte patterns. When it sees the expected trigger, it removes those packets from the normal Windows path and takes control of the connection.

Symantec documented several triggers in the analyzed code. One looked for an HTTP style request beginning with POST and containing the string 756981520337. Other checks looked for binary sequences beginning with 0x10 0x99 0x10 or 0x10 0x99 0x11. These values are useful for defensive research, but they should not be treated as the only possible signatures across every version.

After recognizing a trigger, the driver can send a forged reset packet toward the legitimate destination, making that service believe the connection has closed. It then acknowledges the remote source and continues the session itself. The attacker and the implant can perform a custom key exchange and open an encrypted command-and-control channel.

This design changes what network security teams should expect. There may be no fresh outbound connection to an obvious attacker server. The malicious C2 communication can ride inside a session that began as normal traffic to a legitimate service. Domain blocklists and simple flow analysis may miss the context that matters.

Daxin can also generate its own packets rather than relying on the normal Windows TCP/IP stack. During laboratory testing, researchers changed the Windows Time to Live setting and observed that Daxin generated traffic did not follow the new value. Small differences like that can become useful hunting clues when packet captures and endpoint evidence are examined together.

How Daxin Malware Reaches Isolated Networks

A single infected host can be dangerous. A chain of them is far worse. Daxin supports communications through multiple compromised machines, allowing an operator to relay commands from one node to the next until reaching a system that has no direct internet access.

The malware can receive an ordered list of nodes, connect to the next infected host, complete its custom handshake, and pass an updated instruction onward. Each machine becomes a hidden stepping stone. This capability is particularly relevant to manufacturing sites, government environments, and segmented networks where sensitive systems are intentionally separated from the public internet.

That does not mean segmentation is useless. It means segmentation must be paired with monitored trust boundaries, controlled administrative paths, and strong endpoint visibility. If an attacker controls a machine on both sides of an internal boundary, that host can become a bridge.

The design resembles the behavior expected from an advanced persistent threat. It favors patience, resilience, and access to high value systems rather than immediate disruption. This is one reason Daxin has been discussed as state-sponsored malware and China-linked malware, although public reporting attributes the operation to a China linked actor rather than naming a specific government unit.

What the Daxin Backdoor Can Do After Compromise

Once its encrypted channel is established, the implant provides a compact but powerful control set. The operator can read and write files, execute programs, load DLLs, interact with process input and output, and move raw network packets through the infected system.

A dedicated device named \\.\Tcp4 allows additional components to register for communication through Daxin. This makes the driver more than a remote shell. It can serve as a covert transport layer for other tools deployed during the intrusion.

What is the Stupig Backdoor?

The discovery became more unusual when researchers found a second implant on the same machine. Stupig first appeared as a.dll and was later detected as kbdus1.dll. That second name closely resembles kbdus.dll, the legitimate Microsoft keyboard layout library for U.S. English.

This was not a random disguise. Stupig registered as a keyboard layout provider, causing win32k.sys to load it into winlogon.exe during startup. The DLL returned a valid KBDTABLES pointer, so the keyboard continued to function normally. To an administrator making a quick inspection, the module could look like another obscure Windows language component.

This is a rare form of keyboard layout DLL malware and a disturbing example of Winlogon malware. The trusted process is already involved in the Windows sign in experience and runs with powerful authority. By hiding there, Stupig gains a position before an ordinary user session begins.

How Stupig Executes Commands Before Login

Once loaded into winlogon.exe, Stupig watches the username entered at the Windows logon screen. If that text begins with the string stupig, the characters that follow are interpreted as a command and executed with SYSTEM privileges on the secure desktop.

If the prefix is entered without an additional command, the implant can open a SYSTEM command prompt directly on the logon screen. It then calls the real LsaLogonUser function, allowing Windows to return an ordinary failed sign in message. The attacker gets command execution, while the visible result looks like an unsuccessful login.

The public report also describes inline hooks on SspiCli!LsaLogonUser and Advapi32!CredUnprotectA. Those hooks create a route for potential credential theft inside the trusted Winlogon process. The code referenced another DLL named msyun.dll, but that file was not recovered, so its purpose remains unknown.

This distinction matters. The observed code supports credential interception, but investigators did not publish a complete recovered workflow showing exactly what data the missing companion component collected or where it sent that data. A sound analysis states the capability without inventing the missing chapter.

Daxin and Stupig: Connected, but Not Proven to Be One Family

The two tools were deployed on the same host, carried timestamps a few weeks apart, and performed complementary jobs. Researchers also saw similarities in development practice. Those clues suggest a shared operator or development relationship, but they do not prove common authorship.

It is safer to describe Stupig as a possible companion to Daxin malware, not as a confirmed module of the same codebase. Attribution becomes less reliable when a report turns reasonable assessment into certainty.

What is Known About the Initial Access?

The exact entry point is unknown. Investigators suspected an outdated Digiwin single sign on portal that still used Java Development Kit versions 1.5 and 1.6 from installations dating to roughly 2009 through 2011. Those runtimes were far beyond their supported lives.

No specific exploited vulnerability was named. There is no verified CVE for the initial access described in the public report, and there is no official CVSS score for this incident. CVSS measures the severity of a disclosed vulnerability. It is not a danger rating assigned to a malware family.

The practical lesson is broader than one portal. Legacy identity systems often survive because they are business critical, poorly documented, and risky to replace. That makes continuous asset discovery and vulnerability management especially important for old SSO servers, Java runtimes, remote access systems, and regional applications that may not appear in a modern cloud inventory.

Why This Matters for Manufacturing and Critical Infrastructure

The victim was part of a multinational high tech manufacturer. Such organizations hold intellectual property, product designs, supplier information, production schedules, and trusted connections to partners. They also tend to operate mixed environments where old Windows systems, modern enterprise platforms, and specialized production technology must coexist.

A Taiwan cyber attack involving a strategic manufacturer carries significance beyond one endpoint. Taiwan is central to global high tech supply chains, and long term access may support intelligence collection, future disruption, or deeper movement through commercial relationships. Public reporting does not establish the attacker's final objective in this specific case, so those outcomes should be treated as risk scenarios rather than confirmed actions.

The same architecture could be relevant to a critical infrastructure cyber attack. Daxin's multi hop design is built for networks where sensitive systems are segmented or disconnected from the internet. Once a trusted bridge is compromised, the operator may reach areas that ordinary external scanning cannot see.

A Realistic Attack Scenario

Imagine a manufacturer with a forgotten regional SSO server. It still works, employees rely on it, and replacing it always slips to the next budget cycle. An attacker gains access through that old environment, reaches a Windows server, and installs a signed malicious driver.

Nothing immediately crashes. Production continues. The implant does not call a suspicious domain every five minutes. Instead, it waits inside the network stack. Months later, a carefully formed connection reaches the server, triggers the hidden listener, and becomes an encrypted control channel.

The attacker then uses that host to reach another machine on a restricted segment. Stupig provides a second route through the Windows logon process. Even if one file is found, the other implant may preserve access. By the time analysts see the first alert, they are not investigating a single malicious file. They are reconstructing a hidden access system.

This is why Daxin rootkit analysis must connect driver behavior, network evidence, authentication activity, Registry changes, and historical telemetry. Looking at each clue alone can make the intrusion appear smaller than it is.

Daxin Malware Detection and Threat Hunting

Strong Daxin malware detection begins with the known files, but it cannot end there. Hashes are useful for confirming known samples. They are less useful when an attacker recompiles a component, changes a loader, or introduces a new companion implant.

Effective threat hunting should combine file, driver, process, Registry, authentication, memory, and packet evidence. A modern endpoint detection and response program can provide the process and driver history needed to ask when a module first appeared, what loaded it, and what else happened around the same time.

High value hunting questions

• Is srt64.sys present anywhere in the environment, including backups and dormant systems?
• Which uncommon or old signed drivers are loaded on sensitive Windows servers?
• Has winlogon.exe loaded a.dll, kbdus1.dll, or any unapproved keyboard layout provider?
• Has winlogon.exe spawned cmd.exe or another unexpected child process?
• Do failed login records contain usernames beginning with stupig?
• Are there inbound TCP sessions followed by unusual reset behavior or packet handling that differs from the host's normal Windows stack?
• Did the endpoint stop reporting telemetry for a long period before the first alert?

Network and endpoint data should be correlated rather than reviewed in separate queues. Extended Detection and Response can help connect a driver load, a System32 file change, an unusual login name, and a suspicious network session into one incident timeline.

Daxin Malware Indicators of Compromise

The official report published two file hashes. These indicators of compromise are strong matches for the recovered artifacts, but defenders should also hunt the surrounding behaviors.

Behavioral indicators worth monitoring

• Unexpected kernel drivers, especially drivers with old timestamps or unusual signing history
• Changes to NDIS handler pointers or signs of packet interception below user mode
• HTTP traffic containing the documented Daxin trigger string
• Binary packets beginning with the documented magic byte sequences
• Unknown DLLs loaded into winlogon.exe
• Keyboard layout provider registrations that reference unfamiliar files
• SYSTEM processes created before an interactive user session begins
• Inline modification of LsaLogonUser or CredUnprotectA

For broader context on how a more conventional information stealer behaves, Hoplon's OnyxC2 malware analysis shows a very different model based on credential collection and commodity delivery. Comparing the two helps analysts understand why no single detection method covers every malware family.

The behaviors align with several MITRE ATT&CK techniques. This mapping is an analyst interpretation based on publicly reported functionality, not an official claim that every technique occurred during every stage of the Taiwan intrusion.

What Organizations Should Do Now

If the known files or behaviors appear in an environment, treat the situation as a possible enterprise intrusion, not a routine antivirus cleanup. A kernel level implant can alter what the operating system reports, and a Winlogon implant can operate before a normal user session exists.

Immediate containment

• Isolate suspected hosts through trusted network or EDR controls.
• Preserve volatile memory before rebooting when operationally safe.
• Block the known hashes while searching for renamed or modified variants.
• Restrict exposure of legacy SSO and unsupported Java systems.
• Review connections between the affected host and segmented environments.

Evidence preservation

Capture memory, loaded driver lists, Registry hives, authentication logs, endpoint telemetry, active connections, and relevant packet captures. A digital forensic investigation should preserve original evidence and build a timeline before destructive cleanup changes the system.

Scoping and eradication

Search the full enterprise, including subsidiaries, jump servers, identity systems, backup environments, and machines that have stopped reporting. Rebuild confirmed kernel compromised systems from trusted media. Do not assume that deleting srt64.sys or kbdus1.dll removes every access path.

A complete malware incident response plan should include credential rotation from known clean devices, session revocation, service account review, restoration validation, and heightened monitoring after systems return to production.

Common Misconceptions

Daxin is ransomware

It is not. The publicly documented purpose is covert access, espionage, tunneling, and remote control. No encryption for ransom was described.

The Taiwan victim was definitely compromised for 13 years

That remains plausible but unproven. The timestamps are old and the host lacked earlier telemetry, yet neither fact establishes an uninterrupted 13 year presence.

A digital signature means the driver is trustworthy

A signature confirms a relationship with a certificate and helps verify whether a file changed after signing. It does not guarantee benign intent.

Daxin and Stupig are confirmed parts of one malware family

No direct code level relationship was identified. Their co deployment, timing, and complementary roles suggest a connection, but the public evidence stops short of proof.

A CVSS score can describe how dangerous Daxin is

CVSS scores vulnerabilities, not malware families. Because no specific exploited Digiwin vulnerability was identified, assigning a CVSS score to this intrusion would be misleading.

Frequently Asked Questions

Is Daxin a rootkit or a backdoor?

It is best described as both. It is a Windows kernel driver backdoor with rootkit style interception and stealth capabilities.

Why is Daxin difficult to detect?

It can monitor incoming traffic, recognize secret patterns, hijack a legitimate TCP session, and process malicious packets through its own network stack. That reduces the obvious outbound signals many tools expect.

Can Stupig execute commands before a user logs in?

Yes. According to Symantec, Stupig runs inside winlogon.exe and can execute text following the stupig username prefix with SYSTEM authority on the secure desktop.

Are Daxin and Stupig made by the same actor?

Possibly, but not conclusively. Researchers found suggestive operational and development clues, not direct code proof.

What was the initial access vector?

The public report suspects an outdated Digiwin SSO portal using obsolete Java installations. The exact exploit, CVE, and compromise date remain unknown.

Can antivirus alone remove Daxin safely?

Antivirus may detect known files, but a confirmed kernel compromise warrants full scoping, memory and disk forensics, credential review, and often a trusted rebuild.

What should defenders monitor first?

Start with the known hashes, loaded drivers, Winlogon modules, keyboard layout provider registrations, unusual failed usernames, pre login process creation, and inbound TCP anomalies.

Key Takeaways

• Daxin malware remains operational and was found in a Taiwan manufacturer in 2026.
• Its custom kernel networking supports covert control, encrypted communication, tunneling, and movement through infected nodes.
• Stupig introduces a separate pre authentication route through the Windows keyboard layout and Winlogon system.
• A 13 year dwell time is possible, but current public evidence does not prove it.
• No exploited CVE or official CVSS score has been identified for the suspected Digiwin SSO entry point.
• Reliable detection requires behavior, memory, network, authentication, and historical telemetry, not hashes alone.

Conclusion

The return of Daxin malware is a reminder that advanced operations do not always disappear when public reporting goes quiet. Sometimes the tool remains useful because the environment around it still contains blind spots: unsupported software, incomplete telemetry, trusted drivers, and network paths that no one reviews closely.

The most important defensive move is not to memorize one filename. It is to understand the architecture. A driver that intercepts packets, a DLL that hides in Winlogon, and a host that only recently began reporting are separate clues. Put together, they describe a patient intrusion that deserves enterprise wide investigation.

If your organization has found suspicious drivers, unusual Winlogon activity, or unexplained gaps in endpoint visibility, Hoplon InfoSec can help validate the evidence, scope the exposure, and build a defensible recovery plan through its cyber threat intelligence, endpoint monitoring, forensics, and incident response capabilities.

References

1. Symantec and Carbon Black: Daxin Returns Alongside Stupig
2. Symantec: Daxin Backdoor Designed for Hardened Networks
3. Symantec: Daxin Technical Analysis Part One