TraderTraitor's Binance Playbook as STIX: Three Reports, One Graph

tl;dr

• About $6.34 billion was taken from Binance’s hot wallets in under four hours, and about $2.85 billion has since been frozen.
• About five months passed between a tampered Homebrew (a macOS package manager) download and the theft.
• The only host artefacts Binance published are the file operations behind one swapped pyenv executable, which grew by 70 bytes.

Three reports, three different views

On the evening of 29 October 2026 (UTC), attackers emptied Binance’s hot wallets, the online wallets it uses to process withdrawals. Two days later the FBI, the US Secret Service and IRS Criminal Investigation attributed the theft to North Korea’s TraderTraitor. Their alert is a list of wallet addresses to block. It contains no technical detail about how the attackers got in.

The technical story arrived over the following week, in three reports that each saw something different:

An analyst reading all three can hold the full picture in their head. A detection pipeline, a threat intelligence platform or an AI agent cannot. They need the three accounts as data, joined where they overlap and kept apart where the evidence doesn’t connect them.

STIX 2.1 can do that: one graph that joins the three reports, puts Binance’s account in sequence, separates confirmed indicators from related ones, and records how sure each source is. If you are new to STIX, Understanding STIX 2.1 Objects explains the object types used below.

What Stixify extracted from each report

The first step is to turn each report into STIX, so I uploaded all three to Stixify. Here is what Stixify extracted:

• Binance’s report produced a threat actor (the Democratic People’s Republic of Korea), the FBI and Binance as identities, pyenv as a tool, and a generic “Social engineering” attack pattern.
• ReversingLabs’ report produced the most: file hashes for the Terraform toolset, an IP address, and ATT&CK techniques from its mapping of Binance’s steps and of the toolset.
• Vectra’s report produced two techniques, Supply Chain Compromise (T1195) and Valid Accounts (T1078). Vectra gives no ATT&CK IDs; Stixify extracted both from its description of the tampered download and the attacker’s valid credentials.

Nothing is shared, even where the reports reach for similar techniques. ReversingLabs maps the Terraform toolset to Compromise Software Dependencies and Development Tools (T1195.001). From Vectra’s account of the June tampered Homebrew download, Stixify extracted the parent technique, Supply Chain Compromise (T1195). Techniques from the same family land on different objects, for different events. No report produced TraderTraitor as an object. ReversingLabs builds on Binance’s findings throughout and Vectra links to them, but those cross-references exist only as prose and links, not as STIX relationships.

Joining the three reports: intrusion set, campaign and malware

None of the three graphs contains the thing they all describe, a campaign by TraderTraitor, so the join starts there:

• a campaign, “Binance hot wallet theft, October 2026”, which each of the three reports references and which targets the Binance identity
• an intrusion set, TraderTraitor, with the aliases ReversingLabs lists for it (UNC4899, Jade Sleet, Slow Pisces, Pressure Chollima). The name comes from CISA advisory AA22-108A, published in April 2022, which used it for the group’s trojanised cryptocurrency apps.
• attributed-to relationships from the campaign to TraderTraitor, and from TraderTraitor to the North Korea (DPRK) threat actor from Binance’s report
• malware objects for FLATROOF and ROOFDECK, from the ReversingLabs report
• the campaign’s uses relationships to pyenv and to techniques from each report: Social engineering (Binance); from ReversingLabs’ mapping of Binance’s steps, not its Terraform analysis, Spearphishing via Service (T1566.003), Steal Application Access Token (T1528) and Deploy Container (T1610); and Supply Chain Compromise (T1195) and Valid Accounts (T1078), as extracted from Vectra

Every report reaches every other report in two hops, through the campaign. A query for “everything known about TraderTraitor’s Binance campaign” returns what all three reports contain, together.

Keeping the caveat in the data

Linking FLATROOF and ROOFDECK straight to the Binance campaign would make the graph look complete, and would state something no source says.

ReversingLabs is explicit that no source ties the Terraform toolset to Binance, and that it can’t tell whether the pyenv implant shares code or infrastructure with it. Zscaler, as ReversingLabs reports, links the toolset to TraderTraitor at medium confidence. ROOFDECK is linked to FLATROOF, which installs it, through a drops relationship. FLATROOF is linked to TraderTraitor (the intrusion set), not to the Binance campaign, and that relationship carries Zscaler’s medium confidence as 50. The campaign’s attribution to TraderTraitor, and TraderTraitor’s to North Korea, get 85, because US law enforcement and the blockchain analytics firm TRM Labs (at high confidence, as ReversingLabs summarises) both state it.

Confidence says how sure you are of a link but not why a link is missing, so a note on the campaign and both malware objects records that ReversingLabs can’t tie the toolset to Binance, and that the missing relationship is deliberate.

The close-up below shows the campaign, TraderTraitor, the malware and the note.

A downstream tool that filters on confidence, or an agent that reads notes before answering, now gets the same caution the original authors wrote into their prose. If someone later confirms the link, you add one relationship and retire the note, without rewriting anything else.

The incident as an Attack Flow

The joined graph says what TraderTraitor used against Binance, but not in what order. An Attack Flow, a STIX extension, links ATT&CK techniques into that sequence, and this one is linked to the campaign. If you are new to Attack Flows, How to Build Dynamic Attack Flows with STIX explains how the objects fit together.

This flow contains only the steps Binance describes, in the order Binance gives them. For the same reason as the note above, it leaves out the Terraform toolset.

Binance refers to the staff involved as Engineers A, B and C. The flow has 13 actions, grouped here by date:

• June: a tampered Homebrew download on Engineer A’s machine (T1195, Supply Chain Compromise, as Stixify extracted it from Vectra; ReversingLabs suggests Drive-by Compromise (T1189) as “likely”). Binance caught it and rotated credentials, but the attacker had already mapped the wallet team (T1591.004, Identify Roles).
• September: fake Project Director, HR and CEO personas (T1585, Establish Accounts) approach Engineer B through a legitimate job platform and a chat app (T1566.003, Spearphishing via Service). An “assignment” repository runs during setup (T1204.002, Malicious File), replaces pyenv with a malicious build (T1554, Compromise Host Software Binary; ReversingLabs also gives Hijack Execution Flow, T1574), then contacts an attacker server (T1071, Application Layer Protocol). The implant also removes its traces, which ReversingLabs maps to File Deletion (T1070.004); the flow records that in the step’s description rather than as a separate action.
• 20 October: from Engineer B’s machine, an internal AI tool is used to take control of Engineer A’s and Engineer C’s machines (no technique, see below). A token with container deployment permissions is taken from Engineer A’s machine (T1528, Steal Application Access Token).
• 29 October, from 17:15 UTC: a container is deployed from Engineer C’s machine with Engineer A’s credentials and reaches the wallet signing service (T1610, Deploy Container).
• From 20:05 UTC: the signing service sends XRP, SOL, OP and BTC from the hot wallets to attacker addresses (T1657, Financial Theft).
• The attacker then uses the signing service to abuse EIP-7702, an Ethereum feature that lets a wallet hand execution rights to a smart contract (no technique, see below). Funds keep leaving after Binance pauses withdrawals, until the last transfer at 23:56 UTC (T1657).

Two steps ATT&CK can’t name

The internal AI tool. Remote Services (T1021) and Software Deployment Tools (T1072) are the nearest techniques, and ReversingLabs marks both as only “likely”. Binance hasn’t disclosed which tool it was or how it gave the attacker control, so neither can be confirmed. Vectra makes the defensive point directly: internal AI tools are trust boundaries and should be monitored as such.

EIP-7702 delegation abuse. The attacker used the signing service to sign 50 transactions that gave an attacker-controlled smart contract partial control of a Binance hot wallet. Those permissions lived on the blockchain, so pausing withdrawals on Binance’s side didn’t stop them. ReversingLabs suggests Transmitted Data Manipulation (T1565.002) while saying the step doesn’t map cleanly; that technique covers tampering with data in transit, not on-chain delegation.

An Attack Flow action doesn’t need a technique_id. The detail a technique ID can’t carry goes in a procedure object instead: what the attacker was trying to achieve, the environment it worked in, and what had to be true for it to work. If you are new to procedure objects, TTPs Are Missing the P: Let’s Fix That explains why dogesec models procedures and how the object is structured.

Each of the two steps has a procedure, linked to its Attack Flow action:

The EIP-7702 procedure records the objective (keep control of hot wallet funds after withdrawals are paused), the context (an Ethereum hot wallet signed through an MPC signing service, where several parties jointly produce each signature, so no single key can quickly revoke a delegation) and the preconditions, which are where the defensive value is. One of them, access to the signing service outside the normal withdrawal flow, is something a defender can actually remove, whatever the next variant of this attack looks like on-chain.

IoCs you can hunt with

The pyenv swap is the only indicator confirmed on Binance’s machines, so it alone points to the campaign, at confidence 100. The other 17 come from ReversingLabs’ Terraform analysis. They point to FLATROOF or ROOFDECK at confidence 50, and each description says it is not a confirmed Binance IoC.

The Binance artefact is a file event, not a hash. Binance published the file operations, not the file itself: a pyenv_ staging file is created in /opt/homebrew/Cellar/pyenv/2.8.0/libexec, the legitimate 3,344-byte pyenv is deleted, and the 3,414-byte replacement is renamed into place.

That path is Homebrew on Apple Silicon with pyenv 2.8.0. Intel Macs install under /usr/local/Cellar, and other pyenv versions use a different directory, so adjust the path to your fleet. A broader hunt is any libexec/pyenv whose size doesn’t match the legitimate file for that pyenv version (3,344 bytes for 2.8.0).

The toolset indicators cover delivery, payload hosting and C2. The file hashes are the SHA-256 values from ReversingLabs’ IoC table, and the full list, with each indicator’s STIX ID, is in the reference section at the end. Several of those hosts and URLs sit on shared services: dynamic DNS providers, Vercel, GitHub and Pastebin. Block the full hostname or URL. Blocking serveftp.com or vercel.app takes out every legitimate customer of those services along with the attacker.

The trojanised provider reaches victims through Terraform lock files (.terraform.lock.hcl) that point at a lookalike registry. That suggests a hunt that doesn’t depend on any IoC: look for lock files that reference a registry other than registry.terraform.io (or registry.opentofu.org, if you use OpenTofu, the open-source Terraform fork). Teams that run a private registry or Terraform Cloud will see legitimate hits too, so allow-list those first.

Writing a Sigma rule for the pyenv swap

A Sigma rule is a YAML file that describes suspicious activity in a log, which detection tools then convert into queries for a specific SIEM. If you are new to Sigma, Writing Effective Sigma Detection Rules: A Guide for Novice Detection Engineers explains each field.

Every indicator above can change overnight: a new domain, a rebuilt binary, a new hash. The behaviour in the pyenv step is harder to change, which makes it a good first rule to write. The rule below is adapted from one in the ReversingLabs report, which also has a rule for the Terraform provider if you want rules to deploy rather than to learn from.

Binance’s account gives one reliable signal: a file called pyenv_ appears in pyenv’s libexec directory just before the real pyenv is swapped out. The ReversingLabs original already covers both Apple Silicon (/opt/homebrew) and Intel (/usr/local) Homebrew paths. This version matches /Cellar/pyenv/ under any install prefix, drops the original’s exclusion for the brew process, and keeps only the T1554 tag, so it maps to the one flow step it detects:

title: pyenv Staging File Created in a Homebrew Install
id: 7b6dc95f-61f9-5486-9e72-cd7561a12a79
status: experimental
description: Detects a pyenv_ staging file being created in the libexec directory of a Homebrew pyenv install. In the September 2026 compromise that preceded the Binance theft, this file was created before the legitimate pyenv was deleted and replaced with a malicious build. Adapted from the ReversingLabs rule, generalised to any Homebrew install prefix and without its exclusion for brew itself.
references:
    - https://x.com/binance/status/2117626126214504729
    - https://www.reversinglabs.com/blog/binance-heist-what-we-know-and-what-rl-sees-in-tradertraitors-toolkit
author: dogesec
date: 2026-11-05
tags:
    - attack.persistence
    - attack.t1554
logsource:
    product: macos
    category: file_event
detection:
    selection:
        TargetFilename|contains: '/Cellar/pyenv/'
        TargetFilename|endswith: '/libexec/pyenv_'
    condition: selection
falsepositives:
    - Manual patching of pyenv by a developer (rare)
level: high

The logsource says which telemetry the rule needs (file creation events from macOS endpoints), and the tags map it to the same ATT&CK technique as the flow step, T1554. Converted with the pySigma Splunk backend, the rule becomes:

TargetFilename="*/Cellar/pyenv/*" TargetFilename="*/libexec/pyenv_"

To convert it for your own SIEM, An Introduction to pySigma: Converting Sigma Rules to Work with Your SIEM walks through the process and how to check the result.

As a STIX indicator with pattern_type: sigma, linked to the pyenv action with a detects relationship, the rule sits on the same graph as the attack:

With rules linked to actions, the flow shows which steps you can detect and which you can’t. Here only the pyenv step has a rule, which makes the gaps visible: nothing yet covers the AI tool pivot, the stolen token or the signing service. If you want to take this further, Using Sigma Rules in Attack Flows for Detection Coverage and SOC Triage shows how to use those links to track detection coverage across a flow.

The whole theft in one graph

Put together, the graphs are one model of the theft: the three reports joined through the campaign, Binance’s steps in order with their procedures, the indicators split by what each source can support, and a detection on the step it covers.

If you run OpenCTI, the open-source threat intelligence platform, read OpenCTI Is Not a STIX Database before importing these graphs; it explains why OpenCTI may not store them exactly as written.

In summary

Three reports on the Binance theft started as three unconnected STIX graphs. A campaign and an intrusion set join them. FLATROOF attaches to TraderTraitor at confidence 50, ROOFDECK hangs off FLATROOF, and a note explains why neither touches the campaign. The Attack Flow puts Binance’s confirmed steps in order, leaving two without an ATT&CK technique rather than forcing a match. The result is one graph you can hunt with: one confirmed Binance indicator and 17 related ones, each carrying its source’s confidence, and a Sigma rule linked to the pyenv step it detects.

Reference: IoCs and ATT&CK techniques

For copying into tools that don’t use STIX. Each row gives the STIX ID of the matching object in the graphs above.

IoCs

Domains, URLs and the IP address are defanged ([.], hxxps). “Linked to” is the object each indicator points to: the campaign for the one indicator confirmed on Binance’s machines, and FLATROOF or ROOFDECK for the Terraform toolset indicators, which are not confirmed for Binance.

ATT&CK techniques

The steps of the Attack Flow, in order. Steps 8 and 12 have no ATT&CK technique; their STIX ID is the procedure that describes them.