Skip to content
Persistenceintermediate

Screensaver Hijack

Malware repoints the screensaver registry values at a malicious .scr executable so Windows launches the payload after a period of user inactivity.

A Windows screensaver (.scr) is simply a Portable Executable that the system runs when the user has been idle for a configured number of seconds. Because the OS launches the configured .scr automatically and the file is an ordinary PE, an attacker can repoint the screensaver settings at a malicious binary and gain idle-triggered, low-noise persistence without creating a Run key or scheduled task.

The behaviour is driven by a handful of per-user values under the desktop policy in the registry: a master enable flag, a timeout, and the path to the executable to launch. Setting these to point at a dropped payload means the malware fires every time the workstation is left unattended — a trigger that blends in with normal user behaviour and is rarely on a defender's checklist.

How it works

The screensaver is controlled by values under the per-user Desktop key:

text
HKCU\Control Panel\Desktop
  ScreenSaveActive = "1"          screensaver enabled
  ScreenSaveTimeOut = "60"        idle seconds before launch
  SCRNSAVE.EXE = "C:\Users\Public\evil.scr"   payload to run

A dropper writes these three values, pointing SCRNSAVE.EXE at its own renamed PE. Because the path can be any executable renamed with a .scr extension (or a genuine .scr PE), the malware runs in the user's context after the idle timeout elapses. Attackers keep the file in a user-writable directory (%AppData%, %Public%) and pick a short timeout so the payload re-launches frequently while the host sits idle.

Detection & analysis

Static analysis:

  • Triage with Autoruns (Sysinternals): the screensaver entry is enumerated and flagged if the target is unsigned or sits outside %SystemRoot%. The default scrnsave.scr and shipped screensavers live in System32/SysWOW64; anything pointing elsewhere is suspicious.
  • Offline, parse NTUSER.DAT with RegRipper or Registry Explorer and read Control Panel\Desktop: a SCRNSAVE.EXE value in %AppData%/%Temp%/%Public%, with ScreenSaveActive=1 and a short ScreenSaveTimeOut, is the core indicator. The value's last-write time dates the change.
  • Examine the referenced .scr itself: a .scr that is not a clean GUI screensaver — networking imports, packed sections, no screensaver resource — is the payload.

Dynamic analysis:

  • Run the sample under Procmon filtered on Operation is RegSetValue and Path contains Control Panel\Desktop to capture the write of SCRNSAVE.EXE. Sysmon Event ID 13 records the value set with the writing process image.
  • Force the trigger in a sandbox by idling past the timeout (or invoking the .scr directly); watch Sysmon Event ID 1 for the screensaver process launching the real payload, often spawned by winlogon.exe/scrnsave.

Detection rule hint:

Alert on writes to HKCU\Control Panel\Desktop\SCRNSAVE.EXE whose data points outside %SystemRoot%\System32/SysWOW64, and on a process launching a .scr from a user-writable directory. Correlate the SCRNSAVE.EXE value set (Sysmon 13) with ScreenSaveActive=1 and a low timeout written by the same non-installer process.

Votes

Comments(0)