Thunder terminal exploit - FN

[Ivan1905]

In this opportunity the hacker drained native assets from the protocol without deploying any contract.

Considering the hacker took more than an hour, there should have been a high confidence alert that could flag this one at least in the middle of the process, maybe a high balance decrease.

[Ivan1905]

Here's another one. which was the coinspaid exploiter. Drained native assets as well as usdt. https://etherscan.io/txs?a=0xe5f07ceb38cd95356c1a2f83f65fa8b59569f9b1&p=2

Although the address did not deployed any contract there was not any alert although draining funds in different txs.

[Thisisgeorg3]

Exploitation phase (?) a high priority P2 given that there was no contract deployed. Please prioritize this over other P2s.

[RCantu92]

Hey @Ivan1905, do you have additional info on the two instances you referenced? For example, I looked further into the Thunder Terminal exploit and the funds seem to have been drained from EOAs rather than contracts. At least based on the sample of addresses that transferred ETH to the exploiter address that I looked into.

From this article, it looks like addresses of users themselves were the ones affected. So this rules out some bots that monitor for contracts (not EOAs) that have a large balance decrease/assets drained.

Regarding the Coinspaid exploit, it is similar in that the transfers were from EOAs as well. Here are the transfers of ETH (the bottom two are the ones of interest), and here are the ones for the USDC, USDT, and CPD that were transferred to the exploiter. (Source article)

Do you know which Attack Detector base bot should've fired? Or was it the AD itself that should've? I just want to make sure my understanding aligns with yours. I can look around though myself in the meantime.

[Ivan1905]

Sorry Roberto. Yes, these may seem like two different cases.

What I was trying to do here is pointing out cases where there was not any contract deployment and drained funds happened in more than one tx (over a period of time). I guess as you mentioned in both cases the from address is an EOA and not a contract. Nevertheless maybe there's a way to find a pattern here. For instance all the drained addresses have approved/interacted "X" contract from "Y" protocol. Of course these cases would need the patient zero.

[RCantu92]

From looking into the Thunder Terminal exploit, it was flagged by the Private Key Compromise (PK) bot. (alert).

However, the Attack Detector currently does not consume alerts from the PK bot because that deals with EOAs getting their funds drained, whereas the Attack Detector really focuses on protocol's contracts exploits.

I will work on a new alertId and logic implementation to the Private Key Compromise that focuses on when a significant amount of EOAs have their private keys compromised in a small time window to cover this edge case. This would cover apps that control a lot of EOA's private keys, like Thunder Terminal. We can then monitor its performance after it is deployed before adding that to the Attack Detector.

[Ivan1905]

Hi Roberto, thanks for sharing.

Please correct me if I'm wrong but this may be a similar case: https://rekt.news/seneca-protocol-rekt/

This isn't a PKC but rather a bug in the contract which basically made all the users who approved the certain contract of the protocol, lost their assets.

Here a sample tx: https://etherscan.io/tx/0x23fcf9d4517f7cc39815b09b0a80c023ab2c8196c826c93b4100f2e26b701286

Do you believe that this new alert id will flag such case?

[RCantu92]

Hey Ivo, as it stands, the bot wouldn't flag that instance nor would the update I'm currently working on address this particular case. The edge case I'm covering is to sort of "extend" the bot's current functionality, rather than really altering it.

From my quick look into the Seneca exploit, the attacker called the vulnerable Seneca contract, which then allowed it to call the underlying token contract. Then a transferFrom was executed from the users that had approved the Seneca contract to the attacker.

Some things to note:

• When it comes to token transfers, the bot focuses on high market cap tokens, and the tokens listed in the rekt.news article don't seem to fit that criteria. The bot was built to monitor for the top 100 tokens on Coingecko.
• It probably wouldn't have worked for the Arbitrum transactions because in this case, we'd need to monitor the transaction traces, since the transactions were sent to the Seneca contracts rather than the token contract itself. (Arbitrum doesn't have trace support).
• The bot focuses on filtering for transfer() function calls rather than transferFrom() function calls. That is because transferFrom() are more catered for contracts transferring tokens on behalf of users who gave them approvals, which is what happened.
• Lastly, while the article states that a lot of ETH was stolen, what was actually transferred were tokens like 0xB05cABCd99cf9a73b19805edefC5f67CA5d1895E and then swapped for ETH. Like was done in this transaction. So while the bot handles native ETH transfers as well, it didn't really come into play in this exploit.

[Ivan1905]

Okay, I see. This could fit somehow with the logic of the ice phishing bot, right? Wrong approval and then a transferFrom() - maybe some of this could be applied?

If there's no way we can leave this like an edge case and keep monitoring similar cases.

[RCantu92]

It would be more within the realm of the Ice Phishing (IP) bot rather than the Private Key Compromise (PKC) bot, yes.

And the Ice Phishing bot's README states "verified contracts with low number of transactions and emits an alert of lower severity", so it appears the bog should've flagged it. For example, this contract is verified but only has 60 txns, so it seems it should've fit the criteria and should be researched as to why it didn't.