Compromised Front Ends: When the Real Site Attacks You

The advice to check the domain assumes the danger is a fake site. Sometimes the danger is the real one.

How it happens

DNS hijacking. An attacker gains access to the domain registrar account and points the domain at their own server. The address bar shows the correct domain and the certificate may even be valid.

Compromised hosting. The files served from the legitimate infrastructure are replaced.

Malicious dependency. A JavaScript library the site loads is compromised upstream. The site’s own code is untouched and the behaviour changes anyway.

Insider or credential compromise. Someone with deployment access pushes malicious code.

The third category is the most insidious because the project’s own repository looks clean.

What the user sees

Nothing. The correct domain, the expected interface, the usual flow.

The only difference is that a transaction or signature request is constructed to send funds to an attacker rather than to the protocol.

If the user is verifying the domain, they pass. If they are checking whether the project is legitimate, they pass. The checks that catch ordinary phishing all pass.

What actually helps

Transaction simulation. The wallet shows expected balance changes before signing. A request that would transfer assets to an unfamiliar address rather than interact with the expected contract shows up here regardless of how the page looked.

This is the single most effective defence against this category and it is available in several wallets.

Reading the destination contract. The request names a contract address. Comparing it against the address in the project’s documentation catches a substituted target.

Few people do this and it is the check that works.

A separate wallet. The structural defence again. If the connecting wallet holds a small balance, a compromised front end takes a small balance.

Waiting during incidents. Projects announce compromises, frequently within minutes. Not being the first to interact after an unexplained interface change costs nothing.

What does not help

Checking the domain. Correct by definition.

Checking the project’s reputation. Legitimate projects have been compromised.

Bookmarking the site. The bookmark goes to the compromised page too.

Certificate checks. A hijacked domain can obtain a valid certificate.

The pattern in incidents

The compromise is typically detected within hours by users reporting unexpected transactions, and the project posts a warning.

The window is short and the losses in it are concentrated, because the attack targets exactly the users who interact most.

The structural conclusion

This is the attack that demonstrates why vigilance is insufficient as a strategy.

Every behavioural defence assumes you can distinguish a malicious context from a legitimate one. Here you cannot, because the context is legitimate.

What remains is limiting what any single signature can reach. A small balance in the connecting wallet, long-term holdings in a wallet that never connects, and the working balance at a licensed exchange with a published address where no signature can reach it at all.