Comprehensive Analysis of Phishing Attacks on Blockchain

This article is jointly published by X-explore and WuBlockchain.

Introduction

According to the article from Chainalysis in 2024, $24.2B worth of money has been received by illicit addresses which takes 0.34% of total on-chain transaction volume. With the increased interest in the blockchain industry, more users and assets started to flow in the Web 3 market, yet there have been increased reported incidents from users of cyber attacks.

Among various attacks, phishing remains one of the major aspects of cyber attacks. Attacker targets various tokens such as stablecoins, ETH, or even altcoins. They lure users to sign malicious transactions or input private keys to hold control of the user’s account. The article will further investigate existing methods of phishing scams and explore methods to prevent or identify malicious accounts in the future.

Background & Related Work

Existing phishing attack methods Framework (off-chain)

Phishing attacks focus on alluring users to input private information in the online world. There are various ways to allure users but most phishing is done on platform such as email, Social media channels, or cloned websites that looks legitimate. Such email or website allures users to input private information or sign transactions that give control to the scammer. The article will investigate 3 major frameworks scammers utilize on off-chain first.

Spear Phishing

Spear Phishing attacks target specific individuals or organizations. By gathering customized information beforehand, the attacker crafts a personalized email to specific groups making the email legitimate. Moreover, with the rise of generative AI, one scammer now has the power to gather personalized information and craft personalized emails targeting wider user groups than before.

Pharming attack

Pharming attack crafts URL that redirects to fake websites. For instance, on Slack, website, “ www.apple.com " can look identical to “ www.appie.com " when “i” is replaced with capital “I”. Through such a method, the scammer crafts malicious URLs and distributes them via email or SNS channels such as Telegram or Slack.

Fake browser extensions

The scammer programs malicious extensions programs and crafts download links which are then distributed through email or SNS channels. Upon clicking, such an extension will be downloaded in the user’s environment, which will look for private information such as mnemonic phrases and private keys.

Note that once a user clicks the download link, inputs private information, or signs transactions, the scammer is in total control of the account and the user has no method to roll back. Hence, it is crucial that a user does not click on sources he or she does not trust.

Extraction of funds on Blockchain (on-chain)

Given the off-chain framework, the article will look at how scammer gains full control on on-chain wallets. In the field of blockchain, attackers can gain control of a user’s account in various ways. Especially with ERC-20 token contracts such as stablecoins and altcoins, scammers do not necessarily need a user’s private key but instead need a user’s signature sign-in on-chain or off-chain. The article will look at various ways attackers utilize to drain funds.

Private key

Extraction of private keys is not a common method nowadays. Attacker crafts websites or emails that require users to input a seedphrase or private key. Once the attacker gains the user’s private key or seed phrase, the attacker has total control of the wallet and address.

Even though it is a simple method, users in the past easily fell into the trap due to lack of knowledge in the field of blockchain.

Approve & TransferFrom

Upon the standard of ERC-20, ERC-20 tokens support push and pull transactions for the application of the De-Fi protocol. Push transaction is initiated by the payer who decides how much money to be sent to the payee. However, in pull transactions, payees instruct payers how much money to be sent. Hence, the third part can control the transactions. Pull transaction instructions are managed in Web 3 in the procedure below.

1. Users call and sign Approve(). approve( owner, spender, amount) sets how much the token payee's address can take from user's address. Note that there are increaseAllowance( spender, amount) which can be exploited. The difference between approve and increaseAllowance is approve sets new allowance while increaseAllowance adds to existing allowance [sets a hard limit].

2. Once the boundary is set, payee can call transferFrom(to, from, amount) which will move user's token to payee's address.

In real-world applications, it is usually a smart contract who is the payee. The user will transfer the ERC-20 token to the smart contract and the smart contract will manage funds accordingly. However, it is important to note that once the smart contract gets hacked, a user’s fund will be drained according to how much allowance has been set. In some scenarios, to simplify the user’s UI, smart contracts might ask for a high amount (Infinite amount) of allowance, so that the user do not have to sign every time to set allowances to save gas fees. Since the amount is set to an infinite amount, the user must make sure that the third party is a reliable source.

Setting allowance and utilizing the transferFrom method has been a vulnerable point for quite a long time. However, due to it’s practical application in Decentralized Finance (De-Fi) and dApps, Approve & TransferFrom is frequently utilized nowadays with improvements made.

For instance, due to the max capacity of EVM set to 1024, complex procedures such as set allowance → transferFrom usually led to “1024 stack depth problem” as stacks exceeded the limitation of given spaces leading to revertation of the transaction.

Hence, if each method is called and proceeds to the next method, calling it would introduce a huge vulnerability point. Major exploitation can be re-entrancy attacks. Vitalik was aware of certain scenarios and made improvements back in 2017 and introduced the ERC-223 standard.

There have been other improved protocols introduced, such as permit or permit2, yet the security of the wallet depends on the user signing transaction. Hence, it is important to check 3 major aspects to prevent potential scams.

1. Approval amount: scammers often create an approval request with unusually high allowances in order to acquire total control of the dedicated ERC-20 token. When signing a contract, make sure to check the allowance amount.

2. Verified Smart Contract: Make sure you are signing allowance signature to verified smart contracts provided by known dApps. Checking tags and memo from Etherscan or any other blockchain explorer can help identify if a contract has been flagged as malicious or not.

3. Check security alerts: wallet providers such as Meta Mask or Wallet Connect generate prompts if you are interacting with potential scamming contracts. Make sure to check such alerts.

Example Cases

Let’s visualize how an actual attack is conducted and recorded in Blockchain Explorer.

Blockchain: BSC Chain

Date: 2023–05–11

Attacker: 0x49Dc14Dd851B6EaE8d685715e12a06cc1BFC5d8d

Victim: 0x5F464c94e93CEbd56aE2F1220912BA0ab0a27a38

Step1: User signs Approval contract

Upon receiving false information on the Web 2 environment through a telegram channel, Instagram, or phishing website, the user receives an Approve signature request.

Step 2: Drain funds

Now, as the scammer has control over 426923054270173310680061630 or less amount of ERC-20 token funds in the victim's address, the scammer starts to transfer the victim's token to his or her account. As shown below, the total of 256153832.56 SHIB has been drained from the victim's account.

Permit

Permit was introduced in ERC-2612 as an improved measurement of the approve & transferFrom workflow. Unlike approve and transferFrom, an off-chain signature is created meaning that users do not have to sign for approval on the on-chain before. The workflow of Permit and transferFrom follows below:

1. The user needs to create a signature through permit (owner, spender, value, nounce, deadline). The return values for r, s, v which are 3 splits of signature that has been created.

2. Once the user creates the Permit signature with r,s, and v, a third party will call the permit(owner,spender, value, deadline, v, r, s) with the following values. Once transacted for stage change, it will set the allowance accordingly.

3. Within one transaction, once allowance is set, the third party will execute transfer.

Through the creation of offline signature utilizing permit(), gas fees were able to be saved as there was no need to sign allowance on-chain. Moreover, security has been massively improved through creation of r, s, v, the user never exposes his or her private key to create a signature.

Note that not all ERC-20 standard token support methods permit(). Moreover, the core mechanism of permit() is in the workflow of approve & transferFrom. Vulnerability points lie on the user creating or signing Permit().

Example Cases

Let’s visualize how an actual attack is conducted and recorded in Blockchain Explorer.

Blockchain: ETH

Date: 2024–05–24

Attacker: 0x77865b925f96fc49837cfe27ec04cd5a691e61ef

Victim: 0x7cdd2a99fc014194218119a7100c259e31a10bf2

Step1: User generates an Off-chain signature

Such a process cannot be tracked on Blockchain Explorer as it is done off-chain. The scammer will allure the victim to generate an off-chain signature with a simple click. Even though the victim has not signed a transaction online, signing an off-chain signature through the wallet already allows the scammer to perform TransferFrom later.

Step2: Scammer signs the Permit contract from Off-chain signature

The scammer submits the signed message to the ERC-20 Token contract via an on-chain transaction. Upon validation against the victim’s address and nonce, an approval request will be made. Notice that through permit there has been only one on-chain transaction. Compared to traditional Approve& TransferFrom, there is one less transaction saving gas fee.

ERC-4337 ( Account Abstraction or Smart Contract Wallet)

Introduced by Vitalk in 2021, the novel AA scheme has been created based on the current existing consensus layer protocol. Unlike the former introductions of AA schemes such as EIP-86 ( Bare multi-sig AA), EIP-3074 (Auth and Authcall), and EIP-2938 (Account Abstraction), it was the first scheme that introduces AA within the current consensus layer protocol allowing easier integration in the current market.

Account Abstraction (AA)

In blockchain there exist two major types of accounts: Externally Owned Account and Smart Contract. The traits of the two accounts differ as shown in the table below.

The goal of AA is to create a unified account that holds the benefit of EOA and SC: full programmability with the ability to initiate transactions. The benefits of AA are:

• Ability to respond to contract calls directly

• Ease of transfer ownership of account ( was not able to be done of EOA)

• Introduce novel validation rules ( Pass key can be checked within SC levels)

• Removes gas fee cost from EOA to smart contract

• Manage one address instead of EOA and SC

• Introduction of new payment of gas fee ( does not have to be native token)

Workflow of ERC-4337

AA is a new standard that can create a unified account that massively improves UI for users. The technical flow of ERC-4337 follows as below:

ERC-4337 can be divided into four major processes.

Step 1: Creation of User Operations

Through dApps and wallets, users can interact with AA scheme operations to create User Operations. Users have a better UI as the application can support various features in one, such as multi-signature, social recovery, etc. Once User Operations are created, it will create a signature offline which will be validated by the account later before execution.

Step 2: Bundler Processing

Once a user submits the User Operations, it will be stored in the User Operation Mempool where the bundler will gather and aggregate into a bundle. The bundler will check the validity of the transactions and once passed, the bundled transactions will be sent to on-chain for processing.

Step 3: Entrypoint Contract

There is a unified Entrypoint Contract in the chain as mentioned in the above regulation. Upon receiving the bundle transactions it will perform gas calculations to ensure how much gas fee the smart contract account has to pay. Through the Entrypoint contract, users do not have to pay for the gas fee as the smart contract account pays or paymaster. Moreover, the most imperative advantage of the scheme is that gas fees do not have to be paid in Native tokens. Fee can be regulated upon dApps and paid with ERC-20 token via PayMaster. Such an arrangement improves the user’s experience with transactions.

Step 4: Validation and Execution

Upon receiving methods from the Entrypoint Contract, validation of original User Operations will be done. Once validated, it will execute the transaction accordingly. Note that it is an EntryPoint contract that will add the transactions to the ETH network mempool.

Vulnerability Points

From a security perspective, there remain a lot of vulnerability points. Since the AA scheme allows the execution of user operations from off-chain managed bundler to an on-chain, it provides a lot of gaps for scammers to manipulate users to perform user operations. The article will provide potential vulnerability points throughout the operation execution process.

Fake Entrypoint Contracts

Note that there should be only one EntryPoint contract per chain. However, a scammer can craft his or her version of EntryPoint contracts on a chain to perform user operations. Since most of security protocols and monitoring will be heavily focused on singleton EntryPoint contract, the scammer might want to create his or her version to avoid it. Yet, such contract can be easily detected and managed accordingly with current blockchain monitoring systems.

Malicious Bundler

The scammer can craft his or her version of Bundler service with user operation mem pool. Bundler service consists of four major aspects: configuration, RPC server, Alternative mempool, and bundling UserOperations.

Configuration sets the address for EntryPoint and beneficiary accounts.

RPC Server handles operations given EntryPoint addresses.

async handleMethod (method : string , params : any [ ] ) : Promise <any > { let result : any switch (method ) { case 'eth_supportedEntryPoints' : result = await this . methodHandler . getSupportedEntryPoints ( ) break case 'eth_sendUserOperation' : result = await this . methodHandler . sendUserOperation (params [ 0 ] , params [ 1 ] ) break case 'eth_estimateUserOperationGas' : result = await this . methodHandler . estimateUserOperationGas (params [ 0 ] , params [ 1 ] ) break case 'eth_getUserOperationReceipt' : result = await this . methodHandler . getUserOperationReceipt (params [ 0 ] ) break case 'eth_getUserOperationByHash' : result = await this . methodHandler . getUserOperationByHash (params [ 0 ] ) break // ... default : throw new RpcError ( `Method ${method} is not supported` , - 32601 ) } return result }

Alternative memory stores the operations in array format before sending it to a chain. From a bundler’s perspective, prevention of DoS attacks should be managed here.

// add userOp into the mempool, after initial validation. // replace existing, if any (and if new gas is higher) // revets if unable to add UserOp to mempool (too many UserOps with this sender) addUserOp (userOp : UserOperation , userOpHash : string , prefund : BigNumberish , senderInfo : StakeInfo , referencedContracts : ReferencedCodeHashes , aggregator ? : string ) : void { const entry : MempoolEntry = { userOp , userOpHash , prefund , referencedContracts , aggregator } const index = this . _findBySenderNonce (userOp . sender , userOp . nonce ) if (index !== - 1 ) { const oldEntry = this . mempool [index ] this . checkReplaceUserOp (oldEntry , entry ) debug ( 'replace userOp' , userOp . sender , userOp . nonce ) this . mempool [index ] = entry } else { debug ( 'add userOp' , userOp . sender , userOp . nonce ) this . entryCount [userOp . sender ] = ( this . entryCount [userOp . sender ] ?? 0 ) + 1 this . checkSenderCountInMempool (userOp , senderInfo ) this . mempool . push (entry ) } this . updateSeenStatus (aggregator , userOp ) }

Lastly, for Bundling userOperations, it creates the bundle that will be sent to the EntryPoint Contract. Bundlers must make sure they verify an operation’s ability to pay its fee before forwarding it in order to prevent DoS attacks. If not, then scammers can craft operations that seem like they pay a fee but will revert, causing congestion in the mempool of the chain.

Moreover, the verification steps should not violate state changes meaning it will verify according to data related to the sender. Verification and creation of Bundle is in the below code

async createBundle ( ) : Promise < [ UserOperation [ ] , StorageMap ] > { const entries = this . mempoolManager . getSortedForInclusion ( ) const bundle : UserOperation [ ] = [ ] // paymaster deposit should be enough for all UserOps in the bundle. const paymasterDeposit : { [paymaster : string ] : BigNumber } = { } // throttled paymasters and deployers are allowed only small UserOps per bundle. const stakedEntityCount : { [addr : string ] : number } = { } // each sender is allowed only once per bundle const senders = new Set <string > ( ) // all entities that are known to be valid senders in the mempool const knownSenders = entries . map ( it => { return it . userOp . sender . toLowerCase ( ) } ) const storageMap : StorageMap = { } let totalGas = BigNumber . from ( 0 ) debug ( 'got mempool of ' , entries . length ) // eslint-disable-next-line no-labels mainLoop : for ( const entry of entries ) { // check reputation system // check duplicate UserOps per sender // check stake // check storage access // check UserOp call gas limit // check Paymaster deposit if present // If sender's account already exist: replace with its storage root hash senders . add (entry . userOp . sender ) bundle . push (entry . userOp ) totalGas = newTotalGas } return [bundle , storageMap ] }

Exploitation of PayMaster

As PayMaster is a customized contract to handle transactions, scammers can divert the gas fee through the exploitation of vulnerabilities in code. Further research will be conducted in the future. Currently, there aren’t a lot of confirmed example cases of paymaster exploitation.

Example Cases

Let’s visualize how an actual attack is conducted and recorded in Blockchain Explorer. Notice that AA is a scheme that processes the transactions in a bundle operation manner. Scammers typically utilize AA scheme to process transactions such as Perimt or Approve. The below example will look at the Approve & TransferFrom request.

Blockchain: BSC Chain

Date: 2024–03–23

Attacker: 0x454b8b645a981e6c197087ea154df94b5187d682 , 0x170f7be1baf9234af5966d194a0a6bd6073eed99

Victim: 0x3f3ce11b7809ecf6f571943800c28f585e8b187d

Step1: User signs off-chain permit request

Like a typical permit request, the scammer will allure the user to sign a permit message. It will be disguised as a necessary step to approve a transaction or access service. The victim, believing the request is legitimate, will sign messages off-chain using their private key.

Step2: Interact with Bundler

The scammer will now interact with a bundler who will handle the permit transaction as an operation. The scammer sends the transaction to the bundler and the bundler will now store the transaction under user operation mempool. After being stored in the user operation mempool, it will go through a validation process and handle over to the EntryPoint contract.

Step3: EntryPoint Contract

Receiving the operation processes from the bundler, the EntryPoint contract will validate user operation in the bundle before execution. As shown in the screenshot below. Once it checks the availability of gas fee and the correctness of state changes, it will handle inner operations.

Step 4: Process State Changes

As highlighted below, the inner operation for this example contains two transferFrom operations. Notice the amount of value difference in transfer amount in two addresses: 212856150000000008192 , 37562849999999991808. The ratio is roughly 0.85:0.15, which indicates a possible Drainer service where they provide scam as a service and share the drained amount with the Drainer and customer in a certain ratio. Details about Drainer's service will be discussed later in the article

Attack Methods from Scammers

Crypto Drainers (Scam as Service Prodivers)

There have been increasing reports of Scam as Service Providers in the recent crypto Market. The providers work multi-chain, provide services to drain ERC-20 tokens, and earn stolen tokens as a reward. The article will look at an example case scenario from crypto drainers.

Inferno Drainer

According to Scam Sniffer, Inferno Drainers has stolen $80 million dollars or more within 1 year (11.2022–11.2023) of their active period time. Inferno Drainer sets up phishing websites with social engineering and shares the platform with the customer.

The customer then sends socially engineered website links on Telegram, Facebook, Instagram, or other social networks to allure normal users. Victims who usually do not hold knowledge in the field of cryptocurrency and blockchain will grant access to the customer of Inferno Drainer without knowing.

The general flow of attack from Inferno Drainer is as below:

As shown in the flowchart, Inferno Drainer mainly focuses on constructing phishing social engineered websites to drain victim’s funds and customers are in charge of spreading phishing websites to the victims. Once victims open the site and sign the transactions, customers will take 80% of the stolen token and Inferno Drainer will take 20%.

With a very simple setup with simple Approve&TransferFrom method or Permit method, Inferno Drainer stoled over 80+ million dollars of assets on-chain.

Draining Method

Inferno Drainer mainly used the classical Approve & TransferFrom method or permit method. Let’s look at one of Approve&TransferFrom during their active time

Victim: 0xe142C1858b8447238F3953e685e62ED6005DcAaA

Attacker: 0xFC4EAA4ac84D00f1C5854113581F881b42b4A745

Token: PEPE

Lost amount: 26,372,295.3 ($220)

Step1 : Victim signs approve()

Step 2: Attacker performs TransferFrom()

Angel Drainer and Improvement in Attacking Method

After Inferno Drainer ended its service, a new form of more advanced drainer service came out. One of the notable drainer was Angel Drainer. Unlike Inferno drainer, Angel drainer leveraged advanced techniques to manipulate smart contract logic and user behaviour. Certain methods focused on bypassing security alerts that are triggered by behavioral analysis and rate limiting. The article will look at two main novel attack methods Angel Drainer utilized to drain funds.

1. Nested Smart Contract Deployment Mechanism

As various phishing schemes that utilize Approve&TransferFrom or Permit, blockchain security groups such as ChainAlysis, BlockAid, and Check Point also developed sophisticated monitoring algorithms that can identify potential scammers on the chain. In particular, transactions such as Permit and Approve&TransferFrom on the scammer’s address were very simple to identify. Hence, Angel Drainer adopted a sophisticated method that bypasses security alerts through the creation of new smart contracts that perform Multicall function.

Example

To understand how Angel Drainer managed to bypass security alerts, we will look at a real example attack with an investigation of the smart contracts that have been utilized. Let’s explore the transactions behind :

0xb60c32fb28aa6160df6f472f494f162b997aa49fb06776dce250aff80602a8a3

Step 1: Create a Nested Smart Contract

Angel Drainer first creates a smart contract with the following functions.

As shown in the screenshot below, for this specific transaction, Angel Drainer utilized 0x095838d2() first and next calls 0xf2fde38b() transferOwnership(address).

For simplicity, we will call this contract the main contract. Within the main contract, we need to focus on a function 0x095838d2(). The logic of the function is as followed:

1. Requires three parameters (secondContractAddress, tokenContractAddress, arrayOf3Elements)

2. Check if secondContractAddress is an existing contract. It checks the code size of the given address. If it is greater than zero it means the contract exists, if not vice versa.

3. If it is, execute the Multicall function which includes (Permit & TransferFrom). If not, deploy a new contract with that address and then execute Muticall function.

For this transaction case, secondContractAddress was Null leading it to create a new smart contract first.

Step 2: Mutilcall Function

Once the main contract identifies or creates the second contract, the function Multicall() in second contract will be executed. Such a function exists to orchestrate the contract interaction. Let’s look on multicall() function’s main ability.

As highlighted above, multicall accepts transaction operations as parameters and processes each parameter by making an external contract at the address specified in v1[v3]. Details of multicall can be seen in the process of execution below.

As shown above, muticall processed a total of 3 transactions which are Permit and two transferFrom. Permit and transferFrom is made on token contract Lido: stETH.

Notice the value difference in transferFrom. The ratio is 0.85:0.15. This notes the distribution of profit with Customer and Angel Drainer.

Step3: Transfer of Ownership

In order for the scammer to have full control of the second contract. The last step of 0x095838d2() includes executing TransferofOwnership from the second contract to the scammer's address.

We had a look over a manipulation method utilized by Angel Drainer to bypass security alerts by creating new contracts and processing operations within the multicall of new contracts. As the new contract do not holds any transaction records, obscures transactions through multicall, and is not directly deployed by the scammer’s address, it was able to bypass security alerts. However, thanks to the identification from Check Point Research, the Nested smart contract attack method can now be identified and will not bypass security alerts anymore.

2. EigenLayer Restake Farming attack

EigenLayer is a decentralized protocol designed to enhance the security and efficiency of blockchain networks through the process of “restaking” where it allows users to lock their tokens into a smart contract. Users can initially stake tokens for a certain period of time and earn rewards and also restake more tokens instead of un-staking and re-staking. Through such a process, it allows users to interact with multiple services and stake more tokens, which ultimately enhances the security and utility of the chain at the same time.

Attack vector Point

However, there was a vulnerability point in restaking mechanism. Mainly with queueWithdrawal mechanism of the EigenLayer protocol. To understand how the attack works, we need to understand how the staking and restaking process works.

EigenLayer protocol utilizes a special method for handling staking withdrawals.

After a user stakes a certain amount of token and later decides to withdraw the staked token, the transaction is not processed immediately. Instead, it is stored in a queue. Users have to wait a 7-day escrow period to unstake and on Etherreums partial withdrawals of stake funds are possible once every 4–5 days after a validator sweep. Since such an approval method was new, most security providers or internal security tooling did not validate such an approval type and mark it as a benign transaction. Therefore, it left a vulnerability point for Angel Drainer to exploit.

Example

Chain: ETH

Date: From 2024–01–15 To 2024–01–29

Attacker: 0x8031A648B169a9fa6f63954C0F0B106E57027696

Step1: CREATE2 contract

This is the part where they were able to bypass security alerts and obscure the process. Angel Drainer prepares a contract using CREATE2 with parameters (salt, bytecode). Then CREATE2 will generate a specific new address. The new address will be used to collect rewards and unstake tokens successfully bypassing the security alerts.

Step2: initiate queueWithdrawal

The attacker starts by initiating an unstake from the Eigen layer triggering the 7-day escrow period.

Step3: Draining

After a certain period of time, the token will be drained to the CREATE2 address resulting in a successful attack as shown below.

Thanks to Blockaid, such attacks have been identified and also been notified to EigenLayer Protocol. Currently, higher security measures have been set to detect such attacks unlike before.

Money Laundry in Crypto

Lazarus Group & Ronin Bridge attack

The attack began with Lazarus gaining 5 keys out of nine private key holders for the execution on the cross-chain bridge. Such is possible due to the Shamir Secret Key arranged Multisignature account. After they gain access to the chain, they begin the laundering process.

Steps include:

1. Stolen Ether distributed to intermediary wallets

2. Utilize Tornado Cash → random mix batch protocol

3. ETH to BTC

4. Mix and batch BTC

5. CEX to cashout

Representation in the graph looks like below:

Detection of such activities was extremely difficult due to Tornado cash. However, after the U.S. gained control over Tornado Cash after its accusation of money laundering, the Lazarus group took a different method: Utilizing De-fi protocol.

The key idea is that on-chain transactions are visible to everybody and upon further investigation, transactions can be detected. However, through mix and batch methods, transactions diverge and then consolidate into a single wallet. This will be and has been the trend from sophisticated scammers.

Methods for laundering and phishing will evolve and matching detection methods are required to secure the funds of users.

Detection of Malicious Account

Machine Learning

All the detection methods are based on the fundamentals explained above. However, such forensic processes by humans are very time-consuming and inaccurate; hence major companies such as ChainAlysis utilize machine learning to do so. Exact feature engineering and method has not been enclosed by ChainAlysis or any other security platforms. However, based on various research and documentation, the article suggests the following methods to be further investigated for development purposes in the future.

Graph Neural Network Machine Learning

• https://ieeexplore.ieee.org/document/10191217

• https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9824179/#:~:text=Many studies have been conducted to detect blockchain cybercriminal accounts,as typical financial transaction graphs.

Subgraph Elliptic2 Machine Learning

• https://www.elliptic.co/blog/our-new-research-enhancing-blockchain-analytics-through-ai

• https://arxiv.org/pdf/2404.19109

Deep Neural Network (Feature Engineering)

• https://www.sciencedirect.com/science/article/abs/pii/S095741742201555X

Conclusion

Phishing attacks on blockchain have evolved with the industry's growth, targeting users through sophisticated methods to bypass security alerts. Users must be vigilant, ensuring to verify smart contracts, check approval amounts, and heed security alerts. Staying informed and adopting best practices are essential to safeguarding assets in the decentralized financial ecosystem.

User needs to remember two golden rules to prevent themselves from any form of attack now and in future.

We have explored how phishing attacks are conducted on blockchain and how scammers formulate both on and off-chain infrastructure to compromise users’ accounts and assets. However, with two golden rules you can prevent yourself from any form of attack.

1. Protect your seed phrase

2. Understand what you sign on-chain

Make sure to never expose your private key and seed phrase in Web 2 and Web3 environments and make sure you have a full understanding of what transaction you are signing.

References