The Evolving Threat: How Attackers Exploit Verification in Smart Contract Attacks

The web3 space is a dynamic landscape, where advancements in security practices are constantly met with increasingly sophisticated attacks. The usage of private transactions or batching operations is now the standard MO for attackers in the Web3 space.

Here is another example of such an advancement in this cat and mouse game: in the past, attackers often hardcoded the victim contract’s address directly into their attacking code.

This made detection by automated tools a breeze. Today, however, attackers are adopting a more nuanced approach. In this blog post, we want to draw your attention to a new and counter-intuitive “hiding-in-plain-sight” technique, that attackers started to using to execute their hacks successfully.

Verified Attacks: A Case of Deception

Let's explore two recent attacks:

• The Shido attack -  a small (approx. $238,000) hack in 2023
• The Curio attack - a more recent and substantial ($16M) hack in March 2024

These are 2 different attacks, but what they share in common can be found on the respective block explorer pages of their attacking contracts:

• The Shido attacking contract - https://bscscan.com/address/0xcdb3d057ca0cfdf630baf3f90e9045ddeb9ea4cc#code

• The Curio attacking contract - https://etherscan.io/address/0x1e791527aea32cddbd7ceb7f04612db536816545

Look at the contract tab. Do you see something strange? Both attacking contracts are verified! In both instances, the attackers deployed verified contracts to launch their assaults.

This seemingly counterintuitive move hinges on a critical aspect of security automation – the assumption that a verified contract is less likely to be malicious.  

Security experts often build their tools to prioritize transactions involving (and particularly addressed to) unverified contracts.  

Similarly, simulation tools designed to catch suspicious transactions might assign a lower risk score to interactions with verified contracts.

Why Verify the Attack Contract?

So, why would an attacker expose their weapon?  The answer lies in the very nature of verification.  

One reason might be that verification serves as a badge of legitimacy, a signal that the contract has undergone some level of scrutiny.  

By exploiting this paradigm, attackers can manipulate automated security measures.

Transactions directed at a verified contract might fly under the radar of detection tools, granting the attacker a crucial advantage.

The Attacker's Playbook

‍

‍

Here's a glimpse into possible attacker's strategy:

1. Deploy the attacking contract (unverified initially)
2. Just before the attack, verify the contract: Today, block explorers that provide verification services (like Etherscan) do not necessarily provide complete metadata (e.g. full timestamp) about the verification
3. Launch the attack using a private transaction (minimizing pre-attack detection)

This playbook, as stated before, lowers the chances of detection by the security monitoring services.

Security in the Face of Deception

This evolving tactic underscores the need for a multi-faceted security approach:

• Enhanced Verification Data: Collaboration with block explorers (like Etherscan) to provide details about the verification process, including the verifier and especially the verification timestamp. This enriched data can significantly improve the effectiveness of automated tools and security research, including post-mortem analysis.
• Beyond Verification: Security cannot solely rely on static metadata like contract verification status, sender addresses, or wallet information. A robust security strategy must prioritize in-depth transaction behavior analysis to identify and thwart malicious activity regardless of deceptive tactics.

‍