How Threat Modeling Could Have Prevented the $1.5B Bybit Hack

On February 21, 2025, cryptocurrency exchange Bybit suffered a devastating $1.5 billion hack, the largest in crypto history. This wasn’t due to smart contract flaws or coding errors but rather a sophisticated operational security failure allowing attackers to compromise signers’ devices and manipulate transaction data.

This attack follows a disturbing pattern we’ve observed over the past year, with similar breaches at WazirX ($230M) and Radiant Capital ($50M). In each case, attackers targeted human and operational elements rather than exploiting code vulnerabilities.

As attackers shift from technical exploits to operational security gaps, threat modeling becomes essential. Traditional code audits find implementation issues in code, but only comprehensive threat modeling can reveal the systemic operational and design weaknesses that enabled these most recent breaches.

At Trail of Bits, we’ve conducted numerous threat models for blockchain organizations over the years, though most of these assessments remain confidential as clients typically decline to publish them. This creates an information gap in the industry about the effectiveness of threat models in preventing devastating attacks like the one Bybit experienced.

Building on our previous analysis of the Bybit hack where we discussed how the era of operational security failures has arrived, we’ll now explore specific threat modeling techniques that could have identified these vulnerabilities before they were exploited.

Understanding Threat Modeling in Blockchain Security

Threat modeling is a structured approach to identifying security risks in a system’s architecture, data flows, operational procedures, and human elements. Unlike code review audits, which find implementation bugs, threat models reveal systemic and operational weaknesses — precisely the kind that led to the Bybit hack.

Here’s how our approach breaks down:

1. Establish a set of security controls. We establish a set of security controls based on NIST SP 800-53 and use these controls to guide the engagement.
2. Component Identification: We identify all in-scope system components, from wallet infrastructure to API services, user interfaces, internal admin tools, and third-party integrations.
3. Actor Analysis: We identify all actors interacting with the system, including legitimate users, administrators, and potential attackers. This helps us understand who can access what and what privileges they have.
4. Trust Zone Mapping: We group components into “trust zones” based on shared purpose, ownership, or level of potential damage. Trust zones are bounded by trust boundaries, which typically occur where authentication and authorization are required to obtain a higher level of privilege within the system.
5. Data Flow Analysis: We map how data moves between components and across trust boundaries, identifying where sensitive information might be exposed or manipulated and which threat actors could do so.
6. Threat Scenario Development: For each trust boundary crossing, we analyze potential attack vectors and develop realistic threat scenarios that show how design vulnerabilities could be exploited.

The Bybit Hack Through a Threat Modeling Lens

The Bybit hack exemplifies a sophisticated operational security breach that we believe could have been identified and mitigated through comprehensive threat modeling tightly integrated into the exchange’s software development lifecycle. Let’s examine what happened through this lens.

Attack Mechanics and Failed Controls

Attackers compromised the devices of multiple Bybit multi-sig signers — at least three out of five signatures are required before a transaction can be processed by their Safe multisig contract. When these individuals thought they were authorizing routine transactions, they were actually signing transactions that changed the implementation address of their Safe multi-sig wallet and replaced it with a malicious implementation that granted the attacker control, bypassing the multi-sig requirement entirely.

Attackers exploited the contract’s EVM delegatecall function and deployed malware to manipulate the signing interface. The signers could not see what they were signing due to two critical issues: malware that modified the wallet interface and the limitation of blind signing on hardware wallets, which do not display complete semantic information on what is being signed by the user.

Performing a threat model during the design phase of the software development lifecycle (SDLC) may have informed Bybit that their system contains the following control failures that require mitigation:

1. Endpoint Security Controls

• Description: The cold wallet’s signers likely used general-purpose workstations¹ for sensitive transaction signing operations, creating a broad attack surface for device compromise.
• Identified Risk: Compromise of signer devices could lead to transaction manipulation
• Recommendation: Implement dedicated signing workstations with limited connectivity, and if the devices must be online, add enhanced monitoring. In addition, smart contracts may be added to the system to time-lock the movement of funds to allow time for incident response or restrict where funds may be sent entirely.

2. Transaction Verification Process

• Description: Cold wallet signers likely relied on a single verification interface without secondary confirmation mechanisms¹, leaving signers unable to detect manipulated transaction details.
• Identified Risk: Blind signing can hide transaction details
• Recommendation: Implement secondary verification using transaction verification scripts such as the one maintained by @pcaversaccio. This should be performed on a separate secure workstation to reduce the impact of compromised signer workstations, and signers should thoroughly compare the transaction hashes displayed by the verification script and hardware wallet byte-by-byte.

3. Safe Wallet Configuration

• Description: The multisig wallet was configured to allow delegatecall operations, which enabled attackers to alter the wallet’s concrete implementation.
• Identified Risk: delegatecall operations can change the semantics of transactions being signed by offline or partially offline signer workstations. While delegatecall operations are not a vulnerability on their own, their use in this system creates a design weakness.
• Recommendation: Disable delegatecall functionality entirely, or alternately, design the on-chain components so a signature is only valid for a specific implementation being called into by delegatecall.

4. Operational Segregation

• Description: Bybit may have lacked proper separation between corporate infrastructure and critical signing infrastructure¹, potentially allowing a corporate network compromise to impact signing operations.
• Identified Risk: Corporate infrastructure compromise affects signing infrastructure
• Recommendation: Implement air-gapped signing procedures with physically and logically separate infrastructure.

Introducing Threat Modeling Into Your Organization

With the increase in operational security failures across the blockchain industry, implementing a robust threat modeling program is no longer optional — it’s essential. Smaller organizations should start with the Rekt Test, our simple framework for assessing basic security controls. The Rekt Test is an ideal starting point for a greater threat modeling journey.

Larger organizations require more consideration. Before doing concrete threat modeling work, they should focus on these foundational steps:

Step 1: Setting the Right Scope and Cadence

Effective threat modeling starts with clearly identifying what assets and operations would have the greatest impact on the system if compromised by an attacker. Prioritize the most critical items, such as wallet infrastructure, transaction signing, and other privileged-access systems.

It is also important to treat threat modeling as an ongoing process, not a one-time exercise. Infrastructure changes over time, and the threat model must change with it. Make regular model updates quarterly or semi-annually, as well as after significant architectural changes, new feature launches, or changes in operations.

Step 2: Integrating With Existing Processes

Threat modeling only delivers value when it is combined with your existing development lifecycle and operational workflows. The owners of these workflows are critical stakeholders, and you’ll need their buy-in to successfully integrate threat modeling into your organization.

Below are a few recommended touchpoints where threat modeling can be effective:

• Embed in the software development lifecycle (SDLC): Incorporate threat modeling early in your design process, rather than waiting until the design is finalized to initiate a threat model. This reduces the cost of fixing insecure designs, and gives your team a better idea of the kinds of threats they need to defend against when designing the system. Proposed design changes should be accompanied by an accounting of how their adoption would affect the system’s threat model and attack surface.
• Connect to Risk Management: Ensure that your threat model results feed into your organization’s security roadmap and risk register. If your threat model is not used to inform future risk management decisions, then it will not provide value.
• Align with Incident Response: Base your tabletop exercises and incident response planning on scenarios from your threat model. Aligning these processes with threat-modeled expectations reduces the number of surprises your incident response team encounters.
• Complement Existing Security Testing and Auditing: Use your threat model to guide the scope and focus of internal and external penetration tests, code reviews, audits, and other security assessments. These security controls are much more effective when threat actors and their capabilities are well understood.

Step 3: Prioritize Your Security Investments

Every organization has finite resources. Use threat models to guide your security investment decisions, directing resources towards your weakest defenses and most significant security concerns:

• Risk-Based Approach: Prioritize addressing threats based on impact potential and exploitation likelihood.
• Defense-in-Depth Strategy: Invest across prevention, detection, and response capabilities rather than focusing exclusively on preventive controls.
• Measure Control Effectiveness: Regularly assess whether implemented controls deliver the expected risk reduction.

How Trail of Bits Can Help

Trail of Bits offers comprehensive threat modeling services tailored to blockchain organizations. Our approach can integrate seamlessly with your existing security program:

• Component-Based Methodology: We identify all relevant system components, trust boundaries, data flows, and threat actors in scope to construct a holistic view of your threat landscape.
• Scenario Development: We develop realistic attack scenarios based on our extensive experience with cryptocurrency breaches.
• Maturity Assessment: We evaluate your security controls against industry best practices and provide a clear roadmap for improvement.
• Knowledge Transfer: We work collaboratively with your team throughout the process, ensuring you gain the skills to maintain and update your threat model going forward.

Our threat modeling experts have helped numerous cryptocurrency exchanges, protocols, and blockchain platforms identify and address critical security gaps before they can be exploited. By partnering with Trail of Bits, you’re not just getting a threat model—you’re gaining a strategic advantage in the ongoing arms race against increasingly sophisticated attackers.

Threat Modeling as Strategic Defense

The Bybit hack demonstrates that security in the blockchain space requires more than secure code — it demands systematic approaches accounting for human factors, operational procedures, and technical controls.

While threat modeling is a powerful technique, it’s important to recognize that it’s just one component of a comprehensive security program. For threat modeling to be truly effective, it must be integrated seamlessly with other security disciplines, including risk management, secure development practices, incident response planning, and day-to-day operational processes. This holistic approach creates multiple layers of defense that can withstand sophisticated attacks like those we’ve seen recently.

The question is no longer whether your organization can afford to invest in threat modeling—it’s whether you can afford not to.