Exposing Solana Scammers: Scams and Phishing
Introduction
As the Solana ecosystem experiences a seemingly never-ending rapid growth, phishing and scam incidents have also risen. Scammers once focused on EVM platforms, have increasingly targeted Solana users with more advanced technical methods and covert phishing techniques. Various types of phishing scams are becoming increasingly common. Over the past six months, the GoPlus security team has identified four main types of phishing scams through extensive case studies: Airdrop Scams, Malicious Signatures, Authority Transfers, and Address Poisoning. This article will explore these four phishing scenarios in detail. Additionally, many users have reported financial losses due to wallet simulation failures in mainstream Solana wallets, which we will also analyze in depth.
Scam Scenarios Analysis
Airdrop Scams
First, airdrop scams refer to phishers posting phishing website links disguised as airdrop activities in communities like Twitter and Discord. It mostly happens in some famous project’s Discord server and some real airdrop tweets’ comments.
Among them, on-chain airdrop phishing targeting NFTs involves phishers airdropping NFTs associated with phishing links to users and enticing them to click the link and sign malicious transactions. The image below shows a case where the user received an NFT claiming to redeem 1,000 ZERO tokens. The user clicked the link in the NFT and signed the transaction, later finding that tokens like BONK, ZERO, and USDC were stolen from their wallet.
The principle behind airdrop scams is relatively simple. Phishers use fake airdrop activities to lure users to enter a website and sign a transaction linking their wallet to the site. At this point, the site initiates a phishing transaction containing one or more SOL/SPL Token transfer instructions to acquire the user’s assets. There is a distinction between a single instruction transfer and multiple instruction transfers. Simpler phishing, as shown on the left, involves a single transaction transferring one token type. More complex phishing can include many transfer instructions within a single transaction, as shown on the right.
Malicious Signatures
The second type of scam is malicious signatures. Some experienced users observe wallet simulation results to avoid airdrop phishing. However, phishers exploit this by using anti-simulation and fake simulation techniques to confuse users, increasing the likelihood of malicious transactions being signed. Specifically, by merging transactions, using malicious browser plugins, and other anti-simulation methods (which will be focused on later), the wallet displays false profit results or even no simulation results, thereby inducing users to sign phishing transactions.
Authority Transfers
The third type of scam is authority transfers. In Solana, the SPL Token’s approve operation does not directly lead to token transfers but results in transferring the token asset’s permissions. Therefore, phishers induce users to sign phishing transactions containing the authority operation, transferring ownership of a token account in the user’s wallet to the phisher’s wallet. When the token account ownership transfers, as shown below, the mainstream wallet will issue a warning about the ownership transfer.
The principle behind authority transfers is that each token in Solana has a separate account, Token Account. Hackers can change the token account’s owner by initiating a transaction containing the 「createSetAuthorityInstruction」 operation. Once this operation succeeds, the user cannot transfer the token out even if the token remains in the wallet.
Address Poisoning
The fourth type of scam is address poisoning. It aims to induce users to transfer funds to a phishing address, which resembles the addresses users interact with daily or consider safe, with similar prefixes or suffixes designed meticulously. As shown below, except for the differences circled in red, both addresses have the same prefix and suffix, confusing users into copying the fake phishing address and transferring funds to it. Address poisoning scams are common in Ethereum and Tron and have recently spread to the Solana ecosystem.
Address poisoning can be further divided into the following categories:
- 0U/Small Amount Transfer, where phishers transfer 0 or a small amount of cryptocurrency to induce users to copy the phishing address from historical transaction records incorrectly.
- Transfer + Airdrop Mixed Poisoning, where phishers transfer a small amount of tokens and add airdrop phishing links in the transaction memo to lure users into clicking.
3. Fake System Program Address Poisoning. Attackers generate addresses similar to fake system program addresses as phishing addresses, causing users to believe the phishing address is a trusted address mistakenly. This type of scam was reported on February 3, 2024, by Scam Sniffer on Twitter, where attackers generated addresses with the same suffix as the system program, making users think the disguised address was a normal system program. Fake system program addresses can be generated using the command “solana-keygen grind — starts-with <desired-prefix>:1 — ignore-case.” For example, to get a prefix of “8888,” you would enter this prefix into the command.
Transaction Simulation and Anti-Simulation
Transaction Simulation on Solana provides users with a way to observe the transaction execution results before the transaction happening on chain. The specific process for transaction simulation is shown below. After constructing a transaction object and serializing it, requesting the 「simulateTransaction」 method returns the transaction simulation result, such as changes in account balances and authority. This feature is common in mainstream Solana wallets, helping users check transaction security before confirmation.
However, transaction simulation can sometimes fail, mainly in two situations:
- Anti-Simulation: The transaction simulation fails due to network fluctuations or other reasons, making it impossible to infer transaction execution results.
- Fake Simulation: The transaction simulation succeeds, but the simulated execution results differ from the actual on-chain results.
Anti-Simulation
Anti-simulation can occur in two scenarios:
- Wallet issue. For example, early Phantom wallets merged instructions from different transactions when initiating multiple transactions, causing the simulated transaction size to exceed the maximum limit.
- Network errors. Simulation transaction requests to the wallet RPC service may encounter denial of service attacks, malicious plugin proxy requests, or long request response times, leading to network errors and simulation failures.
Taking the Phantom wallet as an example, we intentionally created network errors during its simulation transactions. The specific code is shown below: First, we connect to an RPC service through Solana web3js. Then, we create dozens of transactions, each containing many instructions. Finally, we send these transactions to the wallet. Due to possible network timeouts, it is impossible to view the simulation results.
Fake Simulation
Fake simulation can occur due to two possible reasons:
- Durable Nonce. This mechanism allows signing first and initiating transactions at a future time. However, if the transaction triggers an upgradable contract (which could be maliciously modified), the simulated transaction execution result at the signing time may differ from the actual execution result when the transaction is initiated.
- Wallet implementation flaws. For example, the wallet simulates multiple transactions simultaneously, resulting in inaccurate results.
Using the Phantom wallet as an example, we simultaneously initiate multiple identical transactions, with the simulation showing the execution result of only one transaction. As shown below, the code sends 0.00002 SOL, but the simulation result shows only 0.00001 SOL.
Mainstream Wallet Anti-Simulation and Fake Simulation Issues
Further, we also explored whether other wallets have similar anti-simulation and fake simulation problems. Here, we analyze two other common Solana wallets, Solflare and Backpack.
Solflare
- It does not display the confirmation button in case of network timeout, reducing the anti-simulation risk caused by network delays.
- When simulating multiple outgoing transactions simultaneously, it does not display the balance change but directly prompts a risk warning.
Backpack
- Like Solflare, it does not display the confirmation button in case of network timeout, reducing the risk of anti-simulation caused by network delays.
- It may have potential risks associated with fake simulation. Referring to the above Phantom fake simulation code, it sends 0.00002 SOL, but the simulation result shows 0.00003 SOL.
Conclusion
User security in the Solana ecosystem still faces significant challenges. While mainstream wallets offer some security features, these do not cover all potential risks. Transaction simulation results are not always reliable, posing serious user risks. Even the most cautious users, who rely on simulation results, can be misled by anti-simulation and fake simulation techniques, leading them to sign malicious transactions.
The GoPlus security team has launched a wallet drainer detection feature to address these challenges. This new capability will empower mainstream applications in the Solana ecosystem by detecting and intercepting potential scams and phishing transactions in real-time, fully protecting each user’s transactions. This development will significantly enhance user security and contribute to the stability and prosperity of the Solana ecosystem. The GoPlus security team urges the Solana blockchain and its ecosystem partners to accelerate the development of user security infrastructure. By providing a safer and more reliable trading environment, and through continuous technological innovation and security protection upgrades, we can effectively reduce the occurrence of phishing scams, protect users’ digital assets, and ensure the long-term stability and healthy development of the Solana ecosystem.
