TASK#STOMP -- VBS-to-PowerShell Windows Backdoor: Document Theft, Timestomping & Runtime C# Compilation

TASK#STOMP is a VBScript-to-PowerShell Windows backdoor documented by Securonix Threat Research (Akshay Gaikwad and Aaron Beardslee) on 2026-09-21. Its objective is continuous, unattended document theft -- Word, PDF, PowerPoint, Excel, and archives are harvested from every fixed drive, prioritized by type and recency -- combined with credential/clipboard theft, screenshot capture, and open-ended remote-command execution over two redundant, token-authenticated command-and-control servers.

The malware's single highest-value defensive angle is not any one filename or task name -- both rotate -- it is the behavioral spine of the install chain: wscript.exe decodes and runs a VBScript from a user-writable path, that script registers four scheduled tasks from XML definitions staged under a single non-standard %LOCALAPPDATA% folder, drops a Startup-folder re-execution copy, backdates five of its own artifacts to a single fixed historical timestamp, launches two hidden PowerShell modules, and compiles C# at runtime via the legitimate csc.exe. That sequence survives every rename the operator makes to task names, folder names, or script filenames, and none of it resembles normal user or admin activity when correlated end to end.

Securonix built this analysis from one infected machine and explicitly states it cannot say how many organizations are affected, and separately states it is not making an attribution claim -- "nothing in the sample's code, infrastructure, or TTPs overlaps cleanly with a known APT's established toolkit." The document-type priority order (Word → PDF → PowerPoint → Excel, ahead of archives) points to corporate-document espionage rather than opportunistic crimeware, and reused, buggy watchdog code across both PowerShell modules is read by Securonix as the signature of a "competent-but-not-elite," mid-tier operator rather than a mature APT.

Single-source limitation: every atomic indicator in this pack traces back to one Securonix write-up analyzing one infected host. Treat IOCs as high-fidelity for THIS sample but do not assume broad campaign infrastructure, scale, or attribution from them -- see §4 and §18.

Defender priority: hunt the chain wscript.exe → ScheduledTaskRegistered (x4, AppData-rooted) → hidden PowerShell → csc.exe under a WinDefendSvc-style folder in %LOCALAPPDATA%. This behavioral spine is mechanically detectable and survives every filename/task-name rotation the operator makes -- prioritize Q1, Q3, and Q6 (§8) over any single hash or domain block.

Sourcing constraint: Securonix is the sole independent primary source. The Hacker News, Help Net Security, and CyberPress are all derivative coverage of the same Securonix report -- none contributes an independent sample, hash, or infrastructure observation. This pack's confidence and the Falcon IOC-import CSV action column (§4, §10) are both scoped down to reflect that.

Research decisions carried into this pack

• Every atomic IOC in §10's Falcon IOC-management CSV ships as action=detect, never prevent, and severity is capped at high (never critical) -- directly because of the single-machine provenance stated above.
• irantenders[.]com is not shipped as a blockable indicator. Beardslee told Help Net Security the site itself is not treated as malicious and warned against blocking the whole domain on a single decoy-page observation -- see §4's non-atomic indicators note.
• Three additional MITRE techniques observed directly in the primary source but not called out in the original tasking brief -- T1016 (System Network Configuration Discovery, via netsh), T1070.004 (File Deletion, purge.bat), and T1059.003 (Windows Command Shell) -- are folded into §6 and §7 since Falcon endpoint telemetry does not cleanly isolate them into standalone CQL.

Attack chain

Hunt hypotheses

1. H1 (high): wscript.exe launching a .vbs file from Desktop/Downloads/Temp is a reliable initial-stage signal regardless of filename. → Q1.
2. H2 (high): A second wscript.exe → .vbs launch from the Startup folder on a later logon indicates re-execution persistence has already taken hold. → Q2.
3. H3 (high): Scheduled tasks that impersonate core Windows component names but resolve to an executable under a user's AppData\Local path are almost never legitimate. → Q3.
4. H4 (high): Any process activity rooted in an AppData folder named to impersonate a Defender/security service (WinDefendSvc-style) merits review even before other TTPs fire. → Q4.
5. H5 (medium): Hidden, Base64-encoded PowerShell that references a .dat file is a strong loader-stage signal once correlated with H3/H4. → Q5.
6. H6 (high): csc.exe spawned directly by powershell.exe is rare outside developer/build hosts and is the clearest single-event T1027.004 signal in this chain. → Q6.
7. H7 (medium): PowerShell invoking SetLastWriteTime is a generic but useful timestomping signal fleet-wide. → Q7.
8. H8 (high): The literal backdate value 2024-01-15 08:30:00 is a near-unique, high-confidence pivot once it appears alongside timestomping syntax. → Q8.
9. H9 (high): DNS resolution of either named C2 domain is a direct, low-noise network signal. → Q9.
10. H10 (medium): WMI enumeration/termination that references the loader's own module-name fragments indicates the self-replacement behavior in Stage 4. → Q10.

Confidence is capped at medium and action is fixed at detect for every atomic indicator below -- Securonix built this evidence from a single infected machine and explicitly cannot speak to prevalence. This table's Action column matches the Falcon IOC-management CSV in §10 exactly, row for row -- do not deploy any of these in prevent mode without independent corroboration.

Atomic indicators (importable -- matches §10 CSV exactly)

Non-atomic indicators (behavioral -- not Falcon IOC-manageable, hunt only)

These checks do not require Falcon and cover techniques (T1016, T1059.003, T1070.004, T1119, T1005, T1113, T1115, T1552.001) that endpoint process telemetry alone represents only partially. Use them to backstop §8's CQL queries, especially in estates with inconsistent sensor coverage.

1. Security Event 4698/4699/4702 (Task Created/Deleted/Updated): filter for the eight known camouflage task names in §4, independent of EDR. Requires "Audit Other Object Access Events" enabled.
2. Sysmon Event ID 11 (FileCreate): alert on file creation under %LOCALAPPDATA%\WinDefendSvc\ and the Startup folder for any user, regardless of the process that wrote it.
3. NTFS timestamp forensics: during IR triage, compare $STANDARD_INFORMATION vs $FILE_NAME timestamps in the MFT and review the USN Journal for the five artifacts. Securonix explicitly calls out that several scripts/data files under a user-writable path sharing the identical historical value 2024-01-15 08:30:00 is itself a high-confidence hunting pivot, independent of any live telemetry.
4. Wi-Fi credential theft (T1552.001, T1016): Security Event 4688 command-line auditing for netsh wlan show profile combined with key=clear, launched by a non-interactive parent (wscript.exe, powershell.exe, or cmd.exe) rather than an interactively-typed console session.
5. Proxy / web-gateway log review (T1071.001, T1016): search for the static X-Auth-Token value or any request to the nine listed API paths (§4) against ANY destination, not just the two known domains -- the token does not rotate per victim and is Securonix's strongest standalone network indicator. This is also the only practical way to catch the malware on hosts without endpoint telemetry.
6. Decoy-page correlation (context only, T1059.003): browser history / process-creation review for chrome.exe launched with the irantenders[.]com/tender/tot-delete-6e137de.php URL as a command-line argument. Use strictly to corroborate a host already flagged by Q1/Q3 -- see §4 for why the domain itself is not blocked.
7. Cleanup-script invocation (T1070.004): Security Event 4688 / Prefetch / AmCache review for any cmd.exe or powershell.exe command line ending in purge.bat. Contents of the script were never recovered by Securonix, so this hunts the invocation, not the payload.
8. Bulk document read/collection baseline (T1119, T1005): DLP/CASB or Falcon FileOpenInfo baseline for a single process performing high-volume sequential reads of .docx/.pdf/.pptx/.xlsx/archive files across multiple fixed drives in a short window, especially from a process image outside the user's normal office-suite footprint.
9. Screenshot / clipboard abuse (T1113, T1115): where available, EDR or DLP clipboard-monitoring telemetry for a script-host or PowerShell process reading clipboard contents and immediately clearing it -- the clear-after-read pattern is unusual for legitimate tooling.

Given the single-machine provenance (§2, §4), every recommendation below deploys in Detect / Alert-only mode first. None should be promoted to Prevent/Block until a second independent sample or corroborating source confirms the pattern is stable across more than one host.

Validation gates fold in the coverage-map caveats from §15: this pack should be re-scored once a second corroborating source or additional infected-host telemetry becomes available.

Playbook 1 -- Restrict Windows Script Host for standard users

# Playbook 1 -- Restrict Windows Script Host for standard users
# Prerequisites: Domain Admin or local GPO edit rights; AppLocker/WDAC already
#                enabled in at least Audit mode on target OUs.
# Reboot required: No (GPO refresh via gpupdate /force is sufficient)
# Rollback: Set the WSH rule action back to "Not Configured" / delete the
#           AppLocker rule, then gpupdate /force. No data loss; scripts that
#           were blocked simply become runnable again.

# 1. Create/verify an AppLocker Script Rule collection is in Enforce mode
Set-AppLockerPolicy -XmlPolicy "C:\Policies\WSH-Restrict.xml" -Merge

# 2. Deny .vbs/.js execution from user-writable roots for the Everyone group,
#    excluding a signed-script allowlist if one exists in your estate
# (Author via Local Security Policy > Application Control Policies > AppLocker
#  > Script Rules > New Rule > Path: %OSDRIVE%\Users\*\Desktop\*;
#  %OSDRIVE%\Users\*\Downloads\*; %OSDRIVE%\Users\*\AppData\Local\Temp\*)

# 3. Push via GPO and force refresh on a pilot OU first
gpupdate /target:computer /force

# 4. Verify enforcement
Get-AppLockerPolicy -Effective | Select-Object -ExpandProperty RuleCollections

Playbook 2 -- Enable ASR rule: Block execution of potentially obfuscated scripts

# Playbook 2 -- Enable ASR rule: Block execution of potentially obfuscated scripts
# Prerequisites: Microsoft Defender Antivirus active (or Defender in passive
#                mode alongside a third-party AV, ASR rules still apply);
#                pilot ring identified before fleet-wide Block.
# Reboot required: No
# Rollback: Re-run with -AttackSurfaceReductionRules_Actions AuditMode (or
#           Disabled) for the same rule ID to revert; takes effect immediately,
#           no reboot required.

# 1. Pilot in Audit mode first
Set-MpPreference -AttackSurfaceReductionRules_Ids 5beb7efe-fd9a-4556-801d-275e5ffc04cc -AttackSurfaceReductionRules_Actions AuditMode

# 2. Review Defender ASR audit events (Event ID 1122) for 1-2 weeks for FPs

# 3. Promote to Block once the pilot ring shows zero unexpected blocks
Set-MpPreference -AttackSurfaceReductionRules_Ids 5beb7efe-fd9a-4556-801d-275e5ffc04cc -AttackSurfaceReductionRules_Actions Enabled

# 4. Verify
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids

Playbook 3 -- Block confirmed C2 domains (DNS/proxy)

# Playbook 3 -- Block confirmed C2 domains at DNS / proxy (never irantenders[.]com)
# Prerequisites: Access to the DNS sinkhole / RPZ zone or secure web gateway
#                policy console.
# Reboot required: No
# Rollback: Remove the two RPZ/deny entries; propagation is immediate to a
#           few minutes depending on TTL/cache.

# 1. Add both confirmed C2 domains to your DNS RPZ / sinkhole zone
corecloudfileshare.xyz    CNAME  sinkhole.internal.
attachmentsharingdrive.xyz CNAME sinkhole.internal.

# 2. Mirror at the secure web gateway / proxy as an explicit deny category

# 3. DO NOT add irantenders.com or any subdomain -- Securonix explicitly
#    cautions against blocking that domain on this evidence (see Section 4).
#    If containment requires action, remove only the specific decoy path:
#    hxxps://www[.]irantenders[.]com/tender/tot-delete-6e137de.php

# 4. Verify
nslookup corecloudfileshare.xyz
nslookup attachmentsharingdrive.xyz

Phase order follows Securonix/Beardslee's own responder guidance verbatim: preserve evidence first, then stop, then remove every persistence mechanism in one coordinated pass, then block network, then verify after reboot.

Validation gates (§11): telemetry-readiness and positive-test checks are pending live-tenant deployment; the 14-day benign-baseline window has not yet started as of pack publication (2026-09-22).

All four snapshots were checked for embedded instructions directed at an AI agent (prompt injection). None were found in any of the four sources.