Identifying the Wallets Behind Vulnerable Recovery Phrases

Introduction

As part of the Ill Bloom investigation, we identified wallet addresses whose recovery phrases could be brute-forced due to weaknesses in their generation process. We then began investigating which wallet applications may have generated those phrases.

A public blockchain address does not reveal which application originally generated the wallet behind it. The challenge is even greater when the wallet is closed source and has since been discontinued. In those cases, the exact software version that generated a wallet may no longer be available at all.

Even for active wallets, identifying the relevant generation path may require locating and analyzing versions of the application other than the current release.

Our goal was not only to attribute vulnerable addresses to specific wallet applications, but also to determine whether those applications may still be generating vulnerable wallets and, where possible, identify the teams responsible for notifying potentially affected users.

Confirmed Wallet Applications

This is not an exhaustive list of all wallet applications that may have generated vulnerable wallets. The wallets below are those we have been able to confirm so far.

How We Identified Them

There was no single path to identifying the wallets. We combined three main sources of evidence: on-chain analysis, public source-code research, and reverse engineering of closed-source or discontinued applications.

On-chain analysis helped us identify groups of addresses and connections to specific wallet ecosystems. Public source code allowed us to trace dependencies and verify how wallet-generation code was used. For closed-source or discontinued applications, we analyzed historical application packages and reconstructed their wallet-generation processes where possible.

Knowing that a project depended on a library containing the vulnerable implementation was only the starting point. We then had to determine whether a particular wallet actually used that code to generate wallets. Because a library could be used across different projects and for many different purposes, simply finding it as a dependency was not enough. We had to trace how it was used within each application and verify that it was part of the wallet-generation process.

Once a wallet was identified, we also had to determine which configurations it supported. Different mnemonic languages, entropy sizes, and derivation paths could lead to different sets of wallets and derived addresses across different networks. These configurations were not interchangeable: each could require a separate search, expanding both the address space and the computational work required.

Each newly identified wallet could therefore introduce new configurations and new search spaces. This made the investigation iterative: findings from on-chain analysis could lead to a wallet, the wallet could reveal new generation parameters, and those parameters could lead to additional addresses and potentially new applications.

Bexo Wallet

Our investigation began when Bexo contacted us to determine the root cause of the May 2026 wallet-drain event.

A review of the wallet application pointed to a potential source of predictable randomness in an open-source library. We determined that it was possible to identify whether a mnemonic had been generated by the vulnerable implementation and developed a method to test for it.

After validating the method against an affected user’s mnemonic under controlled conditions, we confirmed the root cause.

This was the first confirmed link between the vulnerable implementation and a real wallet application, providing a starting point for identifying other potential users of the same code.

RRWallet

RRWallet was identified through public source-code research. We confirmed that the original RRWallet repository contained the vulnerable mnemonic-generation process. That repository is no longer publicly available, but the source code is preserved in this public fork.

We then used on-chain analysis to independently investigate whether the vulnerable recovery phrases were associated with the RenrenBit ecosystem. Among the wallets derived from 128-bit mnemonics using the English and Chinese wordlists, a significant number had interacted with addresses attributed to RenrenBit by Arkham’s entity labeling.

Milo Wallet

While analyzing a specific subset of the results from our 256-bit search, we noticed a notable concentration of on-chain activity: 96% of the wallets in that subset had received the same token, Milo, on Polygon.

We followed this on-chain lead and investigated the ecosystem around the token, eventually identifying Milo Wallet as a candidate application. We then obtained a historical application package for analysis.

We reconstructed its wallet-generation process and confirmed that the application could generate wallets matching those identified during the investigation.

NanChat

As part of our search across public source code and npm packages, we identified NanChat as a project in the Nano ecosystem using the vulnerable implementation through its dependency chain.

We traced the dependency into NanChat’s wallet-generation flow and confirmed that the affected code was used to generate wallets. We reported the issue to the NanChat team, who confirmed our findings.

The affected dependency was subsequently updated to replace the vulnerable entropy source with a cryptographically secure one. NanChat then released version 1.3.0 with a migration mechanism for affected wallets.

Bitcoin Libre

On-chain activity led us to a Twitter account associated with a Bitcoin Libre developer, which in turn led us to the Bitcoin Libre wallet application.

We contacted the developer, who confirmed that some versions of Bitcoin Libre prior to version 4 (released in July 2024) included the vulnerable library for entropy generation.

What We Have Confirmed So Far

After identifying potential wallet applications, we attempted to contact the relevant teams to confirm our findings and support remediation where possible. Some teams confirmed the findings and took action, while others could not be reached.

This process is inherently incomplete. Some applications have disappeared, some historical versions are no longer available, and not every team could be reached. The applications listed here are therefore only those we have confirmed so far, not a complete list of every application that may have been affected.

We will continue investigating additional candidates as new evidence becomes available.

Technical References