Tsundere Bot: Hunting the Initial Access Broker Pipeline to Ransomware

The ransomware ecosystem keeps evolving. Initial access brokers (IABs) are leading the charge. Proofpoint recently documented TA584's adoption of Tsundere Bot, a Node.js-based malware-as-a-service platform that's becoming the new favorite for establishing persistent access before ransomware hits.

I run MDR operations at Crayon. IAB activity is often the first warning sign that a customer might be weeks away from a ransomware incident. Today I'm sharing detection strategies for catching TA584's attack chain before it progresses to data exfiltration or encryption.

How does the TA584 attack chain actually work?

TA584's chain is engineered to look like ordinary user behaviour at every step. The victim receives a clean-looking email from a compromised, aged sender account routed through a legitimate email service provider, the link runs through a traffic direction system that fingerprints the visitor and only serves the payload to "interesting" targets, the malicious step is a ClickFix dialog the user executes themselves, and the post-exploitation C2 hides in legitimate Ethereum RPC traffic. Each hop is low-signal in isolation — the detection wins come from joining them.

TA584 has tripled their activity since early 2025. They've expanded targeting beyond North America to include Europe and Australia. Their current attack chain is:

1. Initial Contact: Emails sent from compromised, aged accounts via SendGrid/Amazon SES
2. Filtering: Geofencing, IP filtering, and redirect chains through traffic direction systems (Keitaro TDS)
3. Social Engineering: CAPTCHA followed by ClickFix page with PowerShell instructions
4. Payload Delivery: Obfuscated script loads XWorm or Tsundere Bot into memory
5. Persistence: Tsundere Bot establishes C2 via Ethereum blockchain (EtherHiding technique)
6. Monetization: Access sold on built-in marketplace, often to ransomware affiliates

What makes Tsundere Bot dangerous? It uses blockchain for C2 resolution. Traditional network-based blocking doesn't work against the initial beacon. That's a problem.

Why the Node.js + blockchain combination is unusual

Most commodity malware reaches for the path of least dependency — PowerShell, .NET, or a self-contained PE. Tsundere Bot's choice to ship as a JavaScript payload bound to the Node runtime is a deliberate trade-off: it gains a richer execution environment (real HTTP libraries, native WebSocket support, easy interaction with Ethereum JSON-RPC) at the cost of needing a 50-100 MB runtime installed on disk. That cost is what gives defenders a very clean detection signal — a fresh, unsigned node.exe outside of Program Files and AppData\Local\Programs is rarely legitimate on a non-developer endpoint.

Mapping the chain to MITRE ATT&CK

Stage	ATT&CK technique	What you see in Defender XDR
Phishing email via legit ESP	T1566.002 — Spearphishing Link	EmailEvents, EmailUrlInfo
TDS / redirect filter	T1583.003 — Acquire Infrastructure: VPS	UrlClickEvents (multi-hop URLs)
ClickFix PowerShell	T1059.001 — PowerShell	DeviceProcessEvents (browser → powershell)
Node.js runtime install	T1105 — Ingress Tool Transfer	DeviceFileEvents (node.exe created)
EtherHiding C2 lookup	T1102.001 — Web Service: Dead Drop Resolver	DeviceNetworkEvents (Infura/Alchemy)
WebSocket C2 channel	T1071.001 — Application Layer Protocol: Web	DeviceNetworkEvents (port 443 ws://)
Marketplace listing	T1657 — Financial Theft (precursor)	Out-of-band, no on-host telemetry

How do you detect Tsundere Bot in Defender XDR Advanced Hunting?

Detection works best when you hunt for the behavioural shape of the chain rather than file hashes or domains, both of which rotate. The four queries below each target one stage; the composite query at the end joins them into a single high-fidelity hunt. Run the composite as a scheduled Sentinel analytics rule on a 1-hour cadence and treat any hit as a confirmed incident.

Detecting ClickFix PowerShell Execution

The ClickFix technique relies on users manually running PowerShell. This creates a distinctive pattern: PowerShell launched as a child of a browser process, often with encoded commands or a URL on the command line.

// Detect PowerShell launched from browser context with encoded commands
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "powershell.exe" or FileName =~ "pwsh.exe"
| where ProcessCommandLine has_any ("-enc", "-encodedcommand", "FromBase64", "IEX", "Invoke-Expression")
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe")
| extend DecodedCommand = base64_decode_tostring(
    extract(@"-[eE](?:nc|ncodedcommand)\s+([A-Za-z0-9+/=]+)", 1, ProcessCommandLine))
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, DecodedCommand, InitiatingProcessFileName
| where isnotempty(DecodedCommand) or ProcessCommandLine has "http"

The InitiatingProcessFileName in~ (browsers) clause is what makes this hunt cheap to run — browsers do not spawn PowerShell during legitimate use, so the false-positive rate is dominated by enterprise IT scripts (push-installs, MDM payload bootstrappers) that you can quickly carve out by allow-listing parent command lines.

Hunting for Node.js-Based Malware (Tsundere Bot Indicator)

Tsundere Bot requires Node.js. It installs Node if it's not already there. That fresh-install pattern is a much stronger signal than the runtime itself:

// Suspicious Node.js installations and executions
let nodeInstalls = DeviceFileEvents
| where Timestamp > ago(7d)
| where FileName endswith "node.exe" or FolderPath contains "nodejs"
| where ActionType == "FileCreated"
| summarize InstallTime = min(Timestamp) by DeviceId, DeviceName;
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "node.exe"
| where ProcessCommandLine has_any (".js", "eval", "require", "child_process")
| join kind=inner nodeInstalls on DeviceId
| where Timestamp > InstallTime
| where datetime_diff('hour', Timestamp, InstallTime) < 24
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InstallTime
| extend SuspicionReason = "Node.js execution shortly after fresh install"

For a developer-heavy environment, narrow this further by joining against IdentityInfo and filtering out devices whose primary user belongs to the engineering group. The signal you care about is "node.exe appeared on a marketing laptop within the last 24 hours" — that case is essentially never legitimate.

Detecting Ethereum Blockchain C2 Resolution

The EtherHiding technique queries blockchain APIs. From the host's perspective the traffic looks like ordinary HTTPS to Infura, Alchemy, or a public RPC endpoint:

// Network connections to Ethereum RPC endpoints
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteUrl has_any (
    "infura.io",
    "alchemy.com",
    "etherscan.io",
    "cloudflare-eth.com",
    "eth.llamarpc.com"
)
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe")
| summarize
    ConnectionCount = count(),
    UniqueEndpoints = dcount(RemoteUrl),
    Processes = make_set(InitiatingProcessFileName)
    by DeviceName, DeviceId, bin(Timestamp, 1h)
| where ConnectionCount > 5 or "node.exe" in (Processes)

The trick is the negative filter on browsers: a developer using MetaMask in Chrome will hit Infura constantly, and you don't care about that. A non-browser process (especially node.exe) hitting Infura is a near-binary indicator of EtherHiding.

WebSocket C2 Communication Pattern

Once the C2 address has been resolved, Tsundere Bot uses WebSockets for the command channel:

// Unusual WebSocket connections from non-browser processes
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemotePort in (80, 443, 8080, 8443)
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "teams.exe", "slack.exe")
| where InitiatingProcessCommandLine has_any ("ws://", "wss://", "socket", "websocket")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort, RemoteUrl
| summarize Connections = count(), IPs = make_set(RemoteIP) by DeviceName, InitiatingProcessFileName
| where Connections > 10

Full Attack Chain Correlation

// Correlate ClickFix → Node.js install → Blockchain C2 → WebSocket activity
let clickfixEvents = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe")
| where ProcessCommandLine has_any ("-enc", "IEX", "http")
| project ClickFixTime = Timestamp, DeviceId, DeviceName;
let nodeEvents = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "node.exe"
| project NodeTime = Timestamp, DeviceId, NodeCommand = ProcessCommandLine;
let blockchainEvents = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteUrl has_any ("infura.io", "alchemy.com", "etherscan.io")
| project BlockchainTime = Timestamp, DeviceId, BlockchainUrl = RemoteUrl;
clickfixEvents
| join kind=inner nodeEvents on DeviceId
| where NodeTime between (ClickFixTime .. (ClickFixTime + 1h))
| join kind=leftouter blockchainEvents on DeviceId
| where BlockchainTime between (NodeTime .. (NodeTime + 30m))
| project DeviceName, ClickFixTime, NodeTime, BlockchainTime, NodeCommand, BlockchainUrl
| extend AttackChainConfidence = iff(isnotempty(BlockchainUrl), "High", "Medium")

A row out of this hunt represents a single device that walked the entire chain — ClickFix to Node install to Ethereum lookup — inside the same two-hour window. Two hits in a week across different devices means TA584 is actively running against your tenant, and you should pivot from detection into a tenant-wide IOC hunt and an email-side block on the original sender domains.

What is the right immediate-response playbook?

When these detections fire, time matters. IABs typically maintain access for days to weeks before selling to ransomware operators. You have a window. Use it. The correct first move is device isolation via Defender for Endpoint, not investigation — investigation while the implant is still online lets it phone home and rotate.

Phase 1: Rapid Triage (0-30 minutes)

1. Isolate the device via Defender for Endpoint
2. Check for lateral movement: Query the account's recent authentications across your tenant
3. Identify the email: Trace back to the initial phishing message for IOCs

Phase 2: Scope Assessment (30 min - 2 hours)

1. Hunt for other victims: Search for the same sender, subject patterns, or URLs
2. Check for Node.js installations across the fleet
3. Review blockchain API connections tenant-wide

Phase 3: Eradication

1. Kill malicious processes and remove Node.js if it was illegitimately installed
2. Reset credentials for affected accounts
3. Block IOCs: Sender addresses, domains, file hashes
4. Report to email providers: SendGrid/Amazon SES abuse channels

How do you proactively prevent Tsundere Bot?

The single most effective preventive control is application allow-listing that blocks Node.js outside developer endpoints. Beyond that, the most leverage comes from PowerShell hardening (Constrained Language Mode + script-block logging make ClickFix payloads immediately visible) and email authentication that demotes the compromised aged accounts TA584 uses for delivery.

Application Control: If your organization doesn't need Node.js, block it via AppLocker or WDAC. This single control would break Tsundere Bot completely. For organisations that do need Node, scope the allow-list to specific developer groups (Entra ID security groups), specific install paths (%ProgramFiles%\nodejs\), and signed binaries from the Node.js publisher.

PowerShell Constraints: Enable Constrained Language Mode and script block logging. ClickFix techniques become much more visible with proper logging — Event ID 4104 captures the deobfuscated script content, and Defender XDR ingests it into DeviceProcessEvents.ProcessCommandLine as the fully decoded string.

Email Authentication: Ensure SPF, DKIM, and DMARC are enforced. While TA584 uses compromised accounts, many of their messages fail authentication checks. Configure Defender for Office 365 to quarantine, not just warn, on auth failures from external senders.

User Awareness: Train users to recognize ClickFix pages. The "run this PowerShell command" instruction is a major red flag. Technical users can learn to spot it. For non-technical users, the better defence is Windows policy — disable clipboard access from web pages where possible, and configure browser group policy to block the Win+R prompt being triggered from within a tab.

The bigger picture: IAB → ransomware pipeline

TA584's adoption of Tsundere Bot shows how the initial access broker market keeps professionalizing. The malware's built-in marketplace for selling compromised hosts creates a direct pipeline to ransomware groups.

In our MDR operations at Crayon, we see IAB activity as an increasingly reliable leading indicator of future ransomware incidents. The window between initial compromise and ransomware deployment has shrunk. Sometimes it's just days.

The good news: this attack chain has multiple detection opportunities. From ClickFix social engineering to the distinctive Node.js + blockchain C2 pattern, defenders have several chances to catch and contain this before it escalates. The same composite-scoring approach works for the SharePoint AiTM campaign on the identity side, and for the Sliver C2 hunt on the post-exploitation side — all three are exercises in joining low-signal events into one high-confidence chain.

---

Connect on LinkedIn or see my CV.