The .fi Files: A Field Report on DNS Hijacking in DeFi
Cow.fi, Steakhouse, HypurrFi, Neutrl. Four protocols. Four DNS hijacks. A few weeks apart. A field report on the campaign nobody wants to call a campaign.
when did we stop calling this a campaign?
Cow.fi got hijacked. DNS level. Registrar compromise, almost certainly.
Same thing that happened to Steakhouse.
Same thing that happened to HypurrFi.
Same thing that happened to Neutrl.
Four DeFi protocols. Four .fi domains.
All hit inside a few weeks.
All through infrastructure takeover, not code exploitation.
At what point do we stop calling these coincidences?
Detection caught cow.fi serving an iframe shell — no application, no interface, just a hollow page loading whatever the attacker wanted. Fresh TLS certificate issued the same day against a domain that’s been live for years.
The smart contracts are fine.
The frontend code is fine.
The team did nothing wrong technically.
Somebody convinced a human at a registrar they were somebody else.
That was enough.
Guardix.io – AI-Powered Security Audits for Solidity Smart Contracts
Most audit firms take weeks. guardix delivers a full security report in under 60 minutes.
30+ specialized AI agents scan your contracts across 14 vulnerability classes. every finding is cross-validated across multiple models and backed by a working exploit, auto-tested on a forked chain via foundry. no theoretical maybes just issues proven to be exploitable.
59.8% recall across 117 high-severity EVMBench vulnerabilities.
field report: we lived this attack chain
An email arrives from our registrar’s abuse department. They’ve approved a request to change the email on our account to contact@<similar-domain>.
A domain we don’t own.
A request we never made.
We caught it within 30 seconds of receipt. Counter-moves initiated simultaneously:
Emailed the attacker’s domain registrar to report abuse and block their SMTP.
Pulled out a laptop in a shopping mall, sat on the floor, logged in, enabled every MFA form available.
Called the registrar directly. Demanded account lock.
10 minutes later, the account was locked.
We ran dig NS <domain> +short on loop the entire week it was locked — watching for any nameserver change that shouldn’t exist. Threatened an ICANN complaint.
Told users to migrate to an alternate domain if the lock wasn’t lifted. Account unlocked within minutes.
Everything is now on AWS Route 53.
What the attacker was actually doing?
Classic account takeover via email change. O
nce the email on file is replaced with one they control, password resets are trivial. Full account ownership follows — nameserver changes, DNS redirect, cert issuance, frontend replacement.
The whole chain executes before anyone notices.
The attacker registered a domain visually similar to ours. Looks legitimate to a support agent.
If the change goes through, future registrar communications go to the attacker with zero visible indication anything is wrong.
Protecting Crypto Domains and Infra: A Guide to Defending Against DNS Hijacking and BGP Attacks, good read to check out from Vladimir.
breaking down the attacker’s methodology
This isn’t script-kiddie activity.
There’s operational methodology. Four techniques extracted from the confirmed incidents.
TTP-1 — Registrar social engineering via email change
Bypass credentials entirely. Go straight to registrar support. Request email account change using OSINT + a convincing story + a receiving domain that looks plausible.
TTP-2 — Time-based rapid execution
Not slow, weeks-ahead planning. Rapid exploitation of an open window. Suggests automation supporting the SE layer, or multiple targets worked simultaneously.
TTP-3 — Registrar as the weak link
The registrar approved the request before notifying the account holder. If you’re slower than 30 minutes, it’s already done. Procedural failure, systematically exploited.
TTP-4 — Consistent initial access across all .fi incidents
Cow.fi, Steakhouse, HypurrFi, Neutrl — same entry point. Convince a human at a registrar to make a change. The core move is identical.
This is a campaign & NOT a coincidence..!!
four-for-four. no code exploits. all frontend.
if your DeFi protocol operates on a .fi domain, your risk profile right now is meaningfully higher than equivalent protocols on other TLDs.
the targeting may not remain .fi-exclusive for long
the certificate freshness signal
CERT_FRESHLY_ISSUED on an established domain is one of the cleaner indicators we have for active takeover.
Domain-validated certs require proof of DNS control, not proof of identity. If you control the nameservers, you pass DV checks automatically.
Let’s Encrypt issues in seconds once validation clears.
Certificate Transparency logs make this detectable in near-real-time if you’re watching. Almost nobody in DeFi is watching this properly.
The cow.fi cert should have triggered an alert before a single user saw that iframe.
The signals exist before the damage propagates.
what to actually do about this
→ Move to enterprise-grade DNS. Now.
AWS Route 53, Cloudflare, or equivalent. The difference isn’t marginal — it’s the gap between social-engineering a support ticket and needing to compromise your AWS account with MFA hardware keys.
→ Registrar hygiene is ground zero.
TOTP or hardware key 2FA — not SMS. Dedicated registration email. Registry lock enabled if supported. Budget registrar? Migration cost is noise compared to hijack cost.
→ Split DNS from your registrar.
Single point of failure otherwise. Two accounts = two separate compromises required.
→ Implement DNSSEC.
Cryptographic signing of DNS records. Supported on .fi. Directly addresses this vulnerability class. No excuse.
→ Monitor signals that fire before damage propagates.
CT log watching for unexpected cert issuance. WHOIS change detection. Nameserver modification alerts. Continuous domain integrity verification.
This is what DigiBastion does
→ Pre-build your domain hijacking playbook.
Pre-establish security contacts at your registrar’s security team. Pre-authorize emergency transfer procedures. Have a trusted fallback domain ready.
The middle of an incident is not when you want to figure this out.
PSA #1 — On enterprise DNS
We moved everything to AWS Route 53 after living through this attack. If you’re not on enterprise-grade DNS, fix that this week.
Not eventually. This week.
PSA #2 — On wallet authorization prompts
If you log into a website with your wallet, read the authorization prompt every time. ConnectWallet flows are becoming attack surfaces. Most users click through like it’s a cookie notice.
Stop doing that.
did we spent five years getting good at the wrong thing?
Audits, formal verification, bug bounties, immutable proxies, timelocks. The ecosystem solved hard problems.
Then someone called a registrar, pretended to be the domain owner, changed a nameserver and none of that mattered.
The attack surface was always there. did nobody took it seriously because it wasn’t interesting enough? Smart contract exploits are intellectually challenging.
Social-engineering a support agent is NOT.
whether this becomes a watershed moment depends on whether the response is individual teams locking individual doors, or whether the ecosystem develops normative pressure around infrastructure security matching what it developed around contract security.
one of those scales. the other is whack-a-mole until the attackers get bored.
DigiBastion provides continuous domain security and frontend integrity monitoring for Web3 protocols. Catch the signal before the damage spreads — digibastion.com
Built by @__Raiders · web3sec.news