fix
Menu

Detect Ongoing Attacks In Web3 With Free Tools

We present a method based on free tools that allows DeFi protocol owners to monitor their own protocols against web3 threats and attacks

5 min read
Table of contents

How hard is it to detect ongoing attacks on smart contracts and alert on time? Wouldn’t that require an expensive monitoring solution to gather and index the data, extract and analyze the various features, filter benign transactions and flag malicious activity?

It’s much simpler than it looks, thanks to publicly available free tools. In this blog post, we show how to monitor any protocol and detect ongoing attacks with minimal effort and budget, whether as a protocol owner or as a security researcher.

This blogpost is based on aggregated experience from experimenting and playing with multiple various free Web3 security tools.

We use Forta bots for monitoring, and Pessimistic Spotter for push notifications. Let the games begin:

Forta Bots for Alerting and Filtering

Step 1: Search for alerts from Forta’s ”attack-detector-feed” bot (combining alerts from various Forta bots)

Step 2: In order to verify a given alert on a specific EOA, search for appearances of it in other Forta bots. An EOA that appears in various other indicative Forta bots (like malicious-smart-contract-ml-v3 for example) is likely to be an attacker, and should be reviewed manually to confirm. otherwise, it's most probably not an attacker.

On a daily average, 40 alerts are raised by the attack-detector-feed bot (step 1) for the entire ecosystem. Filtering a specific protocol or a set of smart contracts results in significantly fewer alerts. Following step 2 takes around 15 minutes, after which we'll have to manually review the remaining alerts.

Let’s take a look at the attack-detector-feed bot alerts from July 30th:

July 30th attack-detector-feed alerts

As we review the results, we can see that many alerts are associated with tagged attackers, such as "JPEGd_69 exploiter1" (0x6Ec21…78538), "JPEGd_69 exploiter2" (0x172f6...21e60), "CurveFinance Exploiter1" (0x30fb9...47aee5), and "CurveFinance Exploiter2" (0xdce5d...5d7d8).

Let's take the alert on EOA 0x6Ec21…978538 for example and illustrate how we perform step 2:

Querying for EOA 0x6Ec21…978538 in Forta

We can see that this EOA appears under several suspicious categories, so it’s definitely a candidate for manual review.

Let’s look how a benign example looks like:

Choosing a random alert on July 30th alerts

Moving to step 2.

Querying the [0xbdbd4…e2120] EOA in Forta

We can quite easily see that there is no point in delving into this EOA further, since it is clearly a false positive.

Note that Forta’s free mode does not allow focused dedicated push notifications. We therefore use Pessimistic Spotter for push notifications, and whenever Pessimistic Spotter detects something suspicious, we use the free Forta bots to further investigate.

Pessimistic Spotter for Push Notifications

Pessimistic Spotter allows us to sign up for push notifications whenever someone deploys a suspicious contract associated with certain addresses. Pessimistic Spotter itself takes into account various parameters such as funds source, contract with selfdestruct, flash loans and much more. All we need to do is to register with the relevant contract and filter the alerts using free Forta bots as described above.

Using this method, we’ve been able to detect the ongoing attack on micDAO minutes before Certik tweeted, the ongoing attack on Onyx Protocol 50 seconds after the attacker’s contracts were deployed, and more.

Pessimistic Spotter notification screeshot

This method is obviously not fool-proof, but no security solution is. We believe it is definitely good enough and cost effective

Conclusion

It’s good to have the capability to monitor your own protocol and detect suspicious activity. But do remember - monitoring is like security cameras, by the time you see the alert, it's usually too late to stop an attacker, and it is not enough to secure a Web3 protocol. Alerts are usually retrospective, require 24/7 incident response, and bear centralization risks (who has the keys to act on alerts?). Securing a protocol and gaining trust requires a runtime preemptive approach that reverts malicious transactions before they’re finalized.

About the author

Maor Ovadia
Analyst at SphereX
Follow

Maor has many years of experience in software development, QA, cyber security and more. Before joining SphereX as an analyst, Maor served 10 years in the Israeli intelligence doing software development, QA, research and leading teams, and 4 years in Kayhut as R&D group leader and product management.

Continue your reading with these value-packed posts
Go back to blog