Securonix recently published research on TASK#STOMP, a Windows intrusion framework that combines VBScript, PowerShell, scheduled tasks, and runtime C# compilation to steal business documents and maintain persistent remote access. The attack is clever — it uses legitimate Windows components, creates fake task names that look like system services, and even timestamps its artifacts to appear two years old.
None of that matters if the payload never lands on disk.
The Attack Depends on Writing Scripts to Disk
TASK#STOMP begins with a VBScript installer that writes multiple files to %LOCALAPPDATA%\WinDefendSvc:
- msdiag.vbs (startup persistence script)
- diag_pack.dat (encoded PowerShell backdoor)
- win_conn_cfg.dat (encoded secondary C2 channel)
- sys_loader.ps1 and win_conn.ps1 (PowerShell loaders)
It also writes four XML files defining scheduled tasks with names designed to look legitimate: “Local Credential Manager,” “Network Audio Service,” “Windows Display Manager,” and “Device Credential Handler.”
Once these files exist on disk, the malware creates scheduled tasks, copies msdiag.vbs to the Startup folder, launches hidden PowerShell processes, and begins searching fixed drives for business documents — .doc, .docx, .pdf, .xls, .xlsx, .zip, .rar, and .7z files created or modified in the past year.
The document theft is automated. The malware reads matching files, uploads them via HTTP POST, and registers a FileSystemWatcher to catch newly created documents in real time. It also steals Wi-Fi passwords, clipboard contents, and screenshots.
The entire execution chain depends on one thing: writing executable scripts to a user-writable directory.
FileSure Blocks the Payload Write Before Execution
FileSure Defend operates at the Windows kernel level via a filter driver. It intercepts file operations — open, read, write, delete, create, rename — before they complete.
A rule blocking script interpreters from writing to user-writable directories would stop TASK#STOMP at the initial installation phase:
File name filter: *.vbs;*.ps1;*.dat;*.xml
Program name filter: \wscript.exe;\powershell.exe;\cscript.exe
Operations: Write, Create
Drive type: Fixed Drive
Path filter: %LOCALAPPDATA% and subdirectories
Result: The installer cannot write msdiag.vbs, the .dat payloads, the .ps1 loaders, or the task XML files. The attack stops before any persistence mechanism is created.
No payload on disk means no execution. No execution means no scheduled tasks, no Startup folder persistence, no document theft, no C2 channel.
The malware tries to evade detection by using randomized filenames, hiding in user-accessible directories, and modifying LastWriteTime timestamps to January 2024. None of that helps if the write operation is denied at the kernel level.
Even If the Payload Lands, Document Exfiltration Can Be Blocked
Suppose the initial payload somehow bypassed the write block — maybe it was delivered via a different mechanism or an authorized program was tricked into writing it.
FileSure can still stop the document theft phase.
TASK#STOMP searches fixed drives for business documents and reads them for exfiltration. Reading a file is a file system operation. A second rule blocking unauthorized programs from reading business document extensions would deny the malware access to the files it’s trying to steal:
File name filter: *.doc;*.docx;*.pdf;*.xls;*.xlsx;*.ppt;*.pptx;*.zip;*.rar;*.7z
Program name filter: \powershell.exe (or any program not explicitly authorized)
Operations: Read
Drive type: Fixed Drive
Result: The malware cannot read business documents. The exfiltration phase fails. The FileSystemWatcher triggers on new file creation, but the subsequent read operation is blocked.
This is defense in depth at the file system level. The first rule prevents payload installation. The second rule prevents data theft even if the payload somehow executes.
Why This Works Against Zero-Day Malware
TASK#STOMP could be replaced tomorrow with a completely new malware variant — different filenames, different task names, different C# helpers, different C2 protocol.
Doesn’t matter.
If the new malware writes scripts to disk, FileSure blocks it. If it reads business documents for exfiltration, FileSure blocks it. The defense isn’t based on recognizing TASK#STOMP specifically. It’s based on controlling what programs are allowed to do to files.
Signature-based detection requires seeing the threat first, analyzing it, creating a signature, and pushing an update. That process takes time. The window between a new malware release and when your antivirus can detect it is when attacks happen.
FileSure doesn’t play that game. It controls file operations, not threat recognition.
Ready to stop the next TASK#STOMP before it starts? FileSure Defend gives you kernel-level file system control on every Windows endpoint. Start your free trial at bystorm.com.
Category: Threat Intelligence
Tags: task#stomp, powershell backdoor, document exfiltration, scheduled task persistence, kernel filter driver, file system security, data loss prevention
