TASK#STOMP Turns New Business Documents Into a Collection Target

The research describes one analysed Windows execution chain. It does not establish how the first VBScript reached the machine, which organisation was affected, how widely the malware was deployed or who operated it.

Four tasks and a Startup copy keep the chain alive

The observed chain begins with a desktop VBScript. It stages files under %LOCALAPPDATA%\WinDefendSvc, a user-writable directory named to resemble a Windows security service. The installer registers four scheduled tasks from XML definitions and also places msdiag.vbs in the user’s Startup folder.

Those persistence paths overlap. The Startup script can register the tasks again, stop existing loader processes, restore modified timestamps and relaunch the two PowerShell branches. Removing one task or process can leave other persistence paths available to restore execution.

Five files were assigned the same false modification time, 15 January 2024 at 08:30. The PowerShell modules run hidden and invoke the legitimate .NET compiler, including csc.exe, to build C# helpers at runtime. That behaviour gives defenders a useful correlation point: hidden PowerShell from an AppData staging directory spawning a compiler and then making external connections.

The first document scan becomes continuous collection

The decoded payload searched fixed drives for Word, PDF, PowerPoint, Excel and archive files created or changed during the previous 365 days. It excluded system and staging paths, skipped very large files and tracked uploaded material to reduce duplicates.

A file-system watcher then monitored for newly created or changed documents. That turns a one-time theft into continuous collection. Separate functions extracted saved Wi-Fi keys, read clipboard text, captured screenshots, gathered host details and ran arbitrary PowerShell commands received from the operator.

The two modules used redundant command servers and one static authentication token. Their runtime C# helpers disabled TLS certificate validation, so an invalid or self-signed certificate would not stop the connection. Securonix did not attribute the activity to a known group, and the observed payload behaviour alone does not prove which data was successfully taken from a real victim.

The reported restart logic also has a defect: a counter is reset before a second check uses it, leaving that secondary mutual-restart path normally unreachable. The primary restart check still works, and the scheduled tasks and Startup copy provide separate persistence. Responders should verify which path actually ran instead of assuming every restart mechanism succeeded.

Detection depends on joining ordinary Windows events

• Review Security Event ID 4698 and Task Scheduler Operational logs for tasks registered from XML in user-writable directories.
• Collect PowerShell Script Block Logging, including Event ID 4104, and AMSI telemetry for decoded script and embedded C# content.
• Alert when hidden PowerShell launched from AppData spawns csc.exe or cvtres.exe.
• Correlate those processes with Startup-folder scripts, repeated task creation, timestamp changes, netsh requests for clear-text Wi-Fi keys and outbound command traffic.
• For a suspected infection, isolate the host and preserve the task XML, staged files and relevant logs before remediation. Terminate the active script processes and remove every scheduled task, Startup copy and staged module together. Rotate exposed credentials from a clean device, check for further payloads, and verify after reboot that no component returns.

None of those events is malicious on its own. The stronger signal is the sequence: user-writable script staging, redundant persistence, hidden PowerShell, runtime compilation, document access and network activity from the same host. Execution-policy bypass is not privilege elevation, and the campaign does not depend on a newly identified Windows vulnerability.

Source

• Securonix TASK#STOMP technical analysis, published 21 September 2026.