TASK#STOMP: A Windows Backdoor That Lives in Scheduled Tasks and VBS

TASK#STOMP is a Windows backdoor that operates using only components that are already present on the host system. The malware is delivered as a PowerShell payload that is installed through scheduled tasks and the Startup folder. The primary goal of the malware is to establish long-term espionage capabilities, rather than causing immediate disruption to the infected system.

The infection chain typically begins with a randomly named VBS file located in a user-writable path. However, the exact method of how this VBS file arrives is not confirmed by Securonix, and it could potentially come from phishing emails, browser downloads, removable media, remote access, or archive extraction.

Once the VBS file is executed, it creates persistence in several locations at once. Four scheduled tasks are defined by XML files stored in the AppData directory, with names that rotate to resemble Windows services. Additionally, a copy of the msdiag.vbs script is dropped into the Startup folder. The loader then terminates any earlier instances of itself, sets specific file timestamps to January 15, 2024, and launches PowerShell with hidden window and execution policy bypass parameters.

The core module of the malware walks every fixed drive to locate Word, PDF, PowerPoint, and Excel files as well as archives. Recent files are given priority, and any files larger than 500 MB are skipped. A file monitor continuously watches for new or modified files to ensure that later edits are also collected. The module also utilizes the Windows netsh wlan command to enumerate stored wireless profiles and recover Wi-Fi passwords, which are held in plaintext.

The operator can control the malware by copying clipboard contents, sending them out, and then clearing the clipboard. They can also request screenshots of the primary display. System and network details are collected for registration with the command and control server. The malware spreads its operations across two independent PowerShell branches, with corresponding servers supporting failover. This means that if one process is killed or a network path is lost, the malware can still maintain access.

The malware utilizes a Chrome-like user agent, compiles small C# helpers using the system compiler (csc.exe), and accepts invalid TLS certificates. Indicators of compromise include the use of two specific C2 domains: corecloudfileshare.xyz and attachmentsharingdrive.xyz, as well as several file names such as sys_loader.ps1, diag_pack.dat, win_conn.ps1, win_conn_cfg.dat, and purge.bat. The published hash values for these files have been truncated in the source material and are not included here.

To effectively detect and respond to a TASK#STOMP infection, it is essential to focus on behavior rather than relying on specific file names. This involves monitoring Windows Script Host processes that create scheduled tasks originating from the AppData directory, followed by the appearance of hidden PowerShell processes and compiler invocations. Detecting this pattern can help alert security teams to the presence of the malware.

In response to a TASK#STOMP infection, coordinated action is necessary. This includes preserving the task XML files and dropped artefacts, stopping the running VBS and PowerShell processes, removing all malicious tasks and startup entries, blocking the associated infrastructure, and then rebooting the system to ensure that no remaining components can reconnect. It is important to note that removing just one script or task will not completely eliminate the threat, as the remaining components can still rebuild the chain.