Skip to main content
Trym HåkanssonSwitch to Labs
All writing

TECHNICAL REFERENCE · PERSONALLY PUBLISHED · NOT AN EMPLOYER PUBLICATION

Hunting TA584 and Tsundere Bot in Defender XDR

A source-based Defender XDR hunting note for Proofpoint's TA584 ClickFix chain and the Tsundere Bot payload.

The strongest detection point in this chain is not the lure brand. TA584 changes lures and infrastructure quickly. The more stable sequence is suspicious PowerShell, Node.js appearing in a user-writable path and Node.js making outbound connections.

Proofpoint published the campaign research behind this note. Kaspersky separately documented the Tsundere botnet's use of Web3 smart contracts, encrypted WebSocket communication and an integrated marketplace. I have adapted the defensive steps to Defender XDR based on previous MDR and Microsoft security-operations work. I am not claiming discovery of the malware or a customer incident.

What Proofpoint observed

Proofpoint tracks TA584 as an initial access broker and described several changes during 2025:

  1. The actor often sent messages from compromised individual accounts on legitimate, aged domains. Proofpoint also saw occasional use of compromised third-party email service provider accounts.
  2. Messages used unique URLs, redirect chains, traffic distribution services, geofencing and IP filtering.
  3. From late July 2025, TA584 used ClickFix pages. The victim completed a CAPTCHA and was told to run a PowerShell command.
  4. The PowerShell stage retrieved another obfuscated script and executed a malware payload.
  5. TA584 continued to deliver XWorm and, from late November 2025, also delivered Tsundere Bot.

Proofpoint's analysis is deliberately scoped to email delivery and early execution. That boundary matters. It supports a detection plan for initial access, but it does not establish what happened in every downstream intrusion.

What makes Tsundere Bot useful to hunt

According to Proofpoint, Tsundere Bot needs Node.js. Installers generated from its C2 panel can install the runtime through MSI or PowerShell. The bot then:

  • queries multiple Ethereum RPC providers to retrieve C2 and configuration data from a Web3 smart contract;
  • uses a consensus mechanism to select the C2 URL returned most often;
  • retains a hardcoded fallback C2 in the installer script;
  • communicates with the C2 over WebSockets;
  • can execute JavaScript supplied by the C2.

Kaspersky also reported fake game installers as a separate distribution path. That is supporting context for the malware family, not evidence that every Kaspersky-observed infection belongs to TA584.

Proofpoint assessed with high confidence that Tsundere Bot infections could lead to ransomware. Keep the wording intact. The report does not support a claim that ransomware always follows or that defenders have a fixed number of days before it happens.

Hunt 1: suspicious PowerShell consistent with ClickFix

ClickFix tells the user to run the command. It is therefore unsafe to require a browser as the direct parent process. Start with command-line behavior and add the parent process as context.

DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (
    "-enc",
    "-encodedcommand",
    "FromBase64String",
    "Invoke-Expression",
    "IEX",
    "DownloadString",
    "Invoke-WebRequest"
)
| where ProcessCommandLine has_any ("http://", "https://")
    or ProcessCommandLine has_any ("-enc", "-encodedcommand")
| project Timestamp, DeviceId, DeviceName, AccountName,
    FileName, ProcessCommandLine, InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

This is a broad ClickFix and script-delivery hunt. It is not specific to TA584. Expect administration scripts and software deployment tools, then remove those cases with explicit, reviewed exclusions.

Hunt 2: Node.js launched from a script host or user-writable path

Proofpoint's defensive guidance specifically calls out powershell.exe or cmd.exe spawning node.exe, especially when Node is under AppData or another non-standard location.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "node.exe"
| where InitiatingProcessFileName in~ (
    "powershell.exe",
    "pwsh.exe",
    "cmd.exe"
)
    or FolderPath has @"\AppData\Local\"
    or FolderPath has @"\AppData\Roaming\"
    or FolderPath has @"\Temp\"
| project Timestamp, DeviceId, DeviceName, AccountName,
    FolderPath, ProcessCommandLine, InitiatingProcessFileName,
    InitiatingProcessCommandLine, SHA256
| order by Timestamp desc

Do not alert on all Node.js execution. Development endpoints, build agents and desktop applications can use Node legitimately. The useful distinction is a new or unexpected runtime in a user-writable path, launched by a script host, on a device that does not normally run it.

Hunt 3: fresh Node.js files in user-writable paths

DeviceFileEvents
| where Timestamp > ago(7d)
| where ActionType == "FileCreated"
| where FileName =~ "node.exe"
| where FolderPath has @"\AppData\"
    or FolderPath has @"\Temp\"
| project Timestamp, DeviceId, DeviceName, FolderPath,
    InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256
| order by Timestamp desc

A file creation event is stronger when it follows the suspicious PowerShell event and precedes a Node.js process start.

Hunt 4: outbound traffic from the suspicious Node.js process

The endpoint table may not expose WebSocket semantics or the smart-contract lookup directly. It can still show where an unexpected Node process connected.

DeviceNetworkEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName =~ "node.exe"
| where InitiatingProcessFolderPath has @"\AppData\"
    or InitiatingProcessFolderPath has @"\Temp\"
| where ActionType == "ConnectionSuccess"
| summarize
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    ConnectionCount = count(),
    RemoteUrls = make_set(RemoteUrl, 25),
    RemoteIPs = make_set(RemoteIP, 25),
    RemotePorts = make_set(RemotePort, 10)
    by DeviceId, DeviceName, InitiatingProcessFolderPath,
        InitiatingProcessCommandLine, InitiatingProcessSHA256
| order by FirstSeen desc

Pivot the resulting domains into proxy or firewall telemetry. Proofpoint recommends monitoring or restricting the Ethereum RPC providers used by the malware and inspecting WebSocket connections to unknown or uncategorized domains. Build that list from the source indicators, current threat intelligence and your approved blockchain use. Do not block an entire protocol without checking the business effect.

Correlate the execution sequence

This query joins a suspicious PowerShell event to a Node.js process on the same device. The one-hour window is an analyst choice for triage, not a timing claim from Proofpoint.

let scriptLaunches =
    DeviceProcessEvents
    | where Timestamp > ago(24h)
    | where FileName in~ ("powershell.exe", "pwsh.exe")
    | where ProcessCommandLine has_any (
        "-enc", "-encodedcommand", "IEX",
        "DownloadString", "Invoke-WebRequest"
    )
    | project ScriptTime = Timestamp, DeviceId, DeviceName,
        ScriptCommand = ProcessCommandLine;
let nodeStarts =
    DeviceProcessEvents
    | where Timestamp > ago(24h)
    | where FileName =~ "node.exe"
    | where InitiatingProcessFileName in~ (
        "powershell.exe", "pwsh.exe", "cmd.exe"
    )
        or FolderPath has @"\AppData\"
        or FolderPath has @"\Temp\"
    | project NodeTime = Timestamp, DeviceId,
        NodePath = FolderPath, NodeCommand = ProcessCommandLine, SHA256;
scriptLaunches
| join kind=inner nodeStarts on DeviceId
| where NodeTime between (ScriptTime .. (ScriptTime + 1h))
| project DeviceName, ScriptTime, NodeTime,
    ScriptCommand, NodePath, NodeCommand, SHA256
| order by ScriptTime desc

A result is a high-priority investigation lead. Confirm it with the original email, user activity, file provenance, network destinations and process tree before assigning malware family or actor attribution.

Response and prevention

For a confirmed compromise:

  1. Isolate the device according to the incident runbook.
  2. Preserve the process tree, scripts, file hashes and network destinations.
  3. Trace the original message, URL and redirect chain.
  4. Hunt the same sender, subject, URL structure and payload across the tenant.
  5. Reset affected credentials if the execution context or follow-on evidence supports identity exposure.
  6. Remove unauthorized Node.js installations and persistence only after evidence has been collected.

For prevention, Proofpoint recommends restricting PowerShell where users do not need it, using AppLocker or Windows Defender Application Control to prevent node.exe from running in non-standard user-writable paths, monitoring Ethereum endpoints and inspecting unknown WebSocket traffic. It also suggests considering a policy that disables Windows+R for users who do not need it.

The practical control is scoped application control. A blanket Node.js ban can break developer and business tooling. Deny execution from user-writable paths first, define the approved runtime locations and test the policy before enforcement.

Sources

  1. Secure AI Adoption: Start With the Data Path

    Microsoft's 2026 Data Security Index shows a control gap among surveyed organizations. This is a practical Microsoft security sequence for finding AI use, reducing data exposure and handling incidents.