Spear Phishing in 2026, Why It Still Works and How to Stop Falling For It

Spear phishing is the oldest trick that keeps paying. After two decades of awareness training, vendor decks, and "click rate" KPIs, it is still the most reliable way into a hardened environment. The reason is uncomfortable: spear phishing exploits trust, not technology, and trust is not something you can patch.

This post is an honest look at what we are seeing in the field in 2026, what has actually changed because of AI, and the small set of controls that hold up.

TL;DR

1. The pattern (research, impersonate, urge action) is unchanged.
2. AI changed the economics, not the playbook. Attackers now run hundreds of personalised campaigns at the cost of one.
3. Defenses that worked in 2018 (training, filters, MFA) still work in 2026, but only if you ship them together.
4. The single highest leverage control is DMARC at p=reject combined with a verified sender directory.

What spear phishing is

Spear phishing is a phishing attack written for one person or one team. The attacker spends real time on reconnaissance: LinkedIn, the company website, recent press, public Slack communities, GitHub commits, conference talk recordings. The output is an email that looks exactly like something the target would expect to receive, from someone they would expect to receive it from.

The danger sits at the boundary between two true things: that the target is trained to be skeptical of strangers, and that the attacker is no longer a stranger. They know the org chart, the project name, the vendor relationship, and the casual phrasing. The skepticism does not fire.

Common shapes of the attack

Business Email Compromise (BEC). A finance team gets an email "from" an executive authorising a transfer or a vendor change. The volume of public data on senior leaders makes this trivial to research.

Vendor Email Compromise. Attacker compromises a real vendor mailbox, watches an active thread for weeks, and intervenes only at the moment a payment is due. They change the bank account and ride the trust of the existing thread.

Whaling. The same attack but aimed at the CEO, CFO, or board. The bait is usually a fake regulator, a fake legal subpoena, or a board document that wants to be opened.

Engineering targeted phishing. Aimed at senior engineers and SREs, usually impersonating a vendor (a cloud provider, a CI tool, a SaaS product). The bait is a "security alert" or a billing issue. Outcome: cookie or token theft from a developer machine, then lateral movement into infrastructure.

What AI actually changed

Three things, none of which are the things vendors talk about.

Volume. A single attacker can now produce thousands of unique, well written, well researched emails per day. The marginal cost of personalising an email approaches zero.

Quality. The grammar tells in old phishing emails are gone. "Sent from my iPhone" typos are gone. The voice matches the target's company. None of this is a deepfake. It is just decent writing at scale.

Speed of pivot. When a campaign is detected and one bait stops working, the attacker writes a new bait in minutes. The old assumption that "we will block the IOC and move on" no longer applies. The bait itself is the IOC, and there are infinite baits.

What AI did not change: the call to action is still "click this link" or "wire money" or "give us your password". The end state is what you defend.

Real engagements (lightly anonymised)

Bengaluru fintech, December 2025

A series of emails arrived in the finance team's inbox over three weeks, each addressing a real ongoing onboarding for a real vendor. The emails were sent from a domain one character off from the legitimate sender (a homoglyph). The final email included a bank account change, signed by the "operations head" at the vendor. Wire was authorised. Loss: 1.4 crore. Recovery: nil.

What broke the chain in the post mortem: nobody called the vendor on a known good number to confirm the change.

Government supplier, March 2026

An engineering manager received a private GitHub repo invitation. The invite arrived on a real GitHub email, sent from a real (compromised) developer account. Cloning the repo triggered a malicious post-install hook. The hook stole the developer's GitHub PAT and AWS credentials.

What broke the chain: the engineering team did not isolate developer credentials in a secrets manager and was using a long-lived PAT.

Indian regulator, January 2026

A spearphishing email "from" a senior officer at the regulator told a vendor's legal team that a new compliance form was required, with a link to a portal. The portal was a clone, but it asked for SSO credentials. Two of the three legal team members entered them. MFA was on, but the attackers proxied the live MFA prompt through evilginx and walked into the SSO session.

What broke the chain: phishing-resistant MFA (FIDO2) was not enforced. SMS and push MFA can be relayed.

Controls that earn their seat

We tend to give organisations the same five recommendations after these engagements, in this order.

1. DMARC at p=reject across every owned domain, with BIMI and verified sender directory if you can. This is the single highest leverage control because it kills the most common bait (a perfectly spoofed "from" address). It costs nothing if your mail platform is modern.

2. FIDO2 / WebAuthn MFA, not push, not SMS. Push MFA is a soft target. Phishing-resistant authenticators raise the bar enough that the attack stops paying.

3. Out of band confirmation rule for every payment authorisation, vendor change, and password reset. This is the human side of MFA. The control is not "we have a process", it is "we have a process and a written rule that this process cannot be skipped, ever, even if the request is from the CFO". Test the rule with simulations.

4. Phishing simulations targeted to roles, not to "everyone". A blanket simulation tells you almost nothing. A simulation that mimics what an attacker would actually send to your finance team in your sector tells you which roles need help.

5. Awareness training that includes AI generated examples. If your training deck still says "look for grammar mistakes", update it. Show the team what a clean AI written spearphish looks like. Then show them what a real one looks like (with permission). The point is not to scare. The point is to set the expectation that "it sounded like them" is no longer evidence.

What does not earn its seat

Generic "phishing awareness" videos that get shown once a year. The half life of the awareness is days, not months.

A standalone "AI phishing detection" tool, on its own. Some of these are useful as part of a stack. None are useful as a single line of defense.

Aggressive "click rate" KPIs that drive teams to game the metric. Any KPI that makes a SOC analyst hide a real incident to keep the click rate down is doing harm.

Closing note

Spear phishing is the attack that matches your maturity. A team with no DMARC and SMS MFA gets phished by an intern with a free trial of an AI writer. A team with FIDO2 and an enforced callback rule gets phished only by adversaries who are willing to spend weeks on reconnaissance, and even then, the spend is no longer worth the prize.

Pick the version of phishing you want to be vulnerable to, and design accordingly.

If you want a controlled spear phishing engagement against your own team, we run them as part of red team programs. Request a briefing.