On 12 October 2022, Journey of Awakening’s ATK token was exploited with the attacker gaining $127,805. The attacker was able to take advantage of a rewards system in the ATK contract. This vulnerability meant the attacker was able to gain rewards based on a manipulated token price.
On 12 October 2022, Journey of Awakening’s ATK token slipped ~69%. Transaction analysis showed that ATK had been exploited via their rewards system for 127,677 USDT. The Journey of Awakening contract that was exploited is unverified so we are unable to see the vulnerable code, however, we can infer that the vulnerability in the contract distributes rewards based on the current value of ATK. This inference is based on the price manipulation of ATK and the amount of tokens the attacker received compared to other reward pay outs.
24 hours before the exploit happened, the attacker (0x3DF6) deposited 970.4 ATK in to the ATK staking contract in order to be eligible for rewards, which are paid out every 24 hours.
Approximately 9 hours before the exploit, a second EOA (0x6826) deposits 971 ATK into the staking contract. This second EOA sends a message to the ATK exploiter and proclaims to be a hacker whilst asking if the exploiter is a whitehat.
This message suggests that the 0x6826 knew the intentions of the ATK hacker before the exploit took place.
Interestingly, a third EOA (0xd578) seemed to have noticed what was about to happen and reached out to the attacker. They asked the attacker to chat on Telegram which didn’t receive on onchain reply. 0xd578 reached out a second time to no avail.
This is interesting as it suggests that at least two entities other than the hacker were aware of the vulnerability and its consequences. The relationship between 0xd578 and the ATK team isn’t clear.
At 05:03 AM UTC+, 12 October the exploit is triggered. EOA (0x6826) sends the attacker (0x3DF6) a message praising them further suggesting that they were anticipating the exploit.
In return, the attacker sends 0x6826 0.621 BNB. This looks to be a good will gesture to a fellow black hat. The amount is enough to cover the costs of 0x6826 sending 971 ATK to the staking contract, which they will have lost in the incident. The attacker concludes by sending 473.7 BNB to Tornado Cash.
It is unclear whether 0x6826 had found the same vulnerability and was beaten to the exploit or if 0xd578 had tipped them off before the incident.
Attack contract created
https://bscscan.com/tx/0xb181e88e6b37ee9986f2a57aefb94779402fdb928654aa7c1dda5138b90d0e14
Deposit ATK with the attack contract
https://bscscan.com/tx/0x9e328f77809ea3c01833ec7ed8928edb4f5798c96f302b54fc640a22b3dd1a52
Attacker acquires ~50m ATK tokens
https://bscscan.com/tx/0x55983d8701e40353fee90803688170a16424ee702f6b21bb198bb8e7282112cd
Attacker sells ATK tokens for 127.7K BSC-USD
https://bscscan.com/tx/0x601b8ab0c1d51e71796a0df5453ca671ae23de3d5ec9ffd87b9c378504f99c32
The groundwork for the exploit began 24 hours prior to the attack. The ATK contract has a rewards system that pays out every 24 hours, so 24 hours prior to the incident the attacker deposited 970.4 ATK into the vulnerable contract. This meant, 24 hours later the attacker would be eligible for rewards based on their deposit amount.
24 hours later the attacker calls a swap function from their exploit contract and takes $130k BUSD from the BSC-USD pair. This manipulates the price of ATK ahead of the attacker calling 0x8a809095(claimToken1) in the vulnerable ATK contract.
The contract calculates the attacker’s rewards based on the manipulated price of ATK and transfers ~50.6 million ATK to the attacker who then returns the BUSD.
The attacker then sells the ~50.6 million ATK reward tokens for 127,677 USDT which is converted to WBNB and sent to a second EOA before being sent to Tornado Cash. The exploit caused a ~66.9% slippage in the price of ATK.
The vulnerable ATK contract is unverified so the analysis is an assumption based on the evidence we can see and inference. Given the amount of reward the user received and the manipulation of the price beforehand then we can infer it is likely the contract pays out rewards based on ATKs current value.
Although the vulnerable contract is unverified, it is highly likely this stems down to a price manipulation issue. It is the type of issue that would be detectable during an audit process. The developer may have considered rewards based on the previous 24 hour token holdings would have prevented abuse of the system but may not have factored in price manipulation. Having more than one source for pricing can help prevent this type of manipulation.