A DNS attack rerouted Aerodrome's frontend to a drainer. ↓ Blockaid detected the compromise in real time and prevented ~$3.5M in theft.

On November 21, Aerodrome and Velodrome experienced a DNS attack that modified the SOA, NS, and A records for “aerodrome . finance” and “velodrome . finance”. The changes redirected both domains to a cloned frontend serving Eleven Drainer code.

Blockaid was the first to detect the compromise, report it to Aerodrome, and inform its Customer Data Network, based on the UTC timeline below: → 20:11 DNS records changed, redirecting both domains to a spoofed UI → 21:31 Blockaid detects malicious transactions across its customer network → 21:32 Blockaid classified the domain as malicious across its customer network → 22:07 First Aerodrome user report arrives, pointing to malicious code on the domain → 22:40 Nameservers are replaced as remediation begins

A great example of Blockaid’s Customer Data Network effect: Once the domain was classified as malicious, partnered wallets, including @MetaMask, @coinbase, @Ledger, @Trezor, @rainbowdotme, and @FireblocksHQ, immediately surfaced warnings to users engaging with @AerodromeFi.

During the incident, Blockaid surfaced early warnings to 408 end users connecting their wallet to Aerodrome’s frontend and another 491 end users actively signing transactions, preventing roughly $3.5M in funds from being drained. Blockaid traced the attacker’s onchain behavior, identifying nine addresses tied to $700K in stolen funds. These losses came from wallet end users outside of our network, who we could not inform.

Incidents like this show how much risk lives outside the protocol. Frontend and DNS layers need the same level of detection and protection.