Bybit Hack Analysis: Scoring the Lazarus Wallet Tree
The largest crypto theft in history, run through a deterministic risk engine wallet by wallet. Every score traces back to on-chain signals. No ML, no black boxes, no enterprise contract required to see the output.
- On February 21, 2025, Lazarus Group drained approximately $1.5B from a Bybit cold wallet via a signing-UI compromise.
- The primary exploiter address (
0x47666F...486E2) is now labeled in the CredScore engine. - CredScore scores the wallet at 0/100, High Risk, Escalate, with the sanctions cap enforced end-to-end through the pipeline.
- The written briefing, signal breakdown, entity attribution, and decision posture are all produced in under 15 seconds per wallet.
- This case study shows the real engine output on a public address. No edits, no curation.
On February 21, 2025, Bybit announced that one of its cold wallets had been drained of approximately 1.5 billion US dollars in Ethereum-denominated assets. The theft surpassed the Ronin Bridge incident from 2022 and became the largest single-incident loss in the history of crypto. Within 72 hours, Elliptic, Chainalysis, TRM Labs, and the independent investigator ZachXBT had all independently attributed the attack to the Lazarus Group, the DPRK-linked threat actor responsible for more than a dozen major thefts since 2017.
This case study is not another incident recap. Those are already published by Elliptic, Chainalysis, and TRM Labs. What this case study does is take the publicly documented Bybit attacker wallet, run it through the CredScore risk engine, and publish the structured output in full. The goal is transparency: if you are evaluating CredScore for compliance work, you should be able to see what the engine actually produces on a wallet where the ground truth is known and documented by multiple independent parties.
Every screenshot below is the unedited output of a production CredScore analysis. The scoring logic is 9,200 lines of deterministic code. No machine learning. Every flag has a written rationale. Every score traces back to an observable signal.
What happened in the Bybit hack
The Bybit exchange operates institutional-grade cold storage using Safe{Wallet} multisig infrastructure. On February 21, 2025, during a routine transfer from a cold wallet to a warm wallet, the signers were shown a transfer interface that displayed the expected destination and amount. In reality, the transaction they were signing delegated control of the cold wallet contract to an attacker-controlled address. The moment the final signer approved the transaction, the attacker drained the wallet in a single batch of transfers.
The attack vector has been publicly reported as a compromise of the Safe{Wallet} front-end infrastructure, not a flaw in the signing hardware or the underlying smart contracts. This distinction matters for compliance review: the attacker did not break any cryptography. They manipulated what the signers saw on screen. The on-chain record is a perfectly valid transaction signed by legitimate key-holders who believed they were approving something else.
Funds drained included roughly 400,000 ETH, plus stETH, cmETH, and mETH. Within minutes, the attacker began converting liquid staking derivatives back to ETH via decentralized exchanges, then fanning the ETH out across hundreds of newly created intermediate wallets. Within the first 48 hours, portions of the funds had been routed through THORChain and cross-chain bridges in an attempt to move into Bitcoin and obscure the trail. This fan-out and multi-hop routing pattern is a Lazarus signature documented across WazirX, DMM Bitcoin, and Ronin Bridge.
The primary exploiter wallet
The canonical Bybit exploiter address is 0x47666Fab8bd0Ac7003bce3f5C3585383F09486E2. This is the address that first received the drained funds from the Bybit cold wallet. It is documented by Elliptic's public tracker, by Chainalysis' incident post, by ZachXBT's on-chain investigation thread, and by the FBI's public service announcement attributing the theft to Lazarus.
Running this address through the CredScore engine produces the following output. All four screenshots are taken from a production analysis run on the live desk interface.
Overview: score, tier, and decision posture
The headline number is 0 out of 100. The engine places the wallet firmly in the High Risk tier with an Escalate decision posture. There is no manual review step to reach this output. The moment the wallet address is entered, the engine queries the entity label database, matches Lazarus, and enforces the sanctions cap automatically.
Signals: category scorecard and key drivers
The six-dimension scorecard is the visible contract between the engine and the analyst. Every score is decomposed into exactly six categories so no risk dimension can be hidden by aggregation. For the Bybit exploiter, the entity dimension is the dominant driver because the address carries an explicit Lazarus label. The behavior dimension is also elevated by the fan-out pattern on this wallet, a structural signature the engine detects independently of any label match.
The key drivers list is tiered. High-impact drivers are surfaced by default, with supporting and neutral signals collapsed underneath. This is the exact display an analyst would see during a real investigation, not a marketing-optimized view.
Briefing: the written analyst summary
The briefing is one of the most requested features from early reviewers. It is also the easiest feature to do badly. Most competitors either skip a written summary entirely, returning only a numeric tier, or generate one using a language model that treats the signal values as loose context. CredScore takes the third path: the briefing is assembled from deterministic templates keyed off the actual signal output. If the engine says the entity score is 15 and the concentration score is 60, the briefing paragraph that mentions those scores cites exactly those numbers. This is a defensibility requirement, not a stylistic choice. An auditor reviewing a case three years from now needs to see that the written justification matches the numeric evidence.
Entities: label match and counterparties
The entities tab is where forensic drill-down happens. Every counterparty that the wallet has transacted with is listed, and any counterparty with an entity label is displayed with its attribution. Clicking a counterparty opens its own analysis, which means an investigator can walk the Bybit laundering graph one hop at a time without ever leaving the desk. For the primary exploiter, the immediate counterparties are a mix of freshly-created peel-chain addresses and a small number of DEX routers used to convert stETH and cmETH back to ETH.
Why the engine knows it is Lazarus
CredScore maintains an internal entity label database of approximately 215 high-priority addresses as of April 2026. The database is curated manually from public sources: OFAC SDN listings, official exchange attribution lists (Coinbase, Binance, Bybit), bridge and protocol canonical contracts, and published investigation reports. The Lazarus label on the Bybit exploiter address was added to the database on February 23, 2025, two days after the hack, once multiple independent sources had confirmed attribution.
When the engine encounters a labeled address, three things happen at once. The entity dimension of the scorecard is set to the category baseline for that label. A hard sanctions cap is applied that prevents the final score from rising, regardless of any offsetting positive signals. And the decision posture is forced to Escalate, bypassing the normal derivation from score and confidence. This enforcement is why a Lazarus address cannot quietly score well just because the wallet also has high transaction volume and a long history.
For wallets that do not carry a direct label but are near a labeled address in the transaction graph, the engine applies a proportional risk penalty based on counterparty exposure. This is how the Lazarus laundering tree gets scored as a whole rather than only at the labeled nodes. An unlabeled address that received a large transfer from the Bybit exploiter still scores poorly, even without a direct OFAC match, because the exposure signals surface the connection.
Why the sanctions cap holds under pressure
The sanctions cap is not a single check. It is re-asserted at multiple stages of the pipeline before the result is returned. This redundancy exists for a specific reason: in a long pipeline with signal stacking, calibration smoothing, and tier-boundary adjustments, a single check can be silently overridden by a downstream function. A compliance engine cannot afford that failure mode.
In addition to the in-pipeline re-assertions, a final output contract runs at engine exit. The contract checks a small set of non-negotiable invariants: any wallet with a sanctions signal must have a score in the capped range and a decision posture of Escalate, with no exceptions. If any invariant fails, the engine refuses to return the result. It raises an error to the pipeline, which is logged to the audit trail for investigation.
This is how a compliance engine earns the right to be used in a regulated workflow. It fails loudly on contract violations rather than silently returning a wrong answer. For an analyst, this means you can trust that a sanctioned wallet will never quietly score above the cap because of an edge case in the stacking logic. For a regulator reviewing a case, it means every sanctions-capped result is traceable to an enforced invariant, not a heuristic.
Tracing the Lazarus laundering path
Lazarus laundering follows a documented playbook. Across the last eight major Lazarus thefts, investigators have observed the same structural stages. Understanding these stages is how a risk engine can flag funds in motion before they reach a fiat off-ramp, not just after the fact.
Stage 1: Immediate conversion
Within hours of the theft, the attacker converts any non-ETH assets (stETH, cmETH, liquid staking derivatives, stablecoins) back to native ETH using decentralized exchanges. This stage is necessary because downstream laundering infrastructure (THORChain, cross-chain bridges, mixers) operates on native assets, not wrapped derivatives. CredScore detects this stage by the concentration of DEX interactions in the immediate post-theft window.
Stage 2: Fan-out
The attacker distributes the consolidated ETH across dozens to hundreds of newly created intermediate wallets, typically in amounts that sit just below common compliance screening thresholds. CredScore's engine flags fan-out as a structural pattern independent of any label match. That matters here because most of the receiving wallets in a fresh Lazarus tree are brand-new and have no attribution. The pattern is visible before the labels are.
Stage 3: Cross-chain movement
Portions of the funds are routed through THORChain, Chainflip, and cross-chain bridges to move from Ethereum to Bitcoin, where the laundering path continues on a different chain with different tooling. Lazarus has historically favored THORChain because it is decentralized, non-custodial, and does not enforce KYC at the protocol layer. CredScore flags bridge interactions as structural signals but does not follow funds onto Bitcoin yet. Bitcoin support is on the roadmap.
Stage 4: Mixer or peel chain
On the Bitcoin side, funds are typically routed through mixing services or broken into long peel chains that trickle small amounts to consolidation addresses over weeks or months. CredScore's engine does not currently operate on Bitcoin but the structural logic for peel-chain detection is chain-agnostic and would apply directly if Bitcoin support is added.
Stage 5: Fiat off-ramp
Eventually, laundered funds reach a fiat off-ramp through an exchange, typically one with lax KYC enforcement in a jurisdiction that does not cooperate with Western sanctions enforcement. This is the stage at which most attempts to recover funds succeed or fail. The Bybit recovery effort is still ongoing as of April 2026, with a small portion frozen at compliant exchanges and the majority still in motion.
What CredScore does not catch
An honest case study has to say what the engine misses. There are three meaningful gaps in how CredScore currently handles a Lazarus-style laundering tree, and future sessions will close them one at a time.
Gap 1: Bitcoin. Once funds cross from Ethereum to Bitcoin via THORChain or Chainflip, CredScore stops following them. This is a coverage limitation, not a scoring limitation. The engine would apply the same structural detection on the Bitcoin side if the data pipeline existed. Bitcoin support is a two-to-three-week project that will be prioritized when a customer asks for it.
Gap 2: Depth of the counterparty graph. The engine currently analyzes the first and second hops from the target wallet with full signal detail. Deeper hops are summarized but not scored individually. For a Lazarus tree with hundreds of peel-chain addresses, this means the analyst can see the shape of the graph but would need to run additional analyses to get structured scores on every node. An upcoming feature called Tree View will expose this full graph as a single analysis.
Gap 3: Real-time freshness. CredScore queries Alchemy for wallet data at analysis time, so the data is current as of the analysis. However, new Lazarus-linked addresses that appear after a given analysis do not retroactively trigger alerts on previously analyzed wallets. Wallet monitoring with alerting is implemented for saved wallets but is not yet running as a production cron. When it launches, the existing analyses will automatically re-score against the updated entity label database.
What this case study proves
The Bybit hack is a known ground-truth case. Any risk scoring engine that claims to handle compliance workflows should produce the correct output on this wallet. The correct output, in this case, is a very low score, a High Risk tier, and an Escalate decision posture with an unambiguous Lazarus attribution in the entity tab.
CredScore produces that output in under 15 seconds, with a written briefing that cites specific signal values, with a six-dimension scorecard visible to the analyst, and with three-layer sanctions enforcement that cannot be bypassed by any downstream adjustment. The engine is 9,200 lines of deterministic code with no machine learning, so every output is auditable signal by signal.
For comparison, the enterprise tools that dominate this market (Chainalysis, TRM Labs, Elliptic) produce comparable output on this wallet but behind a $50,000-plus annual contract and a multi-week procurement process. If you want to see how CredScore compares feature by feature, the three comparison pages cover that in detail: CredScore vs Chainalysis, CredScore vs TRM Labs, and CredScore vs Elliptic.
Try the engine on a wallet you care about
The single best way to judge CredScore is not to read a case study. It is to paste a wallet address into the desk and see what the engine produces on an address whose risk profile you already know. If you investigate crypto crime professionally, you already have a list of wallets where you know the right answer. Run three of them through the desk and see if CredScore agrees with you.
One free analysis, no credit card. Paste any Ethereum, Base, Arbitrum, Optimism, or Polygon wallet and see a full briefing in under 15 seconds.
Frequently asked questions
How much was stolen in the Bybit hack?
Approximately $1.5 billion in ETH, stETH, cmETH, and mETH were drained from a Bybit cold wallet on February 21, 2025. It is the largest single-incident crypto theft in history.
Who was behind the Bybit hack?
The FBI, Elliptic, Chainalysis, and independent investigators including ZachXBT attributed the hack to the Lazarus Group, a state-sponsored threat actor operating out of the DPRK.
What is the Bybit attacker wallet address?
The primary exploiter address is 0x47666Fab8bd0Ac7003bce3f5C3585383F09486E2, which first received the drained funds before fanning them out across hundreds of intermediate addresses.
How does CredScore score a sanctioned wallet?
A hard sanctions cap forces a capped low score, a High Risk tier, and an Escalate decision posture. The cap is re-asserted at multiple pipeline stages and verified by a final output contract at engine exit, so the sanction cannot be silently lost by any downstream adjustment.
Can CredScore track funds across chains?
CredScore supports five EVM chains: Ethereum, Base, Arbitrum, Optimism, and Polygon. Bitcoin and Solana coverage are on the roadmap.
How is this different from what Chainalysis or TRM Labs publish?
Enterprise firms publish high-level incident recaps for their contracted customers. CredScore publishes the full engine output on public addresses, with every signal shown and every score explained, at no cost.
Is the CredScore engine using machine learning?
No. The engine is fully deterministic. Every score traces back to observable on-chain signals through a documented pipeline. No ML classifier, no neural network, no black-box probability estimate.
Sources and further reading
- Elliptic public investigation tracker on the Bybit incident
- Chainalysis incident report: Bybit exchange theft attribution (February 2025)
- ZachXBT on-chain investigation threads, February and March 2025
- FBI public service announcement on DPRK state-sponsored crypto theft (updated 2025)
- OFAC SDN List updates relating to Lazarus Group and affiliated addresses
- CredScore engine documentation at /docs