The Dark Side of Code Verification: How Attackers Are Exploiting Security Measures

The Web3 space is a constantly evolving landscape, where advancements in security are continuously met with more sophisticated attacks. Private transactions and batching operations have become standard tactics for attackers seeking to evade mempool monitoring tools.

In this ongoing cat-and-mouse game, attackers previously hardcoded victims' contract addresses directly into their malicious code, making detection easier for automated tools. However, they have now adopted a more sophisticated approach, dynamically passing the victim’s address in the attacking transactions without revealing it beforehand.

In this blog post, we’ll highlight a new and counterintuitive “hiding-in-plain-sight” technique that attackers are using to execute their hacks more effectively.

Verified Attacks: A Case of Deception

Let's explore two recent attacks:

• The 2023 Shido attack — approximately $238K in damage
• The 2024 Curio attack — $16M in damage

These are two distinct cases, but they share a surprising commonality. If you visit the block explorer pages for their respective contracts, you'll find something interesting:

• Shido attacking contract: Link to BscScan
• Curio attacking contract: Link to Etherscan

Take a look at the "Contract" tab. Notice anything strange? Both attacking contracts are verified!

This seemingly counterintuitive move relies on a key aspect of security automation—the assumption that verified contracts are less likely to be malicious. As a result, some security vendors assign a lower risk score to transactions involving verified contracts, making it easier for attackers to fly under the radar.

‍

This counterintuitive tactic exploits a common belief of many security vendors. Their assumption is that hackers will not publicly expose their code and therefore verified contracts are less likely to be malicious. As a result, some security vendors assign higher risk scores to unverified contracts, and lower risk scores to transactions involving verified contracts.

Why Verify the Attack Contract?

Why would an attacker risk revealing their "secret sauce" and losing their advantage? The answer lies in the power of verification. Verification acts as a badge of legitimacy, signaling that a contract has been scrutinized to some extent. By exploiting this perception, attackers can manipulate automated security systems. Transactions involving verified contracts are more likely to bypass detection tools, giving attackers a significant edge.

The Attacker's Playbook

‍

‍

Here’s a glimpse into a potential attacker’s strategy:

1. Deploy the attacking contract (initially unverified).
2. Just before launching the attack, verify the contract. Block explorers offering verification services, such as Etherscan, often don't provide complete metadata (e.g., full timestamp) for the verification.
3. Execute the attack via a private transaction, minimizing the risk of pre-attack detection.

This approach, as mentioned earlier, reduces the likelihood of being flagged by security monitoring services.

Security in the Face of Deception

This evolving tactic highlights the necessity of a more comprehensive security strategy:

1. Enhanced Verification Data: Collaboration with block explorers, like Etherscan, is crucial to provide more detailed information about the verification process, including the verifier’s identity and, importantly, the verification timestamp. This enriched data can greatly improve the effectiveness of automated tools and support more thorough security research and post-mortem analysis.
2. Beyond Verification: Relying solely on static metadata, such as contract verification status, sender addresses, or wallet information, is insufficient. A robust security approach must focus on in-depth transaction behavior analysis to detect and prevent malicious activities, even when attackers use deceptive tactics.

‍