Solflare for Ransomware Victims: Using Cold Recovery Wallets to Isolate Compromised Keypairs

A Solana user discovers that a system has been compromised—whether through malware, phishing, or unauthorized access to a browser extension. Funds remain in a wallet connected to that device, and the risk is immediate: the attacker may already have access to private keys or recovery phrases, or may gain that access shortly. The practical question is not how to secure the compromised system; it is how to move assets into a completely isolated environment before loss becomes total.

This scenario requires a structured incident response that treats the original wallet as already exposed. The goal is to create a new, clean wallet on an uncompromised device, transfer remaining funds before an attacker can act, and establish the new environment as the authoritative source of truth for ongoing Solana transactions. Solflare, as a non-custodial wallet built specifically for Solana, provides the tools to execute this recovery. The critical distinction is that using a wallet correctly during recovery is different from using it under normal circumstances—backup procedures become immediate actions, isolation becomes a security requirement, and verification replaces assumptions.

Assessing exposure and deciding on immediate action

The first step is to understand what was likely exposed. If malware had local filesystem access, it may have read browser storage where wallet extensions keep encrypted keys. If the browser extension itself was compromised through a fake or modified version, the attacker may have seen every transaction, approval, and interaction. If the user’s seed phrase was ever typed into the compromised system—even if entered into what appeared to be the wallet application—it should be assumed to be known to the attacker. The practical implication is binary: if the device shows any sign of compromise, the existing wallet must be treated as no longer trustworthy.

The decision to move funds immediately is not paranoia. An attacker in possession of a Solana private key or seed phrase can transfer all SOL and SPL-standard tokens within seconds, especially on a network with Solana’s transaction finality. Ransomware operators specifically target cryptocurrency wallets for this reason—the value is liquid and the transfer is irreversible. Even if the attacker has not yet moved funds, they are not announcing their presence; continued delay increases risk with no offsetting benefit.

The timeline should be measured in hours, not days. The user should prioritize determining which device to use for the recovery wallet, obtaining that device, and initiating transfers. Other incident response activities—investigating how the compromise occurred, scanning systems, checking account access elsewhere—are important but secondary. They can run in parallel with recovery, and they should not delay asset movement.

One practical consideration: if the recovered device is also connected to the internet and capable of browsing, the user must immediately reset passwords for email accounts, cryptocurrency exchanges, and other services that could be used to lock out legitimate access. This is not directly a wallet problem, but a compromised email account in the hands of an attacker can be used to reset exchange passwords or lock the user out of other services. The recovery wallet depends on operating in an environment where the user retains control of their identity verification methods.

Selecting and securing the target device

The recovery wallet should be created on a device that has demonstrably not been in contact with the compromised system or the networks it used. This typically means a different physical computer or mobile phone, one that has not logged into the same email accounts, visited the same websites, or been configured by the same administrative account. A laptop from a family member, a newly purchased device that has never been used, or even a basic mobile phone can serve this purpose.

Mobile phones are often preferable for this task because their operating systems provide stronger isolation between applications, and they are less likely to have been used for web development, cryptocurrency trading tools, or other activities that might have left them exposed to advanced malware. A fresh Android device or iPhone can be more defensible than a laptop that has been in regular use. The trade-off is that typing long recovery information on a mobile keyboard is slower and more error-prone, but speed is less important than correctness in this context.

Before installing Solflare or any other application, the device should be updated to the latest operating system version and should not be logged into any account that was also used on the compromised system. It should not share WiFi, email, or backup accounts with compromised systems during this critical phase. The goal is to create an environment where the attacker has no obvious pathway in. If the recovery is occurring at home and the home network itself might be compromised, using a cellular connection or a friend’s WiFi adds another layer of isolation.

A Chromium-based browser such as Chrome, Brave, or Edge can be used if the recovery wallet is being set up on a computer; a mobile app installation is generally simpler and better-isolated. Regardless of the platform, the user should confirm they are installing from the legitimate source—the official browser extension store or app marketplace—and should verify that the installed application matches the expected interface before proceeding with wallet creation.

Creating the new wallet and understanding seed phrase storage

Once the device is ready, Solflare can be installed and a new wallet created. The application will generate a new seed phrase—a 12 or 24-word recovery sequence that represents the master key for all addresses and funds derived from this wallet. This seed phrase is the single most critical piece of information. Unlike the compromised system, where keys may be stored in browser storage or accessible to malware, this phrase will be written or stored only in the user’s direct control and nowhere else.

The non-custodial nature of Solflare means that the developers do not hold this seed phrase, cannot recover it if lost, and cannot reset the wallet if the phrase is forgotten. The user has full responsibility and full control. That is a security advantage—Dokia Capital, the creator of Solflare, cannot be coerced into providing access to funds—but it creates an absolute dependency on the user’s ability to protect the seed phrase itself.

During recovery, the seed phrase should be written on paper using a pen, not typed into any digital device except the wallet application itself. Some users create multiple physical copies in separate secure locations (such as a safe deposit box and a home safe); this is reasonable during recovery because the phrase represents an entirely fresh wallet with no prior history. The phrase should not be photographed, sent in email, typed into a text file, or stored in cloud services. It should not be shown to anyone, even a trusted friend, unless they are directly present and the wallet is being set up jointly with agreed-upon control mechanisms.

The wallet creation process should show the seed phrase once, allow the user to write it down, and then request verification by asking the user to re-enter specific words from the phrase. This verification step is critical—it confirms that the user has written the phrase correctly and can retrieve it if needed. After verification, the user should confirm that they have the phrase written down safely before proceeding to use the wallet.

Identifying the original wallet addresses and preparing for transfer

Before moving funds from the compromised wallet, the user needs to know the Solana addresses involved. This information should be obtained from the compromised system—viewing the address is safe, because addresses are public information. The user can take a screenshot of the address from the compromised wallet, write it down by hand, or note it in a separate document on the recovery device. The goal is to have a record of which addresses contain funds.

The user should also verify the current balance by checking a block explorer such as Solscan or Solana Explorer, which are publicly accessible and do not require a wallet connection. Entering a public address into a block explorer shows the balance, transaction history, and holdings of that address. This provides a checkpoint: the user knows how much should be moved and can confirm afterward that the transfer was complete.

For an address holding multiple token types—SOL, staked SOL, or SPL-standard tokens—each type may require a separate movement depending on its current state. Staked SOL is locked in a validator stake account and requires a dedicated unstaking process, which can take several days on Solana. The user should plan to initiate unstaking immediately even though the funds will not be available for transfer until the lock period expires. In some cases, liquid staking tokens (such as mSOL or stSOL) might be held instead of direct stake accounts; these can be transferred immediately like any other SPL token.

The information about what needs to be moved should be written down on the recovery device or on paper. The user should have a clear list: « Address ABC contains X SOL, Y of token Z, and M stake accounts awaiting unstaking. » This clarity prevents accidental transfers of partial amounts or forgotten assets.

Executing the transfer and verifying completion

With the new Solflare wallet created and ready, the user is now prepared to initiate transfers from the compromised addresses. The mechanics vary depending on the asset type. For transferable SOL and SPL tokens, the user must access the compromised wallet, initiate a send transaction, specify the address of the new wallet, and approve the transaction. Detailed instructions for this specific workflow are available in this guide, which covers both the initial wallet setup and movement of assets from legacy wallets.

The process is straightforward: open the compromised wallet, select « Send, » enter the address of the new Solflare wallet as the destination, specify the amount (or select « max » to transfer everything), review the network fee, and approve the transaction. The transaction will be broadcast to the Solana network and, if approved correctly, will arrive in the new wallet within seconds due to Solana’s fast finality. The user should not repeat or resubmit the transaction immediately if the interface is slow; waiting 30 seconds for confirmation is normal.

After the transaction is initiated, the user should verify completion by checking the block explorer for the destination address. The new Solflare wallet’s address can be found in the Solflare interface; entering that address into Solscan or the Solana Explorer will show incoming transactions. Once the funds appear in the block explorer as confirmed, they are in the user’s control on the new wallet. At this point, the user can consider the original compromised wallet to be abandoned and should not use it for any further transactions or approvals.

For staked SOL or locked tokens, the verification is different. An unstake transaction creates a stake account that must mature for a fixed period (approximately 2-3 days on Solana) before the SOL can be transferred. The user should verify that the unstake transaction was submitted and confirmed, then monitor the stake account status over time until it becomes available for withdrawal. The original compromised wallet should not be accessed again for any approvals during this waiting period.

Securing the new wallet for ongoing use

Once funds are in the new Solflare wallet on the clean device, the next priority is to ensure that this wallet remains secure going forward. The seed phrase should be stored separately from the device—written on paper in a physical location or stored in a hardware security module if the user has access to one. The recovery device itself should have a strong password or biometric lock, and the Solflare extension or app should be configured with any available security options such as PIN or biometric authentication.

Hardware wallet integration is an optional but valuable addition. Solflare supports integration with Ledger and Keystone hardware wallets. If the user acquires one of these devices, they can configure Solflare to use the hardware wallet as the key signer instead of storing keys on the phone or computer. This means that even if the device running Solflare is compromised, the private keys remain on the hardware device and the attacker cannot steal funds without physical access to the hardware. This is a significant security improvement for ongoing use after the recovery phase.

The user should also consider limiting the amounts held on the main wallet and moving larger balances to a hardware wallet or air-gapped backup if available. This reduces the practical impact of future compromises. For ongoing usage—NFT transfers, token swaps, dApp interaction, and staking management—the Solflare wallet’s built-in features (native token swap support, NFT storage, dApp connectivity) are convenient and secure as long as the device itself is not compromised. But the device is only secure as long as the user maintains it; security is not a fixed state but an ongoing process of updates, avoiding suspicious software, and remaining aware of the network being used.

Preventing the next compromise

The recovery process itself is not a solution to the underlying problem—the system was compromised in the first place. Repeating the same practices or using the same infrastructure will likely lead to another incident. The user should invest time in understanding how the compromise occurred and in changing behavior or tools to avoid it.

Common vectors for wallet compromise include fake wallet websites or extensions, malware from suspicious downloads, phishing emails that trick users into authorizing transaction approvals, weak passwords reused across multiple services, and unpatched operating systems. Each has specific mitigations: verify URLs directly from the official project website rather than following links in emails or ads; use an ad blocker and script blocker to reduce exposure to malicious advertisements; enable multi-factor authentication on email and cryptocurrency exchanges; use unique, complex passwords managed by a password manager; and enable automatic operating system updates.

For Solana specifically, using a non-custodial wallet like Solflare is already a significant security advantage because it means the user—not an exchange or centralized service—controls the funds. The remaining risks are device-level and behavioral. Browser extensions are more likely to be compromised than mobile apps, so using the mobile Solflare application instead of the browser extension reduces attack surface. Avoiding frequent approvals on untrusted or public networks, clearing browser cache regularly, and logging out of wallets after use are practical habits that reduce exposure.

The recovered wallet should also be treated differently than the original one was. If the original wallet was used frequently on a compromised system, the new one should be used more carefully. Regular backups of critical data, isolated usage for large transactions, and periodic verification of the wallet’s address against the block explorer all contribute to long-term security. Solflare’s interface makes these practices straightforward, but they require user discipline to maintain.