Stupig Windows Backdoor Opens SYSTEM Shell From Login Screen

A newly documented Windows backdoor called Stupig can open a command shell with SYSTEM privileges when an attacker enters a special username at the sign-in screen. The technique works before a normal user session begins and can leave defenders with little more than an unusual failed-login record.

The behavior is not caused by a vulnerability in a clean Windows installation. Stupig must already be installed on the computer, and an operator must be able to reach its interactive login screen. According to the Symantec Threat Hunter Team investigation, the backdoor was discovered alongside Daxin, a sophisticated kernel-level espionage tool.

Researchers found both implants in May 2026 on a compromised computer belonging to the Taiwan-based subsidiary of a multinational high-tech manufacturer. Symantec linked Daxin to China-aligned espionage activity, but it has not confirmed that the same operators developed or deployed Stupig.

How the Stupig Windows Backdoor Works

Stupig disguises itself as a Windows keyboard-layout library. It registers as a keyboard-layout provider, which causes Windows to load the malicious DLL into winlogon.exe during system startup.

The implant returns valid keyboard-layout data, allowing input to continue working normally. This helps the malicious module appear legitimate during a basic inspection of the computer’s loaded components.

After entering winlogon.exe, Stupig monitors usernames submitted at the Windows sign-in screen. Usernames beginning with the string stupig activate its hidden command-execution function.

Login input	Stupig behavior	Privilege level
The trigger prefix by itself	Opens a command prompt on the secure desktop	SYSTEM
The trigger prefix followed by text	Attempts to execute the appended text as a command	SYSTEM
An ordinary username	Passes the login request to the legitimate Windows process	Normal Windows authentication

Why the Login-Screen Technique Is Difficult to Detect

After processing its hidden command, Stupig still calls the legitimate Windows authentication function. Windows therefore returns an ordinary failed-login message for the unusual username.

Symantec said this activity does not produce a separate logon audit anomaly showing that a SYSTEM shell was created. Defenders may only see a failed authentication attempt involving a username that starts with the malware’s trigger string.

The backdoor also hooks Windows functions involved in authentication and protected credential handling. This gives it the potential to intercept credentials inside winlogon.exe. Researchers found a reference to a possible companion payload named msyun.dll, but that file was not recovered.

Stupig and Daxin Found on the Same Computer

Daxin is a Windows kernel-driver backdoor that Symantec publicly exposed in 2022. The company’s original Daxin research described malware designed to operate inside hardened networks while hiding its communications among legitimate traffic.

Instead of opening an obvious outbound connection to a command-and-control server, Daxin monitors incoming TCP traffic for specific patterns. It can take control of a legitimate connection and use an encrypted channel to receive commands and return information.

Daxin can also relay communications through several infected computers. This capability can help an attacker reach isolated network segments that do not have direct internet access.

Feature	Backdoor.Stupig	Backdoor.Daxin
Malware type	Malicious keyboard-layout DLL	Kernel-mode driver backdoor
Primary role	Pre-login SYSTEM command execution and possible credential interception	Stealthy remote communications and network access
Execution location	winlogon.exe	Windows kernel
Notable technique	Username-based trigger at the sign-in screen	Hijacking legitimate TCP connections
Publicly documented	2026	2022, with known samples dating to 2013

No Confirmed Code-Level Link Between the Backdoors

Stupig and Daxin were present on the same compromised host and provide complementary capabilities. Their compilation timestamps are also separated by only a few weeks in early 2013.

Symantec found similarities in their development practices and said Stupig’s author appeared familiar with Daxin’s source code. However, researchers did not identify a specific code-level relationship, so attribution to the same developer or operator remains an assessment rather than a confirmed fact.

Compilation timestamps can also be modified. The dates support further investigation, but they do not establish when the malware was installed or prove that the affected network remained compromised for 13 years.

Outdated Digiwin Portal Was a Possible Entry Point

The affected computer did not begin supplying telemetry until May 12, 2026. This visibility gap prevented investigators from determining when the compromise started.

Symantec identified an outdated Digiwin single sign-on portal as the most likely initial access route. The portal was still using Java Development Kit 1.5 and 1.6 installations dating from 2009 to 2011, according to the Stupig and Daxin incident report.

The evidence does not establish exactly how the portal was exploited. Organizations should nevertheless treat unsupported Java installations and neglected authentication systems as high-priority exposure, especially when they are reachable from untrusted networks.

Changes Observed After Stupig Was Detected

Researchers initially found Stupig deployed as a.dll in the Windows directory on May 28, 2026. On June 1, the malware appeared in the System32 directory under the name kbdus1.dll.

The second filename closely resembles kbdus.dll, the legitimate Windows library for the US English keyboard layout. The small naming difference could help the malicious file survive casual inspection or simple filename-based searches.

Symantec could not determine whether the renamed file was installed after the first detection or had already existed as a redundant backdoor. Security teams should therefore search for both names and verify the identity of all keyboard-layout DLLs.

How Organizations Can Detect and Respond to Stupig

Defenders should combine endpoint telemetry, file hashes, registry inspection and authentication monitoring. Network monitoring alone may miss Daxin because its communications are designed to blend into legitimate TCP connections, a capability detailed in Symantec’s Daxin technical analysis.

A match for one filename should not automatically be treated as proof of compromise because attackers can rename files. Hash validation, module-signing checks, registry context and process behavior provide stronger evidence.

• Review keyboard-layout provider registrations for unauthorized or recently modified entries.
• Inventory non-Microsoft DLLs loaded into winlogon.exe.
• Search authentication logs for usernames beginning with stupig.
• Investigate unexpected DLLs named a.dll or kbdus1.dll.
• Check Windows driver inventories for srt64.sys and the Daxin hash.
• Replace unsupported Java installations and review legacy Digiwin SSO deployments.
• Restrict physical and interactive console access to sensitive Windows systems.
• Collect forensic evidence before removing suspected implants or rebuilding affected hosts.

If either hash is detected, responders should isolate the affected computer and investigate the wider environment. The co-deployment of a login-screen backdoor and a stealthy network implant may indicate that the attacker has established more than one persistence mechanism.

Indicators of Compromise

Type	Indicator	Description
SHA-256	49c827cf48efb122a9d6fd87b426482b7496ccd4a2dbca31ebbf6b2b80c98530	Backdoor.Daxin sample
Filename	srt64.sys	Daxin kernel-mode driver name observed in the investigation
SHA-256	5bb5cffda4647940919a185df37aab2aef71ca3010a6c1d05bdcc8bc8fb3af3f	Backdoor.Stupig sample
Filename	a.dll	Initial Stupig deployment name observed by researchers
Filename	kbdus1.dll	Stupig filename designed to resemble a legitimate keyboard-layout DLL
Referenced filename	msyun.dll	Possible companion payload referenced by Stupig but not recovered
Username pattern	stupig*	Login-screen trigger pattern associated with the backdoor

Organizations should validate these indicators in context. Clean systems should also be examined for related persistence, unexpected modules inside authentication processes and gaps in historical endpoint telemetry.

FAQ