A dozen DeFi websites hijacked in coordinated domain attack
Hackers took control of roughly a dozen decentralised-finance websites and made off with approximately $138,000 in cryptocurrency, in an incident that appears to have exploited a weakness at a single point of the ecosystem’s infrastructure rather than flaws in the protocols themselves.
The affected sites, according to reporting from The Block, were all registered through the same domain registrar, Name.com. That detail has become the central clue for investigators and security researchers. It suggests the attackers did not need to break each DeFi project individually. Instead, they may have found a way through a shared domain-management or hosting process, gaining control of the front ends that users depend on to connect wallets and approve transactions.
The losses are modest by the standards of recent crypto exploits, where nine-figure breaches have become almost routine. But security professionals and market observers say the method matters far more than the headline number. A single compromised website can target every visitor who lands on it, including users who believe they are interacting with a legitimate, audited DeFi brand.
Why front-end compromises are so dangerous
The attack worked at the interface layer, not the settlement layer. The underlying smart contracts of the affected protocols may not have been breached at all. That distinction is critical for understanding both how the theft occurred and why it is difficult to guard against.
When a user interacts with a DeFi application, the website’s front end is what translates their intentions into transactions. It determines which contract addresses users are prompted to approve, which tokens they are asked to sign for, and where funds ultimately move. If attackers alter the code running on that interface, they can quietly redirect users toward unauthorised transactions without the user ever noticing anything amiss.
The victim sees a familiar website. They connect their wallet in the usual way. They approve what appears to be a routine transaction. The blockchain then does exactly what the malicious instructions told it to do, and the funds are gone. From the perspective of the smart contract, nothing irregular happened: the correct private key signed a valid transaction.
This is what makes front-end compromise so corrosive to trust in the sector. A protocol can pass every audit, hold reserves in multisignature wallets, and publish extensive security documentation, and still lose user funds because the website serving its users was hijacked. The attack surface extends well beyond the chain itself into the browser.
For more on how these incidents ripple through the sector, see our DeFi coverage.
The Name.com connection and the centralisation problem
The shared registrar is the most significant clue in the case. If a single compromised account, leaked credential set, or flaw in an administrative process at Name.com allowed attackers to reach multiple client domains at once, the incident becomes a case study in how concentrated infrastructure undermines the decentralised ideal.
DeFi applications, for all their architectural ambitions, rely heavily on centralised services. Domain registrars assign and control the names users type into their browsers. Cloud providers host much of the front-end code. Content-delivery networks serve it globally. Wallet interfaces, browser extensions and RPC gateways mediate every interaction with the chain. Each of these is a potential single point of failure sitting directly in the path between a user and their funds.
This is not a new concern, but it is one the industry has been slow to address. Previous incidents have shown similar patterns: attackers compromising hosting providers, exploiting DNS vulnerabilities, or targeting the credentials of individual developers with administrative access. The lesson repeated each time is that decentralisation at the settlement layer does not eliminate centralised dependencies at the access layer.
A registrar breach is particularly damaging because it is invisible until it is not. Users have no easy way to verify that the website they are visiting is serving the code its developers intended. Browsers display the correct domain name. TLS certificates appear valid. Everything looks right, because from a DNS perspective everything is right. The attacker simply controls what that correct-looking address serves.
Name.com’s role in the incident raises questions the registrar will need to answer. Was this a breach of a single customer account that happened to control many DeFi domains? A flaw in a reseller or administrative process? Or something more systemic? Until those questions are resolved, other projects registered through the same provider should treat their front ends as potentially at risk and review their own domain security posture, including registry locks, transfer restrictions and access logging.
Practical defences for users and projects
For individual users, the incident reinforces a set of precautions that security researchers have long recommended and that this case makes newly urgent.
First, the security of a project’s smart contracts is no longer sufficient assurance. Users have been trained to look for audit reports, bug bounty programmes and verified contract code. Those checks remain valuable, but they say nothing about whether the website in front of the contract has been tampered with. The domain administration and hosting layer deserves the same scrutiny as the chain.
Second, transaction approval is the moment of highest risk. Users should avoid signing unexpected wallet prompts, particularly those that appear without a clear reason. An approval request that arrives unprompted, or that asks for permissions the user did not initiate, should be treated as a potential sign of compromise. Sudden changes to a familiar website, unusual urgency in interface messaging, or approval requests that deviate from past behaviour all warrant stopping and verifying through alternative channels.
Third, tooling can help. Transaction simulation features and wallet warning systems, where available, can surface what a signature will actually do before it is executed. These are not foolproof, and sophisticated attacks can be crafted to evade casual inspection, but they meaningfully raise the cost and difficulty of front-end phishing campaigns.
Fourth, verification culture matters. Checking domains character by character, bookmarking known-good URLs rather than following links, and confirming unusual requests through a project’s official social channels are habits that cost seconds and prevent losses.
For projects, the obligations run deeper. Registry locks at the domain level prevent unauthorised transfers. Multi-factor authentication and access controls on registrar accounts limit the blast radius of credential theft. Regular audits of front-end code, integrity monitoring to detect unauthorised changes, and communication plans for alerting users when compromise is detected all reduce both the likelihood and the impact of an incident of this kind.
The economics also matter for the broader market. The $138,000 taken here is small, but the technique scales. An attacker who compromises a registrar account controlling a dozen DeFi front ends could, in principle, drain far more if a major protocol’s interface were among the affected domains during a high-traffic period. Insurers and risk desks pricing DeFi exposure already distinguish between smart-contract risk and operational risk; this incident is evidence that the second category deserves a larger share of attention.
Assessment
This attack will not register as a major loss in quarterly figures. It should nonetheless prompt a rethink in how both users and projects conceptualise security in decentralised finance. The industry has spent years and enormous sums auditing smart contracts, and attackers have responded by simply moving upstream to the infrastructure that surrounds them. Registrars, hosts and interfaces are now demonstrably part of the attack surface.
The deeper issue is structural. DeFi’s promise rests on removing trusted intermediaries from the settlement of value. Yet the typical user reaches the protocol through a chain of entirely centralised services, each of which must be trusted, each of which can fail. Until projects invest in front-end security with the same seriousness they bring to contract audits, and until users internalise that the address bar is as important as the audit report, incidents like this one will keep recurring. The decentralised settlement layer worked exactly as designed. Everything around it did not.
