Blog

A user has secured their cryptocurrency holdings in a hardware wallet and connected it to Rabby Wallet, the open-source browser extension for Ethereum and EVM-compatible networks. The hardware device stores private keys offline, transaction signing happens on the device itself, and the user believes their assets are protected from software vulnerabilities, malware, and exchange hacks. Then an attacker calls their mobile carrier, claims to be the account holder, and requests a SIM card replacement. Within an hour, the attacker controls the phone number and, with it, access to authentication codes for email, exchange accounts, and recovery options. The hardware wallet connection becomes irrelevant.

This scenario is not theoretical. SIM swap, email compromise, and social engineering attacks have succeeded repeatedly against cryptocurrency users who believed their technical setup was secure. The security model of a hardware wallet—cryptographic keys remain offline, transactions require physical approval—is genuine and valuable. But it addresses only one part of a much larger attack surface. When the attacker’s objective is to gain control of the account itself, the wallet’s security architecture matters far less than the weakest human or administrative process protecting account recovery. Understanding where hardware wallet protection ends and where other risks begin is essential for anyone using Rabby Wallet or any self-custody wallet in practice.

The difference between key signing and account access

A hardware wallet’s primary function is to keep private keys offline and require physical confirmation before any transaction is signed. When Rabby Wallet connects to a hardware device—whether through USB, Bluetooth, or a dedicated air-gapped interface—the browser extension sends an unsigned transaction to the device. The device displays the details, the user reviews them, presses a button, and the signed transaction returns. At no point does the private key leave the device or become accessible to the wallet software, browser, or operating system.

This design effectively prevents an attacker who has compromised the browser, the computer, or even the Rabby Wallet application itself from stealing or moving funds directly. Malware cannot forge a signature without the private key. A supply-chain compromise of the wallet extension cannot bypass the hardware device’s approval requirement. A phishing email that tricks a user into visiting a fake dApp site cannot sign a transaction without the hardware wallet physically present and the user consciously approving it.

But account control and transaction signing authority are not identical. An attacker who gains access to the user’s email address, phone number, or recovery mechanisms can often reset passwords, change security settings, and redirect assets without ever needing to sign a transaction with the hardware wallet. If Rabby Wallet is connected through a browser or mobile device, and that device becomes compromised through SIM swap or email takeover, the attacker can log into the user’s email, request a wallet recovery in Rabby or another application, and receive a new recovery code. The hardware wallet sits unused while the attacker transfers funds using newly created accounts or freshly imported keys.

The critical insight is that account recovery mechanisms often bypass transaction signing altogether. A recovery phrase, a master key, or a secondary authentication method can restore access and authorize transactions without ever approaching the hardware device. If an attacker can control the email address, phone number, or personal information used to verify identity during recovery, they can become the account holder. The hardware wallet’s offline key remains secure; the attacker simply creates a new pathway around it.

SIM swap: why two-factor authentication becomes single-factor

SIM swap attacks work because mobile phone numbers are treated as a universal identifier across banking, email, cryptocurrency platforms, and social media. A user may have enabled two-factor authentication (2FA) via SMS on their email account, exchange accounts, or authentication applications. The assumption is that an attacker who has guessed or phished a password still cannot access the account because they lack the phone. That assumption collapses if the attacker calls the mobile carrier, impersonates the account holder, and requests a SIM card replacement.

The attacker now controls the phone number. Every SMS-based 2FA code that arrives is read by the attacker, not the legitimate user. Recovery codes, account verification messages, and one-time passwords all flow to the attacker’s device. This is particularly dangerous for cryptocurrency accounts because many users rely on SMS 2FA for email recovery, which is in turn used to recover their Rabby Wallet, hardware wallet, or exchange accounts. The attacker can reset the email password, access the email recovery address, request a seed phrase reset, and import the original wallet using the newly recovered credentials.

The hardware wallet connection offers no protection in this scenario because the attacker does not need to use the hardware device. They simply create a new wallet instance in Rabby, import a previously backed-up seed phrase, or use a new recovery mechanism entirely. The fact that the original setup used a hardware wallet becomes irrelevant once the attacker has administrative access to the account and all recovery channels. Users who rely primarily on SMS-based 2FA are particularly vulnerable because it is the easiest authentication method for an attacker to intercept.

Carriers typically require minimal verification to approve a SIM swap: sometimes only the last four digits of a Social Security number, publicly available information, or simple social engineering of a customer service representative. In some cases, attackers have gained access by simply pretending to be existing customers and stating that they have a new device. Once the SIM is transferred, regaining control of the phone number requires contacting the carrier, confirming identity through other channels, and potentially disputing fraudulent account changes. By that time, the attacker has already drained the cryptocurrency holdings.

Email compromise: the master key to account recovery

Most users who set up Rabby Wallet or other self-custody wallets store their backup recovery phrase locally, in a password manager, or written on paper. But recovery mechanisms often include options that do not require the seed phrase directly. Password recovery, account verification through email, and secondary authentication methods can all enable a new device to access the wallet. If an attacker compromises the email address associated with the Rabby account or Ethereum account, they can often trigger a password reset, change the account contact information, and modify recovery settings.

Email compromise happens through credential reuse across websites, phishing, password-manager breaches, or simple password guessing on accounts where the user chose a weak or commonly used password. An attacker in possession of a user’s email password can reset passwords on dozens of services, including the email account itself, cryptocurrency applications, and browser sync accounts. This effectively locks the legitimate user out and grants the attacker full access to any service tied to that email.

The implications for Rabby Wallet and similar self-custody tools are significant. If the user’s email is compromised and they had enabled optional recovery features—such as backup email addresses, phone numbers, or security questions—the attacker can use those routes to verify their identity and gain account control. Some wallets also offer optional cloud backup or cloud-linked recovery, both of which become exploitable if the cloud account is compromised. A user who believed their funds were safe because they owned the private keys in a hardware wallet may discover that the attacker has simply created a new wallet instance and imported the seed phrase using email recovery credentials.

The defense requires email security to be as strong as hardware wallet security. This means using a unique, strong password for email; enabling authenticator-app-based 2FA on the email account itself; and keeping backup recovery codes for the email account in a secure location separate from the email. An attacker cannot use email recovery if they cannot access the email account in the first place. But this adds complexity and requires the user to maintain discipline across multiple authentication channels, none of which can be delegated to the hardware wallet.

Social engineering: the human target matters more than the software

A sophisticated attacker often does not target the wallet software or the hardware device at all. Instead, they target the user directly through social engineering. They may call claiming to be from cryptocurrency support, request the recovery phrase, and promise to help recover a lost account or fix a transaction problem. Alternatively, they may pretend to be a customer service representative from a wallet provider, exchange, or hardware manufacturer and request sensitive information under the guise of troubleshooting.

Users who have invested in a hardware wallet may feel confident in their security and become complacent about sharing information they believe is safe. A person who would never type a recovery phrase into a website might be persuaded to read it aloud to a caller who claims to represent technical support. Once an attacker has the seed phrase, the hardware wallet becomes a liability rather than a benefit: the attacker can simply import it into their own Rabby Wallet instance and move funds at will.

This attack works regardless of whether the wallet is a self-custody wallet, a hardware wallet, or any other sophisticated setup. The security model depends on the user keeping the recovery phrase secret. If a person can be persuaded to reveal it, all of the cryptographic security becomes moot. The hardware wallet architecture is strong; the human judgment in deciding whether to share a secret is the actual constraint. An attacker who successfully social engineers a user into revealing their seed phrase has accomplished the same goal as an attacker who stole the private key directly, except without needing any technical skill or access to the device.

The defense against social engineering is institutional and cultural rather than technical. Users must understand that legitimate support staff will never ask for the recovery phrase. They should establish a personal rule of never sharing the seed phrase with anyone, by any method, under any pretext. Verification of caller identity should happen through established contact channels, not through numbers or links provided during the call. And redundancy in recovery mechanisms—such as keeping multiple copies of the seed phrase in separate secure locations—can help protect against a single social engineering incident without necessarily losing access to the funds entirely.

Mobile platform risks: the extension becomes an app

Rabby Wallet operates as a browser extension on desktop and as a mobile application on iOS and Android. The mobile version presents different attack vectors than the desktop extension. A user’s smartphone is constantly connected to the internet, regularly interacts with third-party applications, and is frequently a target for malware, phishing, and social engineering. If an attacker gains physical access to an unlocked phone, or if malware is installed that can read clipboard contents, intercept notifications, or monitor app activity, the hardware wallet protection diminishes significantly.

A hardware wallet paired to a mobile device through Bluetooth or a specialized connector is less likely to be compromised because the key signing still occurs on the separate device. However, if the mobile app itself is compromised by malware, an attacker might be able to substitute a different address before the hardware device displays and approves the transaction. This type of attack, known as a man-in-the-middle substitution, requires the user not to notice the address discrepancy. It is less reliable than software theft but more viable on a mobile platform where screen real estate makes address verification harder.

The mobile platform also complicates backup and recovery. A user might back up their seed phrase on the phone itself, in cloud storage accessible from the phone, or through the phone’s native backup system. Each option introduces a new attack surface. Cloud storage requires a secure password and 2FA. Local backup requires physical phone security and protection against malware. The phone’s native backup system (iCloud, Google Drive) depends on the security of the cloud account itself. Hardware wallet integration protects the signing step but not the backup storage, which remains a critical vulnerability on mobile devices.

The recovery phrase: the single point of failure that hardware wallets cannot eliminate

Rabby Wallet and other EVM-compatible self-custody wallets ultimately depend on a recovery phrase—typically a 12 or 24-word mnemonic that can regenerate the master key and all derived accounts. The hardware wallet can protect the private keys during transaction signing, but if an attacker obtains the recovery phrase, they can import the wallet on any device, create new accounts, and transfer funds without the hardware wallet ever being involved. The recovery phrase is the true single point of failure, and protecting it is not a technical problem that hardware wallet integration can solve.

Users must store the recovery phrase securely, which typically means writing it on paper, storing it in a safe or safety deposit box, or using a secure backup service. Each option has trade-offs. Paper is offline and immune to hacking but vulnerable to fire, water damage, and loss. A safe deposit box is secure but requires a physical location and periodic access verification. A secure backup service requires trusting the service provider with the recovery phrase or trusting an encryption scheme where the user retains the decryption key.

The hardware wallet creates a false sense of security around the recovery phrase because the user is not actively using the private key during normal transactions. The signing happens on the device, and the user may believe that the recovery phrase is therefore less critical. This is a dangerous misconception. An attacker who obtains the recovery phrase has full control over the wallet, whether or not the user still has the hardware device. In fact, a user might not even realize the wallet has been compromised if the attacker creates accounts on different EVM chains or transfers funds slowly to avoid triggering balance-change alerts in Rabby Wallet.

Building a realistic threat model around hardware wallet integration

A more useful mental model treats a hardware wallet as protection against one specific class of attacks: compromise of the signing environment. It does not protect against compromise of the account recovery environment, the email environment, the phone number environment, or the user’s own decision-making. A realistic threat model acknowledges that an attacker has multiple pathways to account control and may choose the easiest one available.

Users should evaluate their setup by asking: what is the hardest attack path for an attacker to follow? If email recovery is enabled and unprotected, that becomes the easiest path, and the hardware wallet becomes irrelevant. If the recovery phrase is stored in a location accessible through the compromised email account, the same problem applies. If the phone number is vulnerable to SIM swap and is used for account recovery, that is another easy path. The hardware wallet protects only against an attacker who has already been locked out of all other recovery mechanisms and is forced to physically interact with the device.

A robust setup requires defense in depth across all account recovery pathways. This means protecting email with a unique, strong password and non-SMS-based 2FA; protecting the phone number through carrier account security; storing the recovery phrase in a location that does not require an internet-connected account to access; and establishing a personal rule against sharing the seed phrase with anyone. Download Rabby Wallet only from official sources, such as this page, to reduce the risk that the wallet software itself is compromised. Enable all available security features in Rabby Wallet, including pre-transaction risk scanning and balance change previews, to catch unauthorized activity early.

The hardware wallet remains valuable because it protects the execution step, even if it does not protect account access. An attacker who has gained control through email or SIM swap still needs to approve transactions on the hardware device if it is actively connected and required for signing. But this protection only matters if the user checks the transaction details on the device display, compares them to what was intended, and rejects any transaction that does not match. If the user is tired, distracted, or has been socially engineered into believing that the transaction is legitimate, they might approve it anyway. The hardware wallet then becomes a ceremonial step that provides confirmation without actual security.

The residual risks that remain unsolved

Even with a hardware wallet, Rabby Wallet integration, strong email security, and careful backup practices, several risks persist. A sophisticated attacker might target the user’s physical location, demanding the recovery phrase under duress or threats. A user in a country with an unstable government or weak rule of law faces risks beyond technical security. A user who forgets the recovery phrase, loses the hardware device, or accidentally deletes the wallet might face permanent loss of access to funds, which is a different problem from theft but equally damaging.

Privacy risks also remain even when security is strong. Rabby Wallet, like other Ethereum wallets, can monitor the user’s on-chain activity through their address. If that address is ever linked to the user’s identity—through an exchange transaction, a public donation, or a smart contract interaction—observers can track all historical and future transactions associated with it. A hardware wallet does not provide privacy; it only ensures that transactions are genuinely authorized by the key holder.

The final unsolved problem is that cryptocurrency is ultimately self-custody, which means the user bears complete responsibility for security, recovery, and loss prevention. There is no bank, no customer service, no chargeback, and no insurance if the user’s mistake leads to theft or permanent loss. A hardware wallet reduces the attack surface for some scenarios, but it cannot eliminate the human element. A user who is not willing to maintain discipline across email, phone, backup storage, and personal decision-making is not ready for self-custody, regardless of the wallet’s technical features. The hardware wallet connection is valuable precisely because it is useful, which means users will eventually come to trust it more than they should, and that trust becomes the next vulnerability.