Why this matters now
Binance published its first detailed account of the record crypto theft on November 3, 2026, and the entry point was not a zero-day or a stolen key. It was a hiring scam. In June, an engineer on the wallet development team downloaded a tampered software installer — a Homebrew package for an AI coding tool — that exposed the roles of that engineer and colleagues. In September, someone posing as a project director contacted a second engineer through a job-hunting platform; after a video interview with a fake HR representative and a second round with a person posing as the CEO of a fictitious company, the engineer downloaded a coding assignment from a code repository that compromised his work computer. Palo Alto Networks calls this tactic "Contagious Interview."
On October 20, the attackers used that computer, along with an internal Binance AI tool, to take control of two wallet developers' machines. Nine days later they reached the internal wallet signing service and drained about $6.3 billion: 233.46 million XRP left five internet-connected hot wallets in four minutes, with the final unauthorized transfer at 23:56 UTC. The FBI attributed the theft on October 31 to TraderTraitor, a North Korean state-sponsored unit; North Korea has denied the finding, so treat the actor label as the FBI's assessment, not a settled fact. Binance says about $2.85 billion of the stolen assets has been frozen or intercepted, and that it has replenished about 98% of the affected assets and will cover customer losses.
This is not a one-off lure. A joint advisory published September 18 by Japan's National Police Agency and National Cybersecurity Office, the FBI, the U.S. Department of Defense Cyber Crime Center, Australia's Cyber Security Centre, and Germany's BND and BfV attributes the same campaign to a North Korean group it calls WaterPlum — the industry's Contagious Interview cluster — and documents 30,000 infected devices across more than 100 countries and $10.7 million funneled to North Korea, built on fake job interviews and malicious NPM packages. The Binance case is the same playbook aimed at the highest-value developers it could reach. If your engineers install developer tools and take coding assignments from strangers, this hunt belongs on your backlog.
In MITRE ATT&CK terms, the chain maps to T1204.002 (User Execution: Malicious File) for the installer and the coding assignment, T1036 (Masquerading) for the tampered package and the fake employer, T1105 (Ingress Tool Transfer) for the payload download, T1071.001 (Web Protocols) for command and control, and T1059.001/T1059.003 (PowerShell / Windows Command Shell) for the execution that follows. This article hunts the footprints of that chain on developer endpoints, not the interview itself.
The technique, in hunt terms
Think of a Contagious Interview compromise as leaving four kinds of evidence, in roughly this order. First, a developer runs something that arrived outside the normal software pipeline: an installer from a download folder, a package fetched from an unfamiliar source, a coding assignment opened from a repository the team has never used. Second, that installer or package manager does something installers should not do: it spawns a shell, a scripting interpreter, or a living-off-the-land binary. Third, a new executable appears somewhere a developer's tools do not normally write — a download folder, a temp directory, a hidden path under the user profile — and it starts making network connections. Fourth, the compromised machine reaches for things the developer's job does not require: internal AI tools, signing services, credential stores, other developers' machines.
The payloads these lures drop are usually infostealers or remote-access tools, so the endpoint behaviour overlaps heavily with commodity malware — the difference is the delivery story, and that story is what your triage should test. A shell spawned by a Homebrew install at 10 a.m. by an engineer who was interviewing that week is a different finding from the same shell spawned by a scheduled deployment job. Hunt the behaviour first, then check the story against the calendar: who was interviewing, who was onboarding a new tool, who downloaded a coding assignment.
Hunt 1: Installers and package managers spawning shells
An installer should install software, not run shells. When a package manager or installer process becomes the parent of cmd.exe, PowerShell, bash, or osascript, treat it as a compromise indicator until proven otherwise. This query runs in Microsoft Defender XDR Advanced Hunting over the last 14 days; Defender for Endpoint reports these process events on macOS as well as Windows, which matters here because the Binance entry point was a tampered Homebrew package.
DeviceProcessEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("brew", "node", "node.exe", "npm", "npm.cmd", "python", "python.exe", "python3", "msiexec.exe", "setup.exe", "installer")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "bash", "zsh", "sh", "osascript")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
| order by Timestamp descTriage the command line before anything else. A shell spawned by a legitimate build script will usually show a known project path and a known operator account. A shell spawned with encoded arguments, a download cradle, or a connection to an unfamiliar address is the incident. Check what the parent process actually was: a genuine Homebrew install runs from a known location, while a tampered package may run from a download folder or a temp path. The same parent-child logic generalises to living-off-the-land binaries — see Case File: Living Off the Land — Hunting rundll32 and mshta Abuse in Plain Sight for the same pattern on other binaries.
Hunt 2: Executables first launched from download and temp folders
Developer tools are installed from managed sources or known paths. An executable first launched from a Downloads folder, a temp directory, or a user-profile path is the shape of a coding assignment or a tampered installer being run by hand. This query surfaces those launches:
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FolderPath contains @"\Downloads\" or FolderPath contains "/Downloads/" or FolderPath contains @"\AppData\Local\Temp\" or FolderPath contains "/tmp/"
| where FileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe")
| project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
| order by Timestamp descFor every hit, answer three questions: who ran it (a developer account, and whether that person was interviewing or onboarding a tool that week), what ran it (the initiating process should be a browser download or a terminal, not another installer), and what it did next (join the timestamp to network events — a new binary that immediately connects outbound is a far stronger signal than one that sat idle). If the result set is large, narrow it with a second pass: binaries that first appeared on the device in the last seven days.
DeviceProcessEvents
| where Timestamp > ago(30d)
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp),
Devices=dcount(DeviceName), Runs=count() by FileName, FolderPath
| where FirstSeen > ago(7d)
| order by FirstSeen descA binary that appeared once, on one developer's machine, days after a fake interview, is exactly the footprint this campaign leaves. Correlate it with the interview calendar before you dismiss it: the Binance timeline ran June to October, so a single first-seen binary from months ago is still in scope if it matches the story.
Hunt 3: Developer-tool processes talking to unfamiliar destinations
Where Defender telemetry is unavailable, Sysmon data carries the same signal. The Splunk search below finds processes launched by installers, package managers, or downloads, and a second search flags developer-tool processes opening connections to many distinct destinations — the command-and-control shape of a dropped infostealer phoning home.
index=endpoint EventCode=1 (ParentImage="*\\Downloads\\*" OR ParentImage="*brew*" OR ParentImage="*node.exe" OR ParentImage="*npm*" OR ParentImage="*python*")
| stats earliest(_time) as first_seen, values(Image) as images,
values(CommandLine) as cmdlines, values(User) as users by Computer
| sort first_seenindex=endpoint EventCode=3 (Image="*\\node.exe" OR Image="*\\python.exe" OR Image="*\\python3" OR Image="*brew*")
| stats dc(DestinationIp) as distinct_destinations,
values(DestinationHostname) as hosts by Computer, Image
| where distinct_destinations > 10Adapt the index and field names to your endpoint data — the hunt is the pattern (a dev-tool process with an unusual parent, or one talking to many destinations it has never contacted), not the exact field spelling. A coding-assignment binary that opens one connection to a code repository is normal; one that opens connections to a dozen unfamiliar addresses in its first hour is not. The same post-compromise logic applies to sessions: once the lure lands, the attacker harvests tokens and sessions, and the playbook for chasing that is covered in Hunting Token Theft via Microsoft Teams Message Exfiltration.
Triage: sorting real compromise from noise
Work each hit through this order. First, confirm the story: ask the account owner whether they installed a new tool, ran a coding assignment, or interviewed in the window around the hit — a "yes" with a matching employer name turns a suspicious binary into a lead, not a false positive. Second, check the file itself: read it, hash it, and compare it against the vendor's published release; a tampered Homebrew package will not match the upstream hash, and a coding assignment that is really an executable has already failed the smell test. Third, check the network: look for outbound connections from the process in the hours after first execution, and for connections to destinations the device has never contacted. Fourth, check the blast radius: the Binance attackers moved from one compromised computer to two wallet developers' machines via an internal AI tool, so check whether the account touched shared services, signing infrastructure, or colleagues' machines after the hit.
Close a hit as benign only with evidence, not with familiarity. "That developer always installs tools" is not evidence; a matching hash from the vendor, or a change record from your own software pipeline, is. Anything you cannot explain goes into containment: isolate the machine, preserve logs before they rotate, and check the accounts that machine could reach. The payloads in this campaign are usually infostealers — the endpoint behaviour after the lure lands is covered in Hunting Infostealer Clipboard and Screenshot Capture.
Remediation and hardening
If a hunt hit confirms compromise, the sequence matters. Isolate the machine and remove the dropped files, then rotate every credential that machine could reach — the developer's own passwords and tokens first, then any shared service credentials, signing-service access, and session tokens, because a Contagious Interview payload harvests credentials before it does anything else. Force-logout all sessions so a stolen session cookie dies with the account. Then hunt laterally: the Binance timeline shows a five-month gap between the first installer and the theft, so check every machine the compromised account touched, not just the one that ran the lure.
For machines that hunt clean, the hardening that prevents the next round is straightforward: restrict software installation to managed sources and signed packages, and verify the hash of any developer tool installed outside the pipeline; treat coding assignments as untrusted code — run them in an isolated virtual machine or a sandbox, never on a machine with access to production systems or signing services; and brief engineers that a job interview is now a known attack vector, so an unexpected installer or assignment from a recruiter gets a second look before it gets a double-click. The 30,000 infected devices in the joint advisory are a warning about scale. The hunt above is about the one developer on your team whose interview was not real. Run it over every developer workstation, starting with the people who interviewed, onboarded a new tool, or ran an unfamiliar coding assignment in the last six months.
