Task Stomp Powershell Backdoor Document Theft Remote Access

VBS-PowerShell Backdoor Using Rotating Scheduled Tasks, Timestomping, and Runtime C# Compilation for Document Theft and Remote Access:

Securonix Threat Research analyzed a script-driven Windows execution chain that begins with a desktop VBScript and deploys a redundant persistence framework under %LOCALAPPDATA%\WinDefendSvc. The sample creates four scheduled tasks from XML definitions, places msdiag.vbs in the user Startup folder, terminates existing loader instances, backdates core artifacts, launches two hidden PowerShell modules, compiles C# code at runtime through the legitimate .NET compiler, opens a specific web page in Chrome, and executes a cleanup batch file. Follow-on static analysis decoded the payloads carried by the two PowerShell modules and confirmed that TASK#STOMP is a fully operational PowerShell backdoor: it automatically harvests and exfiltrates business documents, watches the filesystem for new files in real time, steals Wi-Fi passwords and clipboard contents, takes screenshots, and accepts arbitrary remote commands through two redundant, token-authenticated C2 servers.

The decoded modules also reveal a resilient operating model: they use failover between the C2 servers, maintain local victim-tracking data, retry failed transfers, and monitor one another to sustain execution. Their runtime-compiled C# helpers disable TLS certificate validation, allowing communication even when the C2 infrastructure presents invalid, self-signed, or mismatched certificates. Although the confirmed payload is primarily focused on espionage and persistent collection rather than immediate destruction, its unrestricted command-execution capability gives an operator a direct path to deploy additional malware, steal more credentials, or initiate disruptive activity.

The most distinctive behavior is the combination of rotating service-like task names, Startup-folder redundancy, fixed-date timestomping, controlled process replacement, dual PowerShell branches, and separate runtime-compilation events. These behaviors form a strong detection chain when correlated, even if the attacker changes filenames, task names, or staging paths. The process tree alone, however, does not expose the compiled source, task triggers, payload configuration, or network protocol, reinforcing the importance of recovering task XML, PowerShell Script Block Logging, AMSI telemetry, and staged payload files during investigation.

Threat actors routinely abuse Windows Script Host, PowerShell, Task Scheduler, and the .NET toolchain to blend malicious execution with legitimate administrative activity. TASK#STOMP demonstrates this approach through a VBS-controlled framework that installs multiple persistence anchors and delegates follow-on functionality to PowerShell and dynamically compiled C# code. By relying almost entirely on native Windows components, the operation reduces its dependence on conventional executable payloads and makes individual events more difficult to distinguish from benign system activity.

The chain is staged under a user-writable path whose name resembles a Windows Defender service, while its scheduled-task display names imitate operating-system components. This masquerading strategy is paired with deliberate timestamp modification, hidden execution, process replacement, and cleanup behavior, indicating a coordinated effort to frustrate casual inspection and forensic timeline reconstruction. Redundant scheduled tasks and a Startup-folder launcher further ensure that execution can resume if one persistence mechanism is removed or fails.

Analysis of the decoded payloads shows that this framework extends beyond persistence and loading. TASK#STOMP provides continuous document collection, credential and clipboard theft, screenshot capture, redundant command-and-control communications, and arbitrary remote-command execution. Its significance therefore lies not in any single technique, but in the way familiar Windows utilities are combined into a resilient espionage-oriented backdoor whose full capabilities are not apparent from process telemetry alone.

– **Script-hosted orchestration:** wscript.exe controls persistence, process termination, timestomping, payload launch, browser activity, and cleanup. – **Multi-anchor persistence:** Four scheduled tasks are combined with a Startup-folder VBS launcher. – **Task-name rotation:** Two executions use different trusted-sounding names while reusing task.xml through task4.xml. – **Process replacement:** PowerShell locates command lines containing sys_loader or win_conn and force-terminates those processes before relaunch. – **Fixed-date timestomping:** Five artifacts receive the same historical LastWriteTime: 2024-01-15 08:30:00. – **Dual hidden PowerShell branches:** sys_loader.ps1 and win_conn.ps1 execute separately with NoProfile, ExecutionPolicy Bypass, and WindowStyle Hidden. – **Runtime C# compilation:** Each PowerShell process spawns csc.exe and cvtres.exe, strongly suggesting embedded C# compilation such as Add-Type. – **Cleanup staging:** purge.bat runs after the payload branches and invokes a two-second delay. – **Unconfirmed web role:** Chrome opens one specific IranTenders page that may be a decoy, marker, campaign resource, or compromised page. – **Confirmed final payload:** Decoded diag_pack.dat is a complete document-theft and remote-access backdoor with automated exfiltration, live file monitoring, and arbitrary command execution. – **Confirmed C2 infrastructure:** Both decoded modules authenticate to corecloudfileshare[.]xyz and attachmentsharingdrive[.]xyz using one static token, with automatic failover between the two.

The observed execution chain begins when Windows Script Host launches a randomly named VBScript from the affected user’s any location:

**C:\Windows\System32\WScript.exe “C:\Users\researcher\Desktop\95c9050t66.vbs”**

*Figure* *1.Encoded VBS Script.*

*Figure* *2**.**De**coded VBS Script.*

The script’s location places it within a user-accessible directory commonly used for downloaded files, email attachments, manually copied content, or payloads delivered through social engineering. Its randomized filename may have been intended to reduce recognition and complicate filename-based detection.

*Figure* *3**. TASK#STOMP process flow reconstructed from observed process telemetry.*

The VBS file acts as the primary installer and orchestrator for the subsequent persistence and payload-execution stages. However, its presence on the Desktop does not establish how it arrived or whether the user executed it directly. The available process telemetry cannot distinguish among phishing, browser download, removable media, remote access, archive extraction, or another delivery mechanism.

Determining the initial-access vector requires recovery of the original VBS file and its NTFS metadata, particularly the Zone.Identifier alternate data stream, along with browser-download records, email telemetry, archive history, and endpoint file-creation events preceding execution.

Stage 1: Scheduled-Task Persistence

*Figure* *4**. Stage 1: Scheduled-Task Persistence – schtasks.exe commands*

The initial VBS creates four scheduled tasks by passing XML definitions stored beneath %LOCALAPPDATA%\WinDefendSvc to schtasks.exe. The /F option forces task creation and permits an existing task with the same name to be overwritten without an additional confirmation prompt.

schtasks.exe /Create /F /TN “Local Credential Manager” /XML “%LOCALAPPDATA%\WinDefendSvc\task.xml” schtasks.exe /Create /F /TN “Network Audio Service” /XML “%LOCALAPPDATA%\WinDefendSvc\task2.xml” schtasks.exe /Create /F /TN “Windows Display Manager” /XML “%LOCALAPPDATA%\WinDefendSvc\task3.xml” schtasks.exe /Create /F /TN “Device Credential Handler” /XML “%LOCALAPPDATA%\WinDefendSvc\task4.xml”

A later Startup-folder execution reuses the same four XML files with a different task-name set. This shows that the display name is a camouflage layer while the executable action, trigger, principal, and settings remain embedded in the XML.

This reuse demonstrates that the task name is a replaceable camouflage layer rather than a dependable identifier for the underlying persistence mechanism. The selected names resemble Windows credential, audio, display, registry, and session-management components, but they are not standard task names associated with XML files stored in a user-profile directory. Rotating the names may weaken static detections and make the tasks appear legitimate during a superficial administrative review.

The command lines reveal where the XML definitions are stored, but they do not expose each task’s executable action, trigger conditions, execution principal, privilege level, restart behavior, or other settings. Recovering the original XML files—and correlating them with Security Event ID 4698 and Task Scheduler Operational logs—is therefore essential for reconstructing when and how the persistence mechanisms execute.

Stage 2: Startup-Folder Persistence

*Figure* *5**. Stage 2: Startup-Folder Persistence – msdiag.vbs placement*

The installer places a copy of msdiag.vbs in the current user’s Startup folder:

C:\Users\researcher\AppData\Roaming\Microsoft\Windows\Start \Programs\Startup\msdiag.vbs

When the user signs in and the Windows shell processes the Startup folder, Windows Script Host launches the VBS file in the user’s context. This creates a persistence mechanism independent of the scheduled tasks and allows the malware to reconstruct or reinforce its execution chain after a reboot or new interactive logon.

The Startup-launched script repeats task registration, terminates existing loader instances, reapplies the fixed historical timestamps, and starts both hidden PowerShell branches. Repeating these actions allows the framework to restore missing tasks, replace stale or malfunctioning payload processes, and return the implant to a known operating state.

Telemetry also shows multiple background instances launched with wscript.exe /B /Nologo. The /B switch suppresses prompts and user interaction, while /Nologo removes the startup banner, helping the scripts operate unobtrusively. These concurrent instances may reflect overlapping scheduled-task triggers, watchdog-driven restarts, or uncontrolled re-entry; process telemetry alone is insufficient to identify which explanation applies. Parent-process relationships, task-trigger timestamps, and the recovered XML definitions are required to determine the exact source of each execution.

Stage 3: Existing-Instance Termination

*Figure* *6**. Stage 3: Existing-Instance Termination – PowerShell WMI kill*

Before starting new payload instances, hidden PowerShell enumerates WMI process data and force-terminates command lines containing sys_loader or win_conn:

Get-WmiObject Win32_Process | Where-Object { $_.CommandLine -like ‘*sys_loader*’ -or $_.CommandLine -like ‘*win_conn*’ } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force -EA SilentlyContinue }

Querying Win32_Process allows the script to inspect complete command lines rather than relying only on generic process names such as powershell.exe. The substring matching identifies both payload branches even when their process identifiers change between executions. Stop-Process -Force ends each matching instance immediately, while -ErrorAction SilentlyContinue suppresses visible errors if a target has already exited or cannot be terminated.

This behavior most likely enforces a single active copy of each module, replaces outdated or unresponsive instances, or resets failed command-and-control sessions before relaunch. The subsequent 800-millisecond pause gives terminated processes and associated resources a brief opportunity to close before replacement instances begin. When correlated with the later launches of sys_loader.ps1 and win_conn.ps1, the sequence is more consistent with controlled process replacement than with general process discovery.

Stage 4: Timestamp Stomping

*Figure* *7**. Stage 4: Timestamp Stomping – Part 1*

*Figure* *8**. Stage 4: Timestamp Stomping – Part 2*

PowerShell assigns an identical historical LastWriteTime to five staged artifacts:

$d=[datetime]’2024-01-15 08:30:00′ (Get-Item ”).LastWriteTime=$d

The selected timestamp predates the observed 2026 execution by more than two years, making the modification a high-confidence anti-forensic indicator. Applying the exact same date and time to all five related files creates the appearance that they were present long before the intrusion and can mislead investigations that rely primarily on directory listings or basic modification-time sorting.

The operation changes LastWriteTime but does not necessarily erase other evidence of file creation, installation, or execution. Differences between NTFS $STANDARD_INFORMATION and $FILE_NAME timestamps, together with the USN Journal, MFT records, EDR file events, PowerShell logs, and scheduled-task registration events, may preserve the true activity window. The shared value 2024-01-15 08:30:00 is also a useful hunting pivot: several scripts and encoded data files under a user-writable path receiving that identical historical timestamp should be treated as highly suspicious.

Stage 5: Dual Hidden PowerShell Execution

*Figure* *9**. Stage 5: Dual Hidden PowerShell Execution*

Two scripts execute as separate hidden branches:

powershell.exe -NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File “%LOCALAPPDATA%\WinDefendSvc\sys_loader.ps1” powershell.exe -NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File “%LOCALAPPDATA%\WinDefendSvc\win_conn.ps1”

Each option contributes to reliable and unobtrusive execution. -NoProfile prevents user or system profile scripts from altering the runtime environment, while -WindowStyle Hidden suppresses the visible console window. -ExecutionPolicy Bypass allows the scripts to run without enforcement prompts from PowerShell’s execution-policy mechanism; it does not itself elevate privileges or bypass operating-system access controls.

Follow-on payload analysis confirms that the two scripts are lightweight loaders with distinct operational roles. sys_loader.ps1 decodes diag_pack.dat and starts the primary document-theft, surveillance, and remote-access payload. win_conn.ps1 decodes win_conn_cfg.dat and establishes a secondary, always-on C2 channel with overlapping command-execution and collection capabilities.

Running the modules as separate processes provides functional separation and operational redundancy: failure or termination of one branch does not immediately remove the other. The dual launches also produce two independent PowerShell-to-csc.exe compilation chains during the stage. Defenders can detect this behavior by correlating hidden or execution-policy-bypassed PowerShell launched from an AppData path with PowerShell Script Block Logging, AMSI telemetry, and subsequent compiler activity.

Stage 6: Runtime C# Compilation

Each PowerShell branch invokes the legitimate .NET Framework C# compiler, which subsequently launches cvtres.exe to process temporary resource files:

powershell.exe -> csc.exe /noconfig /fullpaths @”%TEMP%\.cmdline” -> cvtres.exe

The decoded payloads confirm that this activity originates from PowerShell’s Add-Type functionality. diag_pack.dat defines a C# helper named SSLFix, while win_conn_cfg.dat defines a near-identical helper named SSLFix2. Each Add-Type invocation produces one independent csc.exe and cvtres.exe chain, explaining why two compilation events appear beneath the separate PowerShell processes.

Both helper classes modify .NET networking behavior by enforcing TLS 1.2 and accepting any server certificate:

*Figure* *10**. Stage 6: Runtime C# Compilation – TLS Certificate Bypass*

Disabling certificate validation allows the malware to communicate with its C2 infrastructure even when a server presents an invalid, self-signed, expired, or hostname-mismatched certificate. The compiled code does not represent a separate full-featured executable payload; it is a small helper loaded into the originating PowerShell process, where the main backdoor logic continues to run.

Forensic investigation should focus on the following evidence:

Recover temporary .cmdline response files to identify compiler options and referenced source or output paths.

Review PowerShell Event ID 4104 and AMSI telemetry for the embedded C# source and surrounding decoded script content.

Preserve temporary compiler artifacts and capture the loaded assembly from PowerShell memory or EDR telemetry where possible.

Correlate the compiler activity with the originating PowerShell command line, AppData script path, and subsequent network connections.

PowerShell spawning csc.exe is unusual and valuable for detection, but it is not inherently malicious. The strongest signal is the complete ancestry and context: hidden PowerShell executing from a user-writable staging directory, decoding local .dat content, compiling a certificate-validation bypass, and then communicating with known C2 infrastructure.

Stage 7: Browser Launch

*Figure* *11**. Stage 7: Browser Launch – Chrome opening IranTenders URL*

The initial VBS launches Google Chrome in a maximized window and supplies a single URL as an argument:

hxxps://www[.]irantenders[.]com/tender/tot-delete-6e137de.php

Opening a visible browser window may serve as a decoy or distraction while the installer establishes persistence and starts its hidden PowerShell payloads. Other plausible roles include signaling successful execution, directing the victim to campaign-related content, or accessing a malicious path hosted on a compromised legitimate website. The filename tot-delete-6e137de.php is unusual but does not, by itself, establish the page’s purpose.

Process telemetry confirms only that Chrome received the URL; it does not reveal the returned content, redirects, downloads, scripts, or subsequent network activity. It also does not establish that the parent domain is controlled by the threat actor. Investigators should preserve Chrome history and cache data and correlate the event with DNS, proxy, TLS, and endpoint network telemetry to determine the response and any follow-on destinations.

The exact URL path should be treated as an investigative indicator and blocked where appropriate during containment. The entire irantenders[.]com domain should not be classified as malicious without additional evidence demonstrating broader compromise or attacker control.

Stage 8: Cleanup and Re-entry

*Figure 1**2**. Stage 8: Cleanup and Re-entry – purge.bat execution*

After launching both PowerShell payload branches, the VBS orchestrator starts purge.bat through cmd.exe:

cmd.exe /C “%LOCALAPPDATA%\WinDefendSvc\purge.bat”

The /C option instructs cmd.exe to execute the batch file and then terminate. Within the observed process chain, purge.bat invokes the following delay:

timeout.exe /T 2 /NOBREAK

This command creates a two-second pause that cannot be interrupted by a keypress. Such delays are commonly used to allow parent processes to exit, release file handles, or complete staging before a script deletes temporary components or removes evidence. However, the supplied telemetry does not expose the remaining batch-file commands, so the actual cleanup targets and whether deletion occurred cannot be confirmed from the process tree alone. Recovering purge.bat, related command-shell telemetry, and file-deletion events is necessary to establish its full purpose.

Following the initial installation, multiple background executions of msdiag.vbs remain visible. This confirms that TASK#STOMP is not a single-run dropper: its persistence framework continues operating after the original Desktop VBS exits. These later executions can repeat task registration, terminate and replace existing module instances, reapply timestamps, and relaunch both PowerShell branches.

Determining the precise source of each re-entry requires correlating the wscript.exe parent process and execution time with the Startup folder, scheduled-task events, and recovered task XML. Regardless of the individual trigger, the repeated launches demonstrate that cleanup of the initial installer does not dismantle the established persistence mechanisms.

Stage 9: Decoded Final-Stage Payloads — Confirmed Backdoor and Command-and-Control

Following the initial process-tree assessment, Securonix Threat Research obtained and decoded the two Base64-encoded payload files referenced by the loader scripts: diag_pack.dat and win_conn_cfg.dat. This closes the primary open question from the original advisory — the actual capability of sys_loader.ps1 and win_conn.ps1 — and confirms TASK#STOMP as a fully functional PowerShell backdoor with automated document theft, live surveillance, and unrestricted remote-command execution.

9.1 Loader Mechanism: Base64-in-DAT, Execute-in-Memory

Both sys_loader.ps1 and win_conn.ps1 use an identical four-step pattern to turn an innocuous-looking .dat file into running PowerShell code:

*Figure 1**3**. Stage 9: Payload Decoding Pattern – Part 1 (sys_loader.ps1)*

*Figure 1**4**. Stage 9: Payload Decoding Pattern – Part 2 (win_conn.ps1)*

– **Step 1:** Read the .dat file as text from the WinDefendSvc staging directory. – **Step 2:** Base64-decode the contents into raw bytes. – **Step 3:** Convert the bytes to a UTF-8 PowerShell source string. – **Step 4:** Compile the string into an in-memory ScriptBlock and execute it immediately with the call operator (&). This qualifies as an encoded-on-disk, memory-executed payload rather than a fully fileless one, because diag_pack.dat and win_conn_cfg.dat remain on disk in Base64 form even though the decoded PowerShell never touches disk as plaintext. “Script-native” is a more accurate descriptor than “fileless” for this loader pattern.

9.2 diag_pack.dat: Document-Theft and Backdoor Module

*Figure 1**5**. diag_pack.dat – Document-Theft and Backdoor Module*

The decoded contents of diag_pack.dat should be classified as a persistent PowerShell data-stealing backdoor with automated document exfiltration, surveillance, credential collection, and arbitrary remote-command execution. Its objectives are:

– Collect victim and network information for C2 registration. – all fixed drives for business documents and archives. – Upload collected files to attacker infrastructure. – Monitor the filesystem for newly created or modified files in real time. – Steal saved Wi-Fi passwords. – Capture screenshots of the primary display. – Steal and clear clipboard contents. – Execute arbitrary PowerShell commands sent by the operator. – Maintain communication through two redundant C2 servers. – Restart the paired win_conn.ps1 module if it stops running.

9.3 Confirmed Command-and-Control Infrastructure

*Figure 1**6**. Confirmed Command-and-Control Infrastructure*

Both diag_pack.dat and win_conn_cfg.dat communicate with the same attacker infrastructure, authenticating every request with a single static token embedded in the script:

Confirmed C2 endpoints used across both modules:

– /status – /upload – /api/client_info – /api/client_map – /api/register – /api/client_online – /api/heartbeat – /api/c2/poll/ – /api/c2/result/

9.4 TLS Certificate Validation Bypass Explains the csc.exe Activity

Both decoded modules embed a short C# class compiled at runtime through PowerShell’s Add-Type, which disables certificate validation so the malware can reach its C2 even over an invalid, self-signed, or mismatched TLS certificate:

ServicePointManager.ServerCertificateValidationCallback = delegate { return true; }; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

This directly resolves the open question raised in Stage 6 of the original process-tree assessment. diag_pack.dat contains a class named SSLFix; win_conn_cfg.dat contains a near-identical class named SSLFix2. Each Add-Type call triggers one csc.exe / cvtres.exe pair, which is why the process tree shows exactly two independent compiler branches rather than one:

PowerShell Add-Type -> csc.exe compiles SSLFix / SSLFix2 -> cvtres.exe processes compiler resources -> class is loaded back into powershell.exe

No separate, hidden executable payload is produced. The compiled class is a small helper loaded directly into the PowerShell process; all malicious functionality continues to run inside powershell.exe.

9.5 Victim Registration and Reconnaissance

On first run, diag_pack.dat collects host and network details and reports them to the C2:

– Hostname – Username – Public IP address (via checkip.amazonaws[.]com, falling back to api[.]ipify[.]org) – Local IPv4 address – Operating-system name – Execution time and time zone – City, country, and ISP (via ip-api[.]com/json/) This data is submitted to POST /api/client_info. The C2 returns a client identifier that is cached locally at %LOCALAPPDATA%\WinDefendSvc\host_id.dat, allowing the operator to recognize the same infected host across reboots and repeated executions.

9.6 Automated Document Discovery and Exfiltration

The payload enumerates every fixed drive for the following extensions:

.doc .docx .pdf .ppt .pptx .xls .xlsx .zip .rar .7z

Selection is filtered by clear rules: created or modified within the 365 days, capped at 500 MB, excluded from system or malware staging directories, and de-duplicated by path, MD5, and size against files already uploaded. Documents are prioritized ahead of archives, in the order Word → PDF → PowerPoint → Excel → archives — a targeting pattern consistent with corporate-document espionage rather than browser-credential or cryptocurrency-wallet theft.

Exfiltration runs over HTTP multipart POST requests to /upload, carrying the auth token, a Base64-encoded original filename, and a compression flag. Files under 10 MB are uploaded directly; files between 10 MB and 200 MB are GZip-compressed first; files over 500 MB are skipped entirely; and failed uploads are retried up to three times before being queued for a later attempt. Every request is sent with the spoofed Chrome user-agent string described in Section 9.3.

9.7 Continuous File Monitoring

9.8 Remote Command-and-Control Capabilities

Both modules poll GET /api/c2/poll/ for operator instructions and return results to POST /api/c2/result/. A fixed set of built-in commands is supported, and anything else is executed as raw PowerShell:

9.9 Credential and Surveillance Capabilities

– **Wi-Fi password theft:** The malware runs netsh wlan show profiles, then netsh wlan show profile name= key=clear for each saved network and extracts the Key Content field, exposing stored Wi-Fi passwords in plaintext. – **Clipboard theft:** Clipboard text is read via [System.Windows.Forms.Clipboard]::GetText(), uploaded, and then cleared with ::Clear() — clearing it may conceal the theft or prevent the user noticing sensitive text they had copied. – **Screenshot capture:** The primary monitor is captured with .NET CopyFromScreen, saved temporarily to %TEMP%\screenshot_yyyyMMdd_HHmmss.png, uploaded, and then deleted from disk.

9.10 win_conn.ps1 / win_conn_cfg.dat: A Dedicated Secondary C2 Channel

win_conn_cfg.dat is a second, dedicated command-and-control implant. Unlike diag_pack.dat, it does not perform the initial document scan or continuous filesystem monitoring — its role is a lighter-weight, always-on remote-access channel that duplicates the C2 polling, screenshot, Wi-Fi, clipboard, sysinfo, and arbitrary-command capabilities described above, and additionally reports document-exfiltration progress on request.

The two modules are mutually dependent: diag_pack.dat checks whether win_conn.ps1 is running and restarts it if not, and win_conn_cfg.dat performs the same check on sys_loader.ps1. This mutual-watchdog relationship explains the process-termination behavior documented in Stage 3 of the original assessment — the initial VBS kills any existing sys_loader or win_conn instances before relaunching fresh copies, resetting both paired modules into a known state and preventing duplicate backdoors.

C2 polling uses a randomized 3–8 second interval (PowerShell’s Get-Random upper bound is exclusive), and every poll cycle is followed by a /status check, producing a fairly noisy and distinctive network pattern:

GET /api/c2/poll/ GET /status Sleep 3–8 seconds Repeat

9.11 Resilience, Watchdogs, and a Logic Defect

Both modules run inside nested infinite loops with try/catch self-restart logic, retry failed uploads, periodically rescan files, and maintain local tracking artifacts:

– %LOCALAPPDATA%\WinDefendSvc\host_id.dat – %LOCALAPPDATA%\WinDefendSvc\data_log.log – %LOCALAPPDATA%\WinDefendSvc\diag_index.dat – %LOCALAPPDATA%\WinDefendSvc\data_progress.dat Both modules also the same watchdog coding defect. The heartbeat/restart tick counter is reset to zero inside the first conditional block that checks it, so a second block guarded by the same condition (intended to run the mutual wscript/sys_loader restart check) normally never fires:

if ($TICK -ge 12) { $TICK = 0; # heartbeat + restart check runs } if ($TICK -ge 12) { # mutual watchdog — effectively unreachable }

In practice this means the primary restart check still works, but the secondary “mutual watchdog” block is largely dead code. Persistence remains strong regardless, since it is independently reinforced by the four scheduled tasks and the Startup-folder copy documented in Stages 1 and 2.

9.12 Revised Payload Architecture

95c9050t66.vbs |– Creates four XML-based scheduled tasks |– Installs Startup msdiag.vbs |– Backdates staged files |– Terminates older module instances | |– sys_loader.ps1 | `– Decodes diag_pack.dat | |– Document discovery + continuous file monitoring | |– File compression and exfiltration | |– Remote command execution | `– Restarts win_conn.ps1 if stopped | `– win_conn.ps1 `– Decodes win_conn_cfg.dat |– Dedicated C2 polling |– Screenshot / Wi-Fi / clipboard collection |– Arbitrary PowerShell execution `– Restarts sys_loader.ps1 if stopped

9.13 High-Value Detection Opportunities from the Decoded Payload

– powershell.exe reading diag_pack.dat or win_conn_cfg.dat from a user-writable AppData path. – The pattern FromBase64String + ReadAllText + [scriptblock]::Create in PowerShell command lines or Script Block Logging (Event ID 4104). – PowerShell Add-Type calls compiling a class that sets ServerCertificateValidationCallback to always return true. – Outbound PowerShell connections to corecloudfileshare[.]xyz or attachmentsharingdrive[.]xyz. – HTTP requests carrying an X-Auth-Token header, or URI paths matching /api/c2/poll/, /api/c2/result/, /api/client_online, /api/heartbeat, or /upload. – powershell.exe spawning netsh.exe with wlan show profile … key=clear. – PowerShell using System.Drawing’s CopyFromScreen (screenshot capture). – PowerShell creating a System.IO.FileSystemWatcher rooted at a fixed-drive letter. The remaining unanswered question is initial access. Confirming how 95c9050t66.vbs first reached the endpoint requires recovering the VBS file itself, its Zone.Identifier alternate data stream, purge.bat, msdiag.vbs, and the four scheduled-task XML definitions.

Defense Evasion Summary

TASK#STOMP uses several techniques intended to conceal execution and complicate investigation:

– **Masquerading:** The WinDefendSvc folder and service-like task names mimic trusted Windows concepts. – **Hidden script execution:** PowerShell and WScript use hidden or background execution options. – **Timestomping:** Five files are backdated to one fixed historical timestamp. – **Compile after delivery:** C# code is compiled on the endpoint through csc.exe. – **Process replacement:** Existing module instances are terminated before fresh execution. – **Cleanup:** purge.bat runs after staging and introduces a delay before suspected deletion. – **Task-name rotation:** Different names are assigned to the same XML task definitions across executions. ## Wrapping Up

TASK#STOMP demonstrates how native Windows scripting, scheduling, and development utilities can be assembled into a resilient intrusion framework whose full purpose is not visible in the initial process tree. The VBS orchestrator establishes multiple persistence anchors, terminates and replaces active payload instances, manipulates file timestamps, launches hidden PowerShell modules, triggers runtime C# compilation, and stages cleanup while a Startup-folder copy sustains execution.

Analysis of the decoded payloads reveals what this execution chain ultimately enables: automated business-document discovery and exfiltration, continuous filesystem monitoring, Wi-Fi password and clipboard theft, screenshot capture, system reconnaissance, and unrestricted remote-command execution. Two authenticated C2 channels with automatic failover provide additional resilience, while locally stored identifiers and tracking data allow the malware to maintain continuity across repeated executions. Although the observed activity is oriented toward espionage and persistent collection rather than immediate disruption, arbitrary command execution leaves the endpoint exposed to further payload delivery and escalation.

Defenders should prioritize behavioral correlation over isolated filenames, task names, or directories. wscript.exe creating several XML-defined tasks from AppData, followed by hidden PowerShell, Base64 payload decoding, csc.exe compilation, timestamp modification, and repeated Startup-folder execution forms a high-confidence malicious sequence even when individual artifacts change. Network connections to the confirmed C2 domains, especially requests carrying the static authentication header or matching the identified API paths, provide an additional high-confidence detection layer.

Effective remediation must address the framework as a whole. Removing only one scheduled task, script, or running process may leave other persistence mechanisms available to reconstruct the infection. Responders should preserve the task XML and staged payloads for analysis, terminate active script processes, remove every persistence anchor in a coordinated action, block the confirmed infrastructure, and verify after reboot that no component returns.

Securonix Recommendations

Monitor Script-Hosted Task Creation

– Detect wscript.exe or cscript.exe spawning schtasks.exe with /Create and /XML. – Prioritize XML definitions stored beneath AppData, Temp, Desktop, Downloads, or other user-writable paths. – Correlate two or more task creations from the same script ancestry within five minutes. – Collect Security Event ID 4698 and Task Scheduler Operational events with the full task definition.

Detect Hidden PowerShell and Runtime Compilation

– Alert when hidden or execution-policy-bypassed PowerShell runs a PS1 file from AppData. – Monitor PowerShell spawning csc.exe, especially when the source or response file is in Temp. – Enable PowerShell Script Block Logging and retain Event IDs 4103 and 4104 centrally. – Collect AMSI content and EDR file events for generated source, response, and assembly files.

Hunt for Anti-Forensic File Changes

– for PowerShell command lines assigning LastWriteTime, CreationTime, or LastAccessTime. – Compare $STANDARD_INFORMATION and $FILE_NAME timestamps during NTFS forensic review. – Treat several AppData scripts receiving the same historical timestamp as high-risk.

Contain All Persistence Anchors Together

– Terminate active VBS and PowerShell instances before deleting tasks or Startup files. – Export task XML and copy WinDefendSvc before remediation. – Remove the Startup copy, all scheduled tasks, staged scripts, DAT files, and cleanup artifacts in one coordinated action. – Reboot and verify that no msdiag.vbs, sys_loader.ps1, or win_conn.ps1 process returns.

Relevant Securonix Detections

Relevant Hunting Queries

[*Remove the square brackets “[ ]” from IP addresses or URLs before use.*]

index = activity AND rg_functionality = “Endpoint Management Systems” AND deviceaction = “Process Create” AND processname ENDS WITH “\schtasks.exe” AND parentprocessname ENDS WITH ANY (“\wscript.exe”, “\cscript.exe”) AND processcommandline CONTAINS “/Create” AND processcommandline CONTAINS “/XML” AND (processcommandline CONTAINS “\AppData\” OR processcommandline CONTAINS “\Users\”)

index = activity AND rg_functionality = “Endpoint Management Systems” AND deviceaction = “Process Create” AND processname ENDS WITH “\csc.exe” AND parentprocessname ENDS WITH “\powershell.exe” AND (parentprocesscommandline CONTAINS “-WindowStyle Hidden” OR parentprocesscommandline CONTAINS “-ExecutionPolicy Bypass”) AND parentprocesscommandline CONTAINS “\AppData\”

index = activity AND rg_functionality = “Endpoint Management Systems” AND deviceaction = “Process Create” AND processname ENDS WITH “\powershell.exe” AND (processcommandline CONTAINS “.LastWriteTime=” OR processcommandline CONTAINS “SetLastWriteTime”) AND (processcommandline CONTAINS “.ps1” OR processcommandline CONTAINS “.vbs” OR processcommandline CONTAINS “.dat”)

index = activity AND rg_functionality = “Endpoint Management Systems” AND deviceaction = “Process Create” AND processname ENDS WITH “\powershell.exe” AND processcommandline CONTAINS “FromBase64String” AND processcommandline CONTAINS “scriptblock” AND processcommandline CONTAINS “.dat”

index = activity AND rg_functionality = “Web Proxy” OR rg_functionality = “Network” AND (destinationhostname CONTAINS “corecloudfileshare.xyz” OR destinationhostname CONTAINS “attachmentsharingdrive.xyz”) AND httpheader CONTAINS “X-Auth-Token”

C2 and Infrastructure

Analyzed Files / Hashes