Securonix Threat Research has detailed a Windows-based intrusion framework dubbed TASK#STOMP, which combines VBScript, PowerShell, Task Scheduler and runtime C# compilation to establish persistent access and steal business documents.
The investigation began with a script-driven execution chain that created multiple persistence mechanisms beneath %LOCALAPPDATA%WinDefendSvc. The framework creates four scheduled tasks from XML definitions, places msdiag.vbs in the Windows Startup folder, terminates existing payload processes, modifies file timestamps, launches two hidden PowerShell modules and uses the legitimate .NET compiler to compile C# code at runtime.
Subsequent analysis of the payloads revealed that TASK#STOMP is more than a persistence mechanism. Securonix confirmed a fully operational PowerShell backdoor capable of automated business-document collection and exfiltration, real-time filesystem monitoring, Wi-Fi password theft, clipboard collection, screenshot capture and arbitrary remote-command execution. The malware maintains two redundant, token-authenticated command-and-control channels to improve operational resilience.
A Multi-Stage Windows Execution Chain
TASK#STOMP illustrates how threat actors can combine legitimate Windows components to make malicious activity blend into normal administrative operations.
The initial execution begins with a randomly named VBScript launched through Windows Script Host. The script functions as the primary installer and orchestrator, controlling subsequent persistence, process management, timestamp manipulation, payload execution, browser activity and cleanup.
The available telemetry does not establish how the initial VBScript reached the endpoint. Possible delivery mechanisms include phishing, browser downloads, removable media, remote access or archive extraction, but determining the actual initial-access vector requires additional forensic evidence such as the original VBS file, NTFS metadata, browser records, email telemetry and file-creation events.
The use of a randomized filename and a user-accessible location also creates an additional layer of concealment, potentially making filename-based detection less effective.
Rotating Scheduled Tasks Create Redundant Persistence
One of the central features of TASK#STOMP is its use of four XML-defined scheduled tasks.
The initial VBS script registers the tasks through schtasks.exe, using XML files stored under %LOCALAPPDATA%WinDefendSvc. The task names are designed to resemble legitimate Windows components, including:
- Local Credential Manager
- Network Audio Service
- Windows Display Manager
- Device Credential Handler
During later Startup-folder execution, the same XML files are reused with different names, including Network Session Agent, System Audio Controller, Host Session Broker and System Registry Handler.
This means the task name itself is not a reliable indicator of the underlying persistence mechanism. The XML definition contains the executable action, trigger, execution principal and other task settings, while the visible task name serves primarily as a camouflage layer.
Securonix notes that investigators should recover the original XML files and correlate them with Windows Security Event ID 4698 and Task Scheduler Operational logs to reconstruct the persistence activity.
Startup Folder Adds a Second Persistence Layer
TASK#STOMP does not rely exclusively on scheduled tasks.
The installer copies msdiag.vbs into the current user’s Startup folder. When the user signs in, Windows Script Host launches the VBS file, providing a persistence mechanism independent of the scheduled tasks.
The Startup-based script can repeat task registration, terminate existing payload instances, restore the altered timestamps and launch both PowerShell branches.
This redundancy allows the framework to reconstruct parts of its execution chain if one persistence mechanism is removed or becomes unavailable.
Telemetry also showed multiple background wscript.exe /B /Nologo executions. These may correspond to overlapping scheduled-task triggers, watchdog activity or other forms of re-entry, although process telemetry alone does not establish the precise cause.
Timestomping Conceals the Activity Timeline
TASK#STOMP also uses timestomping to complicate forensic investigations.
Five staged artifacts receive the same historical LastWriteTime:
- msdiag.vbs
- diag_pack.dat
- win_conn_cfg.dat
- sys_loader.ps1
- win_conn.ps1
The timestamp is set to January 15, 2024, at 08:30:00, more than two years before the observed 2026 execution.
Using the same historical timestamp across related files can make the artifacts appear to have existed on the system long before the intrusion. However, changing LastWriteTime does not necessarily remove other evidence of creation or execution.
Investigators can compare NTFS $STANDARD_INFORMATION and $FILE_NAME timestamps and correlate them with the USN Journal, MFT records, EDR telemetry, PowerShell logs and scheduled-task registration events.
Hidden PowerShell Modules Lead to Runtime C# Compilation
The framework launches two separate PowerShell modules:
- sys_loader.ps1
- win_conn.ps1
Both run with -NoProfile, -ExecutionPolicy Bypass and -WindowStyle Hidden.
The first module decodes and launches diag_pack.dat, which contains the primary document-theft, surveillance and remote-access functionality. The second decodes win_conn_cfg.dat and establishes a secondary C2 channel.
The separation gives the malware functional redundancy because termination of one process does not necessarily eliminate the other.
The two PowerShell processes also produce separate compiler chains involving csc.exe and cvtres.exe. Securonix’s payload analysis determined that these events originate from PowerShell’s Add-Type functionality.
The decoded modules contain small C# helper classes named SSLFix and SSLFix2. These helpers modify .NET networking behavior to enforce TLS 1.2 while accepting server certificates without normal validation.
As a result, the malware can continue communicating with its C2 infrastructure when certificates are invalid, self-signed, expired or otherwise mismatched.
TASK#STOMP Decodes Its Payloads In Memory
The two PowerShell loaders use a similar four-stage decoding process.
First, each loader reads its .dat file from the WinDefendSvc staging directory. It then Base64-decodes the contents, converts the resulting bytes into a UTF-8 PowerShell source string and creates an in-memory ScriptBlock for immediate execution.
Securonix characterizes this as an encoded-on-disk, memory-executed payload, rather than a completely fileless technique. The encoded .dat files remain on disk, but the decoded PowerShell source is not written to disk in plaintext.
This distinction is important for defenders because fileless detection terminology can obscure the artifacts that remain available for forensic investigation.
Document Theft Is a Core Capability
The decoded diag_pack.dat payload turns TASK#STOMP into a persistent document-collection platform.
The malware searches fixed drives for business-oriented file types, including:
.doc, .docx, .pdf, .ppt, .pptx, .xls, .xlsx, .zip, .rar and .7z.
Files are filtered according to age, size, location and whether they have already been processed. Documents created or modified within the previous 365 days are considered, with files larger than 500 MB excluded.
The payload prioritizes business documents ahead of archives and uploads collected files to attacker-controlled infrastructure through HTTP multipart POST requests.
Files under 10 MB can be uploaded directly, while larger files are compressed before transmission. Failed transfers are retried before being placed into a later queue.
The malware also registers a FileSystemWatcher across fixed drives. Newly created or modified files matching its target extensions can therefore be uploaded after the initial drive scan has completed.
This behavior transforms TASK#STOMP from a one-time document stealer into a continuous collection agent.
Remote Access and Credential Theft
The backdoor also provides operators with multiple surveillance and remote-access capabilities.
Both modules poll their C2 infrastructure for commands and can return command results to the servers. Built-in functionality includes:
- Screenshot capture
- Wi-Fi profile and password collection
- Clipboard collection
- System information gathering
- Document collection progress reporting
- Arbitrary PowerShell command execution
The Wi-Fi functionality uses Windows networking commands to retrieve saved wireless profiles and plaintext keys. Clipboard contents can be collected and subsequently cleared, while screenshots are temporarily saved, uploaded and removed.
The ability to execute arbitrary PowerShell commands provides an operator with capabilities beyond the malware’s predefined collection functions.
According to Securonix, this creates a potential path for additional malware deployment, credential theft or disruptive activity even though the observed payload is primarily oriented toward espionage and persistent collection.
Two C2 Channels Provide Redundancy
The two payloads communicate with the same attacker infrastructure through two separate domains:
- corecloudfileshare[.]xyz
- attachmentsharingdrive[.]xyz
The modules implement automatic failover, switching between the two servers when communication fails.
The secondary win_conn channel provides an always-on remote-access capability and overlaps with several functions available through the primary payload.
The two modules also contain watchdog functionality that can restart their paired module if it stops running. Securonix identified a logic defect in part of this mutual-watchdog mechanism, but the broader persistence framework remains independently supported by the scheduled tasks and Startup-folder launcher.
Browser Activity Remains Unconfirmed
Another component of the execution chain launches Google Chrome and opens a specific IranTenders URL.
Securonix cautions that the purpose of this browser activity cannot be established from process telemetry alone. It could function as a decoy, execution marker, campaign-related resource or access to a compromised website.
The research does not establish that the broader irantenders[.]com domain is controlled by the threat actor.
For investigators, the specific URL path is an indicator that can be correlated with browser history, cache data, DNS, proxy, TLS and endpoint network telemetry.
Detection Requires Behavioral Correlation
The research emphasizes that individual filenames, task names or directories may not provide sufficient detection coverage because TASK#STOMP deliberately changes or disguises several of these artifacts.
Instead, defenders can correlate the broader execution sequence:
WScript → XML-defined scheduled tasks → hidden PowerShell → Base64 payload decoding → runtime C# compilation → timestamp manipulation → Startup-folder execution → C2 communication.
High-value detection opportunities identified by Securonix include PowerShell reading .dat payloads from AppData, FromBase64String combined with ScriptBlock creation, PowerShell spawning csc.exe, hidden PowerShell using -ExecutionPolicy Bypass, suspicious LastWriteTime modification and outbound connections to the identified C2 infrastructure.
The research also maps the activity to multiple MITRE ATT&CK techniques spanning execution, persistence, defense evasion, collection, credential access, discovery, command and control and exfiltration.
Remediation Must Address Every Persistence Mechanism
Securonix recommends treating TASK#STOMP as a complete persistence framework rather than removing an individual process or scheduled task.
Incident responders should preserve the task XML files and WinDefendSvc directory for analysis before remediation, terminate active VBS and PowerShell processes, remove the Startup-folder copy and all scheduled tasks, eliminate staged payloads and cleanup artifacts, block the identified infrastructure and verify after reboot that the malicious components do not return.
The broader lesson from TASK#STOMP is that native Windows scripting and development utilities can be combined into a resilient intrusion framework whose full capabilities are not immediately visible from the process tree. The decoded payloads demonstrate that the activity extends from persistence and defense evasion into automated document exfiltration, continuous filesystem monitoring, credential collection, surveillance and arbitrary remote command execution.
For defenders, correlating these behaviors across endpoint, PowerShell, Task Scheduler, filesystem and network telemetry provides a more complete detection picture than relying on any single filename, task name or process.
For the complete technical analysis, indicators, findings, and detection recommendations, read the full Securonix report on TASK#STOMP: PowerShell Backdoor for Document Theft and Remote Access here
Join our LinkedIn group Information Security Community!
