Investigation: Screensaver Hijack via SCRNSAVE.EXE to Suspicious Path

1. Confirm the alert

   Detects the per-user Control Panel Desktop SCRNSAVE.EXE value being pointed at an executable in a user-writable location or a script host. Windows launches the configured screensaver under the logged-on user after the idle timeout, giving low-noise persistence; legitimate screensavers are signed .scr binaries in System32. The rule matched on logsource `registry_set`. Verify the event genuinely matches the described behavior, and not a known legitimate case. The rule matches on these fields — examine the exact value in the event:

   • **TargetObject** contains: `\Control Panel\Desktop\SCRNSAVE.EXE`
   • **Details** contains: `/AppData/`, `/ProgramData/`, `/Temp/`, `/Users/Public/` …

2. Pivot: find the origin and context

   Investigation queries (read-only):

   • Which process wrote the registry key (correlate process_creation, same host/time)
   • Is the value pushed by GPO to other endpoints? (fleet scope)

3. Analyze (D3FEND countermeasures)

   Relevant defensive analysis techniques (MITRE D3FEND), to apply where the telemetry is available:

   • Dynamic Analysis
   • Emulated File Analysis

4. Rule out false positives

   Known benign causes for this rule:

   • Third-party screensaver packages that install a .scr into a per-user path; allowlist the specific signed vendor file.

5. Context (threat intelligence)

   The rule's references — CTI context to qualify the incident:

   • https://attack.mitre.org/techniques/T1546/002/