TASK#STOMP: a PowerShell backdoor hiding in native Windows tools that already log it

Nothing new was invented here, and that is the point

Count the tools TASK#STOMP uses to steal a company's documents, Wi-Fi passwords and clipboard, and you get a list every Windows administrator already knows: wscript.exe, the Task Scheduler, PowerShell, schtasks.exe, netsh, and the .NET C# compiler that ships with the operating system. Securonix Threat Research, which disclosed the campaign on 21 September 2026, counted no bespoke executable payload at all. The backdoor is assembled from parts that are already on the machine and already trusted.

That is the uncomfortable finding. A defender's instinct is to hunt for a malicious binary, but there is not one to find. The whole implant lives inside two PowerShell processes, decoded from two innocuous looking .dat files, and reaches its command servers through connections that look like ordinary Chrome traffic. Securonix names the technique cluster, not an actor, and calls it TASK#STOMP after the scheduled task abuse and the timestamp stomping at its core.

The optimistic reading, and the one this briefing argues for, is that living off the land cuts both ways. Every native tool the backdoor touches is a tool Windows can log or constrain. The task creation raises a Security event. The decoded script is written verbatim to a PowerShell log. The de-obfuscated code is handed to the antimalware engine before it runs. The catch is that those controls are off, or unshipped, on a great many endpoints. TASK#STOMP is less a story about a clever new threat than about telemetry most estates already own and have not switched on.

What the report establishes, and what it does not

Securonix reconstructed the chain from process telemetry, then obtained and decoded the two Base64 payload files, diag_pack.dat and win_conn_cfg.dat. That second step matters: it moves the document theft, the Wi-Fi and clipboard stealing, and the arbitrary command execution from suspicion to confirmation. The report is unusually careful about the boundary between the two, and a reader should be too.

The most important gaps are not incidental. The report cannot say how the first VBScript reached the desktop, who was targeted, or who is behind it. It says so plainly. A briefing that reported TASK#STOMP as, say, an Iran-linked espionage operation would be inventing the attribution: the only Iran connection in the evidence is a single browser tab, and Securonix warns explicitly against reading the domain as attacker controlled.

Stated versus not stated, from the Securonix report of 21 September 2026

Question	What the report establishes
Delivery	Not stated. Telemetry cannot separate phishing, browser download, USB, remote access or archive extraction.
Capabilities	Confirmed by decoding both payloads: document theft, live file watching, Wi-Fi and clipboard theft, screenshots, arbitrary PowerShell.
Persistence	Confirmed: four XML scheduled tasks plus a Startup-folder VBScript, mutually reinforcing.
Command and control	Confirmed: two failover domains, one static token, TLS validation switched off in runtime C#.
Victim and sector	Not stated. No victim, country or industry is named.
Attribution and confidence	Not stated. No actor is named and no confidence level is given.
The Iran browser tab	Observed but unexplained. Securonix lists decoy, marker, campaign resource or compromised page as possibilities.

One more honest detail, because it shows the analysis was read closely rather than paraphrased: Securonix found a coding defect in the malware's own watchdog. A tick counter is reset inside the first block that checks it, so the second block guarded by the same test is effectively dead code. The mutual restart still works because it is reinforced by the scheduled tasks and the Startup copy. The implant is resilient by redundancy, not by clever engineering.

The chain, stage by stage

The observed run starts when Windows Script Host launches a randomly named VBScript from the desktop, 95c9050t66.vbs. The random name is the first evasion: it defeats detections keyed to a filename. From there the script does the work of an installer and an orchestrator in one.

Persistence, three ways. The VBScript creates four scheduled tasks from XML files staged under %LOCALAPPDATA%\WinDefendSvc, a folder named to resemble a Windows Defender service. The task display names, Local Credential Manager, Network Audio Service, Windows Display Manager and Device Credential Handler, imitate operating system components. On a later run from the Startup folder, the same four XML files are registered under a different set of names, which proves the name is disposable camouflage and the real definition lives in the XML. A copy of msdiag.vbs in the Startup folder gives a third anchor that fires on every logon.

Timestomping. PowerShell forces the same historical LastWriteTime, 2024-01-15 08:30:00, onto five staged files. That date sits more than two and a half years before the observed 2026 run, so it is a high confidence anti-forensic marker rather than a coincidence. Securonix flags the useful corollary for defenders: several scripts and .dat files under a user-writable path all sharing one old timestamp is itself a hunting pivot. The stomp only touches LastWriteTime; the NTFS $STANDARD_INFORMATION and $FILE_NAME records, the USN journal and the task registration events can still preserve the true window.

Two branches that watch each other. Two hidden PowerShell processes launch with -NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden. sys_loader.ps1 decodes diag_pack.dat, the document theft and surveillance payload. win_conn.ps1 decodes win_conn_cfg.dat, a lighter always-on command channel. Each is meant to restart the other, and the initial script kills any existing instances before relaunching so only one clean copy of each runs. Running them as separate processes is deliberate: killing one does not remove the other.

Fileless is the wrong word, and the right word matters

It is tempting to file TASK#STOMP under fileless malware and move on. Securonix resists the label, and correctly. The payloads sit on disk the whole time as Base64 inside diag_pack.dat and win_conn_cfg.dat. What never touches disk in plaintext is the decoded PowerShell, which is read, Base64 decoded, turned into a scriptblock and run in memory with the call operator. The report's term for this is script-native, and it is more honest than fileless.

The distinction is not pedantry. Fileless implies there is nothing to recover, which invites teams to give up on disk forensics. Here the encoded .dat files, the .ps1 loaders, the task XML and purge.bat are all recoverable artefacts, and Securonix names recovering them as the priority. The thing that is hidden is the decoded logic, and that is exactly what PowerShell script block logging and AMSI capture at the moment it is de-obfuscated.

The runtime C# compilation is the second place the folklore misleads. Each PowerShell branch calls Add-Type to compile a tiny helper class, which spawns csc.exe and then cvtres.exe. The helper, named SSLFix in one module and SSLFix2 in the other, does one thing: it sets the .NET certificate validation callback to always return true, so the malware can reach its command servers even over an invalid, self-signed or mismatched TLS certificate. No separate executable is produced. powershell.exe spawning csc.exe is unusual enough to be a strong detection signal on its own, and it is the tell that turns a benign looking script into a compilation of network evasion code.

What Windows already offers to see it

This is the part worth grounding in Microsoft's own documentation rather than in habit, because two comfortable beliefs need correcting first.

Scheduled task creation is an event, if you audit for it. Every one of the four tasks raises Security Event ID 4698, and Microsoft's guidance is to monitor all scheduled task creation, especially tasks placed in the Task Scheduler library root where malware tends to sit. The event carries the full task XML in its TaskContent field, which is precisely the definition the command line does not reveal: the trigger, the principal and the action. The event only fires if the Audit Other Object Access Events subcategory is enabled. Microsoft recommends success auditing for it on workstations, servers and domain controllers alike, and rates its volume as low, so the cost of turning it on is small.

Script block logging keeps the decoded script. When PowerShell script block logging is enabled, PowerShell records the content of every scriptblock it processes as Event ID 4104, including the code decoded from those .dat files and the C# handed to Add-Type. This is the single control that most directly defeats the script-native design, because it captures the logic that never lands on disk in plaintext. It is enabled by Group Policy under Administrative Templates, Windows PowerShell. Microsoft's own caution is worth heeding: script logging can capture secrets, so pair it with Protected Event Logging on sensitive estates.

AMSI sees through the obfuscation. The Antimalware Scan Interface exists for exactly this shape of attack. Microsoft's description is that a script may go through several passes of de-obfuscation, "but you ultimately need to supply the scripting engine with plain, un-obfuscated code", and that is the point at which the built-in script hosts call AMSI to have the content scanned. A Base64 blob in a .dat file tells an antivirus engine nothing; the decoded scriptblock, presented to AMSI just before execution, is what a signature or a machine learning model can act on. AMSI is not a panacea, and attackers do target it, but on this chain it is scanning the malware at its least disguised.

Constrained Language Mode removes the compiler trick. The runtime C# compilation depends on Add-Type loading arbitrary C#. Under Constrained Language Mode, Microsoft states that Add-Type can load signed assemblies but "can't load arbitrary C# code or Win32 APIs", and New-Object is limited to an allowlist of types. That mode is not a switch you flip in isolation; PowerShell drops into it automatically when an application control policy, AppLocker or App Control for Business, is enforced. Under App Control script enforcement, an unallowed VBScript run through wscript.exe is blocked outright, and an unallowed .ps1 still runs but only in Constrained Language Mode. Either outcome breaks a link in this specific chain.

Why the saved Wi-Fi passwords come out in plain text

Of everything TASK#STOMP steals, the Wi-Fi passwords are the part most people assume must require administrator rights. They mostly do not, and it is worth being precise about why. The malware runs netsh wlan show profiles, then netsh wlan show profile name=[the network] key=clear for each saved network, and lifts the Key Content field.

Underneath netsh is the Windows WlanGetProfile API. Microsoft's reference says that to return the plain text key, the calling thread needs the wlan_secure_get_plaintext_key permission, and that by default this is allowed only to members of the local Administrators group. Read that alone and you would conclude a standard user is safe. The behaviour on real machines is subtler: the permissions on a wireless profile are set when the profile is created, and the account that saved a network can generally read back its own key in the clear afterwards. Independent testing on Windows 10 and 11 reproduced a standard, non-administrator user retrieving a Wi-Fi password with key=clear for a network that was joined under that same account, with no elevation prompt.

So the honest statement is this: TASK#STOMP runs as the logged-in user, and it can read back the plain text keys of the networks that user saved, plus any all-user profiles the user has read access to. It does not need to be administrator for the networks the victim joined themselves. Microsoft's GUI hides the same key behind a User Account Control prompt, which creates a false sense that the secret is protected; the command line, and this malware, simply do not ask.

What that means for a network. A stolen pre-shared key is a standing credential that does not rotate when a laptop is reimaged or an employee leaves. On a flat guest or office WLAN protected by one shared passphrase, a single infected user hands an attacker the key to the whole segment, and the natural response, changing the passphrase, forces every legitimate device to be re-provisioned. This is the concrete case for 802.1X and per-user certificates on corporate wireless: there is no shared secret sitting in a profile for key=clear to reveal. Microsoft's own answer, in a support thread asking how to block this exact command, was that there is no reliable way to stop it and that pre-shared keys are "not considered enterprise ready".

The command channel, and what the domains tell you

Both modules authenticate every request to the same infrastructure with one static token in an X-Auth-Token header, and fail over between two domains: corecloudfileshare[.]xyz as primary and attachmentsharingdrive[.]xyz as backup. They poll a small set of API paths, /api/c2/poll/ for instructions and /api/c2/result/ for output, on a randomised three to seven second cycle followed by a /status check, which produces a distinctive and fairly noisy network pattern. Traffic is dressed up with a spoofed Chrome user-agent string.

The names are chosen to sound like benign file sharing, the same trick as the task names one layer down. Public registry records give them away as recent: corecloudfileshare[.]xyz was registered on 3 May 2026 and attachmentsharingdrive[.]xyz on 1 August 2026, on the low cost .xyz top level domain. The backup domain being registered ninety days after the primary is consistent with an operation that stood up redundancy over time, though the records alone do not prove a single operator. Newly registered, low reputation domains carrying a static authentication header are a clean thing to alert on, independent of any filename inside the malware.

The static token cuts both ways too. It is operational convenience for the attacker and a durable indicator for the defender: any outbound request carrying that specific X-Auth-Token value, or matching those API paths, is high confidence malicious. Because the certificate validation is switched off in the SSLFix helper, an inspecting proxy that presents its own certificate will not break the channel, which is a reminder that the network signal to rely on is the destination and the header, not a TLS error.

What to do this week, in order

The question that exposes the gap

TASK#STOMP did not defeat a single Windows security feature. It relied on those features being unobserved. The scheduled task fired an event nobody had configured the machine to record. The decoded script ran through an engine nobody had told to log it. The compiler that switched off TLS validation was the one Microsoft ships, invoked in a way that leaves a distinctive trail if anyone is watching for it.

So the question is not whether your antivirus would catch the payload, because there is no conventional payload to catch. It is narrower and more awkward: on your standard Windows build, right now, is script block logging on, is scheduled task auditing on, and would powershell.exe launching csc.exe from an AppData folder reach a human? If the answer is no, TASK#STOMP is not describing a threat you cannot see. It is describing one you have chosen not to.

Key facts