What happened

Blockaid's monitoring detected a front-end attack on swap.cow.fi and warned users with connected wallets to revoke approvals immediately. CoW DAO confirmed at around 16:24 UTC, told users to stay off the domain, and suspended protocol services as a precaution; Aave temporarily disabled its CoW Swap integration. CoW later reported that the anomaly had been detected within 19 minutes and an emergency response triggered.

The post-mortem is the useful part. This was not a compromised server, a leaked credential or a vulnerable dependency. The attackers manipulated the .fi registration process, using forged identity documents, to take over the cow.fi domain and change its DNS records. With DNS pointed at their infrastructure, they served a clone of the real interface and harvested transaction approvals. Nothing behind the domain needed to be touched.

Restoring the original domain took about 26 hours. CoW moved users to cow.finance in the interim, applied a registry lock to the reinstated cow.fi, commissioned an external audit, started legal proceedings and began work on a compensation plan.

Why it matters if you run public infrastructure

Your domain is the root of trust for everything you serve, and it is administered by a third party whose account-recovery and transfer processes you did not design. A registrar or registry that can be talked into a transfer by a convincing document is a vulnerability in every system that hangs off that name, no matter how well those systems are secured. The DeFi angle made this one expensive quickly, but the mechanism applies to a SaaS login page, a payment portal or a corporate mail domain in exactly the same way.

The other lesson is about detection. CoW was found out by a third party watching the front end, within minutes. Most organizations would have found out from a customer, hours later. The signals that a hijack like this produces are external and visible to anyone looking:

  • Name servers or A records change at the apex or on a critical host, outside any change you made.
  • A new certificate appears in certificate transparency for your hostname, from a CA you do not use. The attacker needs valid TLS for the clone to look right, and public CAs issue against DNS control, which the attacker now has. This is often the very first artifact, minutes before the redirect goes live.
  • The served certificate and page change on a host whose deploy pipeline did not run.

What to check this week

  1. Put a registry lock on every domain that matters. Not the registrar's "transfer lock" checkbox; the registry-level lock that requires out-of-band verification before name servers change. CoW added one after. Add yours before.
  2. Audit who can change DNS and how they authenticate. Registrar and DNS provider accounts should have hardware MFA, a monitored recovery email, and no shared logins.
  3. Publish CAA records so a certificate from an unexpected CA is a visible policy violation. It will not stop an attacker who controls DNS (they can change the CAA record too), but the change itself becomes a signal.
  4. Watch your apex and critical hosts from outside for NS, A and CNAME changes and for new certificates, with alerts to a channel that is read at weekends. The .fi hijack happened on a Tuesday afternoon; the next one may not.

How Attack Surface Scan covers this

Attack Surface Scan monitors DNS for every verified domain and records changes to NS, A, AAAA, CNAME, MX and CAA records as entries in the change feed with before-and-after evidence. Certificate transparency is read every 15 minutes, and any certificate for your hostnames from an issuer that is not on your authorized-CA list goes to the unknown-certificate queue and raises an alert, which in a case like this fires before the clone is live. Served-certificate probes catch the moment a host starts presenting a certificate that does not match what your pipeline deployed. None of this prevents a registrar being fooled; it shortens the 90 minutes to something closer to Blockaid's 19.

Sources