Phishing is an impersonation attack designed to make a victim perform the attacker's work. The message may pretend to come from an exchange, wallet provider, colleague, token project, or search result. Its purpose is to move the victim into a controlled environment where they reveal credentials, install software, or authorize a transaction.
The best defense is not spotting poor grammar. Modern campaigns can copy branding, use convincing language, and react in real time. A stronger approach verifies four things independently: who sent the request, which exact domain or application receives the response, what action is being requested, and why the timing is unusually urgent.
What you will learn
- Trace a phishing attempt from initial contact to account or wallet takeover
- Distinguish credential phishing from malicious-signature and recovery-phrase attacks
- Apply verification steps that do not depend on the message being genuine
The attack begins with borrowed trust
Attackers first create a believable reason for action: an account freeze, security alert, airdrop, governance vote, support response, or invoice. They may deliver it through email, direct messages, advertisements, compromised social accounts, calendar invitations, or search results. The channel is only transportation; the attack succeeds when the context feels familiar enough to suppress verification.
A displayed sender name proves very little because email headers, social profiles, and contact labels can be imitated or compromised. Even a message inside a real conversation may be hostile if the other person's account was taken over. Verify sensitive requests through a separately established route, such as a bookmarked official site or a known phone number, never through contact details supplied in the suspicious message.
Credential relays defeat rushed authentication
A fake login page can forward a victim's username and password to the real service immediately. When the real service asks for a one-time authentication code, the fake page asks too, then relays that code before it expires. This adversary-in-the-middle method explains why a short-lived code is not complete protection against a convincing live phishing site.
Hardware security keys and passkeys can provide stronger phishing resistance when the service implements them correctly because authentication is bound to the legitimate website domain. They still do not make the whole session safe: malware, weak account recovery, stolen authenticated sessions, or a user approving an attacker's later withdrawal can create other paths to loss.
NIST SP 800-63-4 and its authentication volume, SP 800-63B-4, provide requirements for digital identity proofing, authentication, and federation for users interacting with government information systems over networks. Revision 4 states that manually entered one-time passwords are not phishing-resistant and identifies WebAuthn as an example of verifier-name binding. That scope makes the guidance useful for exchange and account authentication, but it does not define blockchain private-key custody, wallet seed backup, or the meaning of a smart-contract signature.
Build a repeatable verification pause
Phishing relies on speed, secrecy, reward, or fear. Interrupt that pressure with a fixed routine: do not use the supplied link; navigate independently; inspect the complete hostname; compare the request with expected account activity; and ask whether the legitimate organization ever needs the requested secret. No legitimate wallet support process requires a recovery phrase.
After suspected exposure, change credentials from a known-clean device, end active sessions, review recovery methods, inspect withdrawal addresses, and contact the service through an official channel. If recovery material was entered, treat every wallet the attacker can reconstruct from it as compromised and retire the exposed mnemonic even when a separate passphrase may have limited immediate access. Move controllable assets to fresh keys generated in a clean environment. Merely changing the wallet application's local password does not replace exposed keys.
Common misconceptions
“Phishing messages are easy to detect because they contain spelling mistakes.”
Language quality is not a security control. Attackers can copy official text, compromise trusted accounts, and register domains that differ by one subtle character.
“An authenticator code prevents every phishing takeover.”
A live relay can use a one-time code immediately. Domain-bound authentication is stronger, while recovery paths and authenticated sessions still require protection.
“Signing a message cannot move assets because it is not a transaction.”
Some signatures authorize permits, listings, or later actions. The effect depends on the exact signed data and the contracts that accept it.
Risks and limitations
- Compromised legitimate accounts can send malicious requests inside previously trusted conversations.
- Lookalike domains may use subtle spelling, subdomain, or international-character differences that are hard to notice quickly.
- Session theft and weak account recovery can bypass a strong password and one-time authentication code.
- Transaction simulations can be incomplete or become inaccurate when contract state changes before execution.
Key takeaways
- Verify sender, domain, request, and timing through independent channels.
- Never enter a recovery phrase into a website or support conversation.
- Treat signatures as authorization requests, even when no transaction fee appears.
- Use bookmarks or manually verified applications for sensitive account access.
- Replace exposed wallet keys; changing a local wallet password is insufficient.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.