Security2 publishers3 min readPublished
TASK#STOMP plants five persistence footholds from a single desktop VBScript
Securonix pulled four scheduled tasks and a Startup folder copy out of one infected machine, and the two PowerShell modules restart each other. Delete the desktop script and the backdoor keeps collecting documents.
The Watch · Security desk
What happened
- Securonix took apart TASK#STOMP, a Windows backdoor that searches a victim's drives for business documents, uploads them to attacker servers, then stays resident to grab each new or edited file.
- The chain starts with wscript.exe running an encoded VBScript staged on the user's desktop, 95c9050t66.vbs, under a random name Securonix suspects was chosen to beat filename-based detection.
- That script installs at least five footholds, four scheduled tasks plus a copy of itself in the Startup folder, and Securonix warns that removing only one may leave the others able to rebuild the infection.
- The analysis comes from a single infected machine, so Securonix cannot say how many organizations are affected.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- decision A responder who kills the noisy scheduled task and closes the ticket has not evicted anything. The host is only clean when all five anchors and the WinDefendSvc folder are gone and both PowerShell processes are dead.
- constraint Nobody outside Securonix can scope this yet, and Securonix cannot either without domain registration history or a second victim, so defenders get indicators to hunt and no sense of how widely it has spread.
- contradiction The one indicator that looks like targeting is the one Securonix says to leave alone: it publishes the irantenders[.]com URL while warning against blocking the domain.
- capability Because the operation runs on wscript.exe, PowerShell and Task Scheduler, controls keyed to unsigned executables never fire, and the detection has to sit on script host launches and task creation.
The four scheduled tasks are named Local Credential Manager, Network Audio Service, Windows Display Manager and Device Credential Handler [5]. The malware's files sit in a folder called WinDefendSvc, named to look like a Windows Defender service [7]. Backup persistence is a second script, msdiag.vbs, dropped into the Startup folder and launched at every logon [6]. That copy survives deletion of the desktop script [8]. Remove one scheduled task and four anchors are still in place [9].
Collection and command run as separate processes. sys_loader.ps1 decodes diag_pack.dat and starts the payload that takes system metadata, business documents, Wi-Fi passwords and clipboard contents, watches for newly modified files, captures screenshots and executes arbitrary PowerShell [10]. win_conn.ps1 decodes win_conn_cfg.dat and holds a second persistent channel with its own command execution and collection [11]. Both talk to corecloudfileshare[.]xyz or attachmentsharingdrive[.]xyz [13]. "Running the modules as separate processes provides functional separation and operational redundancy: failure or termination of one branch does not immediately remove the other," Securonix said [12].
The redundancy is not quite as built. diag_pack.dat checks whether win_conn.ps1 is running and restarts it if not, and win_conn.ps1 does the same for its partner [14]. Securonix found the same bug in both modules, and part of that watchdog logic is largely unreachable [15]. The two modules also carry nearly identical code for skipping security-certificate checks [16]. "It points to a competent-but-not-elite operator," Beardslee said [17].
One infected machine is the whole dataset [2]. Dating the campaign would take registration and DNS history for the two command-server domains, or access to other infected hosts [24]. Several of the malware's own files are backdated to January 15, 2024, and Beardslee said "that date is fabricated by the attacker to mislead file-timeline review, not evidence of when the real campaign began" [23].
On the operator, Beardslee said "nothing in the sample's code, infrastructure, or TTPs overlaps cleanly with a known APT's established toolkit, so we're not making an attribution claim" [18]. He takes the order in which the malware works through file types, Word first, then PDF, PowerPoint and Excel, ahead of archives, as something that "points to corporate-document espionage rather than opportunistic crimeware" [19]. The last thing the VBScript does is open Chrome, maximized, at a URL on irantenders[.]com, a searchable database of tenders and contracts issued by Iranian government departments and local authorities. Securonix does not know why [21]. It does not treat the site as malicious and warns against blocking the whole domain without more evidence [20]. Beardslee said "a single decoy domain isn't enough to confirm sector or regional targeting on its own" [22].
Delivery is unconfirmed. "We couldn't confirm the delivery vector directly from what was recovered," Beardslee said. His estimate, drawn from how comparable VBS-loader campaigns arrive, is a phishing email carrying a ZIP or ISO/IMG attachment with the script inside [25]. His controls sit ahead of that point: block or alert when Windows Script Host runs files from Desktop, Downloads or Temp, and restrict Windows Script Host for standard users or allow only signed scripts. At the mail gateway, strip, sandbox or block ISO, IMG and VBS attachments [26]. For hunting after the fact, the advisory lists the command-server domains, the authentication token and the file hashes, and the token shows up only for shops that inspect encrypted web traffic [27].
What to watch
- Registration and DNS history for corecloudfileshare[.]xyz and attachmentsharingdrive[.]xyz, which Securonix says it needs to date the campaign.
- A second infected host, which would test whether the IranTenders decoy indicates sector targeting or is noise.
- Recovery of purge.bat, whose contents Securonix did not obtain, to show what traces the operator erases.