Cybersecurity
TASK#STOMP uses PowerShell to steal files and credentials
Securonix said a campaign it named TASK#STOMP used VBScript and PowerShell stages to persist on Windows hosts, collect sensitive data and maintain two command-and-control channels.
- Securonix researchers Akshay Gaikwad and Aaron Beardslee said they had documented a campaign they named TASK#STOMP in a report shared with The Hacker News.
- They said the malware used VBScript and PowerShell stages to collect documents, Wi‑Fi passwords, clipboard contents and screenshots, and to run remote commands through two token-authenticated command-and-control servers.
- The first stage used wscript.exe to run an encoded file called 95c9050t66.vbs from the victim's desktop; the initial delivery method was unclear, though the researchers said phishing or social engineering were possible.
- The final stage opened Google Chrome to irantenders[.]com and launched purge.bat, but the purpose of those actions was not known.
Securonix researchers Akshay Gaikwad and Aaron Beardslee said they had documented a campaign they named TASK#STOMP in a report shared with The Hacker News. They said it used a PowerShell backdoor to collect documents, Wi‑Fi passwords, clipboard contents and screenshots, and to accept remote commands.
The first stage used wscript.exe to run an encoded file called 95c9050t66.vbs from the victim's desktop. The initial route into the system was not clear, although the researchers said phishing or social engineering were possible.
The VBScript set up persistence through scheduled tasks and through a Startup-folder script called msdiag.vbs, and later PowerShell commands tried to keep only one active session. The researchers also said the actors changed timestamps, hid execution and performed cleanup steps.
sys_loader.ps1 decoded diag_pack.dat and handled the document-stealing and monitoring functions, while win_conn.ps1 decoded win_conn_cfg.dat and set up a second command-and-control channel. Both modules used the same infrastructure and could restart one another if one stopped.
At the end, the orchestrator opened Google Chrome to irantenders[.]com and ran purge.bat, but the reason for those actions was not known. The contents of purge.bat had not been recovered.
Named in this story
People
- Akshay Gaikwad
- co-authored the report
- Aaron Beardslee
- co-authored the report
Companies
- Securonix
- issued the report on the campaign
Products and systems
- TASK#STOMP
- was the name the researchers gave the campaign
- wscript.exe
- ran the first scripted stage
- 95c9050t66.vbs
- was the encoded VBScript file placed on the desktop
- Task Scheduler
- was used to help maintain persistence
- msdiag.vbs
- was launched from the Startup folder as a backup payload
- sys_loader.ps1
- decoded diag_pack.dat and ran the document-stealing stage
- win_conn.ps1
- decoded win_conn_cfg.dat and set up a second C2 channel
- diag_pack.dat
- was decoded by sys_loader.ps1
- win_conn_cfg.dat
- was decoded by win_conn.ps1
- Google Chrome
- was opened in the final stage
- purge.bat
- was launched near the end for unknown purposes
How the source tells it
The piece is mostly technical reporting, with a mild stealth-and-evasion framing built from repeated concealment language.
- stealth the article repeatedly stressed hiding, persistence and under-the-radar execution