Share article

Steakhouse's March 30 DNS hijack did not touch its vaults, but it did briefly put users in front of a cloned site with a wallet drainer. The probable catalyst was not a smart contract bug or private key leak, it was a registrar-level social engineering attack that let an attacker bypass hardware-backed 2FA and rewrite DNS. [1]
That distinction matters. This was an off-chain compromise with very real user risk, and Steakhouse's postmortem reads like a case study in how a single vendor can become the weakest link in an otherwise hardened crypto stack.

Enjoy articles without ads?

Register for free and get unlimited access to all articles.

How the attack happened

Steakhouse said the attacker targeted its domain registrar, OVHcloud, rather than the protocol itself. According to the postmortem, the threat actor impersonated the account owner and convinced a support agent to remove hardware-based two-factor authentication from the registrar account. [2]
Once that door opened, the rest moved fast. The attacker deleted existing security credentials, enrolled new authentication devices, and changed DNS records to point traffic toward infrastructure they controlled. That let them serve a fake Steakhouse website designed to phish wallets through a drainer.

The malicious site was intermittently live for about four hours on March 30. Steakhouse said it identified the issue and publicly warned users within roughly 30 minutes of detection, a response window that likely helped limit damage. [3]

What was and was not compromised

The protocol said no user funds were confirmed lost and no malicious on-chain transactions were verified as a result of the incident. Its core claim is that the compromise stayed at the domain layer. [4]

That is a meaningful technical boundary. Steakhouse's vaults and smart contracts operate independently from the frontend, and the team said it does not hold admin keys that could directly access user deposits. In other words, the attacker got control over where users landed in a browser, not control over the contracts holding assets.

Still, "no confirmed loss" is not the same thing as "no risk." DNS hijacks are dangerous precisely because they exploit user trust in a legitimate domain. If a phishing page can convincingly mimic the real interface, the attack path shifts from contract exploit to wallet approval.

Why browser defenses mattered

Steakhouse credited wallet providers including MetaMask and Phantom for flagging the phishing site quickly. That matters because modern wallet warning systems are increasingly serving as the last line of defense when frontends are compromised. [5]

Those protections are not perfect, and they are often reactive, but in this case they appear to have reduced the blast radius. For users, that is a reminder that wallet warnings should not be treated as background noise.

The real failure was vendor trust

The sharpest point in Steakhouse's postmortem is not about the attacker's toolkit. It is about security assumptions. The team said it had effectively treated the registrar as trustworthy infrastructure, even though support processes could override hardware-key protections.

That is the uncomfortable takeaway. A hardware key is only as strong as the recovery and support workflow behind it. If a phone call or support ticket can disable 2FA without strict out-of-band verification, then the "strong authentication" story breaks at the human layer.

Steakhouse described the registrar as a single point of failure, and that label fits. Crypto teams often spend heavily on contract audits, multisigs, and key ceremonies, then leave domain control exposed to conventional Web2 support escalation risk. Attackers know this, and social engineering remains one of the cheapest ways to get high-impact access.

A familiar crypto threat, packaged differently

This incident also fits a broader pattern. More crypto attacks now mix low-tech access methods, such as impersonation or credential resets, with polished phishing infrastructure and drainer tooling. The source article noted signs consistent with drainer-as-a-service operations, which is increasingly standard in the ecosystem. [1]

That combination changes the threat model. Teams are not just defending code anymore. They are defending registrars, DNS providers, support desks, cloud dashboards, email accounts, and every identity recovery flow attached to them.
For users, the attack surface looks simple: click site, connect wallet, sign prompt. For attackers, the backend path is often much easier than breaking audited contracts.

Steakhouse's response

Following the incident, Steakhouse said it moved to a more secure registrar, rotated credentials, and added continuous DNS monitoring. It also introduced tighter domain management controls, including registrar-level locks and hardware key enforcement. [6]

Those are the right first moves, but the bigger fix is process design. Monitoring helps with detection. Registrar locks help with friction. Neither fully solves the problem if a provider's support organization can still be socially engineered into undoing those controls.

The more durable lesson is to map vendor override paths as part of the threat model. If a human support channel can reverse a security setting, that channel deserves the same scrutiny as any privileged signer.

Why It Matters

Steakhouse avoided the worst-case outcome, but the episode is still a clean warning for DeFi teams: strong on-chain architecture does not neutralize off-chain compromise. A frontend DNS hijack can become a wallet-draining event even when contracts, vaults, and admin keys remain untouched.

The key level here is not a token chart, it is trust in the domain. Steakhouse says funds were safe, warnings went out quickly, and no losses were confirmed. That supports the view that the incident was contained. What would invalidate that comfort is evidence of unnoticed wallet approvals, or proof that registrar-side controls remain reversible through weak support procedures.

For the industry, the takeaway is blunt. If your registrar can be talked into removing 2FA, your hardware key is not your moat.