Not long after the last announcement of the “Another Airdrop Scam, But With a Twist,” we’ve identified a very similar scam based on reports from victims.

According to the reports of many victims, transfers of 0 USDT from unrecognized addresses continued to show in the address transaction history of TRON network users, with the TransferFrom function being called in each instance.

Clicking on a random transaction to view its details, as depicted in Pic 1 for the transaction with tx 701e7 in the red box.

This transaction is a call to the function TransferFrom, which allows the address beginning with TCwd to transfer 0 USDT from the address beginning with TAk5 to an address starting with TMfh.

This indicates that the culprit was the address beginning with TCwd;

Let’s examine this address:

Evidently, this address is calling TransferFrom multiple times every second.

Next, we will examine the USDT transfers from this address.

The majority have records of transferring out 0.001 amounts. This reminded us of a similar scam involving airdrop scams consisting of addresses with identical end numbers.

The address beginning with TCwd could be one of the primary addresses, distributing 0.001 to multiple addresses that might all be used by the attacker for the airdrop. To verify this, the address TMQy….6ZRMK was used.

TADXT……Lhbuo and further down are all of the USDT receiving addresses.

Pic 6 demonstrates that the address TADXT… Lhbuo had two regular transfers with the TMQ… address. This person was being harassed not only by airdrops with the same last number, but also by the 0 transferFrom method described in this article. It is also reasonable to assume that the same organization is responsible for these two methods.

It is possible to initiate a transfer of 0 from any user’s account to an unauthorized account without failure, as the TransferFrom function of the token contract does not require that the approved transfer amount be greater than 0. This condition is utilized by the malicious attacker to repeatedly launch TransferFrom actions to active users in order to trigger these transfer events.

Apart from TRON, we cannot help but worry if the same scenario would occur on the Ethereum network.

So we ran a little test on the Ethereum network.

The test calls were successful, applying the same rule to the Ethereum network.

Unavoidably, if a user discovers a transaction record that is not his or her own, he or she may fear that his or her wallet has been compromised. When a user attempts to alter his or her wallet or re-download it, he or she runs the danger of being scammed and robbed; conversely, if a user’s transaction history is “hijacked” by an attacker, the user may lose assets by copying the wrong transfer address.

SlowMist would like to remind you that due to the immutability of blockchain technology and the irreversibility of on-chain transactions, you should double-check the address before executing any activities. Additionally, if you see any unexpected transactions occurring from your address, please exercise caution and analyze it thoroughly. Feel free to contact us if you have any questions, our DM is always open.

This series is a case study of the MistTrack investigate service.

Overview

Hackers attacked a project and transferred all stolen funds to TornadoCash, prompting the project party to seek assistance from MistTrack.We discovered the withdrawal address set by performing an analysis of TornadoCash transactions and demixing the funds from other users. After a few days of waiting, some of the stolen funds were finally transferred to an exchange. We sent an on-chain message to the hacker’s withdrawal address, requesting the return of stolen funds or facing legal action. The stolen funds were returned to the team within nine hours.

MistTrack played a vital role in Case 01 by following the following steps:

1. Establish Trust Between Parties

2. Tracking of Stolen Funds

3. Hacker Profile Analysis

4. TornadoCash Withdrawal Analysis

5. Monitoring of TornadoCash Withdrawals

6. On-chain Communication

7. Enforcement agency involvement and support when necessary

Tracking of Stolen Funds

After receiving the team’s request for assistance, we immediately started an investigation and analysis into this incident.

During our analysis, we concluded that all stolen funds were transferred to TornadoCash.

Hacker Profile Analysis

MistTrack’s analysis of the hackers profile based on these key points.

Gas fee souce

Tools used

Operational timeline

Hacker profile

Pre-attack analysis

…

The initial funding from this attack originated from TornadoCash, as you can see below.

To avoid detection, stolen funds are frequently swapped, bridged, or even laundered using sophisticated techniques. This can be done with a variety of tools, such as xxSwap, etc., before it’s deposited to TornadoCash.

TornadoCash Withdrawal Analysis

Based on the information provided above, the TornadoCash Withdrawal Analysis is the key that Case 01 was able to solve.

The tool depicted below is used in the withdrawal analysis process. It aided in the sorting of TornadoCash withdrawal addresses that meet the filtering criteria.

After obtaining the list of withdrawal addresses, we classified the withdrawal addresses by the following characteristics:

Active time period

Gas price distribution

Interaction with similar platforms

Withdrawal address patterns

Withdrawal amount distribution

In one of our classifications, we found that it shared similar characteristics:

Used similar platforms — xxSwap

Same active period as the hacker addresses

Consistent with the amount deposited by hackers to TornadoCash

More importantly, one of the withdrawal addresses was associated with the original hacker’s address. Thus giving us proof these addresses were related to the hacker.

Monitoring of TornadoCash Withdrawals

We immediately notified the involved parties of all relevant TornadoCash withdrawal addresses, and used our MistTrack AML monitoring system to alert us of any further activity.

On-chain Communication

After a few days of monitoring, we received an alert informing us that the hackers had sent a portion of the stolen funds to an exchange after transferring them to various wallets. We immediately contacted the victim to discuss the best course of action. We advise the team to reach out to law enforcement agencies for support and assist the project in sending an on-chain message to the hacker. Message: “Refund the stolen funds within 48 hours and retain a portion as bug bounty, or we will continue our investigation and take legal action with the assistance of law enforcement.” Throughout the entire process, we provided law enforcement with evidence and continuously monitored all addresses involved.

Result

Within 9 hours of sending the hacker an on-chain message, the majority of the team’s stolen funds had been returned.

Recently, several users reported that their assets had been stolen. At first, they were unsure how their funds had been stolen, but upon closer inspection, we discovered that this was a new type of airdrop scam.

Many of the victims’ addresses were constantly airdropped with tiny amounts of tokens (0.01 USDT, 0.001 USDT, etc.), and they were most likely targeted because their addresses were involved in high-value transactions and trade volume. The last few digits of the attacker’s address are nearly identical to the last few digits of the user’s address. This is done to deceive the user into accidentally copying the wrong address from the transaction history and sending the funds to the incorrect address.

Related Information

Attacker Address 1: TX…dWfKz

User address 1: TW…dWfKz

Attacker address 2: TK…Qw5oH

User address 2: TW…Qw5oH

MistTrack Analysis

Let’s start with an overview of the two attacker addresses:

The attacker’s address (TX…..dWfKz) and the user’s address (TW…..dWfKz) both end in dWfKz. Even after the user mistakenly sent 115,193 USDT to the wrong address, the attacker still airdrops 0.01 USDT and 0.001 USDT to the victim address using two new addresses that also end in dWfKz.

The same thing happened to our second victim. The attacker’s address (TK…. .Qw5oH) and the user’s address ( (TW…. .Qw5oH) both end in Qw5oH. The victim mistakenly sent 345,940 USDT to the wrong address, and the attacker continues to airdrop 0.01 USDT to the victim address using a new addresses that also end in Qw5oH.

Next, we’ll examine attacker address 1 using our AML platform MistTrack (tx.. .dWfKz). As shown in the figure below, attacker address 1 airdrops 0.01 USDT and 0.02 USDT to various target addresses, all of which have interacted with the address that ends in dWfKz.

Looking back, we can see the initial transfers for these airdrops came from the address TF…. J5Jo8 on October 10, when 0.5 USDT was transferred to it.

Preliminary analysis of TF… .J5Jo8:

This address sent 0.5 USDT to nearly 3300 addresses, indicating that each of these receiving addresses could be an address used by the attacker to airdrop. So we decided to select one address at random to verify our theory.

MistTrack was used to analyze the last address on the above chart, TX…..4yBmC. As shown in the figure below, the address TX….4yBmC is used by the attacker to airdrop 0.01 USDT to multiple addresses that end in 4yBmC.

Let’s look at the attacker’s address 2 (TK…. .Qw5oH): 0.01 USDT was airdropped to multiple addresses, and the initial funding of 0.6 USDT was sent from TD…. .psxmk.

As you can see from the graph below, the attacker sent 0.06 USDT to TD…. .kXbFq and it also interacted with a FTX user’s deposit address that ends in Qw5oH.

So let’s reverse the process and see if other addresses have interacted with TD… .kXbFq. Are there any other addresses with the same ending characters as the ones that were airdropped to them?

Once again, we’ll choose two addresses at random and test our theory. (for example, the Kraken deposit address TU… .hhcWoT and Binance deposit address TM…. .QM7me).

Unfortunately, the scammer was able to deceive some unsuspecting user into sending them their funds.

Summary

This article focuses on how a scammer exploits users who copy the address from the transaction history without verifying the entire address. They accomplish this by generating a similar address that ends in the same way as the user’s address and airdropping small amounts of funds to the user’s address on a regular basis. All of this is done in the hope that users will copy the fake address and send their funds to the scammer the next time.

SlowMist would like to remind everyone that due to the immutability of blockchain technology and the irreversibility of on-chain operations, please double check the address before proceeding. Users are also encouraged to use the address book feature in their wallet so that they don’t need to copy and address each time.

Background

Celer Network officials stated on August 18 that between 3:45 and 6:00 Beijing time, certain cBridge users were directed to malicious smart contracts. Initially, the cBridge front-end interface was suspected of being compromised by DNS attack.

Completely different from the previous cross-chain bridge hacking incidents such as Nomad, Wormhole, Ronin, Harmony, etc., this attack was not caused by bugs in smart contracts and cross-chain protocols or the intrusion of related servers, and the cross-chain assets locked in cBridge have also been kept safe. In this attack, the hackers directly targeted the underlying infrastructure in the Internet architecture outside the Celer system, and allowed cross-chain users to access a “phishing” front-end user interface within a period of time by deceiving the Internet’s underlying routing protocol (BGP).The Celer network was able to limit damages due to their prompt response.This is because the Celer Network team has a 24-hour monitoring system. Their customer service team was able to identify the problem and alert the community in a timely manner. The Celer Network team empowered the SlowMist security team to respond to this emergency and conduct an in-depth investigation.

Analysis Process

The Celer Network team initially suspected a DNS attack, and after communicating with them, we were able to learn more about the domain name in question: cbridge-prod2.celer.network. We discovered that the browser did not report a certificate error during the attack. Therefore, our investigation started with addressing the possibility of DNS attack first. (Special thanks to @greysign1 for helping us to quickly check the possibility of DNS attack)

We began by reviewing the relevant certificate information:

The certificate appears to have been altered unexpectedly, where the original certificate issued by Let’s Encrypt was replaced with a counterfeit certificate issued by GoGetSSL.

GoGetSSL can issue a free 90 day certificate:

Analysis of Certificate 1: https://crt.sh/?id=7356185959

A CRL Check error appears on the certificate at the following time:

Analysis of Certificate 2: https://crt.sh/?id=7356185959

This certificate also has a CRL Check error at the following times:

After examining the IP address, the certificate, as well as other information associated with Certificate 1, we discovered that the IP address bound by this certificate was 44.235.216.69.

The IP address of Certificate 2 unabled to query the IP address corresponding to Certificate 2, which could be due to the short duration of the attack and the Internet search engine’s failure to collect relevant information.

As a result, we focused our analysis on the IP resolution data for the cbridge-prod2.celer.network domain:

IP address, 44.235.216.69, was associated with cbridge-prod2.celer.network for an extended period of time.

Here’s the question: The fact that this IP address, 44.235.216.69, was associated with cbridge-prod2.celer.network for an extended period of time, proves that it belonged to the official Celer Network server. This was also confirmed with the Celer Network team. So why was there a counterfeit certificate associated with this IP?

So we began to investigate the AS of 44.235.216.69 and discovered that the AS corresponding to this IP was unusual.

AS16509 announces bogons:：

Looking through the bogons, we’re able to determine that this is generally the case where an attacker spoofs an IP address to perform an attack: https://networkdirection.net/articles/routingandswitching/bgp-bogonsandmartians/ https://forum.networklessons.com/t/what-are-bogons/6333

Because the AS at 44.235.216.69 exhibited anomalies, we first suspected that the issue was with BGP, therefore we reached out to the Celer Network to obtain the IP address of the attacker: 54.84.236.100. We discovered that AS14618, where the IP address is located, also had an exception. (AS14618 also announces bogons)

Coincidentally, the upstream of AS14618 was AS16509 (AS16509 is also the AS where 44.235.216.69 is located). This alerted us to the possibility of a BGP attack.

Our investigation revealed that IP: 54.84.236.100 was flagged as malicious.

We collected relevant information on IP: 54.84.236.100 from our community and found a mention of that IP address being related to another BGP attack incident that occured back in 2014. However, because this incident occurred a long time ago, it may no longer be relevant.

We then continued our investigation by following the records left behind by this BGP attack:

Tracking the BGP record for the attack IP: 54.84.236.100 revealed that the route is no longer available.

We continued tracking the BGP router traces for celer’s IP: 44.235.216.69 and were able to find the correct route.

We then checked the BGP node change log: Beijing time: 8/18/2022 2:48 AM — 8/18/2022 7:48 AM UTC+8

On 8/18/2022, the time period between 2:48 AM — 7:48 AM BST was found to have a large number of node additions and deletions of change records.

We continued to monitor the AS change log and discovered that AS14618 formerly had the routing information 44.235.216.0/24, but the path was then altered to Withdrawn, proving that:

44.235.216.0/24 in AS14618 used to be the optimal path

Now 44.235.216.0/24 in AS14618 is no longer the optimal path; it is Withdrawn.

(When BGP attack occurs, the attacker will publish an optimal path to direct traffic to his own server)

In order to get more accurate data, we used the following bgplay to check the changes in the paths related to 44.235.216.69 around the time of the attack.

On 8/17/2022, we can see that during the time period between 19:19:23 +UTC and 23:19:23 +UTC, there was a significant fluctuation in the information of BGP routing pathways.

This change is reflected in directing traffic from 44.235.216.0/24 to AS14618, where traffic from 44.235.216.0/24 goes out through AS16509 after the attack.

As a result, we’re considering that this incident is likely a BGP attack event, where AS14618 appears to be a node under the attacker’s control (The router of the AS14618 may have security issues and may be exploited by attackers), with the attack lasting approximately 4 hours.

The attacker was able to bind Certificate 1 (counterfeit certificate) to Celer Network’s IP: 44.235.216.69 because the attacker had a malicious server with the same IP. Since gogetssl supports http for authentication, they can just input text provided by gogetssl into the malicious server. Therefore, making it possible to bind Certificate 1 by directing traffic to the malicious server with the same IP through BGP attack. As a result, the browser was alerted of the certificate error.

We determined that AS14618 was controlled by the attacker for the following reasons.

The attacker first directed traffic of 44.235.216.69 to AS14618, and routed 44.235.216.69 back to AS16509 after the attack.

Attack IP: 54.84.236.100 is also inside AS14618.

After the attack, AS14618 was Withdrawn to 44.235.216.69.

To answer this question: The fact that this IP address, 44.235.216.69, was associated with cbridge-prod2.celer.network for an extended period of time, proves that it belonged to the official Celer Network server. This was also confirmed with the Celer Network team. So why was there a counterfeit certificate associated with this IP?

If you use HTTPS protocol to communicate, you cannot encrypt/decrypt the data (including the data of client/server communication) without getting the private key of the certificate. So to ensure the certificate is correct and be able to carry out the man-in-the-middle attack, the attacker needs to rebind the certificate applied in the authority to the malicious server with the same IP 44.235.216.69. This enables the attacker to decrypt the client’s data and insert the malicious code into data of the response packet.

Analysis Conclusion

We investigated this attack in collaboration with the Celer Network team. Despite the fact that this was a sophisticated BGP attack attempt on the Celer Network, with the attacker preparing everything from the timing of attack, certificate forgery, AS control, and other operations.

Ultimately, we recognize that many projects are already aware of the risks associated with BGP attack attacks and have taken appropriate precautions. However, many are still unaware, particularly when it comes to network path modifications induced by AS changes. Without adequate preparation and response measures, there is a considerable risk of further attacks by the same or other attackers. Therefore, we urge that organizations, ISPs, and server hosting providers recognize such risks and coordinate on defensive strategies to prevent similar incidents from occurring again. And, as always, if you ever need assistance, please contact the SlowMist Security Team.

Attachment

cbridge-prod2.celer.network DNS Chart: