Binance heist: what we know, and what RL sees in TraderTraitor’s toolkit

Updated November 4, 2026

On October 29, 2026, attackers stole approximately $6.34 billion in digital assets from Binance in one of the largest cryptocurrency thefts on record. Since our initial analysis, two significant developments have clarified how the attack unfolded.

On October 31, the FBI formally attributed the theft to North Korea’s TraderTraitor operation. On November 3, Binance released its initial incident findings, revealing a multi-stage compromise involving malicious software delivered through a fake job interview, compromised developer systems, and the abuse of internal wallet infrastructure.

The new findings reinforce a growing concern for security teams: attackers are increasingly targeting trusted developer tools and environments to gain access to critical systems.

That is where ReversingLabs’ original research provides additional insight.

Our analysis of TraderTraitor’s broader malware toolkit uncovered malicious components in ReversingLabs telemetry 77 days before public disclosure, identified backdoor variants with earlier submission histories, and revealed how malicious code can hide within otherwise legitimate developer software.

While ReversingLabs has not established a direct connection between the malware samples examined here and the Binance compromise, our findings offer additional intelligence into the techniques, tooling, and detection challenges associated with TraderTraitor activity.

What Binance has confirmed

Binance’s November 3 incident report describes a sophisticated, multi-stage campaign that extended over several months:

• June 2026 — Initial exposure: A Wallet DevOps engineer downloaded a tampered Homebrew installation while attempting to install an AI coding tool. Binance detected the activity and replaced the affected device, but the attackers had gained insight into the engineer’s role and colleagues.
• September 2026 — Malicious job interview: A second engineer was approached by a fraudulent recruiter and instructed to download a coding assignment from an online repository. The repository contained malicious code that executed during setup, replacing a legitimate development tool component and evading endpoint security detection.
• October 20 — Lateral movement: The attackers leveraged the compromised workstation and an internal AI tool to compromise two additional engineering systems, gaining access to credentials and a container deployment token.
• October 29 — Wallet compromise: The attackers used stolen credentials and deployment access to reach Binance’s wallet signing infrastructure and initiate unauthorized transactions.

The attack demonstrates how a developer-focused social engineering campaign can progress into a compromise of business-critical infrastructure.

Binance has since rebuilt affected systems, replaced compromised devices, revoked exposed credentials, and strengthened its security controls. Its investigation and independent review remain ongoing.

What third parties report (not verified by RL)

On-chain mechanics. TRM Labs, Elliptic and Cointegrity have published consistent accounts of how the funds moved. RL has not independently verified them. The points that matter for defenders:

• The attacker’s operator wallet was funded from Tornado Cash on October 28. A “sweeper” contract was deployed and rehearsed on October 29 before the final version went live at 15:59 UTC.
• At 20:05 UTC, 233.46 million XRP left five Binance XRP Ledger wallets. Solana, Optimism and other chains followed.
• At 20:20 UTC, one Ethereum type-4 transaction carried 50 EIP-7702 authorizations signed by hot wallet “Binance 14,” one per nonce from 18,914,775 to 18,914,824, delegating the wallet to the sweeper. A single sweep() call then moved about 167,464 ETH, 1.615 billion USDT and 62 other tokens.
• Between 21:01 and 21:04 UTC, Tether and Circle froze 971 million USDT and 823 million USDC. Roughly $3 billion was frozen in total.

On nine of the ten chains, funds left through ordinary signed transfers, which fits Binance’s statement that no keys leaked. We assess with moderate confidence, consistent with TRM’s reading, that the attacker controlled the path that requests signatures rather than the keys themselves. Preparing 50 authorizations across consecutive nonces suggests time-limited access to that path, or signing through a system the attacker did not fully own.

Attribution: On October 31, 2026, the FBI officially attributed the Binance theft to North Korea’s TraderTraitor operation, confirming earlier assessments from blockchain intelligence firms, including TRM Labs and Chainalysis.

This establishes government attribution for the attack. However, attribution of the broader intrusion does not establish that any particular malware sample identified in ReversingLabs’ historical telemetry was deployed against Binance.

Our analysis therefore distinguishes the confirmed incident attribution from the separate technical findings involving TraderTraitor’s previously documented developer-targeted malware.

The precedent comes from government attribution of earlier thefts: the FBI attributed the February 2025 Bybit theft to TraderTraitor, and the FBI, Japan’s NPA and the DC3 attributed the 2024 DMM Bitcoin theft to the same group. The address that received both Binance and Bitget proceeds, 0x15104a9ce0f08a8f0075a0869ae80e795fe0feb7, is the most specific shared artifact published so far.

TraderTraitor, also tracked as Jade Sleet, UNC4899, Slow Pisces and Pressure Chollima, is a financially motivated North Korean cluster within the broader Lazarus umbrella. Its access pattern is consistent across cases: a social-engineering lure aimed at an engineer, malware on that engineer’s workstation, theft of session material or credentials, then abuse of the victim’s own transaction approval process. In the Bybit case, the entry point was a Safe{Wallet} developer’s macOS machine.

What is still unknown

Despite the additional disclosures, several important questions remain:

• Whether the specific Terraform provider, FLATROOF, or ROOFDECK samples analyzed by ReversingLabs were involved in the Binance intrusion.
• The complete set of malware artifacts, hashes, and network indicators associated with Binance’s compromised endpoints.
• Whether the broader TraderTraitor malware activity observed in RL telemetry shares additional infrastructure or code with the Binance attack.
• The contents of two previously unpublished WOFF files surfaced by ReversingLabs’ YARA hunting, which were unavailable for download and further validation.

Binance has provided technical details about the malicious development-tool replacement used in the attack, but a complete public account of the malware and its infrastructure remains unavailable.

What RL data shows: TraderTraitor’s DevOps toolset

Binance’s findings confirm the role of malicious developer software in the intrusion. But they also raise a broader question: how early can defenders identify malicious code when it is embedded in software that otherwise appears legitimate?

ReversingLabs’ analysis provides a valuable perspective.

Our telemetry captured a trojanized Terraform provider 77 days before it was publicly documented. The malicious binary appeared alongside 16 legitimate provider builds, demonstrating how difficult it can be to distinguish compromised software using conventional similarity and reputation signals alone.

Further analysis uncovered likely earlier variants of the ROOFDECK backdoor and identified malware operating under generic threat classifications that would not necessarily surface in searches for TraderTraitor.

These findings are not evidence that the specific samples were used against Binance. They are independent insights into the broader threat landscape and the challenges defenders face when investigating sophisticated software supply chain attacks.

On October 8, 2026, Zscaler ThreatLabz published research on a campaign it attributes, with stated caution, to TraderTraitor. It uses a trojanized Terraform AWS provider to infect DevOps engineers. SlowMist separately reported weaponized .terraform.lock.hcl files in fake-interview repositories that pull the malicious provider when the victim runs terraform init, and HivePro published an advisory with additional hashes, domains and IPs.

RL researchers looked up every published file and network indicator in Spectra Intelligence, ran similarity (RHA) pivots on each sample RL holds, and queried the RL data warehouse for submission history, scanner coverage and ATT&CK mappings produced by Spectra Core. Classifications, threat names and scanner counts come from the Spectra Intelligence File Reputation API (TCA-0101), cross-checked against the warehouse. The summary tiles in the figures show Spectra Analyze’s “community threat detections” count, which runs one or two lower.

Part 1: The trojanized Terraform provider

RL first saw terraform-provider-awsbeta_v1.0.0 (SHA-1 8473f85bda00dfa3…) on July 23, 2026, at 01:06 UTC, 77 days before the public write-up. RL classifies it as malicious, threat name MacOS.Trojan.Multiverze. It is a 17.5 MB 64-bit Mach-O built from Go.

RHA, RL’s functional similarity hash, places it in a cluster of 17 Mach-O files first seen between March and October 2026. Sixteen are goodware, legitimate Terraform AWS provider builds. The malicious provider looks almost identical to the real thing because it is the real thing, with a small malicious package compiled in that runs when Terraform loads the plugin.

Figure 1. RHA similarity results for the trojanized provider in Spectra Analyze. Note that one malicious sample sits among 16 goodware provider builds; similarity alone cannot separate them.

Anything that judges a binary by its overall structure, including fuzzy-hash allow-listing, will tend to wave this file through, and 7 of 24 scanners in RL’s multi-scanner records flag it. Per Zscaler, the provider checks for a run-once marker (session.lock), downloads a Bash script from diagnose[.]hashicorp-terraform[.]io, saves it as safari_updater, runs it detached, and then works as a normal provider so terraform plan and apply behave as expected.

Part 2: The loader and the font-file payload

Twelve minutes later, safari_updater (SHA-1 d81081691c3631f3…) arrived. The 5.6 KB shell script is suspicious under the generic name MacOS.Trojan.Generic, with 11 of 24 scanners detecting it. It picks a payload by operating system and CPU architecture, each hidden in a file named like a font: decoy WOFF data, an @@ENDFONT@@ marker, then a Base64-encoded, AES-256-CBC-encrypted executable. Zscaler published eight container hashes. RL holds one, the macOS ARM64 HiraginoSans-Regular.woff (SHA-1 4402e44c0bc959ac…), which arrived a minute after the loader and carries a suspicious verdict under the family-specific name MacOS.Trojan.Flatroof. The other seven are absent from RL’s repository. Here’s what you need to know: the stage that carries the actual backdoor is the stage least likely to be shared, scanned or retained, which makes the network and behavioral indicators below more important than the hashes.

Figure 2. Spectra Analyze record for the FLATROOF font container. Note the WOFF file type and the suspicious classification despite the file presenting as a font.

Inside the loader. RL downloaded both files from Spectra Analyze and read the script. It tries three base URLs in order: hxxps://https://supportaru[.]serveftp[.]com/statics/cache/v11, then a GitHub mirror under hxxps://raw[.]githubusercontent[.]com/bluearuhost/hospitalrun-frontend/refs/heads/main/public/fonts/version1/, then hxxps://stage-fashion365[.]vercel[.]app/static/tinymce4.7.5/plugins/fonts/v1104. The primary entry carries a doubled scheme, https://https://, exactly as shown, so that request cannot succeed as written and every run of this build falls through to the GitHub mirror. We read this as a likely operator error. The font family encodes the operating system (NotoSansCJK for Linux, HiraginoSans for macOS, MalgunGothic for Windows) and the style encodes the CPU (Bold for x86_64, Regular for arm64, ExtraBold for armv7 or armv6, Italic for i386).

Decryption is grep -a -b -o for the marker, then openssl enc -d -aes-256-cbc -md md5 -base64 -A with the hardcoded passphrase PTa3WZPQZAjj55t@. That is OpenSSL’s legacy EVP_BytesToKey derivation with MD5, so the Base64 blob in every container built this way starts with U2FsdGVkX1, the encoding of Salted__. The key is in the script. Nothing else is needed to decrypt a container. Output is written through python3, node, perl or openssl, in that order. The payload lands at $HOME/.config/git/update on Linux, $HOME/Library/com.apple.iTunesCloud/SystemUpdate on macOS or $HOME/AppData/Local/Microsoft/Edge/service.exe on Windows. On macOS the loader strips com.apple.quarantine with xattr and ad-hoc signs the file with codesign -s -. It launches the payload detached with the argument –type=renderer, so a process listing shows what looks like a Chromium renderer. The self-delete line, rm — “$0”, is commented out. The script stays on disk.

The decrypted payload. We applied the same split-and-decrypt logic to the RL-held container in an isolated scratch environment and never executed the output. The result is a 2,295,744-byte Mach-O 64-bit arm64 executable written in Rust, with Rust crate paths under /Users/dev/.cargo/, Telegram error strings and a “~/.zlogout created by script” marker, all consistent with Zscaler’s description of FLATROOF. Spectra Intelligence already held it (SHA-256 3c254614de8c1a2f…), classified malicious under the name MacOS.Trojan.Gaslight, flagged by 10 of 24 scanners and first seen at 01:17:59 UTC on July 23, 2026, inside the same submission window as the provider, the loader and the container. That is a fourth RL family name for the toolset, and none of them says TraderTraitor: Multiverze for the provider, Flatroof for the container, Gaslight for the decrypted FLATROOF and GetShell or ReverseShell for ROOFDECK.

Part 3: ROOFDECK, and evidence of earlier activity

FLATROOF is a Rust backdoor that runs Python credential stealers and then installs a second backdoor, ROOFDECK. Zscaler published one macOS and one Windows ROOFDECK hash, and both are in RL’s repository with a submission history worth noting.

macOS ROOFDECK. The imagent sample (SHA-1 93c655963d7dd6ca…) was first seen by RL on July 23 at 01:18 UTC, in the same 13-minute window as the provider, loader and container. It is malicious, threat name MacOS.Backdoor.GetShell, flagged by 21 of 38 scanners. An RHA pivot found two more malicious macOS samples in the same cluster, both named MacOS.Exploit.ReverseShell: 20e541a41fc8b0e2…, first seen May 22, 2026, and 5728b11d30586bbf…, first seen July 13, 2026. Neither appears in the Zscaler or HivePro reports. Spectra Core maps both to the same ATT&CK techniques as the published sample, all three files are 4.7 MB, and their TLSH digests differ in at most four of 72 characters. We assess with high confidence that these are builds of the same program, and likely earlier ROOFDECK builds, which would put the macOS backdoor in circulation at least two months before the July discovery. The ROOFDECK name rests on Zscaler’s identification of imagent; we have not reverse engineered the siblings.

Windows ROOFDECK. update.exe (SHA-1 0b7ca6630ea1e66b…) was first seen by RL on September 9, 2025, ten months before the reported discovery. It is malicious, threat name Win64.Trojan.ReverseShell, and 14 of 23 scanners detect it. It was submitted under names such as RustyStealer_9d88b4494c7bc27b10358b68a899ad54.exe and 2025-09-09_9d88b4494c7bc27b10358b68a899ad54_akira_rusty-stealer, so in 2025 it was circulating as a generic Rust stealer that some submitters linked to Akira.

Figure 3. Spectra Intelligence summary for Windows ROOFDECK. Note FIRST SEEN CLOUD 2025-09-09 03:57 UTC and the generic threat name Win64.Trojan.ReverseShell.

On both platforms the backdoor was detected as malicious, but under generic names that gave no hint it belonged to a state actor’s crypto-theft toolkit. RL found no sample carrying a TraderTraitor-specific threat name first seen between June 2025 and October 2026. Analysts searching their telemetry for “TraderTraitor” or “Lazarus” labels will not find this toolset.

Part 4: The HivePro indicators are historical

HivePro’s advisory lists 11 SHA-256 hashes and a set of domains. RL holds all 11 files, all malicious, and all between four and six years old:

These are AppleJeus-era trojanized crypto trading applications, legitimate historical TraderTraitor IOCs that do not belong to the 2026 campaign. The domains follow suit. Of 29 files RL has downloaded from five HivePro domains, 28 are goodware; the one malicious download came from technicais[.]sytes[.]net (MacOS.Backdoor.GetShell), and among the HivePro IPs, 176[.]97[.]114[.]232 (AS6698) is the only one from which RL holds a malicious download. Import the HivePro list as hunting context only. Pushing it to an enforcement blocklist will produce false positives and will not detect the 2026 toolset.

Part 5: Network infrastructure

Third-party detection of the 2026 network indicators is thin. Across RL’s URL and domain reputation sources, the 2026 domains are flagged by between 0 and 5 of roughly 49 vendors, and the lookalike registry registry[.]hashicorp-terraform[.]io, the domain a weaponized lock file points at, has none, so a lock file that pins providers to a non-HashiCorp registry is a stronger signal than any reputation score. RL’s URL records first saw hxxp://arusupport-region1-webhook[.]online/ on July 25, 2026, from a third-party source that flagged it as detected, 75 days before the Zscaler publication, and the hashicorp-terraform[.]io lookalikes first appear in those records on September 25, 2026.

One timing coincidence needs stating. RL’s index holds browser-profile artifacts that reference the FLATROOF hosts and were first seen on October 29 between 19:43 and 20:10 UTC, minutes before the first Binance outflow. RL warehouse data shows they were written by three Joe Sandbox URL analyses of the published Zscaler URLs, run on Linux with Firefox 112, each returning “no threats found” with no sample detonated, and the same URLs had been re-checked repeatedly since early October. We assess that routine re-analysis of public IOC URLs accounts for the timing. No victim produced these files, and they do not connect the toolkit to Binance.

Infection chain

The chain below combines Zscaler’s analysis with the samples RL holds. Stages marked [RL] are present in RL’s repository.

fake interview repo  (.terraform.lock.hcl -> registry[.]hashicorp-terraform[.]io)
└── terraform init
    └── terraform-provider-awsbeta_v1.0.0          [RL] malicious, MacOS.Trojan.Multiverze
        ├── writes session.lock                     (run-once marker)
        └── sh -c ./safari_updater &                [RL] suspicious, MacOS.Trojan.Generic
            ├── curl <font>.woff from supportaru[.]serveftp[.]com | GitHub | Vercel
            │                                       [RL] 1 of 8 containers, MacOS.Trojan.Flatroof
            ├── split at @@ENDFONT@@ -> base64 -d -> AES-256-CBC decrypt (openssl -md md5)
            ├── xattr -d com.apple.quarantine; codesign -s - (macOS)
            └── ~/Library/com.apple.iTunesCloud/SystemUpdate --type=renderer   (FLATROOF, Rust)
                │                                   [RL] malicious, MacOS.Trojan.Gaslight (decrypted by RL)
                ├── persistence: ~/.zlogout hook (macOS) | snap-imagent service (Linux)
                │                | HKCU Run "powershell-config-service" (Windows)
                ├── Python stealers: browser cookies, logins, keychain, shell history
                │   -> collected_data.zip
                ├── C2: Telegram bot | GitHub API | hxxps://arusupport-region1-webhook[.]online
                └── ROOFDECK (imagent / update.exe)  [RL] malicious, GetShell / ReverseShell
                    └── C2 resolved via Nostr profile -> Pastebin (RSA-signed) -> delay[.]servehttp[.]com

From an engineer’s workstation, stolen browser sessions, cloud credentials and shell history give an operator authenticated access to internal systems without defeating MFA, which is the pattern TraderTraitor has used in every major case since DMM Bitcoin. Whether that is what happened at Binance is unknown. Binance’s own description of the next step is a service container submitting withdrawals.

Indicators of Compromise (IOCs)

All IOCs and indicators in this blog post can be found in our GitHub repository [LINK]. The following is a subset for reference. File indicators below are the 2026 Terraform toolset as present in RL, plus the two RHA siblings RL identified and the FLATROOF payload RL decrypted. None of these are published as Binance-specific IOCs.

File indicators:

Zscaler-published font containers not present in RL (MD5):
116f7189ed7b41f1b339a749d56e63be, 58fa0d651898446d5f5d2ed8a27a3330, 2621753691be9521288664bb551dfba6, ad0b1b6d2c8b9d09d6473a4a299470ab, 4b8509cde757b5428e5f99c8dffe73ca, 3826dc7a9ba8bd5b1c143560c1530d89, 34a52e6a4d803e94fe497bab682abfd3.

Network indicators (2026 toolset):

On-chain indicators (Binance theft, from TRM Labs, Elliptic and Cointegrity; not RL-derived):

MITRE ATT&CK mapping

The Source column distinguishes techniques Spectra Core mapped from the RL samples or RL’s loader analysis (“RL”), techniques described in third-party analysis of the 2026 toolset (“3P”), and techniques that apply to the Binance incident by inference only (“Inferred”). Mapped against ATT&CK Enterprise at the time of writing.

The EIP-7702 delegation abuse does not map cleanly to an existing ATT&CK technique. We describe it as protocol abuse following signing-path compromise. A Navigator layer JSON is available on request.

Detection and hunting guidance

YARA: FLATROOF font container

The font container is the most distinctive artifact in the chain: a valid WOFF header followed by a text marker and a long Base64 blob, which legitimate fonts do not contain. The loader has to reference the same marker to split the file, so we pair the two.

rule RL_TraderTraitor_FlatroofFontContainer_2026 {
    meta:
        description = "WOFF file carrying an appended @@ENDFONT@@ marker and Base64 payload, as used to stage FLATROOF"
        author      = "[RL researcher], ReversingLabs"
        date        = "2026-10-31"
        reference   = "https://www.reversinglabs.com/blog/[post-slug]"
        hash        = "62e988e9affcd000657bef4db47eb2e85c9a4cc42f4832780a02e19624e36e38"
        score       = 85
    strings:
        // Delimiter between decoy font data and the encrypted payload
        $marker = "@@ENDFONT@@" ascii
        // Base64 run that follows the marker (long, no whitespace)
        $b64 = /@@ENDFONT@@[A-Za-z0-9+\/]{512}/ ascii
    condition:
        uint32be(0) == 0x774F4646        // "wOFF"
        and filesize < 20MB
        and $marker and $b64
}

rule RL_TraderTraitor_FlatroofLoader_Script_2026 {
    meta:
        description = "Shell loader that splits a .woff file at the @@ENDFONT@@ marker to recover the FLATROOF payload"
        author      = "[RL researcher], ReversingLabs"
        date        = "2026-10-31"
        reference   = "https://www.reversinglabs.com/blog/[post-slug]"
        hash        = "451b586ec9d3c997b319986a1177829653e8ae641c953c05ede6a38616f2da97"
        score       = 75
    strings:
        $marker = "@@ENDFONT@@" ascii
        $woff   = ".woff" ascii
    condition:
        uint32be(0) != 0x774F4646 and filesize < 200KB
        and $marker and $woff
}

We chose the marker and the Base64 run that follows it because the loader’s decryption logic depends on both: a variant that changes them must also change the loader. The font names are spoofable, so we did not use them. False positives should be rare, but test the rules against a corpus of web fonts and build scripts before production use. For a tighter variant, require the marker immediately followed by the OpenSSL salt header, $hdr = “@@ENDFONT@@U2FsdGVkX1” ascii, in place of $marker; in the RL-held sample the Base64 begins right after the marker. That is a precision improvement only, and it will miss a variant that inserts whitespace or changes cipher mode.

We ran both rules as an RL Cloud Retro hunt on October 31, 2026. The run ended before covering the full corpus (it was cancelled after more than 70% progress), so treat the results as partial. It produced four unique matches. Both positive controls matched. The font rule also matched two WOFF files that appear in no published IOC list:

Both were first seen on October 9, the day after the Zscaler publication, and no scanner flags either one. We assess it is likely these are additional FLATROOF containers absent from any published IOC list, with a goodware classification that reflects the payload being encrypted at rest. We could not confirm that: Spectra Intelligence marks both as not available for download, because they came in as private uploads, so RL could not retrieve or decrypt them. They stay hunting leads, not confirmed IOCs.

Figure 6. Matches for the RL_TraderTraitor_Flatroof_v1 ruleset in Spectra Analyze. The cloud rows show the two positive controls (suspicious) and the two unpublished WOFF files (goodware). The bottom two rows are local re-matches of the positive controls after RL pulled them onto the appliance.

Sigma: Terraform provider spawning a shell or downloader

title: Terraform Provider Plugin Spawning Shell or Network Utility
id: 4f2a9c61-8b3e-4d7a-9e15-2c6d0b7f3a18
status: experimental
description: Detects a Terraform provider plugin process launching a shell, curl or decryption tooling, as seen with the trojanized terraform-provider-awsbeta used to deliver FLATROOF
references:
    - https://www.reversinglabs.com/blog/[post-slug]
author: [RL researcher], ReversingLabs
date: 2026-10-31
tags:
    - attack.execution
    - attack.t1059.004
    - attack.initial_access
    - attack.t1195.001
logsource:
    product: macos
    category: process_creation
detection:
    selection_parent:
        ParentImage|contains: '/terraform-provider-'
    selection_child:
        Image|endswith:
            - '/sh'
            - '/bash'
            - '/zsh'
            - '/curl'
            - '/openssl'
            - '/xattr'
            - '/codesign'
    condition: selection_parent and selection_child
falsepositives:
    - Community providers that legitimately shell out (rare; review and allow-list by provider name and signer)
level: high

Duplicate the rule with product: linux for Linux build hosts. On Windows, alert on a terraform-provider-*.exe parent spawning powershell.exe, cmd.exe or curl.exe.

Additional hunting queries

• Lock files: Search repositories and developer home directories for .terraform.lock.hcl entries whose provider source is not registry.terraform.io. Any reference to hashicorp-terraform[.]io or hashicorp-aws[.]com is malicious.
• Persistence: On macOS, look for a ~/.zlogout that executes anything from ~/Library/com.apple.iTunesCloud/ or ~/Library/Services/imagent. On Linux, look for a snap-imagent service and $HOME/.config/git/update. On Windows, look for %LOCALAPPDATA%\Microsoft\Edge\service.exe.
• Loader residue: The loader does not delete itself. Search developer home directories and Terraform plugin cache paths for safari_updater and for any shell script containing @@ENDFONT@@. In process telemetry, look for a process outside a browser’s install path that was started with –type=renderer.
• Signing infrastructure: On EVM wallets you operate, alert on any code being set at an address that should be a plain EOA (an EIP-7702 delegation). Treat a request for many authorizations across a range of nonces as a compromise indicator.

How Spectra Intelligence and Spectra Analyze can help

Security teams using Spectra Intelligence can query the hashes and domains in the IOC section and see RL’s current classification, threat name and first-seen date for each, including the earlier ROOFDECK builds identified here. Spectra Analyze’s YARA hunting module can run the FLATROOF container rule against local repositories and RL’s cloud corpus, and RHA similarity search, which surfaced the ROOFDECK siblings, can be re-run as new samples appear. Spectra Detect customers can deploy the YARA rule at ingestion to flag font files carrying staged payloads in build artifacts and package caches.

Figure 4. Spectra Analyze RHA similarity results for macOS ROOFDECK. Note the three 4.7 MB malicious Mach-O files: the published sample (MacOS.Backdoor.GetShell) and two earlier siblings (MacOS.Exploit.ReverseShell) first seen four and five months ago.

Figure 5. Spectra Core ATT&CK mapping for the trojanized Terraform provider. Note Sudo and Sudo Caching (T1548.003), Setuid and Setgid (T1548.001) and File Deletion (T1070.004) alongside the discovery techniques.

Recommendations

• Treat infrastructure-as-code tooling as code execution. terraform init downloads and runs third-party binaries. Pin providers to registry.terraform.io with verified signatures, and block engineer machines from resolving lookalike registries.
• Never run interview or take-home repositories on a work machine. Use a disposable VM with no access to corporate SSO, cloud credentials or signing systems.
• Separate engineer endpoints from signing paths. Binance’s own description puts one laptop two hops from a service that could submit withdrawals. Require a separate, hardened device and a human approval step for anything that can request signatures.
• Monitor for EIP-7702 delegations on every EVM treasury and hot wallet you operate, and keep a tested, pre-approved revocation procedure.
• Do not block on stale indicators. Use the HivePro 2020 to 2022 domains as hunting context only.
• Apply the YARA and Sigma rules above, and search existing telemetry for the 2026 network indicators going back to May 2026.

The Binance theft illustrates how attackers can exploit trust in developer environments to compromise critical infrastructure. What began with malicious software and social engineering progressed into the compromise of multiple engineering systems and ultimately unauthorized access to wallet-signing operations.

The FBI’s attribution and Binance’s newly disclosed attack sequence provide important clarity. ReversingLabs’ contribution is a deeper look into the surrounding malware ecosystem: malicious software observed months before public disclosure, backdoors with earlier histories, and threats that conventional security classifications may fail to connect.

For defenders, the lesson extends beyond cryptocurrency exchanges. Detecting malicious functionality inside trusted software, understanding its behavior, and connecting related threats across time are critical to stopping attacks before they reach business-critical systems.

The specific relationship between the malware analyzed here and the Binance incident remains unconfirmed. Nevertheless, the intelligence provides actionable hunting guidance for organizations looking to strengthen their defenses against developer-targeted attacks.

As the malware ecosystem evolves, RL will continue to monitor, decode, and report on these changes, helping organizations spot threats before they escalate.

References

• Binance incident statements, as reported by The Hacker News, Forbes and Hackread
• TRM Labs: North Korea steals USD 6.36 billion from Binance
• Elliptic: North Korea likely behind the $6.4 billion Binance hack
• TechCrunch: North Korean hackers blamed for stealing record $6.3B in Binance breach
• Euronews: How the Binance hack happened and who was behind it
• Cointegrity: The Binance hack of 29 October 2026, preliminary analysis
• TRM Labs: Bitget loses USD 351.6 million in hot wallet breach
• FBI IC3 PSA: North Korea responsible for $1.5 billion Bybit hack
• Zscaler ThreatLabz: Suspected TraderTraitor group uses trojanized Terraform provider
• HivePro threat advisory TA2026302
• SlowMist TI alert on weaponized Terraform lock files (via KuCoin)