Over the past months, we are very glad to see developers are paying more attention to security threats and best practices. Besides rigorous internal code reviews and external auditings, we are frequently asked by our customers: what we should do to keep our protocol safe once it's deployed on the chain. Indeed, we keep asking ourselves the same question too. We believe the on-chain monitoring could be the missing piece of the full lifecycle security.

Please don't get us wrong. The code reviews and auditings are still crucial to discover critical vulnerabilities before deployment. In fact, most attacks took advantage of missing proper account validations. Since it's relatively well known and targets security threats before deployment, we will skip this topic in this post.

When analyzing the steps in previous attacks, we made quite a few very exciting common observations that distinguish malicious attacks from normal transactions:

1. Use of the flash loan. For example, flash loans were used in CremaFinance and Nirvana attacks to amplify the damage. If a transaction contains large token transfers from any known flash loan instruction, abort it! In fact, Metaplex Candy machine has implemented an anti-bot defense based on transaction-wide info. Check out how does Metaplex candy machine work.
2. Involvement of new and arbitrary fake accounts. Attackers want to hide their cyber footprints and spend a lot of efforts to carefully prepare these accounts to facilitate attacks. As a result, these accounts are new and may be arbitrary.
3. Repeating cycles of attacking instructions. For example, if a transaction involves multiple round-trip trades such as deposit-claim-withdraw and/or there are multiple such transactions, it's a red flag.
4. Reasonably long processes that are usually in the span of a few hours. For example, in the wormhole attack, the time window between the tx which created the 1st fake sysvar account and the tx which completed the transfer spans six hours. Similarly, the hacker’s first fake account was created five days before the attacking transaction for CashioApp. For CremaFinance, the fake tick account was created more than one hour before the first attack. In the Nirvana attack, the time window between the two transactions (deploy flash loan receiver and call Solend flash loan) spans four minutes. So, if there is a service that could alert protocols, there may be a good chance some actions can be taken to mitigate the damages.

Inspired by those observations, we have been keeping our heads down and developing a monitoring service that can identify common attacking scenarios, learn from normal interactions, detect abnormal transactions, and alert/stop suspicious transitions.

Recently, we proudly announced sec3 WatchTower: Smart Monitor for Smart Contracts that provides pro-active and customizable monitoring services to detect several built-in attack scenarios as well as extendable abnormal transactions. We hope the sec3 WatchTower could contribute to post-deployment security and provide developers some peace of mind.

About sec3 (Formerly Soteria)

sec3 is a security research firm that prepares Solana projects for millions of users. sec3’s Launch Audit is a rigorous, researcher-led code examination that investigates and certifies mainnet-grade smart contracts; sec3’s continuous auditing software platform, X-ray, integrates with GitHub to progressively scan pull requests, helping projects fortify code before deployment; and sec3’s post-deployment security solution, WatchTower, ensures funds stay safe. sec3 is building technology-based scalable solutions for Web3 projects to ensure protocols stay safe as they scale.

To learn more about sec3, please visit https://www.sec3.dev

‍

‍