X-exploreAdvanced Analysis For Arbitrum Airdrop
This article is jointly published by X-explore and WuBlockchain.OverviewThe long-awaited Arbitrum has finally released its airdrop news. Along with the airdrop news, they also released their rules for checking Sybil addresses.https://github.com/ArbitrumFoundation/sybil-detectionAccording to the rule described, we can infer that the project team:Excluded cross-chain bridges, centralized exchanges, and smart contracts while detecting SybilA relatively tolerant detection was adopted for small-sc...
X-explore链上地址投毒，让你防不胜防
Abstract: 近一周，0U 转账的链上地址投毒攻击愈演愈烈，截至12月2日，已经有超过37W地址被投毒，总计92个受害地址，被盗取金额超过164W USD。 本篇文章，X-explore 对攻击态势进行了全面分析，对攻击者进行了链上溯源，同时也深入分析了攻击的实现方式。 我们呼吁钱包APP加强风险提示，普通用户在转账时谨防此类攻击。因为我们注意到UTC时间11月2日10点38分，有一位链上用户损失惨重，近100万美金因投毒而被转到黑客地址。本文由 X-explore 与吴说区块链联合发布。1. 背景近期，我们的链上风险监控发现ETH、BSC链上频繁出现 0u 转账现象，以下图bsc链的交易数据为例，受害者A发出一笔正常交易将452 BSC-USD发给B后，会收到C转来的0 BSC-USD，同时，在同一笔交易hash内用户A自己也会不受控制的给C转0 BSC-USD（实现了“一来一回”的0 BSC-USD转账操作）用户交易列表出现的现象在社区中，很多用户不知所以然，担心自己的钱包私钥已经泄漏，攻击者正在窃取资产。2. 攻击意图其实遇到这种情况的用户不用紧张，大家的资产是安全的...
X-exploreHNT fake recharge traceability - $40 Million defrauded
A number of group attacking activities have been found in the Binance accident of HNT misallocation, due to its system vulnerability, occurred a few days ago. This article will trace and analyze the attacking group with the largest amount, hoping the analysis will give all exchanges some insights to improve their resilience in regards to the underlying risk. Furthermore, this article will also expose the details of actual attackers, whose miner nodes are still working, so that anyone of inter...
X-exploreAdvanced Analysis For Arbitrum Airdrop
This article is jointly published by X-explore and WuBlockchain.OverviewThe long-awaited Arbitrum has finally released its airdrop news. Along with the airdrop news, they also released their rules for checking Sybil addresses.https://github.com/ArbitrumFoundation/sybil-detectionAccording to the rule described, we can infer that the project team:Excluded cross-chain bridges, centralized exchanges, and smart contracts while detecting SybilA relatively tolerant detection was adopted for small-sc...
X-explore链上地址投毒，让你防不胜防
Abstract: 近一周，0U 转账的链上地址投毒攻击愈演愈烈，截至12月2日，已经有超过37W地址被投毒，总计92个受害地址，被盗取金额超过164W USD。 本篇文章，X-explore 对攻击态势进行了全面分析，对攻击者进行了链上溯源，同时也深入分析了攻击的实现方式。 我们呼吁钱包APP加强风险提示，普通用户在转账时谨防此类攻击。因为我们注意到UTC时间11月2日10点38分，有一位链上用户损失惨重，近100万美金因投毒而被转到黑客地址。本文由 X-explore 与吴说区块链联合发布。1. 背景近期，我们的链上风险监控发现ETH、BSC链上频繁出现 0u 转账现象，以下图bsc链的交易数据为例，受害者A发出一笔正常交易将452 BSC-USD发给B后，会收到C转来的0 BSC-USD，同时，在同一笔交易hash内用户A自己也会不受控制的给C转0 BSC-USD（实现了“一来一回”的0 BSC-USD转账操作）用户交易列表出现的现象在社区中，很多用户不知所以然，担心自己的钱包私钥已经泄漏，攻击者正在窃取资产。2. 攻击意图其实遇到这种情况的用户不用紧张，大家的资产是安全的...
X-exploreHNT fake recharge traceability - $40 Million defrauded
A number of group attacking activities have been found in the Binance accident of HNT misallocation, due to its system vulnerability, occurred a few days ago. This article will trace and analyze the attacking group with the largest amount, hoping the analysis will give all exchanges some insights to improve their resilience in regards to the underlying risk. Furthermore, this article will also expose the details of actual attackers, whose miner nodes are still working, so that anyone of inter...
Share Dialog
Share Dialog
Subscribe to X-explore
Subscribe to X-explore
>300 subscribers
>300 subscribers
This article is jointly published by X-explore and WuBlockchain.
The address poisoning attack on $0 USD transfers is savage in recent weeks. As of December 2, more than 340K addresses have been poisoned on the chain, totaling 99 victim addresses and more than 1.64M USD stolen.
In this article, X-explore provides a comprehensive analysis of the attack landscape, traces the attackers on-chain, and also provides an in-depth analysis of how the attack is implemented.
We would like to appeal to wallet apps to step up risk alerts and ordinary users to be aware of such attacks when transferring tokens.
Recently, our on-chain risk monitoring found that $0 USD transfers occur frequently on ETH and BSC chains. We took the following BSC chain transaction data as an example to illurstrate how is this going. After VICTIM A sends a normal transaction to send 452 BSC-USD to USER B, USER B will immediately receive 0 BSC-USD from ATTACKER C. At the same time, within the same transaction hash, USER A himself will uncontrollably transfer 0 BSC-USD to ATTACKER C (realizing a "back and forth" 0 BSC-USD transfer operation)
Many users in the social media community are unaware of this and fear that their wallet private keys have been compromised, and attackers are stealing assets.
In fact, users who encounter this situation do not need to be nervous, everyone's assets are safe, the private key is not leaked, you just need to carefully confirm the address and not transfer the wrong address is fine. The hacker's methods are very simple:
The hacker monitors the transfer information of several stablecoins on the chain and captures the transfer information that victim address A normally sends to user B.
The hacker carefully constructs a hacker address C with the same first and last digits as user address B, so that victim A and hacker address C transfer 0U to each other. (Here the attacker can use the pretty number generation tool Profanity to generate an address with the same first and last 7 digits as the user address in a few seconds)
The next time Victim A carelessly copies the address of the historical transaction, it is easy to copy it to the address C prepared by the hacker by mistake, thus transferring the funds to the wrong account
We consider this attack to be an on-chain address poisoning attack:
First, the hacker makes his address appear in the user's transaction history, luring the user into mistaking it for a trusted interaction address.
In addition, the hacker constructs an address that has the same first and last digits as the user's trusted address and is used by the user for the next transaction.
Users are vulnerable to capital loss under double poisoning, and all on-chain users need to be on guard together!
As of December 2, the number of attacks on the BSC and ETH chains exceeded 290,000 and 40,000, respectively, and the number of independent addresses affected by the attacks exceeded 150,000 and 36,000, respectively.
In terms of trends, the BSC chain has been exploding since Nov. 22, while the ETH chain has been exploding since Nov. 27, with the scale of attacks on both chains intensifying.
In addition, it can be seen that there is a significant regularity in the timing of the attacks, with a significant decrease in the volume of attacks between 17:00 UTC and 0:00 UTC each day. The suspected attackers are in the Asian time zone.
As of December 2, a total of 94 unique addresses have been scammed, with a cumulative total of 1,640,000 USD, and with the increase in attackers' targets, it is expected that a large number of users will continue to be scammed in the near future.
In addition, we analyzed the attacker's cost of attack and the total cost is currently close to 25,000 USD (46 BNB + 9 ETH), with the attacker having a strong preference for BSC-USD and USDT, related to the coin circulation and user holdings of the stablecoin.
We trace one of the attackers, associated with two major centralized exchanges, the complete process is shown in the figure below.
The source address of its attack funds is associated with OKX.com, and the attacker transfers the original attack funds from the TRON chain to the BSC chain by using the Transit.Finance cross-chain bridge.
The stolen funds are eventually attributed to Huobi.com, and the attacker is still using the Transit.Finance cross-chain bridge to transfer the stolen funds to the TRON chain.
Let us expand further and trace the flow of the stolen funds to the source.
First, the victim address 0xe17c2b2b40574d229a251fe3776e6da2cc46aa5e transfers a total of 1300U to the attacker address 0x720c1cfe1bfc38b3b21c20961262ad1e095a6867 in two installments.
Next, the attacker address deposit the funds to address 0x89e692c1b31e7f03b7b9cbb1c7ab7872ddeadd49
The attacker performed a cross-chain transfer of funds at address 0x89e692c1b31e7f03b7b9cbb1c7ab7872ddeadd49, in a txhash of 0 x72905bd839f682f795946d285500143ee7606e9690df2ad32968e878ad290d9f in the transaction as shown below, passing 10561 USDT through the contract of Transit.Finance (0 xb45a2dda996c32e93b8c47098e90ed0e7ab18e39) was Crossed. In the Event Logs of this transaction, you can see that the funds went to the USDT of the TRON chain. The corresponding address is TLUKBw37BVWDZdhbGco2ZEfdMd5Cit8TMD, corresponding to the transaction hash on the TRON chain is: 716507136ad28717ffd5f2f437af753ff96d344d2bcbe83f24d801db49f5a884
Eventually, the attacker topped up the TLUKBw37BVWDZdhbGco2ZEfdMd5Cit8TMD address into the Huobi exchange. The deposit addresses for the top-ups are: TPtzsrCAG61QMwig3jZV8Px7Rd1WZVnRXG, TDp7r3S1hJeiNfH1CvCVXeY8notY47nagJ
Attacker Case 1:
Attacker Case 2:
The token attacks on the bsc chain mainly include BSC-USD, BUSD, USDC, ETH, etc. Most of them are through the batch call of transferFrom() function by the attack contract, but there are also cases of manual call of transfer() function and the case for the main coin. The principle is basically the same. The following is an example of an attack contract with BSC-USD.
transferFrom()
In a transaction where the attacker calls the attack contract, the attack contract only calls the transferFrom() function of BSC-USD, and by filling the parameters with sender, recipient, and amount, it can manipulate the 0 USD transfer between any addresses, and at the same time generate the events of AuthorizeApproval() and TransferTransfer().
The source code of the BSC-USD contract shows that the transferFrom() function calls the _transfer() and _approve() functions in sequence.
The _transfer() function has a simple function. First, it excludes all-zero addresses from the transaction, then it subtracts money for the sender and adds money for the receiver, and finally it records the transfer event. The add and subtract functions used here add()/sub() are OpenZeppelin's safemath library, and overflow will report an error revert.
The _approve() function also excludes the full zero address and modifies the authorization value. The focus of this function is in the parameter calculation of the transferFrom call to approve, which uses_allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance") , to subtract the number of existing authorization tokens from the transfer The remaining authorization amount is put into approve and re-authorized. The subtraction function sub() used here is OpenZeppelin's safemath library, and overflow will report an error revert; however, if the parameter amount of the whole process is zero, no detection mechanism can reject the transaction, which also leads to a large number of $0 transfers on the chain that can be sent normally, and the hacker only needs to pay a fee to reap a significant return.
transfer()
Call transfer () function of the attack in the same way as the principle, the whole process only adds or subtracts the overflow detection, there is no filtering of the zero transfer.
BNB
In the process of token attack tracing, we also found the first and last identical phishing attack through 0 BNB transfer, the principle is similar to token phishing, constructing the first and last identical address for phishing.
Attack Transactions: https://bscscan.com/tx/0x5ae6a7b8e3ee1f342153c1992ef9170788e024c4142941590857d773c63ceeb3
After constructing the address is very confusing, accidentally transferred to the wrong hacker address
Normal user address: 0x69cb60065ddd0197e0837fac61f8de8e186c2a73
Hacker construction address: 0x69c22da7a26a322ace4098cba637b39fa0a42a73
X-explore currently provides the real-time on-chain monitoring for such attacks. In order to avoid further harm, we recommend that:
The Wallet App helps users distinguish addresses through color or other prompts, and does a good job of alerting users.
Users should carefully distinguish and double check historical transaction addresses when transferring funds, preferably by keeping an address book on their own.
In the meantime, we developed and revealed this address poisoning attack on data basis as the reference, which are supported by Dune.
dune dashboard: https://dune.com/opang/first-and-last-address-construction
For more, please follow x-explore. Mirror: https://mirror.xyz/x-explore.eth Twitter: https://twitter.com/x_explore_eth
This article is jointly published by X-explore and WuBlockchain.
The address poisoning attack on $0 USD transfers is savage in recent weeks. As of December 2, more than 340K addresses have been poisoned on the chain, totaling 99 victim addresses and more than 1.64M USD stolen.
In this article, X-explore provides a comprehensive analysis of the attack landscape, traces the attackers on-chain, and also provides an in-depth analysis of how the attack is implemented.
We would like to appeal to wallet apps to step up risk alerts and ordinary users to be aware of such attacks when transferring tokens.
Recently, our on-chain risk monitoring found that $0 USD transfers occur frequently on ETH and BSC chains. We took the following BSC chain transaction data as an example to illurstrate how is this going. After VICTIM A sends a normal transaction to send 452 BSC-USD to USER B, USER B will immediately receive 0 BSC-USD from ATTACKER C. At the same time, within the same transaction hash, USER A himself will uncontrollably transfer 0 BSC-USD to ATTACKER C (realizing a "back and forth" 0 BSC-USD transfer operation)
Many users in the social media community are unaware of this and fear that their wallet private keys have been compromised, and attackers are stealing assets.
In fact, users who encounter this situation do not need to be nervous, everyone's assets are safe, the private key is not leaked, you just need to carefully confirm the address and not transfer the wrong address is fine. The hacker's methods are very simple:
The hacker monitors the transfer information of several stablecoins on the chain and captures the transfer information that victim address A normally sends to user B.
The hacker carefully constructs a hacker address C with the same first and last digits as user address B, so that victim A and hacker address C transfer 0U to each other. (Here the attacker can use the pretty number generation tool Profanity to generate an address with the same first and last 7 digits as the user address in a few seconds)
The next time Victim A carelessly copies the address of the historical transaction, it is easy to copy it to the address C prepared by the hacker by mistake, thus transferring the funds to the wrong account
We consider this attack to be an on-chain address poisoning attack:
First, the hacker makes his address appear in the user's transaction history, luring the user into mistaking it for a trusted interaction address.
In addition, the hacker constructs an address that has the same first and last digits as the user's trusted address and is used by the user for the next transaction.
Users are vulnerable to capital loss under double poisoning, and all on-chain users need to be on guard together!
As of December 2, the number of attacks on the BSC and ETH chains exceeded 290,000 and 40,000, respectively, and the number of independent addresses affected by the attacks exceeded 150,000 and 36,000, respectively.
In terms of trends, the BSC chain has been exploding since Nov. 22, while the ETH chain has been exploding since Nov. 27, with the scale of attacks on both chains intensifying.
In addition, it can be seen that there is a significant regularity in the timing of the attacks, with a significant decrease in the volume of attacks between 17:00 UTC and 0:00 UTC each day. The suspected attackers are in the Asian time zone.
As of December 2, a total of 94 unique addresses have been scammed, with a cumulative total of 1,640,000 USD, and with the increase in attackers' targets, it is expected that a large number of users will continue to be scammed in the near future.
In addition, we analyzed the attacker's cost of attack and the total cost is currently close to 25,000 USD (46 BNB + 9 ETH), with the attacker having a strong preference for BSC-USD and USDT, related to the coin circulation and user holdings of the stablecoin.
We trace one of the attackers, associated with two major centralized exchanges, the complete process is shown in the figure below.
The source address of its attack funds is associated with OKX.com, and the attacker transfers the original attack funds from the TRON chain to the BSC chain by using the Transit.Finance cross-chain bridge.
The stolen funds are eventually attributed to Huobi.com, and the attacker is still using the Transit.Finance cross-chain bridge to transfer the stolen funds to the TRON chain.
Let us expand further and trace the flow of the stolen funds to the source.
First, the victim address 0xe17c2b2b40574d229a251fe3776e6da2cc46aa5e transfers a total of 1300U to the attacker address 0x720c1cfe1bfc38b3b21c20961262ad1e095a6867 in two installments.
Next, the attacker address deposit the funds to address 0x89e692c1b31e7f03b7b9cbb1c7ab7872ddeadd49
The attacker performed a cross-chain transfer of funds at address 0x89e692c1b31e7f03b7b9cbb1c7ab7872ddeadd49, in a txhash of 0 x72905bd839f682f795946d285500143ee7606e9690df2ad32968e878ad290d9f in the transaction as shown below, passing 10561 USDT through the contract of Transit.Finance (0 xb45a2dda996c32e93b8c47098e90ed0e7ab18e39) was Crossed. In the Event Logs of this transaction, you can see that the funds went to the USDT of the TRON chain. The corresponding address is TLUKBw37BVWDZdhbGco2ZEfdMd5Cit8TMD, corresponding to the transaction hash on the TRON chain is: 716507136ad28717ffd5f2f437af753ff96d344d2bcbe83f24d801db49f5a884
Eventually, the attacker topped up the TLUKBw37BVWDZdhbGco2ZEfdMd5Cit8TMD address into the Huobi exchange. The deposit addresses for the top-ups are: TPtzsrCAG61QMwig3jZV8Px7Rd1WZVnRXG, TDp7r3S1hJeiNfH1CvCVXeY8notY47nagJ
Attacker Case 1:
Attacker Case 2:
The token attacks on the bsc chain mainly include BSC-USD, BUSD, USDC, ETH, etc. Most of them are through the batch call of transferFrom() function by the attack contract, but there are also cases of manual call of transfer() function and the case for the main coin. The principle is basically the same. The following is an example of an attack contract with BSC-USD.
transferFrom()
In a transaction where the attacker calls the attack contract, the attack contract only calls the transferFrom() function of BSC-USD, and by filling the parameters with sender, recipient, and amount, it can manipulate the 0 USD transfer between any addresses, and at the same time generate the events of AuthorizeApproval() and TransferTransfer().
The source code of the BSC-USD contract shows that the transferFrom() function calls the _transfer() and _approve() functions in sequence.
The _transfer() function has a simple function. First, it excludes all-zero addresses from the transaction, then it subtracts money for the sender and adds money for the receiver, and finally it records the transfer event. The add and subtract functions used here add()/sub() are OpenZeppelin's safemath library, and overflow will report an error revert.
The _approve() function also excludes the full zero address and modifies the authorization value. The focus of this function is in the parameter calculation of the transferFrom call to approve, which uses_allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance") , to subtract the number of existing authorization tokens from the transfer The remaining authorization amount is put into approve and re-authorized. The subtraction function sub() used here is OpenZeppelin's safemath library, and overflow will report an error revert; however, if the parameter amount of the whole process is zero, no detection mechanism can reject the transaction, which also leads to a large number of $0 transfers on the chain that can be sent normally, and the hacker only needs to pay a fee to reap a significant return.
transfer()
Call transfer () function of the attack in the same way as the principle, the whole process only adds or subtracts the overflow detection, there is no filtering of the zero transfer.
BNB
In the process of token attack tracing, we also found the first and last identical phishing attack through 0 BNB transfer, the principle is similar to token phishing, constructing the first and last identical address for phishing.
Attack Transactions: https://bscscan.com/tx/0x5ae6a7b8e3ee1f342153c1992ef9170788e024c4142941590857d773c63ceeb3
After constructing the address is very confusing, accidentally transferred to the wrong hacker address
Normal user address: 0x69cb60065ddd0197e0837fac61f8de8e186c2a73
Hacker construction address: 0x69c22da7a26a322ace4098cba637b39fa0a42a73
X-explore currently provides the real-time on-chain monitoring for such attacks. In order to avoid further harm, we recommend that:
The Wallet App helps users distinguish addresses through color or other prompts, and does a good job of alerting users.
Users should carefully distinguish and double check historical transaction addresses when transferring funds, preferably by keeping an address book on their own.
In the meantime, we developed and revealed this address poisoning attack on data basis as the reference, which are supported by Dune.
dune dashboard: https://dune.com/opang/first-and-last-address-construction
For more, please follow x-explore. Mirror: https://mirror.xyz/x-explore.eth Twitter: https://twitter.com/x_explore_eth
No activity yet