Daxin + Stupig — Pre-Login SYSTEM Backdoor Hunt

Broadcom/Symantec's Threat Hunter team reported (2026-07-20) that Daxin — a China-attributed kernel-mode rootkit first documented in March 2022 and in use since ~2013 — was found still operational on a host at a Taiwan-based subsidiary of a multinational high-tech manufacturer. On the same host they recovered a previously undocumented backdoor they named Stupig. Both samples carry early-2013 compile timestamps, yet the host only began reporting telemetry in May 2026 — a possible 13-year undetected intrusion.

The standout novel TTP is Stupig's persistence. It ships as a malicious keyboard-layout DLL (a.dll / kbdus1.dll, masquerading as the legitimate kbdus.dll U.S. English layout). By registering as a keyboard-layout provider, it is loaded by win32k.sys into winlogon.exe at startup. It then watches the logon screen for a username beginning with stupig; any text after that prefix executes as SYSTEM on the secure desktop — before anyone signs in and without raising a logon audit event. The DLL returns a valid KBDTABLES pointer so Windows treats it as a real keyboard layout.

Daxin is a passive backdoor: it makes no outbound connections of its own. The kernel driver (srt64.sys) monitors incoming TCP traffic for specific magic patterns and hijacks existing legitimate connections for encrypted, multi-hop C2 — which is why beacon-hunting will never find it.

Five sources fetched and snapshotted at research time (Daxin-Stupig-PreLogin-Hunt-sources/). The two SHA256 hashes are corroborated across three independent sources (Symantec appendix, GBHackers, Cyber Security News). The exact keyboard-layout registry key/value used for loading was not published in any source; that hunt angle is therefore represented behaviorally and with a labelled placeholder rather than an invented registry path.

Hypotheses: (H1) If Stupig is present, a non-standard keyboard-layout DLL is loaded into winlogon.exe. (H2) If Daxin is present, the kernel driver srt64.sys is on disk in System32\drivers and/or loaded. (H3) The known sample hashes appear in process/module-load/file-write telemetry. (H4) A keyboard-layout or Winlogon-notify autostart registry value references a non-system DLL. (H5) Daxin's passive C2 will NOT appear as an outbound beacon — treat network silence as expected, not clean.

Angles that do not require CQL — use where endpoint telemetry is thin or for live triage:

• Registered keyboard layouts (live-response / PowerShell): enumerate HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\* and inspect each subkey's Layout File value. Any value that is not a standard kbd*.dll shipped in System32 — or that resolves to a file outside System32 — is suspect. Compare against a known-clean gold image.
• winlogon.exe loaded modules: on a suspect host, list modules loaded by winlogon.exe (e.g. Sysinternals listdlls winlogon.exe) and flag any DLL outside System32/SysWOW64, any unsigned module, or names a.dll/kbdus1.dll/msyun.dll.
• Kernel driver inventory: enumerate loaded drivers and System32\drivers\*.sys; flag srt64.sys, and more broadly any driver with a 2013-era compile timestamp that is unknown to your baseline.
• Winlogon\Notify: review HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify for unexpected DLL registrations (legacy notification-provider persistence).
• Compile-timestamp sweep: Both samples show early-2013 timestamps. A modern host carrying a 2013-stamped driver/DLL in a system path is a strong anomaly worth manual review.

IOA-1 · Non-standard module load in winlogon.exe

Rule Group: Logon Integrity · Type: Image Load (or Process, with module context) · Action: Detect first · Severity: Critical · MITRE: T1547.004

• Parent / Process Image Filename: .*\\winlogon\.exe$
• Loaded module / Image Filename: .*\\(a|kbdus1|msyun)\.dll$ (PCRE)
• Description: winlogon.exe loading a DLL whose basename matches a known Stupig keyboard-layout module. Pre-auth SYSTEM execution vector.
• FP tuning: allowlist legitimate kbd*.dll in System32 and known credential-provider modules; validate on a canary group before promoting to Block.

IOA-2 · Kernel driver srt64.sys

Rule Group: Rootkit Defense · Type: File / Driver · Action: Detect → Block after validation · Severity: Critical · MITRE: T1014

• Image Filename: .*\\srt64\.sys$
• Description: Presence/load of the Daxin rootkit driver. Non-standard driver name; safe to block once confirmed absent from baseline.

1. Telemetry ready: confirm module-load (ImageHash), file-write (PeFileWritten), and registry (AsepValueUpdate) events are flowing from Windows endpoints. Driver-load coverage varies by sensor policy — verify.
2. Benign baseline: run Q4/Q5/Q6 across a known-clean fleet window first; record the legit winlogon modules, keyboard-layout writes, and routine driver writes so real hits stand out.
3. Positive test (isolated host only, benign payload): on a canary VM, register a harmless custom keyboard layout pointing to a benign test DLL outside System32 and confirm Q4/Q5 surface it. Never use the real samples.
4. Promotion: keep behavioral queries (Q1,Q4,Q5,Q6) in Detect for 14+ days and measure FP rate before any Block. Hash IOCs (Q2) and srt64.sys/named-module rules may go to Prevent immediately given high-confidence attribution.

1 · Enumerate keyboard-layout DLLs fleet-wide (PowerShell, read-only)

# List every registered keyboard layout and its Layout File; flag non-standard DLLs.
$base = 'HKLM:\SYSTEM\CurrentControlSet\Control\Keyboard Layouts'
Get-ChildItem $base | ForEach-Object {
  $lf = (Get-ItemProperty $_.PSPath -Name 'Layout File' -ErrorAction SilentlyContinue).'Layout File'
  if ($lf -and $lf -notmatch '^kbd.*\.dll$') {
    [pscustomobject]@{ Key = $_.PSChildName; LayoutFile = $lf }   # review any hit
  }
}

2 · Check winlogon module set and for srt64.sys (read-only)

# Modules loaded by winlogon.exe (needs Sysinternals listdlls or use Get-Process modules):
Get-Process winlogon | ForEach-Object { $_.Modules } |
  Where-Object { $_.FileName -notmatch '\\System32\\|\\SysWOW64\\' } |
  Select-Object ModuleName, FileName

# Daxin driver presence:
Test-Path "$env:SystemRoot\System32\drivers\srt64.sys"
Get-ChildItem "$env:SystemRoot\System32\drivers\*.sys" |
  Where-Object { $_.Name -eq 'srt64.sys' } | Select-Object FullName, CreationTime

3 · Enable Microsoft Vulnerable Driver Blocklist + HVCI

# Vulnerable-driver blocklist (Win 11 22H2+ has it on by default; enforce via registry):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable /t REG_DWORD /d 1 /f
# HVCI / Memory Integrity:
# HVCI needs VBS enabled as well -- the scenario key alone is inert and the
# control silently never activates. All three values are required.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 1 /f
# Prereqs: UEFI + Secure Boot + virtualization extensions. Reboot required.
# PILOT FIRST -- incompatible legacy drivers can block boot under HVCI.
# Verify AFTER reboot (SecurityServicesRunning must contain 2):
#   (Get-CimInstance Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning
# Rollback: set both DeviceGuard values and the scenario Enabled back to 0, then reboot.
#   If the host will not boot, revert from Safe Mode or WinRE.
# Reboot required. Validate driver compatibility on a pilot group first.

Priority gaps: The pre-login command execution itself raises no logon audit event, so detection depends entirely on catching the loaded module (Q1) — keep that query healthy. Daxin's passive C2 has no reliable endpoint/network signature; coverage is via driver presence (Q3) plus the hypothesis that network silence is not proof of cleanliness. Initial access (T1190) is off the endpoint sensor — close it through hardening (retire EOL JDK / Digiwin SSO). Validation gates: all behavioral queries must clear a benign baseline and a canary positive test before Detect→Block promotion (s11).