Record the #dugu hacking incident and my analysis

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.)

Let’s get started.


My perspective


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.

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.

Unfortunately, according to the blockchain explorer, his coins had already been transferred:

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.


Alarm bells rang

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:

This friend also attached two screenshots, one was the transfer record in their own wallet, and the other was a post on chiaforum:

I immediately recognized that address: the XCH stolen from my friend before had also gone to this address!

I quickly got up from my bed, opened chiaforum to check the post, and also opened the blockchain explorer:

It could be seen that XCH was constantly flowing into this address. This was not an isolated case, but a premeditated and large-scale theft!

(Thanks to @HVNC, who sounded the alarm in a timely manner, allowing us to quickly realize the seriousness of the situation and start taking action.)

I first posted an alert message in the Chinese community and then immediately posted the same message on Twitter:

(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.


Where was the private key leaked from?

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 ( 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.


Remedial measures

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.

I would like to take this opportunity to introduce Pawket, the first Air-gapped wallet on the Chia blockchain that can be used to store assets offline and sign transactions while offline. Here is a tutorial for reference: Tutorial: How to create an Air-gapped(offline) wallet with Pawket?Keep Safe! - General - Chia Devs


Hacker’s Perspective

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).

  • Wallet hacker-1: xch16euvttx9ynd68xzl0qefc6k2jahycuwzr7umlqya4z4hq57r2dkq6tdugu

    • (d678c5acc524dba3985f78329c6aca976e4c71c21fb9bf809da8ab7053c3536c)
  • Wallet hacker-2: xch1zt476z4rh30fngvapdqjvlt9t0y5tr2x5em8d442xrp3q48kfwqql5z72c

    • (12ebed0aa3bc5e99a19d0b41267d655bc9458d46a67676d6aa30c31054f64b80)
  • Wallet hacker-3: xch16l2n6tj0jvtks7mkvfkqf88xlh54rmtj8k7rlt5k4nqpt80z3tjqru4a5d

    • (d7d53d2e4f9317687b76626c049ce6fde951ed723dbc3fae96acc0159de28ae4)

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.


Stolen coin flow shown by Wallet hacker-1

When analyzing, all times are in UTC+0.

Coin theft initiation

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.

We can see the corresponding records on the blockchain explorer:


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).


First Round of Coin Theft

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.

An obvious time point is 14:24:41, where we can see that the script stopped at this moment.


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


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).


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).


Second round of Coin Theft

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.


coin summary

Now let’s sort out the summary records of stolen coins:

Time Block_height Send Receive Amount(XCH)
2023-03-05 13:40:08 3336402 wallet hacker1 wallet hacker 3 1000
2023-03-05 14:29:13 3336552 wallet hacker1 wallet hacker 3 1000
2023-03-05 14:29:13 3336552 wallet hacker1 wallet hacker 2 2785.82(then transfer to Wallet 3)
2023-03-06 09:53:11 3340197 wallet hacker2 wallet hacker 3 1000
2023-03-06 10:09:09 3340253 wallet hacker2 wallet hacker 3 1000
2023-03-06 10:25:08 3340309 wallet hacker2 wallet hacker 3 855.65

Total: 4855.65XCH


An interesting discovery:

  • 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.


New Clue

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.


Was it an accident or intentional?

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.


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.


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?



Key Information

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 :joy:)

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 :+1:
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 :face_with_raised_eyebrow:


yeah who is flagging these posts and why?

edit: could also be some auto anti-spam function though


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.


@Voodoo Thank you for your additional clarification, this is what I want to express

1 Like