The Rising Threat of Phishing Attacks with Crypto Drainers

By Oded Vanunu, Dikla Barda, Roman Zaikin

Unmasking Deceptive Tactics: A recent investigation by Check Point Research exposes a troubling trend in the cryptocurrency landscape. The cryptocurrency community has been witnessing an alarming increase in sophisticated phishing attacks.

These threats are unique in their approach, targeting a wide range of blockchain networks, from Ethereum and Binance Smart Chain to Polygon, Avalanche, and almost 20 other networks by using a crypto wallet-draining technique.

Check Point’s Threat Intel blockchain system identified and alerted us on such phishing attacks:

During our investigation into some of the attacks, we came across a reoccurring address: 0x412f10aad96fd78da6736387e2c84931ac20313f and 0x0000d38a234679F88dd6343d34E26DCB50C30000 which are familiar by the names Angel Drainer address.

“Angel Drainer” refers to a notorious phishing group involved in cyberattacks, particularly in the cryptocurrency space. This group has been linked to various malicious activities, including the draining of cryptocurrency wallets through sophisticated phishing schemes.

Despite the shutdown of similar groups like Inferno Drainer, which assisted in stealing over $80 million in cryptocurrency, Angel Drainer continues its operations. These wallet drainers charge a percentage of the stolen amount from hackers in exchange for providing wallet-draining scripts and other services. The persistence of such scam-as-a-service entities poses significant challenges to the cryptocurrency market and emphasizes the importance of robust security measures to protect users and their assets.

Looking into the Angel Drainer kit in the wild, we came across a forum that gave us information about Angel Drainer service:

A crypto draining kit is crafted to facilitate cyber theft by draining funds from digital wallets. It operates primarily through phishing scams, luring victims to enter their wallet details on counterfeit websites.

Crypto drainers, also known as cryptocurrency stealers, are malicious programs or scripts designed to illegally transfer cryptocurrency from victims’ wallets without their consent.

The way most crypto drainers work is relatively straightforward:

1. Launch of a Malicious Campaign: Attackers create fake airdrop or phishing campaigns, often promoted on social media or via email, offering free tokens to lure users.
2. Deceptive Website: Users attempting to claim these tokens are directed to a fraudulent website that mimics a genuine token distribution platform.
3. Wallet Connection: Users are asked to connect their wallets to the website, preparing for the subsequent attack phase without immediate compromise.
4. Smart Contract Interaction: The user is induced to interact with a malicious smart contract under the guise of claiming the airdrop, which stealthily increases the attacker’s allowance through functions like approve or permit.
5. Asset Transfer and Obfuscation: Unknowingly, the user grants the attacker access to their funds, enabling token theft without further user interaction. Attackers then use methods like mixers or multiple transfers to obscure their tracks and liquidate the stolen assets.

Permit in the context of ERC-20 tokens is a feature that allows token holders to approve a spender (such as a smart contract) to transfer tokens on their behalf without conducting an on-chain transaction for each approval.

This can be done by signing a message off-chain with the token holder’s private key, which includes details like the spender’s address, the amount they are allowed to spend, and a validity period. This signed message can then be used by the spender or a contract to set the allowance on-chain. The permit function enhances user experience by reducing transaction costs and streamlines interactions in decentralized applications (dApps), especially in the DeFi sector. If the user is tricked and signs such a function, the attacker will be able to transfer his funds.

What is even more interesting in such behavior is that no trace will be logged to the blockchain because the sign is happening off-chain via communication between the wallet and the phishing DeFi website.

Deep Dive

Let’s start by examining one of the transactions used by Angel Drainer technique: 0xb60c32fb28aa6160df6f472f494f162b997aa49fb06776dce250aff80602a8a3

If we analyze the transaction logs, we can see a few main events:

• Ownership transfer event
• Approval event
• Transfer and Transfer events

To fully understand the sequence of events in the attack, an in-depth analysis of the smart contract at address 0x47cbbfee58e6a134d00ea3a8f1ddfff60a8d94d6 is necessary, this includes examining the specific function that was triggered, which is identified by the code 0x095838d2.

By exploring the data involved in this function call, we can uncover the particular actions executed by the smart contract and how these actions played a role in the attack, so let’s look at the data that was sent to the scammer contract:

0x095838d2000000000000000000000000c55b8ebf5ec4c76fb9182e86cb2a29eb363d919c000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000003000000000000000000000000ae7ab96520de3a18e5e111b5eaab095312d7fe84000000000000000000000000ae7ab96520de3a18e5e111b5eaab095312d7fe84000000000000000000000000ae7ab96520de3a18e5e111b5eaab095312d7fe84000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000000022000000000000000000000000000000000000000000000000000000000000000e4d505accf0000000000000000000000009a875f6ce282e8009aa9432784f8124067032c99000000000000000000000000c55b8ebf5ec4c76fb9182e86cb2a29eb363d919c00000000000000b88e282822ab5ed106947c1c60af583c1741a38e858de0000000000000000000000000000000000000000000000000000000000193870b574e000000000000000000000000000000000000000000000000000000000000001ca361b0da886b37585d06e3ef06b22a1c328c949d7f6e412df12c19e2821e57935fb0f4948df32c52b17cabd6c7753129cad97e95edb1113ba181c83df0849f4200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006423b872dd0000000000000000000000009a875f6ce282e8009aa9432784f8124067032c99000000000000000000000000fbcbc1dc95eec0ecec3051fb55a8921cf5157f2800000000000000000000000000000000000000000000000083ffc624afcd500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006423b872dd0000000000000000000000009a875f6ce282e8009aa9432784f8124067032c99000000000000000000000000412f10aad96fd78da6736387e2c84931ac20313f000000000000000000000000000000000000000000000000174b4115886f87cc00000000000000000000000000000000000000000000000000000000

The function selector 0x095838d2, extracted from the initial 4 bytes of the input, clarifies that the function with this selector was executed. The parameters passed to this function were:

• Param1: An Ethereum address: 0xc55b8ebf5ec4c76fb9182e86cb2a29eb363d919c.
• Param2: An array consisting of three identical Ethereum addresses: 0xae7ab96520de3a18e5e111b5eaab095312d7fe84 for each entry.
• Param3: an array of 3 long elements.

These parameters provide insights into the nature of the transaction initiated by the contract, helping to understand the methodology of the operation within the scam.

For clarity and ease of reference, let’s label the aforementioned address with an alias:

• 0xc55b8ebf5ec4c76fb9182e86cb2a29eb363d919c – scammer_contract_1
• 0xae7ab96520de3a18e5e111b5eaab095312d7fe84 – stEth_token_contract

• 0x9a875f6ce282e8009aa9432784f8124067032c99 – victim_address
• 0x412f10aad96fd78da6736387e2c84931ac20313f – angel_drainer_wallet
• 0x47cbbfee58e6a134d00ea3a8f1ddfff60a8d94d6 – scammer_contract_2

Function 0x095838d2(): executed by scammer_contract_2

The initial action executed involved the creation of a contract at the scammer_contract_1 address, which is referred to as Param1 in the process data.

In the screenshot below we can see:

The scammer’s strategy involves verifying the existence of a contract at the address provided in scammer_contract_1 by checking the code size at that address. If the code size is greater than zero, indicating a contract exists, the scammer proceeds to execute the multicall function on this existing contract. Subsequently, if the multicall operation is successful, a new contract is deployed.

On the other hand, if there is no existing contract at the scammer_contract_1 address (i.e., the code size is zero), the scammer’s approach changes. In this case, the first step is to deploy new contract addresses with no transaction history, enabling them to bypass wallet security alerts, followed by invoking the multicall function on this newly created contract.

In the situation we’re analyzing, the sequence of actions chosen involves first deploying a new contract, followed by the execution of the multicall function to the deployed address (scammer_contract_1) as can be seen in the screenshot below. This method highlights a particular approach to orchestrating contract interactions. Let’s proceed to examine the details of this procedure.

Function multicall(): executed by scammer_contract_1

The multicall function in question, executed on the contract at address scammer_contract_1, involves the use of two additional arrays (referred to as param2 and param3) as parameters. In this specific operation, the function is directed to carry out three distinct actions as can be seen in the screenshot below. All these actions target the same contract address, stEth_token_contract, which is associated with the stETH token and corresponds to param2 in the function call data.

In the execution of the multicall function on the contract at scammer_contract_1, the signatures for all operations were included as parameters. Analyzing the data reveals the specific function signatures that were utilized in these operations. These signatures effectively outline the set of actions to be performed by the multicall function:

1. 0xd505accf – Permit function
2. 0x23b872dd – TransferFrom X2

Function Call(): executed by stEth_token_contract

Let’s examine the initial transaction involving the Permit function. When we analyze the data that was submitted for this function call, we can identify the Permit signature in the first four bytes.

Breaking down the Permit function data, we note that it typically requires the following parameters:

Owner, spender, value, deadline, and V, R, S.

Understanding these parameters and their implications is key to recognizing how such functions can be exploited in scams, and why vigilance is necessary when dealing with token permissions, so let’s look at the data:

• Owner: This is the address of the token owner, essentially the victim in this scenario. In our case, it’s:0x9a875f6ce282e8009aa9432784f8124067032c99.
• Spender: The address that is authorized to spend the tokens, controlled by the scammer.

In our case, it’s 0xc55b8ebf5ec4c76fb9182e86cb2a29eb363d919c.

• Value: The specified amount of tokens the spender is permitted to use. In our case is: 83476733574422399944877753435006670731032001850387113967616000000000000000000, This extraordinarily large number typically indicates permission for an unlimited amount of tokens.
• Deadline: The expiration time for the permit’s validity. In our case is: 1733137487694.
• V, R, S: These are the components of the cryptographic signature, essential for verifying the authenticity of the transaction.

From this data, it’s evident that if the victim signs this permit, the scammer’s contract address would gain access to a potentially unlimited amount of the victim’s stETH tokens. This highlights the critical importance of understanding and verifying transaction details, especially in the context of token permissions and transfers.

Upon executing the Permit call with the victim’s signature, the scammer would then use the transferFrom function from scammer_contract_1 to move tokens on behalf of the victim.

Following this, another transfer is arranged from the scammer’s address to the address Angel_drainer_wallet, often referred to as the Angel drainer address, as part of a presumed agreement to distribute the stolen funds.

Upon completion of these transfers, the victim would be deprived of all their stETH tokens. Subsequently, the scammer would change the ownership of the contract address they used for the attack, scammer_contract_1, transferring it from one contract address to another scammer controlled address. This final step would effectively complete the scam operation, leaving the victim without their tokens and the scammer in control of the new contract.

Looking at the “Angel Drainer” wallet address, it seems that he earns significant amounts of money not just through direct activities but also from others using its drain kit.

Safeguarding Your Assets

The risks involved in these scams are manifold. First and foremost is the risk of unsolicited emails and messages, which are a common starting point for these phishing attacks. Users must be extremely cautious with such communications, especially when they lead to external links. Another significant risk is the use of URLs that closely mimic legitimate ones, designed to deceive even the most vigilant eye. The most critical risk, however, is embedded in the approval of transactions that seem innocuous but are, in fact, malicious.

The key to safeguarding against these phishing attacks lies in a combination of vigilance and the use of technological safeguards. Users are advised to:

• Be skeptical of airdrop claims, especially those requiring wallet interaction.
• Understand the implications of approving transactions or signing messages in their wallets.
• Verify the legitimacy of smart contracts before interacting with them.
• Limit the use of high allowances or regularly review and revoke them using blockchain explorers or wallet interfaces.
• Employ hardware wallets for enhanced security, especially for substantial holdings.

Conclusion

The threat posed by these phishing attacks cannot be overstated. In the dynamic and ever-evolving world of cryptocurrency, staying informed and cautious is not just advisable; it’s essential. The community needs to collectively work towards building a more secure and aware environment, where each member is equipped with the knowledge and tools to protect their digital assets. Remember, in the realm of cybersecurity, it’s always better to err on the side of caution. Let’s spread the word and help keep our community safe.

The Threat Intel Blockchain system, developed by Check Point, continues to accumulate valuable information on emerging threats, and this intelligence will be shared in the future. In this collaborative effort, we aim to empower investors with the knowledge needed to navigate the crypto space securely and protect themselves from potential pitfalls. For more information contact us at: [email protected]