Social engineering is the technique that defeats security programs whose technical controls are otherwise tight. When the firewall is correctly configured, the patching is current, the EDR is tuned, and the network segmentation is real, the operator’s reliable path through the perimeter is the person on the receiving end of an email or phone call. People want to be helpful, they get rushed before lunch and distracted by 4:55 PM, and they trust the voice or face that’s been carefully constructed to look familiar.
This post covers the targeted end of phishing: spear phishing (carefully researched lures aimed at specific individuals) and whaling (the same techniques aimed at executives, board members, and other high-value targets). The technical distinction between the two is mostly the target’s seniority and the operator’s preparation effort; the techniques are the same. Mass phishing (the millions-of-emails approach used by commodity crime gangs) is a different discipline and isn’t covered here.
OSINT for the targeted lure#
The difference between a generic phish and a spear phish is preparation. The operator who has spent a week researching the target writes an email the target reads instead of deletes. The standard OSINT workflow for a corporate target:
- LinkedIn. The target’s job title, tenure, recent role changes, current projects (visible from their feed), the names of their peers and direct reports, and the language the company uses for its internal vocabulary (you’ll learn whether the IT team is called “IT,” “Tech Services,” or “Workplace Engineering”). Sales Navigator surfaces more than the free tier; aged dummy accounts get further than fresh ones.
- The company’s website. Press releases for ongoing initiatives, the leadership bio page for the executive directory, the careers page for the security tooling stack (“must have experience with CrowdStrike Falcon” tells you what EDR is on the box), the company blog for the language and tone the marketing team uses.
- News articles and SEC filings. Recent acquisitions, partnerships, product launches, executive moves. These produce the timely hooks that make pretexts feel current. A spear phish referencing a deal the target’s company announced last week reads as informed; a generic “your account has been suspended” reads as a mass campaign.
- Hunter.io, Apollo, or Snov.io. Verify the email format the company uses (
first.last@company.comvsfirstinitiallastname@company.com) and grab a list of working addresses. Most of these services have free tiers sufficient for a single-target lookup. - Have I Been Pwned and public breach data. The target’s past breach exposures are a treasure trove for the operator. If the target’s email shows up in a 2020 LinkedIn dump and a 2022 Adobe dump, that’s two data points about the kinds of services they use; sometimes the breached password is reused on the target’s current corporate account and the operator can skip phishing entirely.
- The target’s social media outside LinkedIn. Twitter for the personal voice and recent activity, Strava for the running routes (yes, this is how the US discovered the locations of classified bases in Iraq via Strava heatmaps; treat your targets the same way you’d want their adversaries to treat you), Instagram for the photos that show what’s on their desk.
The output of OSINT is a pretext that the target will recognize. The vendor technician arriving for “the SAP support ticket SAP-2026-3387 we opened last Tuesday.” The new hire whose manager (named in LinkedIn) “told me to reach out about getting access to SharePoint.” The industry analyst (with a real-looking firm behind them) asking for “thirty minutes to discuss your recent acquisition of CompanyX.” Each of these gives the target a comfortable role to play; the operator’s craft is constructing that role around details the target can verify if they want to.
Cialdini’s principles, applied#
The psychology that makes phishing work isn’t a mystery; Robert Cialdini cataloged it in Influence: The Psychology of Persuasion (1984) and added a seventh principle in Pre-Suasion (2016). Every working phishing pretext leans on at least two of these. The ones that show up most often:
- Authority. “This is the VP of Finance” or “IT is requiring everyone to complete the new MFA enrollment by Friday.” The target’s instinct is to defer to perceived authority rather than challenge it. Hardest to defeat when paired with an authentic-looking sender domain.
- Scarcity, usually expressed as urgency. “Wire the deposit before the 4 PM cutoff or we lose the deal.” A deadline collapses the target’s evaluation window; the target who would have asked a clarifying question if they’d had ten minutes instead clicks and forwards in the two minutes they think they have.
- Social proof. “Bob in Accounting said you could help me.” Or a forwarded chain showing other colleagues already engaged. Validation by reference to people the target already trusts.
- Liking. “Hey, I’m new here and I’m just trying to figure out where this gets logged. Could you walk me through it?” The target wants to help a sympathetic-sounding requester and feels good doing it.
- Reciprocity. Bring something small (a useful piece of information, a free industry report) and the target will reach to balance the exchange.
- Commitment and consistency. The target who agreed to a small request earlier (“can I confirm your email is jane.smith@company.com ?”) feels obligated to honor a later, larger one.
- Unity. “Hey, fellow Falcons fan, I noticed your Atlanta area code…” Manufactured in-group membership, which lowers defenses faster than personal Liking does. The “from your IT team” lures lean on Unity more than on Liking.
A working pretext usually combines two or three of these. Authority plus urgency is the canonical pair for executive impersonation (“the CEO needs you to process a $500K wire transfer before COB today”). Liking plus reciprocity is the canonical pair for IT-impersonation lures. The pretext that leans on a single principle too hard, especially authority by itself, reads as bullying rather than as authority and gets reported.
The technical kit#
The operator side of phishing has three technical components: the sending infrastructure (looks legitimate to the target’s mail server), the lure (the email content itself), and the landing page or payload (where the click goes).
Sending infrastructure that lands in the inbox#
Email authentication has tightened considerably in the past five years. Gmail and Microsoft 365 reject mail without DMARC, SPF, and DKIM aligned; AOL-era spoofing of arbitrary From: addresses dies at the receiving mail server before it ever reaches the user. The operator’s response is to register a domain that looks like the target’s and authenticate the operator’s own mail from it correctly. A typical engagement workflow:
- Register a lookalike domain (
amaz0n-billing.com,microsoft-secure.online, or an aged domain that already has a clean reputation). - Stand up the DNS records (SPF allowing the operator’s mail server, DKIM signing key, DMARC policy).
- Warm the domain for a few days before the campaign (send legitimate-looking traffic to gradually build a sending reputation).
- Send the campaign through a service that’s not blacklisted (Postfix on a clean VPS is fine if the IP isn’t burned; Mailgun, Postmark, or AWS SES work if you can get past their abuse checks).
The lazy operator uses evilginx or a phishing framework’s built-in mail server and watches their messages land in spam. The competent operator does the infrastructure work, lands in the inbox, and gets click rates that justify the engagement budget.
Lure templates#
A spear phishing email is one to four paragraphs, references something the target can verify, includes a single clear call to action, and asks for something small that’s plausibly within the target’s authority to provide. Templates that work in 2026:
- MFA enrollment / token expiration. “Your Okta token expires in 24 hours. Click here to re-verify.” Lands on an Evilginx page that proxies the real Okta login and steals the session cookie.
- Shared document. “[Real coworker’s name] shared a document with you in SharePoint: Q3 2026 Strategy.docx.” Click goes to a fake Microsoft login.
- Helpdesk impersonation. “We detected unusual activity on your account. Please verify your identity by entering your username, password, and the MFA code from your phone.” (This one is the MGM/Caesars pattern, except by phone rather than email; covered in the case studies below.)
- DocuSign / Adobe Sign. “Please sign the attached contract.” Lands on a credential-capture page styled to look like the real service.
Landing pages and AiTM#
The historical pattern was a fake login page that captured credentials directly. That still works against targets without MFA, but most enterprise targets have MFA enabled, so the operator’s tool of choice is Evilginx (Kuba Gretzky), an Adversary-in-the-Middle (AiTM) toolkit that proxies the victim through to the real M365 / Google / Okta endpoint. The victim enters their password and the MFA code into what looks like the real login page; Evilginx captures the credentials and the post-authentication session cookie, which the operator then imports into their own browser and uses to log in as the victim.
Evilginx 3 (released May 2023) is the current generation; v2 is deprecated. The community version is at github.com/kgretzky/evilginx2; there’s a paid Evilginx Pro that’s ahead of the community version on features but uses the same core technique. AiTM is the technique that breaks every form of phishable MFA (SMS, TOTP, push notifications); only FIDO2 hardware tokens and passkeys, which bind to the legitimate origin and refuse to authenticate against a proxy domain, resist it.
Malware payloads via attachment#
Macro-bearing Office documents were the dominant payload through about 2022. Microsoft’s 2022 default-block on macros from internet-sourced documents largely killed that vector. The modern attacker tradecraft has moved to ISO and IMG containers (which strip Mark-of-the-Web from their contents when mounted), HTML smuggling (an HTML attachment that assembles the payload client-side in the browser), OneNote attachments (which can embed and execute scripts), and LNK-in-archive delivery. Macro phishing still occasionally works against targets that allow internal-network macros; everything else is the current state of play.
Case studies (corrected)#
2016 Podesta phish (Fancy Bear / Cozy Bear)#
The DNC compromise that drove the 2016 US election news cycle. On March 19, 2016, Fancy Bear (APT28, GRU Unit 26165) sent John Podesta a spear-phishing email disguised as a Google security alert, with a Bitly-shortened URL leading to a credential-harvesting page. Podesta forwarded it to an IT staffer for verification; the staffer replied “this is a legitimate email” (later clarified as a typo for “illegitimate”) and Podesta clicked anyway. The credentials harvested gave Fancy Bear access to roughly a decade of Podesta’s email, which got dumped via WikiLeaks in October 2016.
The broader DNC network breach also involved Cozy Bear (APT29, SVR), which had been resident in the network since 2015 via separate spear phishing. Both Russian intelligence services were in the network simultaneously and apparently unaware of each other, which is itself an interesting forensic finding.
Bangladesh Bank heist (Lazarus Group, 2016)#
North Korea’s Lazarus Group spear-phished Bangladesh Bank employees in late 2015, delivered malware that pivoted to the SWIFT terminal workstations, and on February 4 to 5, 2016 issued 35 fraudulent SWIFT transfer requests totaling about $951 million. Five of the transfers succeeded, moving about $101 million out of the New York Fed’s correspondent account. About $20 million was recovered from Sri Lanka after a typo flagged one transfer for review; about $81 million reached the Philippines and disappeared into casinos, with roughly $15 million eventually recovered. The Philippine portion is what gets cited in most accounts as “the Bangladesh Bank heist.”
The operator-side lesson is that the initial vector was unglamorous (spear phishing emails delivered through commodity malware to mid-level bank employees) and the high-value pivot only happened because the bank’s network segmentation between user workstations and SWIFT terminals was inadequate. Phishing is rarely the end of the engagement; it’s the start of one.
2023 Scattered Spider / MGM and Caesars#
The case study that defines modern social engineering. In September 2023, Scattered Spider operators identified employees of MGM Resorts and Caesars Entertainment via LinkedIn, called the IT helpdesks, and impersonated the employees convincingly enough to obtain Okta and Azure AD admin access. The MGM call reportedly took about ten minutes. Caesars paid roughly $15 million (from a $30 million demand, per their 8-K filing); MGM didn’t pay and ate roughly $100 million in operational disruption plus subsequent regulatory fines.
The technique was vishing rather than email phishing: a real phone call from a fluent English-speaking operator who had LinkedIn-researched the target employee’s name, role, manager, and recent activity. The helpdesk’s verification procedure for “I forgot my password” relied on questions the operator could answer from public OSINT. The technique still lands in 2026 against helpdesks that haven’t tightened their verification flow; Microsoft enforced MFA number-matching globally on May 8, 2023, which killed naive MFA fatigue against M365 accounts, but the helpdesk-reset path doesn’t go through MFA, so MFA number-matching doesn’t help there.
What’s NOT a spear phishing case study#
A note on errors that appear in other writing on this topic:
- WannaCry (May 2017) is not a spear phishing case study. It propagated via EternalBlue (CVE-2017-0144, the leaked NSA exploit against SMBv1) and DoublePulsar. Early CISA reporting speculated about a phishing initial vector but no phishing entry was ever confirmed. WannaCry is the canonical wormable-exploit case study, not a phishing one.
- 2017 British Parliament attack is also not spear phishing. On June 23, 2017, a sustained twelve-hour brute-force / password-guessing attack hit roughly 9,000 Parliamentary email accounts and compromised about 90 of them (under 1%) due to weak passwords. The vector was credential stuffing or brute force, not phishing.
Both of these claims show up frequently in social engineering writeups because they make convenient narrative anchors. They’re wrong. The correct framing for both is in the EternalBlue and credential-stuffing literature respectively.
Whaling specifically#
Whaling is spear phishing aimed at executives, board members, or other high-value individual targets. The techniques are the same as for any other spear phish; the differences are scale of OSINT (executives generate more public information, so the pretext can be much more specific) and stakes (a successful whale yields wire transfer authority, board-document access, or both). Most modern Business Email Compromise (BEC) lands here: spoofed-CEO messages to the CFO authorizing a wire transfer, fake-vendor invoice messages to Accounts Payable, “I need you to buy gift cards for client appreciation” messages from the impersonated CEO to their executive assistant.
The defensive lift is the same as for regular phishing (DMARC alignment on inbound mail, MFA with phishing-resistant factors like passkeys and FIDO2, out-of-band verification for any unusual financial request), but the budget tends to be higher because the dollar impact of a successful whale is concentrated. BEC, per the FBI’s IC3 reporting, has been the highest-dollar category of cybercrime by reported losses for several years running, ahead of ransomware in raw dollar terms.
Why phishing campaigns get caught#
The things that flag a spear phishing email to a trained target, in rough order of how often each one kills a campaign:
- Grammar and spelling mistakes. Most still-functional commodity phishing comes from non-native English speakers, and even AI-assisted lures sometimes carry telltale phrasing (the apocryphal “kindly do the needful” being the most-cited example). One typo in a “from the CEO” message and the recipient gets suspicious.
- Sender domain doesn’t match.
accounts@microsoftsecure.comclaiming to be Microsoft, orsupport@amazon-fulfillment.netclaiming to be Amazon. The mismatch between brand and domain is the first thing most trained users check. - Generic pretext. “Your software needs an update” without naming the software. “Your account has been suspended” without naming the account. The lack of specifics signals a mass campaign rather than a targeted approach.
- Inconsistent branding. Logos rendered at the wrong size, fonts that don’t match the company’s actual style, color schemes that are close but not exact. Modern brand-protection services flag many of these automatically.
- Unusual request. A request for sensitive data, financial information, or credentials that the target wouldn’t normally provide via email. Even unsophisticated users notice when the ask doesn’t fit the relationship.
- Off-hours timing. “Urgent” message at 11 PM on a Saturday from the CEO. Most executives know their own communication patterns and notice when an “urgent” message arrives at a time that doesn’t fit.
- Overly aggressive tone. Threats of account closure, legal consequences, or other negative outcomes. Reads as bullying; trained users report rather than comply.
- Unexpected sender. A vendor or service the target has never used or signed up for. Easy red flag for users who pause for two seconds before clicking.
- Suspicious links and attachments. URL doesn’t match the link text on hover, unexpected attachment types (.iso, .img, .lnk, OneNote files), or attachments from senders the target doesn’t normally receive files from.
- Too-good-to-be-true offers. Unexpectedly high salaries, surprise bonuses, prize wins, urgent investment opportunities. The classic “free money” tell.
The defender side of this list is the user awareness training program; the operator side is the checklist of mistakes to avoid in lure design. Both sides know the same list; the operator’s craft is producing a lure that doesn’t trigger any of them, and the defender’s training is teaching users to recognize the ones that slip through.
Operator tooling in 2026#
The current phishing toolkit, in operator-relevance order:
- GoPhish (Jordan Wright): the de facto open-source phishing engagement platform. Go-based, REST-API-driven, runs a web UI for campaign management with templates, landing pages, click and credential tracking, scheduling, and reporting. Still maintained in 2026 (last commit late 2024, slower release cadence than its heyday but functional). The standard for legitimate red team phishing engagements.
- Evilginx (Kuba Gretzky): the AiTM proxy that defeats phishable MFA. Evilginx 3 is current (community version v3.3.0, April 2024, with the older v2 deprecated); there’s a paid Evilginx Pro that runs ahead of community on features. Stand it up alongside GoPhish for a complete phishing-plus-credential-capture pipeline.
- Social-Engineer Toolkit (SET) (Dave Kennedy, TrustedSec): the original. Includes phishing-page generators, payload deliveries, fake login-page modules, vishing scripts. In maintenance mode as of 2026 (last commit October 2024, Python compatibility fixes) rather than active feature development, but still useful for the modules other tools don’t cover.
- Gophish-Modlishka (Piotr Duszyński): an alternative AiTM proxy. Less polished than Evilginx but with a different architecture; useful when Evilginx is fingerprinted by the target’s defenses.
- Phishing Frenzy (Brandon McCann, Pentest Geek): the historical pioneer of phishing campaign management. Ruby on Rails based. Effectively abandoned after a long pause from 2018 to a single 2023 maintenance commit. Replaced by GoPhish in most modern operator workflows.
- Metasploit: has a small number of auxiliary modules for phishing (
auxiliary/server/capture/http_basic,auxiliary/gather/browser_*) but isn’t a primary phishing framework. Reach for it for the payload-generation side (msfvenom for staged Meterpreter payloads, the browser-exploit auxiliaries) rather than for campaign management.
The 2026 starter stack for a phishing engagement is usually GoPhish for the campaign infrastructure, Evilginx 3 for the AiTM credential capture, a paid Apollo or Hunter.io subscription for OSINT, and a freshly registered (or aged) lookalike domain with DMARC/SPF/DKIM correctly configured. Total operator-side spend before sending the first email runs about $200 and a couple of days of setup.
What this comes down to#
Phishing is the technique that defeats every security investment that doesn’t include the people who work for the organization. The technical controls have gotten better (DMARC alignment is real, EDR catches more, MFA blocks the credential-only attacks). The defenses against phishing-resistant attack techniques (AiTM, helpdesk vishing, MFA fatigue, deepfake-voice executive impersonation) are still maturing, which is why phishing keeps appearing as the top initial-access vector year after year in the Verizon DBIR.
The operator’s job on the offensive side is preparing well enough that the lure looks like something the target was expecting to receive. The defender’s job is teaching their users to recognize the lures that slip through and giving them a fast, painless way to report when they suspect one (a single “Report phishing” button in Outlook beats a 30-minute annual training session by every metric anyone has measured). Both sides are working from the same Cialdini-derived playbook; the operator’s edge is preparation and patience, and the defender’s edge is the user who pauses for two seconds before clicking.