Wallet Scam: A Case Study in Crypto Drainer Tactics

Key takeaways

• Check Point Research (CPR) uncovered a malicious app on Google Play designed to steal cryptocurrency marking the first time a drainer has targeted mobile device users exclusively. The app used a set of evasion techniques to avoid detection and remained available for nearly five months before being removed.
• To pose as a legitimate tool for Web3 apps, the attackers exploited the trusted name of the WalletConnect protocol, which connects crypto wallets to decentralized apps. Fake reviews and consistent branding helped the app achieve over 10,000 downloads by ranking high in search results.
• Advanced social engineering and the use of the most modern crypto drainer toolkit allowed the hackers to steal approximately $70,000 in cryptocurrency from victims.

Introduction

Crypto drainers are malicious tools that steal digital assets like NFTs, and tokens from cryptocurrency wallets. They often use phishing techniques and leverage smart contracts to enhance their impact. Typically, users are tricked into visiting phishing websites that mimic legitimate cryptocurrency platforms. Drainers then initiate fraudulent transactions and deceive users into signing them, allowing the drainer to siphon off funds to the attacker.

As crypto wallets become more secure and Web3 users grow more aware of malicious techniques, it becomes increasingly challenging for attackers to trick a victim into authorizing a malicious drainer transaction. Now, cybercriminals are developing more sophisticated methods to deceive users.

Recently, attackers shifted their focus to mobile devices, marking the first time drainers exclusively targeted mobile users. Check Point Research (CPR) uncovered a malicious crypto drainer app on Google Play that exploited the name of the well-known Web3 protocol, WalletConnect, creating the illusion of legitimacy. Using advanced evasion techniques, first published on March 21, 2024, the app remained undetected for over five months and was downloaded over 10,000 times.

Figure 1 – Malicious WalletConnect application in Google Play.

The fake WalletConnect application has already been removed from Google Play. However, it managed to victimize over 150 users, resulting in losses exceeding $70,000. Not all of the users who downloaded the drainer were affected. Some didn’t complete the wallet connection, others recognized suspicious activity and secured their assets, and some may not have met the malware’s specific targeting criteria.

Exploiting WalletConnect Users With Social Engineering

WalletConnect is an open-source protocol that acts as a bridge between decentralized applications (dApps) and cryptocurrency wallets using either a QR code or deep linking, which are URLs that navigate directly to a particular part of an application. It allows users to interact with dApps directly from their mobile wallets without the need to expose private keys, making it a crucial tool for enhancing security and user experience in the decentralized finance (DeFi) ecosystem.

WalletConnect stablishes communication between dApps and mobile wallets. It was created to solve the problem of seamlessly connecting dApps with various wallets, ensuring a smooth and secure user experience.

Figure 2 – WalletConnect workflow for connecting to a Web3 application.

However, users may experience issues with WalletConnect when connecting to Web3 applications. Some wallets don’t support WalletConnect. For example, one of the most popular wallets for EVM networks like Ethereum, MetaMask, did not support WalletConnect v2 until last year, causing difficulties for many users (https://github.com/WalletConnect/walletconnect-monorepo/issues/2622). Additionally, even if a wallet implements WalletConnect support, some users may lack automatic app updates and still use outdated versions. In such situations, when opening a Web3 application in a mobile browser and attempting to connect the wallet via WalletConnect, the wallet app typically opens, but the connection does not occur.

If the wallet connection to a Web3 application fails, the wallet connection window can give the impression that WalletConnect is just another wallet like MetaMask. For example, this is how the connection window looks on the popular platform OpenSea:

Figure 3 – Connecting a wallet to a Web3 application.

Given all the complications with WalletConnect, an inexperienced user might conclude that it is a separate wallet application that needs to be downloaded and installed. Attackers hijack the confusion, hoping that users will search for a WalletConnect app in the application store.

However, when searching WalletConnect in Google Play, users find the malicious app “WalletConnect – Crypto Wallet” at the top of the list:

Figure 4 – Malicious WalletConnect app appearing at the top of Google Play search results.

Despite the app’s high rating and numerous positive reviews, a deeper, more thorough analysis is needed to uncover the following discrepancy:

Figure 5 – Fake review and high rating of the malicious WalletConnect app.

Application reviews are evidently fake, as they are unrelated to the app’s actual content. After analyzing review pages, we found prevalent fake reviews in English, French, and Spanish.

The Deceptive WalletConnect App

The malicious WalletConnect app we found has the package name – “co.median.android.rxqnqb” and was created using the service median.co. This service allows users to convert a website into an app for Android or iOS. The app essentially functions as a web browser that opens a specified site. Median.co enables the configuration of the app icon, status bar, behavior when links are clicked, initial URL, and other parameters.

The app was published on Google Play on March 21, 2024 under the name “Mestox Calculator”. The application’s name was later changed several times.

Figure 6 – Cached app page in Google.

Obfuscation and anti-analysis techniques

In this section, we explore how the application operates and uncover why it has zero detection on VirusTotal (VT). We also explain how it passed verification on Google Play while remaining undetected for so long despite its obvious malicious nature.

Figure 7 – APK detection on the VirusTotal.

The initial URL of the analyzed malicious Median application points to “https://mestoxcalculator[.]com/”.

If users visit this site through a browser, they will see a seemingly harmless web application, a multifunctional calculator with many features called “Mestox Calculator”. The website is based on the open-source project called CalcDiverse.

Figure 8 – Mestox Calculator decoy application.

However, this is all a charade to evade detection of the app’s malicious functionality. Before we start, the complete workflow of how their resources operate is illustrated in the graph below:

Figure 9 – Malicious application workflow.

Depending on certain parameters, such as the user’s IP address and User-Agent, the user is redirected to the following resource:

https://connectprotocol[.]app/gate/index.php

Figure 10 – Redirecting to the malicious website.

This technique allows attackers to pass the app review process in Google Play, as automated and manual checks will load the “harmless” calculator application.

The new link hosts the actual malicious web application. However, another technique to evade analysis and detection is used during its loading phase. The main HTML page contains an embedded script encoded in BASE64:

Figure 11 – Base64-encoded inline script on the main page of the malicious application.

This script loads another script, which is located at an address also stored in BASE64 encoding:

Figure 12 – Decoded inline script.

After decoding the BASE64 string, we obtain the address from which the next script is loaded:

https://web3protocol[.]online/server.php?__id=a98fdf84-1d17-11ef-a38c-44a842484069

It should be noted that during our experiments, the “__id” field remained the same each time and did not change based on the client’s IP address or User-Agent.

We discovered that if the user’s location is in certain countries (as determined by the IP address) and if the User-Agent of the HTTP request does not match that of a mobile device, “server.php” generates code for redirection to a legitimate resource, while the value of the “__id” request field remains unchanged:

Figure 13 – The script redirects desktop browsers to a legitimate website.

Otherwise, “server.php” generates an empty response and no redirection occurs, allowing the user to see the main page of the malicious application.

The loaded app mimics the design of the legitimate Web3Inbox app. It is also noteworthy that in January 2024, the Web3Inbox app announced support for WalletConnect, as reported in a blog post by WalletConnect (https://walletconnect.com/blog/introducing-web3inbox-app).

Figure 14 – Comparison of the design between the malicious application (left) and the legitimate Web3Inbox application (right).

The main malicious functionality of the application is implemented in the script: https://connectprotocol[.]app/assets-998111/web3-provider.js

Figure 15 – The main obfuscated script of the application.

The script is most likely obfuscated using the service obfuscator.io with the “High obfuscation” preset, which also includes anti-debugging protection:

Figure 16 – Obfuscator parameters explanation.

When attempting to open the developer tools in the browser before and after the site loads, the anti-debugging function continuously triggers the debugger, freezing the application.

Figure 17 – Anti-debug techniques implemented in the obfuscator.

Thanks to the availability of deobfuscators for obfuscator.io, we were able to obtain partially deobfuscated code that can be analyzed after renaming the variables. After deobfuscation, we can also identify the function responsible for the anti-debugging technique mentioned earlier, which is located at the very end of the file web3-provider.js:

Figure 18 – Deobfuscated and beautified code of the anti-debug technique.

To disable this anti-debugging technique, you just need to set a breakpoint inside the “try” block of the “antidebug” function and execute the following code in the console when the breakpoint hits:

antidebug_recursive.prototype.constructor = function() {};

Now we can analyze the application without any hindrance.

Our analysis revealed that all malicious code occurs outside the application, with the app serving merely as a thin client for these harmful operations. Such a design makes it challenging to detect malicious actions as they don’t require any permissions, and external resources control app behavior. This approach allows the attackers and their schemes to remain undetected.

MS Drainer

After analyzing the malicious application’s de-obfuscated JavaScript code, we identified it as the MS Drainer, specifically the version dated May 26, 2024. Considering that the malicious application first appeared in March, we can conclude that its operators keep its functionality updated with the most recent features.

MS Drainer is a highly advanced malicious toolkit that represents one of the most sophisticated drainers currently available on the market. It supports a wide range of EVM blockchains, including Ethereum, BNB Smart Chain, Polygon, Avalanche, Arbitrum, Fantom, and Optimism.

The drainer excels in its asset discovery capabilities. It utilizes reliable providers like DeBank, Ankr, Zapper, or OpenSea to scan user wallets for valuable assets such as primary coins, ERC-20 tokens, and NFTs. Once identified, the drainer automatically withdraws these assets, prioritizing the most valuable ones and optimizing the transaction process to minimize fees.

At the time of this publication, MS Drainer is available for purchase at a base price of $1,499.99, which includes all core functionalities except for additional modules. The drainer is sold with its complete source code, detailed installation instructions, and ongoing support to address any issues. The developers can significantly increase their revenue through a 10% commission on transactions processed via the public smart contract associated with the drainer.

Drainer functionality

When the deceptive WalletConnect app is launched, users are immediately prompted to connect their wallet. We assume that users install this malicious app to connect their wallet to Web3 applications that do not support direct connections to wallets like MetaMask, Binance Wallet, or Trust Wallet, but only use the WalletConnect protocol. They likely expect the downloaded WalletConnect app to function as a sort of proxy. Therefore, the connection request does not appear suspicious.

Figure 19 – Wallet connection window in the malicious application.

When the user clicks on one of the wallet buttons, the malicious app launches the selected wallet and opens a malicious website, https://connectprotocol[.]app/gate/wc/, using a deep link.

Figure 20 – Deep link used to open the malicious website in the Metamask wallet browser.

The following deep links are used depending on the type of wallet selected:

• Metamask: dapp://connectprotocol[.]app/gate/wc/
• Coinbase: https://go.cb-w[.]com/dapp?cb_url=https://connectprotocol[.]app/gate/wc/
• Trust Wallet: https://link.trustwallet[.]com/open_url?coin_id=60&url=https://connectprotocol[.]app/gate/wc/

When Binance Wallet is selected, the extension page opens in the Chrome browser.

Next, the user is prompted with a message stating that they must verify their wallet and are asked to sign several transactions consecutively.

Figure 21 – Deceptive wallet verification request.

Each user action sends an encrypted message to the Command and Control (C&C) server. The web application also transmits information about the user’s wallet, the selected network (such as Ethereum or BNB Smart Chain), and the addresses in use.

In the initial messages, the server sends the client a configuration that includes the attacker’s wallet addresses used during the attack, the addresses of smart contracts, and their ABI (Application Binary Interface).

After receiving the blockchain addresses from the client, the server gathers information about the victim’s assets and their value and sends this data back to the client to generate malicious transactions.

C&C communication

The malware uses a dedicated host as its C&C server: cakeserver[.]online.

Figure 22 – Requests to the C&C server.

Before sending, MS Drainer converts the data into JSON format, encodes it in BASE64, and then encrypts it using a proprietary algorithm (the “prs” function shown in the screenshot below). The encrypted data is then sent in the body of an HTTP POST request:

Figure 23 – Format of requests to the C&C server.

The argument “ver” shows the MS Drainer version number. The “raw” argument contains the encrypted data.

We extracted data encryption and decryption algorithms used by the malware:

const prs = (key, data) => {
  const stringToCharCodes = str => str.split('').map(char => char.charCodeAt(0));
  const toHexString = num => ('0' + Number(num).toString(16)).substr(-2);
  const xorWithKey = initialValue => stringToCharCodes(key).reduce((accumulator, charCode) => accumulator ^ charCode, initialValue);

  return data.split('').map(stringToCharCodes).map(xorWithKey).map(toHexString).join('');
};

const srp = (key, encryptedData) => {
  const stringToCharCodes = str => str.split('').map(char => char.charCodeAt(0));
  const xorWithKey = initialValue => stringToCharCodes(key).reduce((accumulator, charCode) => accumulator ^ charCode, initialValue);

  return encryptedData.match(/.{1,2}/g).map(hexString => parseInt(hexString, 16)).map(xorWithKey).map(charCode => String.fromCharCode(charCode)).join('');
};

let MS_Encryption_Key = 0x20e601731;
let base64Key = btoa(String(3295 + MS_Encryption_Key));

// encryption
encryptedData = prs(base64Key, btoa(JSON.stringify(dataToEncrypt)));

// decryption
decryptedData = atob(srp(base64Key, encryptedData));

Using the decryption algorithms shown above, we can decrypt both requests and C&C responses. The decrypted messages contain data in JSON format. Let’s examine the most critical stages of the malware’s communication with the server.

Configuration request

MS Drainer supports flexible configuration of parameters. In the very first message, the client sends a request for the drainer’s configuration. The decrypted request appears as follows and includes the user ID and a timestamp:

Figure 24 – Decrypted configuration request.

The server’s response is quite lengthy, so we show only the portion containing the most relevant information:

Figure 25 – Decrypted configuration (part).

• Public_Contract: Contains the addresses of the smart contracts used by the drainer to withdraw funds across different networks. The contract addresses in the configuration are the same for all networks.
• Receiver: The wallet address of the attackers.
• Address: The address for which token withdrawal permission is granted (to be described further below): 0xf721d710e7C27323CC0AeE847bA01147b0fb8dBF.
• CIS: If set to true, the drainer’s operation in CIS countries is restricted. In this case, the parameter is set to false, allowing the drainer to operate in all countries without restrictions.

We note that MS Drainer was developed by Russian-speaking programmers, and the usage rules for MS Drainer (https://lolz[.]live/threads/4869270/) explicitly prohibit its use in CIS countries:

14. The buyer agrees that using this script within the territory of the Russian Federation, CIS countries, and the EAEU is strictly prohibited. The seller also informs that the script includes technical functions to block its operation if it detects that the user is located in these regions and attempts to use the script.

Successful connection notification

A message confirming the successful connection is sent when the user connects their wallet to the malicious Web3 application. This message includes the victim’s blockchain address, the name of the wallet used, and the network identifier (e.g., Ethereum, BSC, etc.):

Figure 26 – Successful connection notification.

Check Wallet request

On the C&C server side, data collection is implemented for the victim’s assets, such as tokens, NFTs, and their values. To retrieve this information, the client sends the following request to the server for each wallet:

Figure 27 – Check Wallet request.

The server responds with a list of all the user’s assets across different networks, including their value in USD:

Figure 28 – Check Wallet response with the list of assets.

Theft of Funds from Victim’s Wallets

As shown above, the application retrieves the value of all assets in the victim’s wallets. It first attempts to withdraw the more expensive tokens, followed by the cheaper ones.

The native cryptocurrency, such as ETH or BNB, can be withdrawn either by direct transfer to the attacker’s wallet or through a public smart contract provided by the MS Drainer developers. This smart contract has an attractive address like 0x000…000 to appear more trustworthy. It also has a verified source code and is relatively simple. The contract includes various functions with names like ClaimReward, Connect, Withdraw, and Execute, allowing it to be used in numerous fraudulent schemes. All these functions perform the same sequence of actions: they transfer funds to the attackers’ wallets and send a certain percentage to the MS Drainer creators.

Below is an example of a transaction to the attackers’ wallet (0xfac247a19Cc49dbA87130336d3fd8dc8b6b944e1) through an intermediary smart contract (0x0000366a6afea972e4353b070ad904744a530000): https://etherscan.io/tx/0xc71da5090e9b0407c90dcc63740ebaf68db0add522b4bf790dd73633962c15b1

Figure 29 – Stealing assets from the victim’s wallet using the intermediary contract.

The drainer uses two transactions for each token to steal ERC-20 and BEP-20 tokens, such as USDT, implemented through smart contracts. The first transaction calls the “Approve” method on the token contract from the victim’s wallet. The “Approve” method in the ERC-20 and BEP-20 token standards grants permission to another address to spend a certain amount of tokens on behalf of the token holder. The second transaction, initiated by the attacker, calls the “TransferFrom” method to withdraw the tokens.

To better understand how this occurs, let’s examine the following diagram and each step in more detail.

Figure 30 – ERC-20 and BEP-20 token theft.

Similar to the theft of native cryptocurrency, the malicious app first tricks the user into signing a transaction in their wallet. Through this transaction, the victim grants permission for the attacker’s address 0xf721d710e7C27323CC0AeE847bA01147b0fb8dBF (the “Address” field in the configuration) to transfer the maximum amount of the specified asset (if allowed by its smart contract) . The request to sign such a transaction in the wallet application:

Figure 31 – Token “approve” request for the infinite amount of tokens.

Next, on the backend of the malicious application, the “TransferFrom” function of the token’s smart contract is called, which directly transfers the tokens from the victim’s wallet to the wallet 0xfac247a19Cc49dbA87130336d3fd8dc8b6b944e1 controlled by the attackers (the “Receiver” field in the configuration).

Below is an example of a transaction with the “Approve” call for the WMT token on the Binance Smart Chain (BSC) network: https://bscscan.com/tx/0x0ddea61fa8afb05c3a4420bc39b38619ea9d23b2e9ac53770439bc455e700ab7

Figure 32 – ERC-20 token “approve” transaction.

Next, we see the withdrawal of funds from the victim’s wallet using the “TransferFrom” function: https://bscscan.com/tx/0xe319cc872f94271073494884f800201b8f210f8bf9aed8bbce165b4015af4e38

Figure 33 – ERC-20 token “TrasferFrom” transaction.

The use of two different addresses for stealing tokens involves several security considerations. In this scheme, the “TransferFrom” operation is executed on the backend, which implies that the backend server would need access to the private key, making it vulnerable to potential breaches or seizures. The first attacker’s address (0xf721…8dBF) is used solely to facilitate the transaction, while the stolen tokens are sent to a third, secure receiver address (0xfac2…44e1), whose private key is protected and can be stored securely. This approach also allows the attacker to capture tokens that are transferred to the victim’s wallet in the future.

In this regard, it is important to note that if the victim does not revoke the permission to withdraw tokens from their wallet, the attackers can keep taking them so as soon as funds appear in the victim’s wallet. No further action from the victim is required for this to happen. Therefore, if you were victimized by a drainer, it is unsafe to continue using your wallet until you create a new one or revoke the token spending approval for each token.

After attempting to withdraw funds in the current network, the application automatically suggests switching to a different network:

Figure 34 – Network switch request.

Withdrawal attempts then continue for assets used in another network.

The number of victims and their loses

We analyzed the address 0xfac247a19Cc49dbA87130336d3fd8dc8b6b944e1 from the malicious application’s configuration, where the stolen funds from victims are stored. In various EVM networks, we found token transactions from over 150 addresses, which allows us to estimate the number of actual victims.

There were almost no outgoing transactions from the attackers’ wallets, and most of the stolen funds were kept at the attackers’ addresses across various networks. Based on blockchain explorer data, we estimate the total current value of assets accumulated in the attackers’ wallets to be over $70,000:

Figure 35 – Funds accumulated in the attackers’ wallets.

Of the users who lost money, only twenty wrote negative reviews on Google Play, saying the app was a scam. This could mean many victims are still unsure about what happened and where their money went. What’s more, when the app does get bad reviews, the malware developers usually flood the page with fake positive reviews to make the app look good and to mislead other potential victims.

Figure 36 – Fake & Negative Reviews in Google Play (translated).

When we inspected all the transactions, we noticed another one occurred before the app loaded but with the same smart contact.

Figure 37 – Transaction that uses the same Smart contract.

Indeed, a few months back, an application called “Walletconnect | Web3Inbox” was made available on Google Play. This app employed the same methods designed to trick the user that we found during our research:

• The app has the same legitimate “median.co” service that converts the website to the app.
• The app was previously called a calculator (“WC Calculator” according to the app description screenshots).
• The app description is a combination of the calculator description and the description of WalletConnect.
• The final name contains the keywords “WalletConnect” and “Web3Inbox”.

Figure 38 – Information about similar applications.

Therefore, we can assume that this was an earlier attempt to deploy malicious applications on Google Play. According to the statistics, more than 5,000 people installed this application.

Conclusion

We uncovered a novel use of the MS Drainer toolkit that explicitly targets mobile users through malicious apps on Google Play. The attackers leveraged a combination of social engineering, technical manipulation, and clever exploitation of user confusion to carry out a sophisticated crypto draining operation. By capitalizing on a well-known and trusted name like WalletConnect and exploiting the shortcomings of simple and undemanding applications, they were able to deceive over 150 victims and accumulate significant amounts of cryptocurrency without triggering immediate suspicion.

This incident highlights the growing sophistication of cybercriminal tactics, particularly in the realm of decentralized finance, where users often rely on third-party tools and protocols to manage their digital assets. The malicious app did not rely on traditional attack vectors like permissions or keylogging. Instead, it used smart contracts and deep links to silently drain assets once users were tricked into using the app.

This app’s effectiveness is compounded by its ability to evade detection through techniques like redirects and user-agent checking. Traditional tools such as Google search, Shodan, and automatic checks often do not identify such threats, as they rely on visible and accessible data that these apps deliberately obscure. This makes it nearly impossible for automated systems and manual searches to uncover them.

To stay protected, users must remain vigilant and wary of the applications they download, even when they appear legitimate. Additionally, app stores must strengthen their verification processes to prevent such malicious apps from slipping through the cracks. The crypto community needs to continue to educate users about the risks associated with Web3 technologies and the importance of scrutiny when managing their digital assets. This case illustrates that even seemingly innocuous interactions can lead to significant financial losses.

Protection

Check Point’s Harmony Mobile prevents malware from infiltrating mobile devices by detecting and blocking the download of malicious apps in real-time. Harmony Mobile’s unique network security infrastructure — On-device Network Protection — allows you to stay ahead of emerging threats by extending Check Point’s industry-leading network security technologies to mobile devices.

IOCs

Domains

mestoxcalculator[.]com

web3protocol[.]online

connectprotocol[.]app

cakeserver[.]online

SHA256

ea526792150e71402f896ddaf1f04aedcb1356aea3bfebbcaf6c90bcdde7aa0c

bf557e975733c113acc38daa18ca1849a1022b4c30b118899f68210cd3c7f990

42330ccaaacea8a18794c7e9fad100de31ea415bff7821e407b9ac70ef690032