DEV Community

kozhevniko
kozhevniko

Posted on

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

#malware #windows #persistence #detection

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

Securonix published an analysis of TASK#STOMP, a Windows backdoor that uses only components already present on the host. The payload is PowerShell, persistence comes from scheduled tasks and the Startup folder, and collection targets documents, clipboard contents, screenshots and saved Wi-Fi passwords. The design goal is long-term espionage rather than immediate disruption.

The infection chain

The observed chain begins with a randomly named VBS file in a user-writable path, for example 95c9050t66.vbs. Securonix has not confirmed how it arrives, and the available evidence cannot separate phishing, a browser download, removable media, remote access or archive extraction.
Once started, the script creates persistence in several places at once. Four scheduled tasks are defined by XML files stored under AppData, named task.xml, task2.xml, task3.xml and task4.xml, and the task names rotate to resemble Windows services. A copy of the script, msdiag.vbs, is dropped into the Startup folder. The loader terminates earlier instances, sets several file timestamps to 15 January 2024, then launches PowerShell with a hidden window and execution policy bypass parameters.

Collection and command and control

The core module walks every fixed drive for Word, PDF, PowerPoint and Excel files plus archives. Documents that are recent take priority, and files larger than 500 MB are skipped. A file monitor keeps watching for new or modified files, so later edits are collected as well. The module also runs the Windows netsh wlan command to enumerate stored wireless profiles and recover Wi-Fi passwords held in plaintext.
The operator can copy clipboard contents, send them out and then clear the clipboard, and can request screenshots of the primary display. System and network details are collected for registration with the command and control server. Work is split across two independent PowerShell branches, and the corresponding servers support failover, so killing one process or losing one network path does not end access. The malware presents a Chrome-like user agent, compiles small C# helpers with the system compiler csc.exe, and accepts invalid TLS certificates.

Indicators

Type Value
C2 domain corecloudfileshare[.]xyz
C2 domain attachmentsharingdrive[.]xyz
File sys_loader.ps1
File diag_pack.dat
File win_conn.ps1
File win_conn_cfg.dat
File purge.bat

The published hash values for these files were truncated in the source material and are not reproduced here.

Detection and response

Script block logging, AMSI records, scheduled task logs and endpoint file events together preserve the commands and temporary files needed to rebuild the chain. Detection should key on behaviour rather than names: a Windows Script Host process creating a scheduled task from AppData, followed by hidden PowerShell and a compiler invocation, is the pattern worth alerting on.
Response needs to be coordinated: preserve the task XML files and the dropped artefacts, stop the running VBS and PowerShell processes, remove every malicious task and startup entry, block the infrastructure, then reboot and confirm that nothing reconnects. Removing one script or one task leaves the remaining components able to rebuild the chain.

References

Top comments (0)