Skip to content

Phishing

Phishing replaces trusted context. The attacker does not need to defeat a signature algorithm if the user signs through a fake website, sends funds to a substituted address, or installs a wallet presented as an official update.

The interface is outside consensus

A blockchain verifies transaction syntax, signatures, balances, and contract rules. It does not verify the website that prepared the transaction or the story told to the signer. A valid transaction generated by a cloned interface is indistinguishable from one generated by the real application once both reach the network.

That gap supports several forms of phishing:

  • a lookalike domain copies a wallet, exchange, bridge, or mint;
  • a compromised social account posts a time-limited migration or claim link;
  • a search advertisement appears above the legitimate site;
  • a fake extension or mobile application imports a seed phrase;
  • clipboard malware replaces a destination address;
  • a poisoned address appears in transaction history so a user copies the familiar prefix and suffix;
  • a fake support account moves the conversation into direct messages and requests a secret or signature.

HTTPS confirms an encrypted connection to the domain in the address bar. It does not establish that the domain belongs to the intended project.

Connection is not the dangerous step

Connecting a wallet normally reveals accounts and chain information to the site. The consequential steps are signing messages, signing typed data, sending transactions, or disclosing recovery material. Interfaces often blur those boundaries with one sequence of dialogs. A user who expects a harmless login may approve a token allowance or a marketplace order instead.

Wallet software can reduce ambiguity by decoding calls, showing the contract address, identifying the spender, displaying token amounts in human units, and warning about unlimited approvals. Simulation can show predicted balance changes. Neither mechanism is complete. A simulation uses a particular state and model; a hostile contract may behave differently after state changes or when called by another path.

Verification habits that change the outcome

Bookmarks and independently verified project documentation reduce reliance on search results and direct messages. Address books reduce repeated copying. Hardware-wallet screens help only if the user reads and understands them. For high-value actions, verify the contract address and function through a second trusted source, then send a small transaction when the protocol permits it.

Organizations need controls that do not depend on one person noticing a visual defect. Separate transaction preparation from approval, require multiple signers for treasury actions, restrict admin calls to known targets, and rehearse compromise procedures. A multisig cannot help if every signer follows the same fake link and approves the same hostile transaction without independent verification.

After interaction with a phishing site

The response depends on what happened. Merely opening a page differs from connecting a wallet, signing a login message, granting an allowance, signing an off-chain order, sending a transaction, or entering a seed phrase. Review wallet activity and approvals from a trusted interface. Revoke unnecessary authority, cancel supported orders, move assets if keys or the seed were exposed, and preserve domains, transaction hashes, addresses, and screenshots for reporting.

Revocation is a new on-chain transaction. It cannot reverse transfers already executed, and it may race an attacker who still has usable authority.

Further reading

← Previous: Seed Phrase Theft · Back to Security · Next: Malicious Signatures →