The $1.5B Bybit Theft (Feb 2025): A Developer Machine, Stolen AWS Session Tokens and a Poisoned S3 Asset

Retrospective: this article looks back at events from February 2025, written in 2026 with the benefit of hindsight.

On or about February 21, 2025, cryptocurrency exchange Bybit lost approximately $1.5 billion in virtual assets — the largest cryptocurrency theft on record. Within days, the FBI attributed the theft to North Korea, labeling the activity TraderTraitor, a subunit associated with the Lazarus Group.

1. Developer compromisedAttackers compromise a Safe{Wallet} developer's machine.
2. Cloud accessUsing the developer's access — reported to include AWS session tokens — they reach Safe's infrastructure.
3. Interface tamperingMalicious JavaScript is injected into the Safe{Wallet} web interface, targeting Bybit specifically.
4. Manipulated signingBybit's signers approve what looks like a routine transaction; the code alters it and hands control to the attackers.
5. AttributionThe FBI attributes the roughly $1.5 billion theft to North Korea, labeling the activity TraderTraitor.

Bybit's own systems weren't the starting point. The attack began at Safe{Wallet}, the third-party multi-signature wallet platform Bybit used to approve transactions — and specifically on one developer's computer.

What happened

Investigations described this sequence:

1. Attackers compromised a Safe{Wallet} developer's machine.
2. Through that developer's access — reported to include active AWS session tokens, which allowed access to Safe's cloud environment without defeating MFA again — the attackers reached the infrastructure that served Safe's web application.
3. They injected malicious JavaScript into the Safe{Wallet} interface. The code was targeted: it activated for Bybit's transactions.
4. When Bybit's signers approved what appeared to be a routine transfer from a cold wallet, the malicious code altered the transaction so that control passed to the attackers.
5. After the theft, the malicious code was removed.

Multi-signature approval — several people must sign — is designed to prevent exactly this kind of loss. It didn't help, because every signer was looking at the same tampered interface.

Why it mattered

Developers are privileged users. Developer workstations often hold active sessions and keys for production cloud environments, source code and deployment pipelines. North Korean groups in particular have targeted developers with fake job offers and malicious coding projects for years.

Session tokens bypass MFA. Once a session is established, stealing the token from the device provides the access without another MFA prompt.

The interface is part of the security boundary. Approvals are only as trustworthy as what the approver sees. Static web assets in cloud storage became a supply-chain attack vector.

Your vendor's developer is your risk. Bybit's controls depended on a third party's engineering security.

What to do now

1. Separate production access from daily work. Use a hardened device — a privileged access workstation or a cloud-hosted admin workstation — for production administration, and keep untrusted activity (testing unknown code, coding challenges, downloads) in isolated VMs or dev containers.
2. Shorten and scope AWS sessions. In IAM Identity Center, use short session durations for production permission sets (for example, one hour) and separate read-only from write access. Require elevation, ideally with approval, for write access to production.
3. Require phishing-resistant MFA for developer access to cloud consoles, source control and CI/CD.
4. Make production changes go through pipelines. People shouldn't be able to write directly to buckets that serve production web assets; only reviewed deployment pipelines should.
5. Protect web asset integrity. Enable versioning and change alerts on buckets serving front-end code, use content security policies and Subresource Integrity where applicable, and verify deployed files against the build output.
6. Manage developer devices. EDR, disk encryption, automatic updates and restrictions on unsigned software.
7. Verify high-value actions independently. For critical transactions or configuration changes, confirm details through a second channel that doesn't rely on the same interface.
8. Ask critical vendors how they protect developer access to the systems you depend on.

How to detect session theft and asset tampering

• Sessions used from new locations. In CloudTrail, an assumed-role or IAM Identity Center session appearing from a different IP address or ASN than where it began, especially VPN or hosting providers.
• Developer roles writing to production. PutObject, CopyObject or DeleteObject on production asset buckets by human roles rather than the deployment pipeline.
• Out-of-hours activity inconsistent with a developer's normal pattern.
• GuardDuty findings for anomalous behavior or credential use from unusual locations.
• Integrity monitoring that compares served JavaScript with the expected build artifact.

Common mistakes

• Long-lived sessions that stay valid for days on developer laptops.
• Write access to production "just in case."
• Treating front-end assets as low-risk because they're "just static files."
• Assuming multi-signature or multi-approver processes are enough without verifying what approvers see.

Lessons for any software supplier

You don't need to run a cryptocurrency exchange to face the same risk. Any organization whose customers depend on its web application, mobile app, browser extension or software updates is in Safe{Wallet}'s position. A compromised developer or build system can change what customers see and approve.

Practical safeguards include signed builds and releases, separation between people who write code and the systems that deploy it, protected branches with required reviews, deployment pipelines that are the only path to production, integrity checks on what's actually served, and incident response plans that include notifying customers quickly if tampering is suspected.

Why North Korean groups target developers

US agencies have warned for years that North Korean operators target people who work in cryptocurrency and software development — often with fake recruiters, job interviews that include "coding tests," or malicious open-source projects. The goal is to get code running on a developer's machine, where it can steal credentials and session tokens. Telling engineering teams about these lures, and giving them isolated environments to evaluate unfamiliar code, removes one of the most common entry points.

Questions for leadership

• Which developers can change production systems directly, outside a reviewed pipeline?
• Do developers use separate, hardened devices or accounts for production access?
• Could someone change our customer-facing application without review — and would we notice?

Key takeaways

• The $1.5 billion Bybit theft started with one compromised developer machine at a vendor.
• Stolen session access allowed attackers to tamper with the interface signers trusted.
• Treat developer access to production like administrator access: limited, short-lived, monitored.
• Route production changes through pipelines and monitor the integrity of what you serve.