10 mincritical
Daxin Returns: Stealthy Malware Resurfaces in Taiwan Alongside a New Backdoor
Symantec identified renewed activity of Backdoor.Daxin, a sophisticated China-linked kernel-mode rootkit that hijacks legitimate TCP connections for covert C2, on a Taiwan manufacturing subsidiary in May 2026, four years after its initial public disclosure. Alongside it, researchers discovered a new backdoor, Stupig, which abuses the Windows keyboard-layout provider mechanism to execute SYSTEM-level commands from the logon screen pre-authentication and hook credential-handling APIs within winlogon.exe. Compile timestamps on both tools date to 2013 despite the host having no telemetry until 2026, suggesting a potentially decade-plus dwell time enabled by likely initial access via an outdated, end-of-life Digiwin SSO/JDK deployment.
Sens:■ Immediate
Showing defanged values
- filenamea.dllInitial dropped filename for Backdoor.Stupig in the Windows directory, later renamed and relocated
- filenamekbdus1.dllRenamed Backdoor.Stupig placed in System32, mimicking the legitimate keyboard-layout library kbdus.dll to evade filename-based detection
- filenamemsyun.dllCompanion payload referenced via LoadLibraryA call within Stupig; the file itself was not recovered during the investigation
- filenamesrt64.sysBackdoor.Daxin kernel-mode driver installed in %SystemRoot%\System32\drivers, digitally signed to bypass driver-signature checks
- sha25649c827cf48efb122a9d6fd87b426482b7496ccd4a2dbca31ebbf6b2b80c98530Hash associated with srt64.sys (Backdoor.Daxin)
- sha2565bb5cffda4647940919a185df37aab2aef71ca3010a6c1d05bdcc8bc8fb3af3fHash associated with a.dll / kbdus1.dll (Backdoor.Stupig)
Detection / HunterAnthropic
What Happened
Security researchers found that a very stealthy piece of spying software called Daxin, linked to China, is still being used - this time against a Taiwanese factory owned by a global tech manufacturer. Alongside it, they found a brand-new tool called Stupig that lets an attacker run commands with full administrator-level control directly from the Windows login screen, before anyone even logs in, making it very hard to notice. Companies with older or unpatched login/portal software (in this case, an outdated single sign-on system) are especially at risk, and evidence suggests attackers may have had hidden access to this network for over a decade without being caught. This matters because it shows that quiet, long-term spying operations can persist for years even against organizations that believe their systems are secure. Organizations, especially in manufacturing and other strategically sensitive sectors, should ensure old software is patched or retired, monitor for unusual logon-screen behavior, and use up-to-date security tools capable of detecting this kind of stealthy activity.
Key Takeaways
- Backdoor.Daxin, a China-linked kernel-mode rootkit first documented by Symantec in 2022, has resurfaced on a compromised host in Taiwan in 2026, indicating the operation behind it remains active after years of apparent dormancy.
- A previously undocumented backdoor, Backdoor.Stupig, was found co-deployed with Daxin and uses a novel technique: a trojanized keyboard-layout DLL loaded by winlogon.exe that allows pre-authentication SYSTEM-level command execution from the Windows logon screen without triggering anomalous audit events.
- Both samples carry compile timestamps from early 2013 but the host had no telemetry until May 2026, suggesting the intrusion may have persisted undetected for as long as 13 years.
- Stupig also installs inline hooks on LsaLogonUser and CredUnprotectA to intercept credentials directly within the winlogon.exe process, and references an unrecovered companion payload (msyun.dll).
- The likely initial access vector was an outdated Digiwin single sign-on portal running long-end-of-life JDK 1.5/1.6 installations, highlighting the risk of unpatched, aged software components.
Affected Systems
- Windows systems (kernel-mode driver, winlogon.exe/win32k.sys persistence)
- Digiwin single sign-on portal running JDK 1.5 and 1.6 (end-of-life since 2009/2013)
- Taiwan-based subsidiary of a multinational high-tech manufacturer
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Likely exploitation or compromise of an outdated Digiwin single sign-on portal running long end-of-life JDK 1.5/1.6
- Persistence (Daxin): Signed kernel-mode driver (srt64.sys) installed in System32\drivers to hijack legitimate inbound TCP connections for covert C2
- Persistence (Stupig): Malicious DLL registered as a keyboard-layout provider so win32k.sys loads it into winlogon.exe at startup
- Pre-Auth Execution: Attacker enters a specially crafted username at the logon screen beginning with a defined prefix, triggering command execution as SYSTEM on the secure desktop before authentication completes
- Credential Access: Inline hooks on LsaLogonUser and CredUnprotectA intercept credentials within the winlogon.exe process
- Operational Security: Following initial detection of a.dll, the backdoor is renamed to kbdus1.dll and moved to System32 to blend in with legitimate system files and evade detection
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
- Platforms: Symantec Protection Bulletin
The article states that Symantec products detect this activity via the definitions Backdoor.Daxin and Backdoor.Stupig, with updates available through the Symantec Protection Bulletin. No YARA, Sigma, Snort/Suricata, or query-language rules are reproduced or referenced in the article.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | The kernel-mode driver and DLL loaded into winlogon.exe may evade typical process-based EDR telemetry since Stupig masquerades as a legitimate keyboard-layout component and Daxin avoids initiating its own outbound network connections; however, driver loading and unusual module loads into winlogon.exe could be visible to EDR with strong kernel/driver monitoring. |
| Network Visibility | Low | Daxin's core evasion technique is hijacking existing legitimate TCP connections rather than establishing new outbound C2 channels, making conventional network monitoring largely ineffective at detecting its communications. |
| Detection Difficulty | Very Hard | Both tools are specifically engineered to blend into normal system operation - Daxin hijacks legitimate traffic instead of generating new C2 connections, and Stupig masquerades as a valid keyboard-layout provider that still functions correctly, generating only a standard failed-logon event rather than an anomaly. |
Required Log Sources
- Windows Security Event Logs (logon events, especially failed logons with unusual usernames)
- Driver/module load telemetry (Sysmon Event ID 6/7 or EDR driver load events)
- Process creation and image load events for winlogon.exe
- File integrity monitoring for System32\drivers and System32 directories
- Digital signature validation logs for loaded drivers
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for failed logon attempts using usernames with unusual or non-standard prefixes that do not correspond to any valid account, which could indicate abuse of a logon-screen backdoor mechanism. | Windows Security Event Logs (Event ID 4625 failed logons) | Execution / Pre-Authentication Access | Low to Medium - typo'd usernames or brute-force attempts could also produce similar patterns, requiring correlation with other indicators |
| Consider auditing keyboard-layout DLLs registered in the system for unexpected filenames, unusual load paths, or files with names closely resembling legitimate kbdXX.dll libraries. | File integrity monitoring, registry keys governing keyboard layout providers, module load events into winlogon.exe | Persistence (T1547.004) | Low - legitimate keyboard layout DLLs are a small, well-known finite set |
| Consider reviewing digitally signed kernel drivers loaded on critical hosts for anomalous behavior such as network filter/hook installation not associated with legitimate security or networking software. | Driver load events, kernel callback registration monitoring if available via EDR | Persistence / Command and Control (T1014) | Medium - legitimate security and networking drivers also install filters/hooks |
| Consider investigating hosts that recently began reporting telemetry (i.e., previously unmonitored or newly onboarded endpoints) for signs of long-dwell historic compromise, particularly if running end-of-life software. | EDR/telemetry onboarding logs, asset inventory records, software version audits | Initial Access / Long-term Persistence | Low - newly onboarded hosts are a defined, auditable population |
| Consider monitoring for inline API hooking behavior (e.g., unexpected VirtualProtect, ZwAllocateVirtualMemory, or memcpy calls) targeting security-related DLLs such as sspicli.dll or advapi32.dll within system processes like winlogon.exe. | EDR API-hooking/behavioral detection, memory protection change events | Credential Access (T1056.004) | Medium - some legitimate security software also modifies memory protections in system processes |
Control Gaps
- Traditional network-based monitoring and firewalls are unlikely to detect Daxin's C2 since it hijacks legitimate, already-established TCP connections rather than making new outbound calls
- Standard logon auditing does not flag Stupig's pre-authentication SYSTEM execution beyond a routine failed-logon event
- Filename-based or signature-based file detection can be evaded by naming malicious files to closely resemble legitimate system files
- Digital signature checks alone are insufficient since the Daxin driver was digitally signed to pass Windows driver-signature enforcement
Key Behavioral Indicators
- Failed logon events using usernames with unrecognized or non-standard prefixes not tied to valid accounts
- Presence of DLLs in System32 with names nearly identical to legitimate keyboard-layout libraries but differing by minor character variations
- Unexpected kernel driver files in System32\drivers with signing timestamps inconsistent with their apparent age or purpose
- Sudden onboarding of telemetry from a previously unmonitored host, especially one running long end-of-life software components
- Command prompt or process spawning as SYSTEM directly from the secure desktop/logon screen context
False Positive Assessment
Low - the described indicators (specific file names, hash values, and unusual logon-screen behavior) are highly specific and unlikely to arise from legitimate activity, though generic hunting hypotheses around failed logons or driver loads may require correlation to reduce noise.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting; if the described indicators are found, consider isolating the affected host(s) via EDR if supported, and preserve forensic evidence prior to remediation.
- Consider searching for the specific file paths and hashes described (srt64.sys, a.dll, kbdus1.dll) across your environment using EDR or endpoint scanning tools.
- If a host is found with the described indicators, consider auditing all locally cached credentials and rotating them, given the credential interception capability described.
- Consider reviewing recently onboarded or newly-telemetry-reporting hosts for signs of historic compromise before assuming a clean baseline.
Infrastructure Hardening
- Evaluate whether end-of-life software components (such as outdated JDK versions or SSO portals) exist in your environment and prioritize patching or decommissioning them.
- Consider implementing strict driver-signing policy enforcement combined with allow-listing of known-good drivers rather than relying solely on signature validation.
- Where feasible, consider network segmentation to limit the blast radius of a compromised host attempting multi-hop lateral movement via hijacked TCP sessions.
- Consider deploying integrity monitoring on critical system directories (System32, System32\drivers) to detect unauthorized file additions or renames.
User Protection
- Consider deploying EDR solutions with strong kernel driver and module-load visibility, particularly around winlogon.exe and other core system processes.
- Evaluate whether your endpoint protection platform can detect anomalous logon-screen behavior or unexpected process spawning as SYSTEM prior to authentication.
- Consider enabling enhanced logging (e.g., Sysmon) for driver and DLL load events on high-value or internet-facing hosts.
Security Awareness
- Consider briefing IT and security teams on the risk posed by long end-of-life software components remaining in production, particularly SSO/authentication portals.
- Consider incorporating awareness of pre-authentication attack techniques into security training for IT administrators managing Windows logon infrastructure.
- Consider reviewing asset management practices to ensure all hosts are consistently reporting telemetry, reducing blind spots exploited for long-term persistence.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping6 techniques
Tactic
Initial Access
Tactic
Persistence
Tactic
Stealth
Tactic
Defense Impairment
Tactic
Credential Access
Tactic
Command and Control
Additional IOCs
- File Hashes:
49c827cf48efb122a9d6fd87b426482b7496ccd4a2dbca31ebbf6b2b80c98530(SHA256) - srt64.sys - Backdoor.Daxin5bb5cffda4647940919a185df37aab2aef71ca3010a6c1d05bdcc8bc8fb3af3f(SHA256) - a.dll / kbdus1.dll - Backdoor.Stupig
- File Paths:
C:\Windows\System32\drivers\srt64.sys- Location of the Daxin kernel-mode driver on the compromised hostC:\Windows\a.dll- Original drop location of Stupig backdoor in the Windows directoryC:\Windows\System32\kbdus1.dll- Renamed Stupig backdoor placed in System32 to mimic legitimate kbdus.dll