📖 Story📚 Glossary🗺️ Concepts💡 Examples🃏 Flashcards✅ Quiz🎯 Tricks
Chapter 22 · Examples

Phishing — Real-World Examples

Concrete attack scenarios and exam-style questions showing phishing techniques in practice.

Example 1: Credential Harvest Leading to Ransomware

An attacker registers microsoftonline-alertservice.com and deploys a phishing kit containing a pixel-perfect Microsoft 365 login page. They send 50,000 emails with the subject "Unusual sign-in activity on your account." The emails pass basic spam filters because the content is professional and the sending domain has its own SPF record (it's not spoofing microsoft.com — it's its own domain with a convincing name).

Three hundred employees click the link. Eighty-five enter their credentials. The attacker logs into each compromised account and quickly identifies the most valuable: one is an accounting employee with access to shared financial drives. Using that account, the attacker maps accessible file servers, discovers a local privilege escalation vulnerability on a file server, escalates to local admin, and begins lateral movement using pass-the-hash techniques. Over the following three weeks, the attacker establishes persistence on 60 servers, exfiltrates sensitive data, and deploys ransomware simultaneously across all 60 machines.

Key Lesson: One click → credential harvest → lateral movement → ransomware. MFA would have broken the kill chain at step 2: even with 85 harvested username/password pairs, not a single login would have succeeded without the second factor. The entire three-week campaign — the data theft, the ransomware, the recovery costs — traced back to the absence of MFA on those 85 accounts.

Example 2: CEO Whaling / Business Email Compromise

An attacker researches the target company on LinkedIn and public sources. They identify: CFO Sarah Chen, Executive Assistant Michael Torres, CEO Robert Park. They find that Robert is speaking at an industry conference this week (visible on the conference website and his LinkedIn activity).

The attacker creates a Gmail account with the display name "Robert Park CEO" and sends Michael the following email: "Michael, I'm in back-to-back sessions at the conference and can't talk right now. We're finalizing the Acme acquisition — I need you to process a $175,000 wire to the escrow account in the attached document. This needs to go out today before end of business. Keep this confidential until the public announcement. Thanks, Robert."

The pretext is perfect: the CEO is at the conference (publicly verifiable), there's a plausible business reason (acquisition), the urgency is real ("today before end of business"), and the secrecy instruction removes the natural verification step ("Keep this confidential"). Michael wires the money.

Key Lesson: No technical controls stop this attack — the email came from a free Gmail account with no spoofing. DMARC on the real company domain does nothing here. The only effective defense is a process control: a strict policy requiring all wire transfers above a threshold to be verbally confirmed by a direct callback to the CEO at a known, pre-verified phone number — not a number provided in the suspicious email.

Example 3: Clone Phishing via DocuSign

A contract manager receives a legitimate DocuSign e-signature request for a vendor agreement. The email is real — it comes from DocuSign's actual servers, contains the real document name, and uses the standard DocuSign format. She signs the document through the legitimate DocuSign portal.

One week later, she receives an identical-looking DocuSign email — same format, same DocuSign logo, same "Please DocuSign: [exact same document name]" subject line. The email even references the same contract. But this email was sent by an attacker who monitored her email (perhaps through a previously compromised account), copied the original DocuSign email exactly, replaced the "Review Document" link with one pointing to docusign-secure-verify.net (not docusign.com), and sent it from docusign-notifications@docusignmail.net.

She recognizes "the DocuSign email" — it matches the one she already received and acted on. She clicks without hovering. Her credentials are harvested. She is redirected to the real DocuSign portal and notices nothing unusual.

Key Lesson: Clone phishing exploits recognition memory — the recipient sees something they know is real (they received the legitimate original) and applies that trust to the clone. The defense requires breaking the pattern-recognition response: hover over every link every time, regardless of how familiar the email looks. The body can be perfectly authentic while the link destination is completely different.

Example 4: Pharming via DNS Cache Poisoning

An attacker exploits a vulnerability in an ISP's recursive DNS resolver to poison its cache. The attack inserts a false DNS record for bankofamerica.com, mapping the domain to the attacker's IP address. All customers whose DNS queries resolve through this ISP's compromised resolver — potentially millions of users — now receive the attacker's IP address when they look up bankofamerica.com.

Users who type bankofamerica.com correctly in their browser arrive at a pixel-perfect fake bank site. Because they typed the URL themselves and clicked no suspicious links, they have no reason to be suspicious. The fake site uses a self-signed certificate — some users receive a browser security warning and leave; others click through the warning or have browsers configured to accept it. Thousands of credentials are harvested before the poisoning is detected and the DNS cache is flushed.

Key Lesson: Pharming is insidious because the user does everything right — types the URL, clicks no links, follows every phishing awareness training recommendation — and still ends up on a fake site. The defense at the individual level is the HTTPS certificate warning: the fake site either has no certificate, a self-signed certificate, or a certificate for a different domain. Never click through certificate warnings on banking or sensitive sites. DNSSEC can cryptographically protect DNS responses at the infrastructure level.

Example 5: Smishing — Package Delivery Scam

A mass SMS campaign sends the following message to millions of phone numbers: "Your FedEx package #274-003-88 has been delayed. Please update your delivery preferences to reschedule: [bit.ly/xK7mP2]." The message is sent regardless of whether recipients are actually expecting a package — the statistics are favorable because a significant percentage of people are always expecting some delivery.

Recipients who click the short URL are redirected through multiple hops to fedex-delivery-updates.net, which displays a professional FedEx-branded page requesting their name, address, and a $3.99 "re-delivery fee" requiring a credit card. The credit card data is harvested. Some variants install malware on mobile devices rather than harvesting payment information.

Key Lesson: The short URL in SMS completely obscures the destination — there is no equivalent of "hover to preview" on most SMS clients. The defense: never click links in unsolicited SMS messages about packages, deliveries, or payments. Open the FedEx app or go directly to fedex.com and enter the tracking number there. If the SMS is real, the tracking number will work on the official site.

Exam Scenario 1

Question: A user reports receiving an email from "IT Support" telling them their password expires today and they must click a link to reset it. The email has the company logo but the sender address is itsupport@helpdesk-company-it.com. Hovering over the reset link shows https://company-it.com/reset-password. What type of attack is this, what are the indicators, and what should the user do?

Answer: This is phishing — specifically a credential harvesting attack targeting the user's corporate credentials. Two technical indicators: (1) The sender domain (helpdesk-company-it.com) does not match the company's legitimate domain — this is a cousin domain registered by the attacker. (2) The link destination (company-it.com) also does not match the company's real domain — another cousin domain. Both domains have "company-it" in them, designed to appear legitimate to a casual reader but neither is the real corporate domain. A third indicator: urgency ("expires today") is designed to prevent careful consideration. Correct user action: do not click the link. Report the email using the "Report Phishing" button. If a password reset may actually be needed, navigate directly to the IT portal using a known-good bookmark or by typing the real corporate URL.

Exam Scenario 2

Question: A company's outbound email is being spoofed — scammers are sending emails appearing to come from ceo@legitcompany.com to the company's vendors requesting payment to changed bank accounts. The emails reach vendors' inboxes and are visually convincing. What technical control best prevents this?

Answer: DMARC set to reject policy, implemented alongside properly configured SPF and DKIM records. With DMARC at reject, all receiving mail servers are instructed to block any email claiming to be from legitcompany.com that fails SPF or DKIM validation. Since the spoofed emails are being sent from attacker-controlled servers that are not in legitcompany.com's SPF record, and are not signed with legitcompany.com's DKIM private key, they will fail both checks. With DMARC reject, those failures result in the emails being blocked before delivery to vendors — the attack stops entirely. Without DMARC (or with DMARC set to "none"), SPF and DKIM failures are recorded but emails are still delivered. DMARC is what converts authentication failures into blocked emails.

Exam Scenario 3

Question: A user was phished three days ago. The organization detects the credential compromise today. What is the first priority action and why? What does the three-day gap imply?

Answer: The first priority is immediately invalidating the compromised credentials and revoking all active sessions for that account. This terminates any active attacker session and prevents continued access. Three days of undetected access is significant dwell time — the attacker has had ample opportunity to: perform reconnaissance (map the network, enumerate systems and accounts the compromised user can reach), establish persistence mechanisms (add forwarding rules, authorize OAuth apps, create backdoor accounts), attempt lateral movement to higher-privilege accounts, and potentially exfiltrate data. Do not assume the compromise is limited to this one account. Simultaneous actions: review the account's complete activity log for the past three days looking for emails sent, files accessed, OAuth apps authorized, inbox rules created, and login locations. Identify any systems accessed by the compromised account and determine whether those systems show signs of compromise. The three-day gap means the incident response must treat this as a potentially broad compromise, not an isolated single-account incident.