What Is a Phishing Attack?

A phishing attack is a message or webpage that impersonates someone you trust — your bank, your employer, a delivery service — specifically to trick you into handing over credentials, payment details, or system access. It's a con, not a technical exploit: the vulnerability being targeted is human trust, not a flaw in your software.

How a phishing attack actually works, step by step

Every phishing attack, regardless of channel, follows roughly the same four-stage anatomy — understanding it is more useful than memorizing examples, because the examples change every few months and the underlying structure doesn't:

1. The pretext. The attacker picks a scenario that justifies urgent action from a trusted source — an invoice, a locked account, a failed delivery, a message from "IT" about an expiring password.
2. The lure. A message is sent through email, text, a phone call, or a QR code, spoofing the sender identity closely enough to survive a quick glance, and applying time pressure so you act before you think.
3. The hook. A link to a cloned login page, a malicious attachment, or a request to "confirm" information over the phone — whatever gets the victim to hand over something valuable.
4. Capture and monetization. Credentials get tested against other services, sold in bulk, or used directly for wire fraud; malware payloads get used to deploy further tools, including ransomware, deeper into a network.

The reason this framework matters practically: almost every effective defense targets one of these four stages specifically, rather than trying to detect "phishing" as a single thing.

The many faces of phishing — it's rarely just email anymore

The core con is identical across all of these; only the delivery channel changes, usually to whichever channel currently has the weakest scrutiny:

• Email phishing — mass-sent, low-effort, low targeting-per-message, relying on volume.
• Spear phishing — personalized using information gathered from social media, breach data, or a company directory, making the pretext far more convincing.
• Whaling — spear phishing aimed specifically at executives or finance staff, usually to authorize a fraudulent wire transfer through business email compromise.
• Smishing — SMS-based, frequently impersonating package delivery or bank fraud alerts; harder to inspect on a phone screen where full URLs and sender addresses are often truncated.
• Vishing — voice-call phishing, increasingly paired with spoofed caller ID and, more recently, AI-generated voice cloning of a real colleague or family member's voice to add urgency.
• Quishing — phishing delivered via QR code, in emails, physical flyers, or even fake parking-meter stickers. It specifically exploits the fact that most email security scanners inspect URLs as text; a QR code's destination is embedded in an image, invisible to that kind of automated link scanning until it's decoded.
• Clone phishing — a near-identical resend of a real, previously legitimate email, with the original link or attachment swapped for a malicious one.

The technique most guides skip: phishing that defeats two-factor authentication entirely

Standard advice says two-factor authentication stops phishing. Against modern attack kits, that's no longer reliably true. Adversary-in-the-middle (AiTM) phishing kits — Evilginx is the best-known example in this category — don't just clone a login page's appearance. They act as a live reverse proxy sitting directly between the victim and the real service, relaying every request and response in real time.

When the victim enters a password and then approves a push notification or types in a one-time code, that entire exchange passes straight through to the real service — which authenticates it successfully, because it's genuinely correct. The service then issues a valid, authenticated session cookie back through the same relay, and the attacker captures that cookie directly. From that point on, the attacker has a live, already-authenticated session — no password needed again, no further MFA prompt required, because from the real service's point of view, nothing suspicious happened at all.

Red flags that actually hold up — and the one that doesn't

Some advice repeated in basic security training genuinely helps; some of it is outdated or flatly wrong. Here's what's still worth checking:

• Sender mismatch. The display name says "Bank Support," but the actual email address behind it is unrelated — always check the real address, not just the name shown.
• Hover before you click. On desktop, hovering over a link previews its true destination in the status bar without visiting it — a mismatch between the visible text and the real URL is a strong signal.
• Look-alike domains. Homograph attacks substitute visually identical characters from other alphabets — a Cyrillic "а" in place of a Latin "a," for instance — producing a domain that looks correct to the human eye but resolves somewhere entirely different.
• Recently registered domains. A domain created days or weeks ago impersonating an established company is a meaningful red flag, checkable through our own WHOIS lookup tool or any public registry.
• Manufactured urgency. "Your account will be suspended in 24 hours" exists specifically to short-circuit careful reading.

And the one that doesn't hold up: the padlock icon or "https://" in the address bar. Free, automated certificate authorities like Let's Encrypt issue valid encryption certificates to any domain, including one registered five minutes ago for a phishing campaign. HTTPS confirms the connection is encrypted in transit — it says nothing about who controls the server on the other end. Treat the padlock as meaningless for judging trust; it was never designed to signal that in the first place.

What happens after someone actually clicks

The outcome depends heavily on what was actually captured. If a password was typed into a cloned login page, it gets tested immediately against other popular services — a far bigger risk if that password was reused anywhere, since credential-stuffing tools automate exactly that check within minutes of a new haul. Running the entered password through our password strength checker is a reasonable first move if you're unsure whether it's strong enough to have survived the attempt.

If the kit used was an AiTM proxy, the far more serious outcome is a stolen live session — meaning the attacker didn't just get a password, they got standing access to the account as it already existed, MFA and all, until that session is manually revoked. If a malicious attachment was opened rather than a link clicked, the concern shifts to whatever payload ran locally — commonly an infostealer designed to harvest saved browser passwords and cookies directly off the device, which is a different and often worse problem than a single phished credential.

What actually stops it

In rough order of how much they actually help, based on what defeats the attack techniques above rather than just general good habits:

• Passkeys or hardware security keys wherever the option exists — the only method here that structurally defeats AiTM relay attacks, not just casual phishing.
• A password manager that autofills only on the exact domain it was saved for. This is a genuinely underrated defense: on a convincing look-alike domain, a password manager will simply refuse to offer autofill at all, because the origin doesn't match — a practical tell that's easy to miss if you're typing manually but nearly impossible to miss once you're used to a manager filling things automatically. If you're not already using one, our password strength checker is a good place to see how your current passwords hold up in the meantime.
• Verifying through a separate, known channel. If a message claims to be your bank, call the number printed on your card — never a number or link supplied inside the message itself.
• Reporting it. Forward suspicious emails to your provider's phishing-report address, or to the Anti-Phishing Working Group; organizations should also enforce DMARC, SPF, and DKIM to make spoofing their own domain harder in the first place.