The Web3 ecosystem is well aware that security is pivotal for the overall success of the industry. Despite smart contract auditors working around the clock, hacks still occur on a weekly basis. Security requires a comprehensive security approach that spans from audits, bug bounties, all the way to monitoring and incident response.
Establishing security monitoring, however, requires a tremendous amount of expertise and can present friction to one’s comprehensive security approach. Over the last two months, the Forta community has invested in lowering that friction by introducing easy-to-use Forta Threat Detection Kits for DeFi, NFT, Stable Coins, Bridges and Governance. Protocols simply need to subscribe to these alerts to see an immediate security value add.
Forta is a real-time detection network for security & operational monitoring of blockchain activity. Forta’s mission is to monitor all transactions and protect all assets in Web3 and fulfill protocol’s security monitoring needs.
Overview
This blog post introduces the Threat Detection Kits in more detail and how they complement custom detection bots. For more details on the Threat Detection Kits, please refer to the Threat Detection Kit Documentation.
At a high level, these kits identify generic attack behavior when the condition is generic; but when there is the need for some specific configuration like a specific token or contract address, function or event signature, the threat detection kits also exist as easily configurable templates that can be deployed by the protocol without any development efforts.
Threat detection kits, however, are not comprehensive and not a replacement for custom detection bot development as there may be specific attack conditions associated with a protocol that the bots in the detection kits will not be able to cover. In those cases, a detection bot can be developed with ease utilizing the Forta Javascript/Typescript or Python SDK to get comprehensive coverage on your protocol.
Attack Stages
Threat Detection Kits have been developed and curated by the Forta community analyzing dozens of past attacks extracting repeatedly observed attack behavior. Attack behavior, as previously introduced, usually follows four distinct stages:
– Funding: an attacker first needs to obtain funds; these are needed to acquire digital assets used in the attack, manipulate prices, pay for gas, etc.
– Preparation: often an attack needs to be prepared. This could be tricking users into granting ERC-20 approvals in case of an ice phishing attack, deploying an attack contract to facilitate a reentrancy attack, etc.
– Exploitation: in this stage, the attacker actually drains the funds from smart contracts or users. The approaches in this stage are broad and can range from logic bugs, flash loans, reentrancy attacks, etc.
– Money Laundering: once the funds have been obtained with the previous stage, an attacker proceeds to launder these funds so they can actually be used again turning to privacy oriented protocols.
Based on the type of protocol and specific attack behavior, relevant threat detection kits differ. For instance, the NFT Sleep Minting Bot is not relevant to Bridge protocols; Sneak Governance Proposal Bot is relevant to Governance protocols, but not to DeFi protocols. But while there are many generic attack behaviors that are protocol independent (e.g. Attacker Account Funded by Tornado Cash Bot), there are also threat detection kits curated to specific protocol types to ensure broad coverage of attacks.
One thing to keep in mind is that the threat landscape is continuously evolving and increasing in complexity. While the threat detection kits exist in v1.0 form today, they will need to evolve with the threat landscape.The Forta community is engaged in analyzing changes, gleaning insights, and applying those lessons to future versions of the threat detection kits. To join in the fight against increasingly sophisticated adversaries, join the discussions in Forta’s #threat-detection-kits Discord channel.
DeFi Threat Detection Kit
This section looks at the DeFi Threat Detection Kit in more detail highlighting specific detection bot examples.
As mentioned in the previous section, the Threat Detection Kits are modeled after the four attack stages: Funding, Preparation, Exploitation, and Money Laundering. In each stage, a set of generic detection bots and detection bot templates can be found that identify the underlying generic attack behavior. Some bots detect attack behavior across each attack stage. For instance, the Known Exploiter Address Transaction Bot alerts on each transaction from that account which could map to the funding, preparation, exploitation, or money laundering stages.
The DeFi Threat Detection Kit is shown above. Refer to the DeFi Threat Detection Kit documentation for a comprehensive description of each kit and bot. Next, let’s look at a few bots in more detail.
Tornado Cash Funded Account Interaction (Generic Bot)
The Tornado Cash Funded Account Interaction Bot (GitHub, deployed bot) alerts when an account funded by Tornado Cash is interacting with one’s protocol. While this can be a noisy bot as Tornado Cash funded accounts are not necessarily malicious, in recent attacks, most attacker accounts were initially funded by Tornado Cash. Given it is an alert that triggers in the first stage of the attack stages, this can represent an early opportunity to mitigate an attack. For example, the heads up from the alert may allow a protocol to activate a time lock on transactions exceeding a certain monetary value coming from those accounts.
Price Change Anomalies (Generic Bot)
The Price Change Anomaly Bot (GitHub, deployed bot) was developed by Vyacheslav Trushkov as part of a recent Forta bot development contest. It was designed to identify oracle price manipulation attacks at the exploitation stage, like the Inverse Finance attack (Ethereum block 14502359 to 14507132).
Described in a recent post on time series analysis, this detection bot monitors any critical price changes for all trading pools of all protocols that support the pool’s Uniswap-like ABI (at least 500+ pools on one Ethereum network). The price in each pool is analyzed using time series analysis to alert on statistically significant price changes taking into account history of a specific pool (e.g. a stablecoin would have much less volatility than a coin with little liquidity). It illustrates how a seemingly frequent event, like a price change, can be turned into an actionable alert.
Balance Decrease (Template)
The Balance Decrease Bot is a template (GitHub) developed by Nethermind detecting if the balance of a protocol decreases significantly or completely and emitting two different alerts for these two events of different severity. As the balance of a protocol may be dependent on what the protocol’s holdings, it is designed as a template to configure which contract’s balance to monitor. It has been verified on a series of transactions (e.g. tx 0x0fe2542079644e107cbf13690eb9c2c65963ccb79089ff96bfaf8dced2331c92 on token 0xd06527d5e56a3495252a528c4987003b712860ee).
Deploying a Template Bot
In order to deploy a template bot, execute the following steps:
1. Setup your development environment
2. Clone the repository
3. Modify the bot-config.json to the specific token address to monitor
5. Open the bot stats page and subscribe to the bot
6. Filter for alerts that pertain to your protocol based on the addresses field
Alert Combiner (Generic Bot)
The Alert Combiner Bot (GitHub, deployed bot) is a special bot that is bundled with the Threat Detection Kits that has no logic to identify attack behavior itself. Rather, it combines existing alerts that are consistent with the four attack stages and emits a highly precise alert when conditions are satisfied. This bot successfully detected the recent Inverse Finance attack, which was a flash loan assisted price manipulation attack.
Subscriptions
Bots contained in the threat detection kits are generic (e.g. the Ice Phishing Bot will alert on all Ice Phishing attacks), but through the subscription mechanism, one only obtains the alerts that pertain to the contract addresses specified in the subscription step. While certain bots may detect malicious activity on Forta generically, if they cannot be tied to a specific protocol, they are not included in the Threat Detection Kit (e.g. money laundering related bots as those bots detect money laundering, but don’t track the origin of those funds). One can still subscribe to those bots through the bot’s subscription page, but this monitoring method is likely going to lead to alerts that do not pertain to one’s specific protocol.
When subscribing to alerts, one may be presented with a series of noisy alerts. For example, the flashbot bot detects flashbot usage, which is common in MEV. If one’s protocol is subject to MEV, those alerts will be of little use, but for other protocols where MEV is very unusual, it may be indicative of an attack. It is suggested that when you subscribe to the kits to analyze each alert and decide what types of alerts are actionable, which need to be investigated, and which should be deemed as noise.
Alert fatigue is a common concern with monitoring solutions (both in Web3 as well as Web2) that can lead to security teams ignoring alerts altogether. It would be an unfortunate development to have received an actionable alert that could have prevented an attack, but having ignored it due to alert fatigue and how the alert was handled. If you find yourself overwhelmed and/or do not have the capacity to handle alerts, subscribe to the Alert Combiner Bot. As described above, it combines alerts from a broad range of detection bots to emit a highly precise alert.
Incident Response
All security relevant monitoring and the best alerts will be of no use unless they tie into a manual or automated incident response process. Alerts raised by threat detection kits need to be reviewed, triaged, and acted upon if they indicate an incident. The Forta community has developed an incident response process that is derived from FEMA’s National Incident Management System (NIMS). It is a standardized approach used by US government agencies for incident management that translates well into the cybersecurity space. The incident response process follows four distinct phases:
1. Preparation/ Incident Response Readiness
2. Triage and Incident Declaration
3. Response
4. Post Mortem
It is strongly recommended to define the incident response process alongside the monitoring approach. Stay tuned for more on incident response approaches that can be implemented together with Forta! If you are a protocol, investor, liquidity provider, or user, subscribe to the threat detection kits of the protocol and provide feedback on Forta’s #threat-detection-kits Discord channel. If you are a security researcher or developer, join the Forta Community in developing bots and suggest additions to the kits on the aforementioned channel.
Share post