The Bait, The Hook, The Catch: How Phishing Really Works

2 AM: Sixty Servers Down

Priya's phone rang at 2 AM. She was a security analyst, and when the SOC called at 2 AM it was never good news. By the time she had her laptop open, the scope was already clear: sixty servers encrypted, operations halted, a ransom note demanding 50 Bitcoin displayed on every affected machine.

The incident response team worked through the night tracing the attack backward through logs, network traffic, and authentication records. What they found three weeks into the past was not a sophisticated zero-day exploit. It was a single email.

David in accounting had received an email that appeared to be from Microsoft 365. The subject line read "Action Required: Unusual Sign-in Detected on Your Account." The email looked exactly like every other Microsoft account security notification he had seen before — the logo, the colors, the format, the footer. He clicked the "Verify your account" button, entered his Microsoft 365 username and password on what appeared to be the Microsoft login page, and went back to work.

That was three weeks ago. In the intervening 21 days, the attacker logged in as David, explored his access to shared file servers, discovered an unpatched local privilege escalation vulnerability, escalated to local admin on multiple machines, pivoted laterally across the network using those credentials, established multiple persistence mechanisms, and when the time was right — deployed ransomware across sixty servers simultaneously.

One phishing email. One credential harvest. Three weeks of undetected lateral movement. One ransomware deployment. Total damage: weeks of downtime, six-figure recovery costs, and potential regulatory exposure for the compromised data accessed during those three weeks.

An Attack on Human Pattern Recognition

The next morning, Priya briefed the incident response team. She started not with the technical details but with the question everyone was silently asking: how does a sophisticated security-aware organization get compromised by a phishing email?

"It's not a technical attack," she said. "It's an attack on human pattern recognition. We process hundreds of emails every day, most of them on autopilot. We've built up conditioned responses over years: Microsoft wants me to verify my account — I click the link and enter my credentials. That's the workflow. That's what I always do."

Phishing works by inserting malicious content into trusted workflows. The attacker doesn't need to break encryption or exploit a vulnerability. They need to craft an email that looks exactly like a communication from an organization you already trust — Microsoft, DocuSign, FedEx, your HR department, your bank — and present it at a moment when your pattern recognition fires before your critical thinking engages.

Every design choice in a phishing email is optimized for those first few seconds of processing: the logo so it matches the real one, the sender display name set to "Microsoft Account Team," the subject line crafted to trigger urgency without triggering alarm, the layout identical to genuine notifications, the call-to-action button exactly where it should be.

The Phishing Taxonomy

Priya mapped out the full phishing landscape on the whiteboard. The team needed to understand that "phishing" was a category, not a single attack type.

Phishing — the broad category: mass email campaigns with generic content, low personalization, broad targeting. Cast wide nets. Even a 0.5% success rate across 100,000 emails is 500 compromised accounts.

Spear phishing — targeted, personalized. The attacker researches the specific victim — name, employer, role, manager, recent projects — and crafts an email that references real details. "Hi David, following up on the Q3 budget review you mentioned to Sarah" is far more convincing than "Dear Customer." Much higher success rates, much higher attacker effort.

Whaling — spear phishing aimed specifically at executives: CEOs, CFOs, board members. Higher research investment for higher-value targets. Often used in Business Email Compromise attacks — impersonating the CEO to instruct the CFO to wire funds.

Vishing — voice phishing. Phone calls. An attacker calls claiming to be IT support ("We've detected malware on your computer, I need to verify your credentials"), the IRS ("You owe back taxes, pay now or face arrest"), or a bank fraud department. Caller ID spoofing makes the call appear to come from a legitimate number. The urgency and human interaction make vishing highly effective.

Smishing — SMS phishing. Text messages containing malicious links or fraudulent requests, impersonating package carriers, banks, or government agencies. The short URLs common in SMS (bit.ly, etc.) completely obscure the real destination. The small screen real estate makes URL inspection harder.

Clone phishing — an attacker takes a real, previously delivered legitimate email (a DocuSign request, a shipping notification, a meeting invitation), replaces the link or attachment with a malicious version, and resends it from a spoofed address. The email content is authentic — only the payload has changed.

Pharming — a different category entirely. Instead of tricking the user into clicking a malicious link, pharming corrupts the name resolution process itself. Through DNS cache poisoning or hosts file modification, the attacker redirects users from legitimate URLs to malicious sites. The victim types bankofamerica.com correctly and arrives at a fake bank site. No malicious link required.

Dissecting the Email That Started It All

Priya pulled up the email David had received. The team examined every component.

Sender display name: "Microsoft Account Team" — looked exactly right. Most email clients display the name prominently and show the email address in small text below, or not at all unless you expand it.

Sender email address: support@microsoft-security-alerts.com — not microsoft.com. This was the red flag that nobody checked. The display name was correct; the actual sending domain was a cousin domain registered by the attacker. Had anyone examined the full email address rather than just the display name, the attack would have been obvious.

Subject: "Action Required: Unusual Sign-in Detected on Your Account" — urgency and specificity combined. Not generic ("Your account needs attention") — specific enough to seem real ("Unusual sign-in detected").

Body: Professional layout. Microsoft's exact logo. Correct brand colors. "We detected a sign-in from an unrecognized device in Chicago, IL at 11:43 AM." Specific enough to seem credible — the random city added verisimilitude without being verifiable. A "Verify your account" button in Microsoft blue.

What hovering would have shown: http://login.microsoftonline.microsoft-security-alerts.com/verify — the attacker deliberately included "microsoftonline" as a subdomain of their domain. A casual glance sees "microsoftonline" and pattern-matches to the real Microsoft. But the actual domain is microsoft-security-alerts.com, not microsoft.com.

The credential harvesting page: A pixel-perfect copy of the Microsoft 365 login page — downloaded from the real Microsoft site and hosted on the attacker's server. When David entered his credentials, they were captured and forwarded to the attacker. He was then redirected to the real Microsoft site, which logged him in normally. He never knew anything had happened.

The Attacker's Technical Toolkit

Priya explained the technical infrastructure that makes phishing campaigns work at scale.

Typosquatting: Registering domain names that are common misspellings or visual substitutions of legitimate domains. micros0ft.com uses a zero instead of the letter O. paypa1.com uses the numeral one instead of L. arnazon.com uses "rn" which at small font sizes looks like "m" — amazon vs arnazon. These domains are legitimate registrations — they pass basic checks but mislead casual inspection.

Homograph attacks: Using Unicode characters that are visually identical to ASCII characters to create lookalike domain names. The Cyrillic letter 'а' (U+0430) is visually indistinguishable from the Latin 'a' (U+0061) in most fonts. A domain using the Cyrillic 'а' in place of the Latin 'a' looks identical to the real domain in the browser address bar, but is a completely different domain. Browsers may display the punycode representation (xn--pple-43d.com) for domains using mixed scripts, but not always.

Phishing kits: Pre-built packages containing everything needed to deploy a credential-harvesting site. The kit includes: a mirrored copy of the target site's HTML and CSS (downloaded directly from the real site), PHP scripts that capture form submissions and forward credentials via email, obfuscated code designed to evade security scanners. Phishing kits are sold on dark web forums for $20–200 and enable attackers with no web development skills to deploy professional-looking credential-harvesting campaigns against any major service within hours.

Credential harvesting: The core goal of most phishing attacks is not the phishing email itself but what happens after the user clicks. The harvesting page captures username, password, and increasingly — MFA codes in real-time relay attacks, session tokens, and security question answers. The attacker's infrastructure logs everything submitted and uses it immediately or sells it.

The Technical Defenses: Why Email Authentication Matters

Priya walked through the email authentication stack. Understanding these three protocols was critical — both for defending your own domain against spoofing and for understanding why attackers use cousin domains instead.

SPF — Sender Policy Framework: A DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. When an email claims to be from microsoft.com, the receiving mail server checks Microsoft's SPF record: is the sending server's IP address on the authorized list? If not, the email fails SPF. SPF alone doesn't stop display-name spoofing (the attacker can still display "Microsoft" as the name) or cousin domain attacks (the attacker registers microsoft-security-alerts.com and sets up their own SPF for that domain).

DKIM — DomainKeys Identified Mail: Adds a cryptographic signature to outgoing emails. The sending server signs the email with a private key; the public key is published in DNS. The receiving server retrieves the public key and verifies the signature. If the email was modified in transit or sent from an unauthorized server, the signature verification fails. DKIM validates both the sending server's authorization and the message integrity.

DMARC — Domain-based Message Authentication, Reporting and Conformance: Builds on SPF and DKIM by answering the critical question: what should the receiving server DO when SPF or DKIM fails? DMARC policies: none (monitor only — still deliver, just log the failure), quarantine (route to spam folder), reject (block the email entirely — do not deliver). DMARC also enables reporting: the domain owner receives aggregated reports showing all attempts to send email claiming to be from their domain, making spoofing attempts visible.

The Complete Anti-Phishing Stack

Priya summarized the complete defense architecture the organization needed to implement. No single control stops phishing — the defense must be layered.

Technical controls: SPF, DKIM, and DMARC configured on your domain with reject policy — prevents your domain from being used to spoof others. Email gateway filtering with URL scanning and attachment sandboxing. External email warning banners ("[EXTERNAL]" on all emails from outside the organization). MFA for every account — the single most impactful control for limiting the damage from credential harvesting. DNS filtering to block known phishing domains at the resolver level.

Human controls: Security awareness training — not just slides, but scenario-based learning. Simulated phishing campaigns that teach through experience: if you click a simulated phishing link, you immediately receive a short tutorial showing what the tell-tale signs were, not a reprimand. The hover-before-click habit specifically — this single behavior catches the majority of phishing links. Verify unexpected requests through independent channels: call the vendor at their known number, not the number in the suspicious email.

Process controls: A reporting procedure that is frictionless — one-click "report phishing" button directly in the email client. Rapid investigation of reported emails — a reported phishing email that gets investigated and blocked protects everyone else. An incident response plan specifically for credential compromise: immediate session revocation, password reset, audit log review, and broader hunt for lateral movement if credentials were harvested more than minutes ago.

The key insight from Priya's incident: MFA is the highest-impact single technical control against credential phishing. Even when phishing succeeds and credentials are stolen, MFA prevents the attacker from replaying those credentials to log in. David's incident could have ended at the credential harvest — three weeks of lateral movement and 60 encrypted servers could have been prevented entirely — if his account had MFA enabled.