TASK # STOMP: Backdoor on Windows uses VBScript and PowerShell to exfilter documents and credentials

Security investigators have detailed a new campaign, identified as TASK # STOMP, which uses VBScript and PowerShell to install a backdoor that collects and exfilters business documents, credentials and other sensitive data from Windows computers. According to the technical report shared by Securonix researchers and disseminated by specialized media, the operation combines several "living-off-the-land" persistence and execution techniques (use of native Windows tools) to make detection and forensic investigation difficult.

Confirmed facts: sample analyses document a VBScript file run by wscript.exe (an example named in the report as "95c9050t66.vbs") that creates programmed tasks with names designed to look like legitimate processes (e.g., Local Creative Manager, Network Audio Service) and also places a second script in the Start folder ("msdiag.vbs") as a backup method. That VBScript launches two hidden PowerShell modules: one called sys _ leader.ps1 that decodifies a file "diag _ pack.dat" and starts the functionality of document theft, screenshots, Wi-Fi passwords and clipboard content; and another, win _ conn.ps1, which decodifies "win _ conn _ cfg.dat" and establishes a persistent command and control channel (C2). Both modules communicate with the same C2 infrastructure (reported domains: corecloudfileshare [.] xyz and attachmentshareingdrive [.] xyz) and monitor each other so that, if one fails, the other reinitiates it. The use of timestomping techniques, hidden execution and evidence-cleaning steps was also observed, in addition to a final action that opens Google Chrome to an Iranian bid site (iritenders [.] com) and launches a batch file ("purge.bat") whose content was not recovered.

Estimated or unconfirmed information: the exact initial access vector is not publicly established; researchers point out that it could have been phishing by mail or social engineering, but that part remains to be confirmed. The intention behind opening the Iranian bid site is not known and could be due to screen / obfusation tests, user distraction or a specific undocumented target. The content of "purge.bat" is also not available, so its exact function (fingerprinting, removal of local artifacts, etc.) is speculative.

Technically, TASK # STOMP exploits the administrative flexibility of Windows: wscript.exe to run VBScript, Task Scheduler for persistence with names that simulate valid services, the Start folder as a backup method and PowerShell to deploy advanced collection and control capabilities. The use of coded DAT files that are decoded and executed in memory, the possible dynamic compilation via .NET / C #, and functional separation in different processes (one focused on collection and the other on communications) give redundancy and resistance: killing a process does not eliminate the other branch and the mutual watch mechanism facilitates the automatic recovery of interrupted components.

Who's it to? Mainly Windows equipment that allows VBS / PowerShell scripts to run without restrictions, especially in environments where the user has sufficient privileges, or where there is no running control of scripts or outgoing traffic visibility. Organizations with weak macro- and scripts policies, lack of EDR or without monitoring techniques (PowerShell Logging, Sysmon, scheduled task registration) are at greater risk. Since the campaign uses public domain for C2 and techniques that mix malicious activity with legitimate administrative actions, it is also likely to go unnoticed in networks with limited supervision.

Practical consequences: the presence of this backdoor allows you to exfilter corporate documents and metadata, capture local credentials and stored Wi-Fi passwords, steal the contents of the clipboard (risk for copied passwords), take screenshots and receive / execute arbitrary commands from the remote actor. This opens the door to continuous engagement, corporate espionage, lateral movement and use of endpoint to pivote within the network. In addition, avoidance techniques (timstomping, cleaning, misleading names) increase the complexity of forensic response and recovery.

What should the reader do now (concrete and immediate measures): 1) Detecting indicators and artifacts: review suspicious scheduled tasks with Get-ScheduledTask or the Task Viewer, check entries in the User's Start folder, search for files and scripts indicated (names reported as 95c9050t66.vbs, msdiag.vbs, sys _ loder.ps1, win _ conn.ps1, diag _ pack.dat, win _ conn _ cfg.dat, purge.bat) and run regiments of wscript.exe or PowerShell hidden processes. Check outgoing connections to the reported domains and any DNS resolution or HTTP / S traffic to those names. 2) Contain and collect evidence: if you detect engagement, isolate network equipment, preserve memory and disk overflow for analysis (non-formatting), and collect PowerShell, Sysmon and Security / Application login. (3) Remediate: remove malicious tasks and persistence files, change potentially compromised local and service credentials (including Wi-Fi passwords), force the restoration of authenticated sessions and apply MFA where appropriate. (4) Strengthening prevention: Disable Windows Script Host if not needed (see Microsoft guide), limit PowerShell execution by running restriction policies, activate the PowerShell Block Logging and Module Logging Script, and adopt application lock (AppLocker / Windows Defender Application Control). Block or monitor with priority the IP domains and addresses associated with firewall and proxy systems.

For defenders and admins: implement detection rules aimed at observed TTP (running wscript from user routes, creating programmed tasks with names that mimic services, PowerShell processes that run memory decoding, communications with unusual domains). Use advanced telemetry (Sysmon, EDR) to correlate process creation, decoded .dat file creation and persistent network sessions. See technical references on persistence and living-off-the-land techniques under MITRE ATT & CK to adjust detection: https: / / attack.mitre.org / techniques / T1218 / and https: / / attack.mitre.org / techniques / T1053 /.

Recommended resources and readings: to understand and mitigate risks related to PowerShell and scripts on Windows, Microsoft official documentation on PowerShell and security measures is a good starting point: https: / / learn.microsoft.com / powershell /. Securonix analysis and media coverage expand case details and can be consulted for IOCs and specific observables; specialized media such as The Hacker News have published summaries: https: / / thehackernews.com /.

Limitations and next steps: while the analyzed artifacts and C2 domains are reported, they remain untold about the initial vector, the real reach (if there are related campaigns) and the motivation behind such elements as the opening of the Iranian bidding site. Organizations that identify similar activity should share indicators with their CSIRT and intelligence providers to help identify more samples and contain them at the sectoral level.

In short, TASK # STOMP does not introduce a radically new technique, but it is an operational reminder: attackers continue to take advantage of native Windows components and combine redundancy and mutual monitoring between modules to maintain persistent access. Effective defense requires visibility in endpoints, scripts execution control, credentials rotation and a response prepared to preserve evidence and cut exfiltration channels.