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.
It was late at night, around 23:35 (UTC15:35), and I was getting ready to go to bed when I suddenly saw someone in the Chinese community saying that their coins had been stolen:
(image)
This friend also attached two screenshots, one was the transfer record in their own wallet, and the other was a post on chiaforum:
(Itâs a bit of a pity that we issued the alert in the middle of the night in China, so only a few Chinese farmers managed to transfer their XCH out in time after seeing the message. Later on, I will mention that the hackers scanned and stole from the same batch of accounts for two to three rounds.)
After issuing the alert, I went back to sleep. By this time, it was already 2:00 in the morning on my end.
The next day when I woke up, news of the hackerâs attack had already spread online, and the fact that the coins had been stolen was irreversible. At this point, people were more concerned about where the private key (mnemonic) was leaked from.
There were various discussions online, and I summarize them as follows:
Chinese community: The stolen accounts were all mining accounts, and many people had used a tool called fastchia. In addition, many people had joined Hpool and YY pool (chiayy.com). Many people believed that YY was more suspicious because there were rumors that their servers had been hacked.
Other communities: Many of the stolen accounts had joined the sweetchia pool. Many people had also used third-party plotting tools.
However, some netizens said that they had used all of these pools and mining tools, but they had not been hacked. But what I want to point out is that not being hacked does not mean that your private key has not been leaked. As I will mention in the subsequent analysis, the hacker may have obtained the private key and then scanned the balance in each account, and then selected the one with the highest balance to attack. If you were not targeted, it may just be that you were not on their selection list.
Fortunately, in the continuous interviews, I finally found a âperfect victimâ who had never used any third-party plotting tools and had only joined mining pools. However, because he had joined several mining pools, some of which he couldnât even remember the name of, we could only preliminarily conclude that the probability of the private key being leaked from a mining pool (which used proprietary software, and requires some form of key/mnemonic input/presence ) was the highest.
It is possible that it was not just one mining pool that leaked the private key, and it is also not necessarily the mining pool that you recently joined. Some private keys may have ended up in a certain place in 2021 and finally ended up in the hands of the hacker.
Once your private key is leaked, it means that your wallet is no longer under your control, and the hacker may transfer your coins at any time. The usual understanding is to immediately abandon the compromised private key and stop using it.
However, for many farmers, abandoning the private key means having to redo the plotting process. If there are many hard drives involved, it will cost a considerable amount of money.
There were many discussions in the Chinese community, and in the end, the most feasible solution was suggested:
If you donât have too many hard drives (less than 200T), you can abandon the old plot and redo the plotting process.
If you have a large-scale operation with many hard drives and do not want to redo the plotting process, it is recommended to write a script to automatically transfer the coins to a safe wallet after winning a block. But this is still risky, as we can only assume that the hacker is not more diligent than you.
Special reminder: Mining wallets and storage wallets must be separated! It is best to use a cold wallet to store your XCH.
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.
The first stolen coins were taken on March 5th at 3:50.
Time: 2023-03-05 03:50:35+00 (all following times are in UTC+0)
Block height: 3334523
In this block, three transactions transferred money from three addresses.
image.png
We can see the corresponding records on the blockchain explorer:
image.png
image.png
image.png
From the records, these three addresses appear to be deposit addresses (where miners gather coins every few days). I checked the fourth address stolen by the hacker (in the next block) and it appeared to be a similar case.
However, the fifth address stolen by the hacker looked like a regular mining address because the profits were continuous.
Because the amount of coins was small, the hacker took three blocks (three transactions) to empty the money from this address (3334562/3334565/3334567).
After randomly checking a few more addresses, I tentatively concluded that the hacker began stealing from mining addresses starting from the fifth address.
Therefore, itâs possible that the first four addresses were actually the hackerâs own addresses, perhaps from previous thefts, and were combined in this instance (this is just a guess).
I obtained all the transaction records from Wallet hacker-1, filtered out transactions where the hacker transferred funds to their own addresses and transactions below 1000 mojo (mostly dust storms), and merged records with the same block height, resulting in 633 records (the table is attached at the end of this article).
From these records, we can see that the timeline of the entire coin theft is very continuous. The hacker probably used a script to automatically transfer the money from the addresses.
image.png
An obvious time point is 14:24:41, where we can see that the script stopped at this moment.
image.png
During this time, the hackerâs first round of theft ended, and the hacker was organizing the assets they had stolen. The hacker transferred funds between wallet hack-1 and wallet hack-2
image.png
In fact, before 14:24, the hacker had already been organizing these assets. I filtered out the hackerâs self-transfer records and found that from 13:01, wallet hacker-1 was constantly transferring funds to itself (combining small coins into large ones).
image.png
The behavior of merging coins should also be automated by the script, until it stopped at 13:26:33, and then the hacker started manual operations to collect the stolen coins. This manual operation ended at 14:29:13 on March 5, 2023.
Based on this time point, I believe this was the hackerâs first round of coin theft, with stolen funds of approximately 4785.029004 XCH (because dust storms below 1000 mojo were excluded, there may be slight differences).
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.
From the manually transferred records above, it seems that the hackerâs active time is around UTC 10:00 and UTC 14:00, which may imply their time zone.
When I looked at the records of Wallet2, I suddenly realized that when Wallet2 sent the amount to Wallet3, the change was returned to Wallet2âs address. This means that the hacker did not use the Chia client at this time (which generates a new address for change every time), but used either the Pawket or Goby wallet.
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.
If you look at the records of wallet hacker-1 and wallet hacker-2 now, you will find two very strange transactions that occurred after the hacker summed up the stolen amount, and these two transactions were eventually claimed by a netizen:
This is indeed a very strange situation. The hacker cannot send this amount to a netizen for no reason.
Guess
Some friends guessed that it might be because MojoSec has been posting the hackerâs address information on Twitter and created the #duguXCH tag, which caught the hackerâs attention.
Out of a mischievous mindset, the hacker sent these two XCH to him.
But from a sociological perspective, this behavior is really unnecessary. This may expose the hackerâs true identity. If the hacker is smart enough, he should not provoke people in the community actively. It is smarter to wait quietly for time to pass.
Clues
Now the hackerâs transfer to this address has exposed several things at least:
The hacker did not use the official client, but Pawket or Goby wallet (because the change was returned to the original address)
The hacker has been active on Twitter and observing everyoneâs behavior.
The hacker intentionally gave MojoSec coins, which proves that he is at least a very impatient person. Otherwise, he can do nothing. Maybe he has been suspected in the real world, so he needs to transfer attention? (Because we speculate that it is most likely the private key leaked by the mining pool. People who can get this private key are usually internal personnel of the mining pool or employees who have left. Perhaps someone in the community has contacted the hacker in real life, but does not know that he has done this.)
The hacker is likely to be a member of the community. MojoSecâs address is not that easy to find. Although he said that he left his address under almost all airdrop activities, I searched for âMojoSec addressâ âMojoSec xchââFarmerTD2 addressââFarmerTD2 xchâ on Twitter, and it was not that easy to directly find his address, especially the address xch1vcww4y4rjavv8cr9j787klvyz7qjjvnnlzrgwsxaw3mhwv2dhdlqgh2h9x that the hacker used to transfer money to him. I cannot search it using the above method (If you enter this address directly, you can search it on Twitter, but the hacker may not know this address at the beginning, so he cannot use this method to search).
In comparison, MojoSec has another commonly used airdrop address: ¡xch1uxukj8ffynayzcrxgxpxxdhm3zc9ve5txzlxzrag9j8l5rfgh8ms52udy0¡. This address is easier to search for on Twitter, but for some reason, the hacker skipped over this more frequently appearing and easily searchable address and chose another address that was not as easy to find. Perhaps this means that the hacker is actually familiar with MojoSec? (But MojoSec may not necessarily know the hackerâs identity. I want to emphasize that this statement is not an accusation, but rather a guess based on the hackerâs behavior).
If the hacker is familiar with MojoSec, then he must know that MojoSec is playing a game called Chiania, as evidenced by the NFT held by the udy0 address. Moreover, it is easy to search for the udy0 address in Chianiaâs Discord, because players need to bind their addresses when creating game accounts, and this address is also bound to a DID.
Therefore, it is unlikely that the hacker âaccidentallyâ made this transfer because it would have taken time and effort to find MojoSecâs address. Unless, of course, the hacker already knew who MojoSec was and had recorded his address early on.
So, is the hackerâs behavior actually a provocation? Even if he made this transfer, you cannot find me, can you?
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.
)
