Recently, a user posted about losing millions of RMB in assets due to a phishing scam on Solana. According to the description, he mistakenly clicked on a link posted by a phishing group under a tweet from the Maneki project, leading him to a fraudulent website.

What puzzled him was that during the interaction, the website did not seem to require any token authorization operation, and the hacker succeeded in stealing the assets directly. When he realized there might be an issue with the website and attempted to transfer tokens from his wallet to avoid theft, he found that multiple attempts to transfer failed, and he could no longer withdraw his assets.

Due to the limited details provided, we cannot fully bring back the incident scene. However, it is clear that the user lost control of the Maneki token account, which is why the attempts to transfer assets from his wallet failed. Users accustomed to EVM might be confused about what account control means.

This is because Solana uses an implementation different from the EVM chain. Continuing to interact with Solana using the habits from EVM is like using an outdated sword to fight a modern battle, inevitably leading to significant risks.

To enjoy playing on Solana, it is essential to understand Solana’s characteristics and fraudulent tactics. For this reason, we have compiled some of the attack methods on Solana that differ from those on EVM, hoping to help users unfamiliar with Solana avoid pitfalls.

1. Cuckoo in the Nest: Token Account Ownership Transfer

The protagonist of our opening case encountered this type of attack. In a Solana wallet, each token has a separate account (Token Account), similar to how a bank account may have separate accounts for different currencies like RMB and USD, which are independent of each other. Each token account also has an ownership attribute.

By default, the owner of a token account is designated as the current wallet. However, this is not hard-coded. By calling the createSetAuthorityInstruction operation, the ownership of the token account can be changed. Hackers use this operation to trick users into transferring the ownership of a token account from their wallet to the hacker’s wallet.

Once successful, even though the tokens are still in the wallet, the user cannot transfer them out, which is essentially the same as having the tokens stolen.

Due to the high risk of this operation, both Phantom and @Backpack_CN wallets intercept and warn users of the transaction’s risks, requiring a second confirmation for the transaction, unless the user insists on approving it.

2. No Pre-authorization Required for Transactions on Solana

On EVM, a phishing contract needs the user to authorize the contract on the token contract before it can transfer tokens from the user’s wallet. The phishing contract can only initiate the transaction to transfer the user’s assets after receiving authorization.

However, on Solana, “approve” doesn’t mean authorization but rather transaction approval. If the user mistakenly treats this as the authorization step and approves it, the phishing transaction is sent out, leaving little chance for recovery.

A more dangerous situation is if the user is tricked into authorizing tokens on EVM, only the authorized token is affected, and other unauthorized tokens remain safe. On Solana, since no authorization is required and only user approval is needed to transfer tokens, combined with the third point we’ll discuss next, it could result in significant losses for the user.

3. Beware of Being Induced to Transfer Multiple Tokens

Solana’s transaction design allows multiple sub-transactions to be included in a single transaction, with each sub-transaction completing an interaction, such as transferring a specific token. Compared to EVM, where transferring each token requires a separate transaction, this feature of Solana provides some convenience.

For example, your wallet might contain some tokens with very low value, less than 1 USD. Sol-incinerator utilizes this feature to allow users to batch send small-value tokens from their wallet and convert them back to SOL without needing multiple conversions, which would consume a lot of gas and save operational time.

While this feature provides convenience, it also greatly facilitates hacking activities. If a hacker successfully tricks a user into confirming a transaction, they can drain the user’s wallet of tokens, NFTs, and even SOL. Therefore, if you see a transaction involving the transfer of many tokens, be cautious as it might be a hacker attempting to empty your wallet using this feature.

4. Stealing Transaction Signatures

In the EVM ecosystem, permit signatures are favored by phishing groups due to their stealthiness and the fact that they do not appear in the authorizer’s wallet. Currently, more than half of phishing attacks use this method. In the Solana world, there is a similar method: Durable Nonce.

Durable Nonce functions similarly to permit. If a user unknowingly signs a transaction, they will not immediately lose assets or see this transaction in their wallet. Instead, the signed transaction information is sent to the phishing group, who then submit the transaction to the blockchain. This offline transaction characteristic is just as dangerous as permit.

Since Solana can simulate transaction results, Durable Nonce is more readable than permit, making it easier for users to identify. However, phishing groups have combined Durable Nonce with contract upgrades to more effectively steal assets while bypassing transaction simulation warnings.

Phishing websites first interact with users using normal contracts without malicious transactions. The wallet’s transaction simulation feature shows no issues at this stage. Once the user approves the transaction, the phishing group does not immediately broadcast it to the blockchain. Instead, they wait and later upgrade the contract to a version with malicious code before broadcasting it. The user will then suddenly find their assets missing, often days after they signed the transaction.

This upgraded attack method is extremely stealthy and harmful. Current transaction simulation functions cannot display this risk. Therefore, it is crucial to maintain high vigilance and not rely too heavily on wallet software warnings or blindly trust transaction simulation results.

Conclusion

The original design purpose of these features was to lower user barriers and provide more convenience. However, like a double-edged sword, new technologies have also provided phishing groups with a wider range of attack methods.

Just before writing this article, Solana released two new features: Action and Blink. While there is much anticipation around these features, some have also warned about the potential for phishing groups to exploit them.

Phishing on Solana is characterized by one-click operations and high stealth. Due to rpc instability and other reasons, transaction simulation functions may not always work, so they cannot be fully relied upon.

It is recommended for users with the means to use a Keystone hardware wallet for interactions. This adds an extra layer of confirmation, preventing quick confirmation transactions caused by impulse or misclicks.

Additionally, Keystone parses transactions on the hardware end. In cases where software wallet transaction simulations fail, the hardware can still parse the transaction content, providing the last line of defense.

Blockchain technology is constantly evolving and transforming. While we worry about the risks associated with new technologies, we cannot afford to stop progressing. Phishing groups are like pests that everyone wants to eliminate, and professionals, including hardware wallet manufacturers and security companies, are continuously developing solutions to counter new threats.

As ordinary users, it is essential to remind ourselves not to be lured by “free gifts” but to scrutinize transaction details carefully. With this level of security awareness, phishing attempts are much less likely to succeed.

Disclaimer：

1. This article is reprinted from [Keystone]. All copyrights belong to the original author [Keystone]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.