Since the XCH theft incident by a hacker on March 5th, 2023, I have been closely monitoring its developments. Unfortunately, several of my friends fell victim to the attack, and many others have shared their similar experiences online.
While the source of the private key leak and the identity of the perpetrator remain unknown, the transparent nature of blockchain technology ensures that the recorded transactions are reliable. To better understand the situation, I spent several days analyzing all the transaction records associated with the hackerâs address, which allowed me to reconstruct a timeline of their activities.
In this account of the event, I will share my observations from two perspectives. First, as an outsider, I will describe how I initially became aware of the situation and the various reactions online. Second, drawing from my analysis of the blockchain, I will provide insights into the hackerâs actions, including their trajectory and potential modus operandi.
(As a side note, due to the limitations on the number of images new users can post on this forum, I omitted some screenshots. I would appreciate it if the administrator could remove this restriction so that I can add them later.)
(Additionally, I used ChatGPT to assist me with the translation, as my native language is Chinese. Please correct me if there are any errors in my phrasing.)
At 4:16 PM Beijing time on March 5th (UTC 08:16), I received a message from a friend who said that he could not see the balance in his wallet and did not see any transfer records.
(image.png)
At first, I thought it was a wallet synchronization issue. Since upgrading to version 1.7, the Chia Client often had abnormal balance synchronization issues (Iâm not sure if itâs related to Chinaâs network environment). So I suggested that my friend revert to an earlier version and synchronize again.
However, at 5:04 PM (UTC 09:04), I received another message from another friend who also said his coins were missing. I thought it was another synchronization issue, but he said he hadnât upgraded the client, so I asked him to send me his address.
(image.png)
Unfortunately, according to the blockchain explorer, his coins had already been transferred:
(image.png)
The XCH that was stolen was not a large amount (6.5 XCH). We briefly speculated on the possible reasons, such as his office computer being hacked or buying a pre-plotted hard drive online but not changing the plot address to a new one, resulting in the seller who knew the private key transferring it out (this kind of thing is not uncommon in Chinese farming circles), etc. But no matter how we analyzed it, we just treated it as a simple case, and since it was stolen, we just started over.
Now letâs turn our attention to the hackerâs perspective. Who planned this heinous event? How did he/they operate?
I spent some time sorting out all the records of the hacker on the blockchain. I will explain it first and then provide the source files for my on-chain analysis at the end.
Hackerâs addresses information
It is known that the hacker mainly used three addresses, and xchscan has also marked them.
I will use these labels in this article and provide their corresponding puzzle_hash (because I directly use the puzzle_hash in the on-chain analysis later).
The hacker first transferred the stolen coins to Wallet hacker-1, then consolidated them into Wallet hacker-2, with several transfers in between, and finally consolidated them into Wallet hacker-3.
Therefore, analyzing the historical records of Wallet hacker-1 can basically describe the entire coin theft process of the hacker. Therefore, this article will mainly analyze Wallet hacker-1.
From the block time, it can be seen that the hacker quickly began the second round of theft.
Start time: 2023-03-05 15:55:22+00 (all times below are in UTC+0)
Block height: 3336817
The hacker should have used the same script as the first round to continue scanning for remaining assets.
Why is this conclusion drawn? Because I compared some online comments from netizens (some netizens transferred a small amount of money to the stolen wallet after the first theft, and it was indeed transferred away again after a period of time), and at the same time, I obtained the addresses of several friends who were stolen, and found that their addresses were indeed stolen in both the first and second rounds.
The duration of the second round (maybe the hacker scanned for three rounds during this process, but because the entire script time is continuous from the blockchain perspective, letâs consider them all as the second round), started from 15:55 on March 5 and stopped at 14:25 on March 6. It lasted nearly 24 hours.
The amount stolen in the second round was much less. It was probably due to some addresses receiving mining rewards that were not transferred in time after being scanned in the first round.
The amount stolen in the second round is about 72.61286884 XCH.
When I realized that the hacker might be using Pawket, I suddenly remembered that on March 2nd, there was an unusually high volume of API access to Pawket, and our monitoring system alerted us that the number of accounts had been increased to more than 20,000 within a short period of time from UTC 13:46 (again, during this time period!).
When we saw this data, we were surprised but didnât pay much attention to it. Last year, when Chia friend announced the airdrop, the Pawket API access volume was also increased to more than 10,000 accounts because many people visited Pawket with different IPs to create a large number of accounts to receive the airdrop (this was confirmed in my communication with community members). Therefore, we thought it was just another airdrop activity.
However, now, combining the time of the abnormal access to Pawket with the time of the theft, I believe it is highly likely that this was done by the hacker.
Based on the information above, I have inferred a timeline of the hackerâs theft.
The hacker first obtained a large number of private keys (mnemonics) from a source, most likely leaked from a mining pool ďźwhich uses proprietary software, and requires some form of key/mnemonic input/presence.ďźbased on information provided by internet users.
In order to steal coins more efficiently, the hacker needed to confirm which accounts had money and sort them in descending order (based on results displayed on the blockchain, the hacker seemed to have targeted accounts with the most coins first).
Because syncing data on the Chia Client takes a long time, the hacker chose to directly call Pawketâs API to query account balances. As a result, Pawket had a large number of abnormal access records starting from 13:46 on March 2, and the number of online accounts displayed exceeded 20,000 in a short period of time. This number may indicate the number of leaked private keys.
The hacker obtained balance information for over 20,000 accounts, then preliminarily screened and sorted them, ultimately selecting a portion of the accounts for theft.
I estimate that the hackerâs list of stolen accounts only contained around 400 to 600 accounts. The reasons are as follows:
The hackerâs theft script is linear and continuous. Although the original record had over 10,000 entries, after merging entries with the same block height, only 633 entries remained. If only the first round of coin theft is considered, there were only 427 entries.
The initial batch of blocks may have contained transactions from multiple accounts (because the amount was relatively large and the coins were relatively intact, they could be quickly submitted to the mempool and thus packaged into the same block). However, as the theft continued, the number of coins in the wallets the hacker stole from increased (while the amounts decreased), and many times only transactions from a single account could be packaged into a block, and sometimes interference from dust storms meant that it could take several blocks to transfer all the money out of an account. Therefore, I roughly estimate that the number of affected accounts may be around 400 to 600.
Since victims may have multiple accounts, I believe that the number of victims in this case may be only a few hundred, which is consistent with the public opinion on the internet. If there were more victims, there would be more noise on the internet.
After receiving this list on March 2, the hacker may have spent some time writing the theft script.
At UTC 03:50 on March 5, the hacker began executing the script.
At UTC 13:01 on March 5, Wallet hacker-1 had received a large amount of coins, so the hacker began running the script to automatically merge these coins, stopping for some manual operations around 13:26. From 13:40 to 14:29, the amounts were gradually transferred to wallet hacker-2 and wallet hacker-3.
At UTC 15:40 on March 5, the hacker began the second round of scanning, which ended at 14:25 on March 6. After that, the hacker consolidated all the amounts to wallet hacker-3.
The main purpose of this article is to provide a comprehensive record of the entire event, which may not necessarily help us recover the stolen assets (as the blockchain is anonymous), but through such a review, we can confirm several key pieces of information and guide us in the future.
The private key was most likely leaked from the mining pool which uses proprietary software, and requires some form of key/mnemonic input/presence. and there may be more than one channel for the leak, which may not have happened recently, but much earlier. This means that the probability of the poolâs internal personnel (or former personnel) committing the crime is high.
The leaked private key (mnemonic) far exceeds the number of accounts that were stolen this time. The reason is that the hacker selected accounts with coins in advance and only targeted those accounts. This means that the hacker may carry out similar operations on another batch of accounts for a long time to come (so we remind everyone to transfer coins to a secure wallet in a timely manner after each mining).
The scale of the stolen accounts is estimated to be between 400-600.
The hackerâs active time period is from UTC 09:00 to 10:00 (when the coins were aggregated to wallet hacker-3) and from UTC 13:00 to 15:00 (when the hacker used the Pawket API to capture balance information, manually closed and started the script, transferred stolen funds, etc.). This may help us narrow down the hackerâs time zone.
The hacker is very active on Twitter and follows the investigation of the event (otherwise, there would not have been the strange transfer operation in the end). The hacker may even be a member of the community.
The hacker is currently managing his account with Pawket or Goby wallet because the change returned to the first address after each transfer.
The hacker is currently inactive because there is no mixing system on Chia. Once he transfers coins to an exchange, he may be located. Perhaps he is waiting for an opportunity.
What Pawket team can do
After realizing that Pawket API may be used by hackers, we have decided to strengthen the monitoring of this part and report any abnormal requests to the community in a timely manner.
It is important to note that Pawket is a decentralized wallet, so we cannot see usersâ accounts and mnemonics, including those of the hacker. We can only make a preliminary judgment on requests sent to the Pawket API, such as whether they were initiated by an Android or iOS device, or by a program written manually by someone.
We still comply with all the terms of the Pawket privacy agreement and do not collect excessive information.
If you want to strengthen the security management of your wallet, we sincerely recommend that you try using Pawket to create an air-gapped wallet, which is completely offline but can complete offline signatures and achieve a balance between security and usability. ălinkădevelopers.chia. net/t/tutorial-how-to-create-an-air-gapped-offline-wallet-with-pawket-keep-safe/828
This is all the transaction data of Wallet-hacker-1 on the chain I pulled. I hope it can help some friends to do a more in-depth analysis.
(Uh, I really donât have the permission to upload attachments, is there any administrator to help me find a way )
wallet-hacker-1 analysis.xlsx
Hereâs a description of each listing:
wallet-hacker1-origin This sheet is all the original on-chain data of wallet-hacker1
send-deduplication: Sendlist which removed self-address transfer
receive-nosand-deduplication: Receivelist which removed wallet-hacker-1 self-address transfer, the tranfer of wallet2 to wallet1 and sandstorm(<=1000mojo)
merge-only-same-block: Merged the same block height
round1-merge-same-add&block: Merged the same address and block height of round1
round1-merge-only-same-add: Only merged the same address of round1
round2-merge-same-add&block: Merged the same address and block height of round2
round2-merge-only-same-add: Only merged the same address of round2
Thanks a lot, seems like a very thorough analysis
Strange some of your posts were âflagged by the communityâ so quickly, I donât see anything offensive or illegal in them⌠Maybe the hacker is watching this space too
It would have to be a mining pool that uses proprietary software, and requires some form of key/mnemonic input/presence.
Pools using the Chia official pool protocol do not need the private keys and they donât have software running on the clients computer.
)
