Steakhouse Frontend Hijack: DeFi’s Real Attack Surface

Steakhouse frontend hijack was not a smart-contract exploit, and that is exactly why it matters. On March 30, Steakhouse Financial warned users not to interact with its app or website after identifying a phishing attack on its domain, while stressing that deposits were safe and contracts were unaffected.

Steakhouse said the danger lived in the interface, not the vaults

The official Steakhouse warning, surfaced in search results from the project’s X account, told users: “Do not interact with the Steakhouse app until further notice,” adding that the issue affected both the app and website domain, while “no deposits are at risk” and “no contracts are affected.” TheStreet’s reporting matched that framing and said the problem was limited to the frontend, meaning the immediate danger was that users could be tricked into signing malicious transactions rather than having funds drained directly from protocol contracts.

That distinction is not cosmetic. It changes the risk model from “protocol code failed” to “the trusted doorway into the protocol was replaced.” In a contract exploit, users often lose funds because protocol logic misprices, misaccounts, or misroutes value. In a frontend hijack, users lose funds because they are lured into authorizing the theft themselves through a malicious interface that looks like the legitimate one. Steakhouse’s message that existing depositors were safe is therefore credible and incomplete at the same time: safe in-contract does not mean safe to click.

Steakhouse’s official warning

The malicious site looked like Steakhouse because DNS, not Solidity, was compromised

Later reporting that summarized a follow-up Steakhouse update described the attack more specifically. PANews, as republished by MEXC and mirrored by other outlets, said Steakhouse told users the incident stemmed from a phone-based social-engineering attack against OVH Cloud. According to that summary, the attacker gained sensitive access to the project’s domain management, changed the DNS A records for both the main website and the app subdomain to point at a malicious IP address, and also attempted to initiate a five-day domain transfer.

That is the core technical point of the incident. Users do not need a protocol’s contracts to be broken in order to be in danger. They only need the domain-resolution layer to be pointed at the wrong server. Once the A records are changed, a wallet connection flow that used to be safe can become a drainer prompt wearing the same brand, colors, and URL that users already trust. OVH’s own documentation on DNS explains how records map a domain to an IP address; if an attacker controls those records, they control where users land.

TheStreet’s report on the phishing incident

Blockaid’s drainer attribution shows how industrialized frontend phishing has become

TheStreet reported that Blockaid detected the compromise and said the malicious site contained code linked to the “Angerferno drainer.” Blockaid’s own X post, captured in web search results, said its system had identified a front-end attack on steakhouse[.]financial and that the site contained Angerferno drainer code. The same reporting said the attack mainly threatened new interactions with the interface, rather than funds already sitting in vault contracts.

That attribution matters because it suggests Steakhouse was not hit by a one-off improvised scam page. It appears to have been plugged into a known wallet-drainer operation. In practical terms, that means the attackers did not need to write original exploit code for this target. They only needed a believable domain, a cloned interface, and a battle-tested drainer package ready to turn signed approvals into stolen assets. This is where DeFi attack surface has shifted: away from only protocol math and toward reusable phishing infrastructure layered on top of trustworthy-looking interfaces.

It also explains why no confirmed public loss tally was available at the time of disclosure. Steakhouse framed the event as an active phishing incident, not a completed drain with a known victim set. TheStreet did not report any verified on-chain losses, and the project’s warning was preventative rather than post-mortem. That is the right editorial frame here: live risk, not yet a confirmed loss ledger.

The real story is that DeFi risk now sits in registrars, DNS panels, and support desks

The value-add in this incident is not another reminder to “be careful.” It is that Steakhouse’s contracts stayed safe while the soft tissue around the protocol failed. A phone-based social-engineering attack against a cloud or registrar support path is a very different class of weakness from a reentrancy bug, but to an end user the result can be just as dangerous. If the trusted route to a vault becomes a drainer, the protocol’s immaculate contract security does not help the person signing the wrong transaction.

This is why DeFi teams need to stop treating frontend and domain security as operational side quests. DNS change controls, registrar lock policies, out-of-band verification for account recovery, transfer locks, hardware-bound admin access, and emergency domain freezes are part of protocol security now. The PANews summary of Steakhouse’s update said the attacker not only changed A records but also attempted a domain transfer. That is not a random nuisance. It is a takeover chain aimed at persistence.

The incident also shows why “contracts unaffected” is only half a reassurance. It tells depositors their existing positions are not under direct protocol threat. It does not solve the user-trust problem created when the official domain can no longer be trusted. In a wallet-based system, interface trust is part of custody, because a malicious prompt can manufacture the user’s consent to theft.

PANews summary of Steakhouse’s later update

What DeFi teams should change after Steakhouse

Steakhouse’s later update, as summarized by PANews, said the malicious DNS changes had been reversed, records cleared, and the team was working with OVH to resolve the incident. The same summary said vaults remained accessible directly through Morpho and that deposits, withdrawals, and vault functions continued to work normally while the frontend stayed offline. That is a useful emergency pattern: keep the contracts available through trusted alternate interfaces, but tell users not to trust the compromised domain until it is fully restored.

The more durable fixes are procedural. Projects should require registrar and DNS accounts to use hardware-backed authentication, domain-transfer locks, documented callback-verification protocols with providers, and immediate monitoring for DNS record changes. Security teams should also plan for frontend compromise as a standard incident type, with prewritten user alerts, alternate safe access routes, and wallet-security partners ready to flag malicious code fast. Blockaid’s involvement here suggests that front-end detection and drainer fingerprinting are now as relevant to DeFi defense as contract monitoring.

The next technical signal to watch is Steakhouse’s promised post-incident report. That report should matter more than the initial warning because it can show whether the team now treats DNS and support-desk security as first-class protocol controls. Steakhouse’s contracts may have survived untouched, but the incident proved something more uncomfortable: in 2026, some of the most dangerous DeFi attacks do not break the vault. They hijack the sign-in screen.

Blockaid’s warning on X