A well-crafted phishing email no longer looks like a scam. In 2026, large language models write the copy, clone a company’s exact tone, and generate a fake Microsoft sign-in page in under a minute. The FBI’s Internet Crime Complaint Center (IC3) logged $20.9 billion in reported cybercrime losses for 2025, and email-based fraud, business email compromise, phishing, and government impersonation combined, topped $4 billion, up 46% year over year. This tutorial walks through a repeatable, 12-step process for detecting phishing emails at the header level, the content level, and the identity level, including the adversary-in-the-middle (AiTM) and ClickFix techniques that dominated threat reports through August 2026. By the end, you’ll have a working Python triage script, a set of detection queries, and a documented playbook your team can run today.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What You’ll Need Before You Start (Prerequisites)
This guide mixes hands-on scripting with policy and process changes, so you’ll need a mix of technical access and organizational buy-in. None of the tooling here requires an enterprise budget: everything below runs on a laptop or a single cloud VM.
- Python 3.11 or newer — for the header analysis and triage scripts (test with
python3 --version) - Access to DNS records for your domain (or admin console access) to check SPF, DKIM, and DMARC
- A mail admin console — Microsoft 365 Defender, Google Workspace Admin, or your MTA’s logs
- A sample of raw email files (.eml) — export a few real or test phishing emails with full headers intact
- Optional: Microsoft Sentinel, Defender XDR, or another SIEM — for the AiTM detection query in Step 5
- A terminal with curl, dig, and mail (or msmtp) installed for the reporting automation in Step 9
- 90 minutes of uninterrupted time to work through all 12 steps end to end
If you manage email security for an organization rather than just your own inbox, loop in whoever owns your DNS zone and your identity provider before Step 6 — you’ll be changing conditional access and DMARC enforcement settings that affect every user.
Why Phishing Detection Changed in 2026: AI, ClickFix, and AiTM
Three shifts explain why the old advice, look for typos and a mismatched sender name, stopped being sufficient. First, generative AI removed the grammar and formatting tells that used to give phishing away; large language models now write flawless, context-aware lures. Second, ClickFix attacks, which trick a user into pasting a malicious command into the Windows Run dialog or PowerShell under the guise of “fixing” a CAPTCHA or verification error, went mainstream in 2026 and are now used by financially motivated crews and nation-state groups alike. Third, adversary-in-the-middle (AiTM) phishing kits proxy the real login page in real time, capturing not just a password but the live session cookie, which lets an attacker bypass multi-factor authentication entirely.
Threat intelligence from August 2026 confirms identity has become the preferred attack surface. Security Signals reporting covering July 28 to August 11, 2026 lists MITRE ATT&CK technique T1566 (phishing) as a top initial-access tactic, with campaigns using device-code phishing, fake recruiter outreach, Google Ads lures, procurement scams, and AiTM proxies. Microsoft 365 remains the most targeted environment because a single compromised identity can unlock email, SharePoint, Teams, and OneDrive in one move. IBM’s 2025 Cost of a Data Breach report found that roughly 1 in 6 breaches now involve AI on the attacker’s side, most commonly for phishing content generation and deepfake impersonation.
| Metric | 2025-2026 Figure | Source |
|---|---|---|
| Total IC3 cybercrime losses (2025) | $20.9 billion | FBI IC3 2025 Annual Report |
| Business email compromise (BEC) losses (2025) | $3.046 billion | FBI IC3 2025 Annual Report |
| Combined email-fraud losses (BEC + phishing + gov impersonation) | Over $4 billion, up 46% YoY | FBI IC3 / Red Sift analysis |
| Phishing as data breach initial vector | 16% of breaches, avg $4.8M per breach | IBM Cost of a Data Breach 2025 |
| Breaches involving attacker use of AI | 1 in 6 breaches (37% used it for phishing content) | IBM Cost of a Data Breach 2025 |
| Stolen/compromised credentials as breach initial vector | 22% of breaches | Verizon DBIR 2025 |
| Median time from opening email to clicking a phishing link | 21 seconds | Verizon DBIR |
| Median time from click to entering credentials | 28 seconds | Verizon DBIR |
| Fortune 500 companies with DMARC published, 2026 | ~95%, 62.7% at full p=reject enforcement | EasyDMARC 2026 Adoption Report |
Read together, those numbers say two things: attackers move fast (under a minute from open to credential entry), and detection has to happen before the click, not after. The next twelve steps build that pipeline.
Step 1: Audit Your Email Authentication Records (SPF, DKIM, DMARC)
Before you can detect a spoofed email, you need to know whether your own domain is protected against being spoofed, and whether the sender domains you receive mail from publish authentication records at all. SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance) are the three DNS-based checks that let a receiving mail server verify a message actually came from where it claims. Run these lookups against your own domain and a handful of common vendor domains you correspond with:
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT selector1._domainkey.example.com +short
# Quick pass/fail summary using a public checker (no data leaves your terminal
# beyond the DNS query itself)
dig TXT _dmarc.example.com +short | grep -i "p="A healthy DMARC record looks like v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100. If your policy still reads p=none, you’re only monitoring, not blocking, spoofed mail sent from your own domain. As of 2026, roughly 95% of Fortune 500 companies publish a DMARC record, and just under two-thirds enforce it at p=reject, according to EasyDMARC’s 2026 adoption report. If you’re below that bar, moving from p=none to p=quarantine for 30 days, then to p=reject, is the single highest-leverage change you can make this week.
Reading the Authentication-Results header
Every message that passes through a modern mail gateway gets stamped with an Authentication-Results header showing how SPF, DKIM, and DMARC each resolved. This is the single fastest manual check for a suspicious email: open the raw message source (in Gmail, “Show original”; in Outlook, “View message source”) and look for lines containing spf=, dkim=, and dmarc=. Anything other than pass on all three is a signal worth investigating further, though it is not proof of phishing on its own, since some legitimate mailing-list and forwarding setups also fail these checks.
Step 2: Build a Header Analysis Script
Manually reading headers doesn’t scale past a handful of emails a day. The script below parses a raw .eml file, pulls the authentication results, checks whether the Reply-To address quietly diverges from the From address (a classic BEC tell), and flags urgency language in the subject line. It’s intentionally minimal so you can extend it with your own rules.
import email
from email import policy
from email.parser import BytesParser
def analyze_headers(raw_path):
with open(raw_path, "rb") as f:
msg = BytesParser(policy=policy.default).parse(f)
auth_results = msg.get("Authentication-Results", "").lower()
spf_pass = "spf=pass" in auth_results
dkim_pass = "dkim=pass" in auth_results
dmarc_pass = "dmarc=pass" in auth_results
from_header = (msg.get("From") or "").strip()
reply_to = (msg.get("Reply-To") or "").strip()
subject = (msg.get("Subject") or "").lower()
risk_score = 0
if not spf_pass:
risk_score += 25
if not dkim_pass:
risk_score += 25
if not dmarc_pass:
risk_score += 20
if reply_to and reply_to != from_header:
risk_score += 15
if any(w in subject for w in ("urgent", "verify now", "suspended", "act now")):
risk_score += 15
return {
"from": from_header,
"reply_to_mismatch": bool(reply_to and reply_to != from_header),
"spf_pass": spf_pass,
"dkim_pass": dkim_pass,
"dmarc_pass": dmarc_pass,
"risk_score": risk_score,
}
if __name__ == "__main__":
result = analyze_headers("suspect_email.eml")
print(result)Save this as header_check.py, drop a few sample .eml files in the same folder, and run it against both known-clean and known-phishing samples so you can see how the score behaves before trusting it on live traffic. In Step 11 you’ll fold this into a larger toolkit.
Step 3: Create a 60-Second Phishing Triage Checklist
Not every employee can run a Python script, and they shouldn’t have to. Give your team a short, weighted checklist they can apply to any suspicious message in under a minute. Weight the signals so a single odd detail doesn’t trigger a false alarm, but two or three together do.
| Signal | What to check | Risk weight |
|---|---|---|
| Authentication headers | SPF, DKIM, or DMARC shows fail or none | High |
| Sender/display name mismatch | Display name says “IT Support” but the address is a personal Gmail or lookalike domain | High |
| Urgency or threat language | “Your account will be suspended,” “verify within 24 hours” | Medium |
| Unexpected MFA or “fix this issue” prompt | Asks you to re-authenticate, paste a command, or run a script (ClickFix pattern) | High |
| Link destination vs. link text | Hover reveals a domain that doesn’t match the displayed text or expected vendor | High |
| Generic greeting on a “personal” request | “Dear Customer” on a message claiming to be from your manager | Low-Medium |
| Attachment type | .zip, .iso, .js, or macro-enabled Office files from an unknown sender | High |
| Request for payment, gift cards, or credential re-entry | Any unsolicited request to move money or “confirm” a password | High |
Two or more “High” weight signals means the message should be reported, not investigated further by the recipient. Print this table, put it on your intranet, and reference it directly in your simulated phishing training (Step 8) so the checklist and the training reinforce each other.
Keep the checklist to one page. Security teams routinely undermine their own reporting rates by publishing a 20-item PDF nobody reads under time pressure. The whole point of a weighted, 60-second checklist is that an employee can run through it while a message is still open on screen, decide in one glance whether two or more high-weight signals are present, and act, rather than closing the tab, forgetting about it, and never reporting anything at all.
Step 4: Recognize ClickFix and Fake Verification Lures
ClickFix is the technique most likely to slip past both spam filters and a trained eye, because the malicious payload never arrives as a file attachment. Instead, the victim lands on a page that mimics a CAPTCHA, a Windows error, or a document-viewer “fix,” and is instructed to press Win+R, paste a string, and hit Enter. That string is usually a PowerShell one-liner that downloads and executes malware, all without triggering an antivirus file-scan because nothing is ever saved to disk in the initial step. Threat intelligence from August 2026 describes ClickFix as having “gained momentum” across unrelated threat actor groups, including financially motivated crews and DPRK-linked operators, precisely because it bypasses traditional attachment-based detection.
Train your team on one absolute rule: no legitimate verification, CAPTCHA, or “fix” process will ever ask you to open the Run dialog or a terminal and paste something you copied from a web page. If a browser tab tells you to do that, close the tab. On the technical side, block or alert on PowerShell processes spawned by explorer.exe shortly after clipboard activity, since that parent-child relationship is unusual outside of ClickFix-style attacks. Most EDR platforms, including Microsoft Defender for Endpoint, ship detection rules for this pattern; confirm yours is enabled rather than assuming it is on by default.
Step 5: Detect Adversary-in-the-Middle (AiTM) Session Theft
AiTM phishing kits sit as a reverse proxy between the victim and the real login page (Microsoft’s own identity documentation describes attackers “replaying the session with the stolen session cookie before the token expiration time”). Because the victim is authenticating against the genuine service through the proxy, MFA prompts appear and get satisfied normally, but the attacker captures the resulting session cookie in real time and reuses it, sidestepping the password and the MFA challenge entirely. This is why “we have MFA enabled” is no longer sufficient reassurance on its own.
The detection signal that works best is impossible travel: a session token used from two geographically distant locations, or two different IP ranges, within a short window. If you run Microsoft Sentinel or Defender XDR, the following KQL query is a practical starting point for surfacing candidate AiTM sessions across sign-in logs:
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| summarize
Countries = make_set(LocationDetails.countryOrRegion),
IPs = make_set(IPAddress),
SignInCount = count()
by UserPrincipalName, AppDisplayName, bin(TimeGenerated, 1h)
| where array_length(Countries) > 1
| where SignInCount >= 2
| project TimeGenerated, UserPrincipalName, AppDisplayName, Countries, IPs, SignInCount
| order by TimeGenerated descTune the time window and country threshold to your organization’s normal travel patterns before turning this into an alert, otherwise VPN users and legitimate business travelers will generate noise. Pair this with Conditional Access token protection (sign-in binding) if your Microsoft 365 licensing tier includes it, since that feature specifically ties a session token to the device it was issued on, neutralizing the token-replay half of an AiTM attack even if the credential was captured.
Step 6: Lock Down Microsoft 365 and Google Workspace Identity Settings
Microsoft 365 remains the single most targeted identity environment in 2026 threat reporting, largely because a compromised account unlocks email, file storage, chat, and often connected SaaS tools through OAuth in one step. Start with these four settings, in order of impact:
- Disable legacy authentication protocols (POP, IMAP, SMTP AUTH) unless a specific application still requires them, since these protocols don’t support modern MFA and are a favorite AiTM bypass route
- Require phishing-resistant MFA (FIDO2 security keys or passkeys) for admins and any account with access to sensitive data, rather than SMS or push-notification MFA alone
- Restrict third-party OAuth app consent to admin-approved apps only, closing the “consent phishing” path where a user grants a malicious app permissions instead of typing a password
- Enable mailbox audit logging and inbox rule alerts, since attackers who do get in often create a hidden forwarding rule to exfiltrate future mail silently
Google Workspace administrators should apply the equivalent settings: enforce 2-Step Verification with security keys for admins, review third-party app access under Security > API Controls, and turn on advanced phishing and malware protection in Gmail settings, which adds delayed-delivery scanning for messages with suspicious attachments or spoofed sender patterns.
Step 7: Layer AI-Powered Email Filtering on Top of Native Protection
Native filtering in Microsoft 365 or Google Workspace catches known-bad senders and signatures well, but AI-generated phishing content is specifically designed to avoid pattern-matching. A third-party or add-on filtering layer that scores behavioral signals, sending-domain age, unusual login geography, first-time-sender status, adds a second net. Pricing varies by vendor and tier, but the 2026 market has converged around a few clear price bands:
| Tool | Entry tier price | Advanced tier price | Best fit |
|---|---|---|---|
| Microsoft Defender for Office 365 | $2.00/user/month (Plan 1) | $5.00/user/month (Plan 2) | Organizations already on Microsoft 365, want native integration |
| Proofpoint Essentials | $2.75/user/month (Business) | $5.33/user/month (Professional) | Mid-market teams wanting a dedicated gateway plus reporting |
| Mimecast | ~$3.50/user/month (base, 1,000+ seats) | $5-8/user/month (with Targeted Threat Protection) | Larger enterprises needing archiving plus advanced threat modules |
None of these tools is a silver bullet against a well-executed AiTM or ClickFix attack, since both techniques are designed to look like normal, authenticated user behavior after the initial click. Treat filtering as the first layer, not the last, and pair it with the detection steps above rather than relying on it alone.
Step 8: Run Realistic Simulated Phishing Campaigns
KnowBe4’s 2025-2026 Phishing by Industry Benchmarking Report puts the global baseline “phish-prone percentage,” the share of employees who click or enter data on a simulated phishing test before any training, at roughly 33%. After twelve months of ongoing, varied simulations, that figure drops to around 4%. The gap between those two numbers is the entire argument for running simulations regularly instead of once a year.
Build your simulation library around the actual techniques covered in this guide, not generic “you’ve won a prize” templates: a fake IT ticket asking the user to “verify” through a ClickFix-style Run-dialog prompt, a spoofed vendor invoice with a lookalike domain, and a fake Microsoft sign-in page hosted on a proxy-style URL to test AiTM awareness. Fortinet’s 2025 research found that the share of organizations running phishing simulations actually dropped slightly, from 86% in 2024 to 73% in 2025, even as attack sophistication rose, so consistency here is a genuine differentiator, not table stakes everyone already has covered.
Step 9: Automate Reporting and Response with a Script
Once your team can spot a suspicious email, make reporting it as close to zero-friction as possible. The script below takes a raw .eml file, extracts headers and any URLs as indicators of compromise (IOCs), and forwards the original message to your SOC or phishing-reports mailbox for triage.
#!/bin/bash
# report-phish.sh - triage and forward a suspicious .eml to the SOC mailbox
EML_FILE="$1"
SOC_MAILBOX="[email protected]"
if [ -z "$EML_FILE" ]; then
echo "Usage: ./report-phish.sh suspicious_email.eml"
exit 1
fi
echo "== Headers =="
grep -Ei "^(From|Reply-To|Return-Path|Received-SPF):" "$EML_FILE"
echo "== URLs found =="
grep -Eo 'https?://[^ ">]+' "$EML_FILE" | sort -u | tee /tmp/iocs_urls.txt
echo "== Forwarding to SOC mailbox =="
cat "$EML_FILE" | mail -s "Phishing Report: $(basename "$EML_FILE")" "$SOC_MAILBOX"
echo "Done. IOCs saved to /tmp/iocs_urls.txt"Wire this script to a “Report Phishing” button in Outlook or Gmail (both platforms support custom add-ins that call a script or webhook), so users never have to think about the mechanics of forwarding headers correctly. Verizon’s DBIR benchmark puts the average user-reporting rate at around 20% globally, well below where it needs to be, and friction is the most common reason cited for that gap.
Step 10: Monitor Detection Metrics and Tune Rules Monthly
A detection pipeline that isn’t measured tends to drift, either producing so many false positives that people ignore it or missing new lure patterns entirely. Track a small set of metrics monthly rather than trying to boil the ocean:
- Report rate: percentage of phishing simulations reported (not just avoided) by users
- Median time-to-report: how long between delivery and a user flagging the message
- False positive rate: legitimate mail your filters or scripts flagged incorrectly
- AiTM/impossible-travel alert volume: trending up or down after tuning the KQL query from Step 5
- DMARC enforcement rate: percentage of inbound domains you correspond with that actually publish and enforce DMARC
Review these numbers with whoever owns security awareness training and whoever owns your SIEM in the same meeting. Detection rules and training content should move together: a spike in ClickFix-style reports should immediately update your next simulation template, not sit in a dashboard nobody revisits.
Build these five numbers into a single monthly one-pager rather than a sprawling dashboard. Security leadership rarely has time to dig through a SIEM console, but a trend line showing report rate climbing while false positives hold steady is exactly the evidence needed to justify continued investment in the toolkit you built in Steps 2 and 9.
Step 11: Stress-Test Defenses with a Tabletop Exercise
Run a tabletop exercise at least twice a year that assumes detection failed, not that it worked. A useful scenario for 2026: “An employee pasted a ClickFix command into PowerShell after a fake CAPTCHA. The resulting malware harvested a Microsoft 365 session token via a local infostealer. The attacker used that token from an unfamiliar IP forty minutes later.” Walk your incident responders through every step: how would you have caught the PowerShell execution, how would the impossible-travel query from Step 5 have fired, who gets paged, and how fast can you revoke the session token and force re-authentication across the tenant?
Time each phase of the exercise. If detection-to-containment takes longer than an hour in a tabletop with no real pressure, it will take considerably longer during an actual incident. Feed the gaps you find directly back into Steps 5, 6, and 9.
Step 12: Document the Playbook and Assign Ownership
Everything above only holds up if it survives someone’s vacation or a staff change. Write down, in a shared runbook, who owns DNS and DMARC records, who owns the Sentinel/Defender query tuning, who receives the phishing-reports mailbox, and who has authority to force a tenant-wide session revocation during an active incident. Assign a named backup for each role. A playbook that lives only in one engineer’s head is not a playbook, it’s a single point of failure that happens to also be a person.
Review and re-approve the document quarterly, and update it any time you change identity providers, email filtering vendors, or SIEM platforms. Link it from your incident response plan so responders aren’t hunting for it mid-incident.
The Complete Working Project: Phishing Triage Toolkit
Combining the header analysis from Step 2 with a URL risk check gives you a single command-line tool that scores any .eml file and returns a verdict. This is intentionally lightweight, it’s a triage aid to prioritize human review, not a replacement for your email security gateway.
#!/usr/bin/env python3
"""phishing_triage.py - lightweight phishing email triage toolkit (2026)"""
import argparse, json, re, sys
from email import policy
from email.parser import BytesParser
SUSPICIOUS_TLDS = {".zip", ".mov", ".top", ".xyz", ".click", ".gq"}
URGENCY_WORDS = ["urgent", "verify now", "act now", "suspended", "confirm your identity", "security alert"]
def load_email(path):
with open(path, "rb") as f:
return BytesParser(policy=policy.default).parse(f)
def score_headers(msg):
score, reasons = 0, []
auth = (msg.get("Authentication-Results") or "").lower()
for check, weight in (("spf=pass", 20), ("dkim=pass", 20), ("dmarc=pass", 20)):
if check not in auth:
score += weight
reasons.append(f"{check.split('=')[0].upper()} did not pass")
from_addr = (msg.get("From") or "").strip()
reply_to = (msg.get("Reply-To") or "").strip()
if reply_to and reply_to != from_addr:
score += 15
reasons.append("Reply-To differs from From address")
subject = (msg.get("Subject") or "").lower()
if any(w in subject for w in URGENCY_WORDS):
score += 10
reasons.append("Subject line uses urgency/pressure language")
return score, reasons
def score_urls(msg):
score, reasons, urls = 0, [], []
body = msg.get_body(preferencelist=("plain", "html"))
text = body.get_content() if body else ""
found = re.findall(r'https?://[^\s"\'<>]+', text)
for u in found:
urls.append(u)
if any(tld in u.lower() for tld in SUSPICIOUS_TLDS):
score += 15
reasons.append(f"Suspicious TLD/pattern in URL: {u}")
return score, reasons, urls
def main():
parser = argparse.ArgumentParser(description="Score a .eml file for phishing risk")
parser.add_argument("eml_file")
args = parser.parse_args()
msg = load_email(args.eml_file)
h_score, h_reasons = score_headers(msg)
u_score, u_reasons, urls = score_urls(msg)
total = min(h_score + u_score, 100)
verdict = "LIKELY PHISHING" if total >= 50 else "SUSPICIOUS" if total >= 25 else "LOW RISK"
print(json.dumps({
"file": args.eml_file,
"risk_score": total,
"verdict": verdict,
"reasons": h_reasons + u_reasons,
"urls_found": urls,
}, indent=2))
if __name__ == "__main__":
sys.exit(main())Sample output on a suspicious invoice email with a spoofed Reply-To address and a failed DKIM check looks like this:
{
"file": "invoice_urgent.eml",
"risk_score": 70,
"verdict": "LIKELY PHISHING",
"reasons": [
"DKIM did not pass",
"DMARC did not pass",
"Reply-To differs from From address",
"Subject line uses urgency/pressure language"
],
"urls_found": [
"https://secure-invoice-verify.top/login"
]
}Wire the exit code into your reporting script from Step 9 so any file scoring above 50 automatically triggers the forward-to-SOC workflow, closing the loop between detection and response without a human needing to run two separate tools.
Common Pitfalls When Detecting Phishing Emails
- Treating SPF/DKIM/DMARC failures as absolute proof. Legitimate forwarding, mailing lists, and some CRM tools legitimately fail these checks. Use them as one weighted signal, not a binary verdict.
- Skipping the ClickFix training angle. Most anti-phishing training still focuses on links and attachments and never mentions the Run-dialog/PowerShell pattern, leaving a real gap against one of 2026’s fastest-growing techniques.
- Assuming MFA alone stops account takeover. AiTM kits proxy MFA challenges in real time; only phishing-resistant methods like FIDO2 keys or token-binding meaningfully close this gap.
- Ignoring OAuth consent phishing. Teams that lock down passwords tightly often leave third-party app consent wide open, letting an attacker request persistent mailbox access without ever touching a password.
- Running phishing simulations once a year. A single annual test does not build the muscle memory that ongoing, varied simulations do, and the phish-prone-percentage data backs that up clearly.
- Not tuning detection queries for your organization’s travel patterns. An impossible-travel rule with no tolerance for VPN exit nodes or genuine business travel will generate so many false positives that analysts start ignoring it.
Troubleshooting: 8 Common Detection Problems and Fixes
| Problem | Likely cause | Fix |
|---|---|---|
| Header script reports SPF fail on legitimate mail | Sender uses a third-party ESP (Mailchimp, SendGrid) without proper SPF alignment | Check for a passing DKIM signature instead; treat SPF-only failure as lower weight |
| DMARC reports show your own domain “failing” its own policy | A legitimate internal system (helpdesk, CRM) sends as your domain without being in your SPF record | Add the sending IP/service to your SPF record or set up DKIM signing for that service |
| KQL impossible-travel query returns hundreds of false positives | Corporate VPN or mobile carrier NAT makes IP geolocation unreliable | Filter out known corporate VPN egress IPs; raise the country-count and time-window thresholds |
| Users report legitimate emails as phishing constantly | Checklist weighting is too aggressive, or a real vendor’s emails look “spoofy” by design | Add trusted-sender allowlist; refine the checklist with real examples from your environment |
| ClickFix-style PowerShell execution isn’t being flagged by EDR | Detection rule for explorer.exe-spawned PowerShell after clipboard paste is disabled by default | Explicitly enable the relevant attack-surface-reduction or behavioral rule in your EDR console |
| Triage script throws an error on certain .eml files | Message uses a nonstandard MIME structure or missing Authentication-Results header | Wrap header/body lookups in try/except and default to a neutral score rather than crashing |
| Report-phish script fails to send via “mail” command | No local MTA configured on the host running the script | Install and configure msmtp or postfix as a relay, or switch to an API-based mail send (e.g., Graph API) |
| Simulated phishing click rates aren’t improving | Same template reused repeatedly; training feels punitive rather than instructive | Rotate lure types (ClickFix, AiTM, invoice fraud) and pair failures with a two-minute explainer, not a lecture |
Advanced Tips for Defending Against 2026-Era Phishing
Once the twelve core steps are in place, a few advanced moves push detection further. First, enable Conditional Access token protection (also called sign-in binding) if your Microsoft 365 licensing supports it; this cryptographically ties a session token to the device that requested it, which neutralizes AiTM token replay even after a successful credential and MFA capture. Second, treat AI coding and chat assistants as part of your identity attack surface, not just your endpoint attack surface: a documented issue in August 2026 showed publicly shared AI assistant conversations getting indexed by search engines, which can leak internal context useful for a targeted spear-phishing pretext. Audit sharing defaults on any AI tools your team uses.
Third, extend your supply-chain review to AI infrastructure components, not just traditional software dependencies; an August 2026 supply-chain compromise affecting LiteLLM-based AI infrastructure is a reminder that the tooling teams use to build AI features is itself now a phishing and credential-theft target. Finally, feed your SOC’s UEBA (User and Entity Behavior Analytics) tooling with the same triage script output from this guide, since behavioral baselines improve fastest when they’re trained on your organization’s actual phishing traffic rather than generic vendor models alone.
Frequently Asked Questions
How can I tell if a phishing email was written by AI?
You mostly can’t from writing quality alone anymore. AI-generated phishing has largely erased the grammar and formatting tells that used to be reliable. Lean on authentication headers, sender domain history, and link destination instead of writing style.
What is a ClickFix attack and how is it different from a normal phishing email?
ClickFix tricks a victim into manually pasting and running a malicious command via the Windows Run dialog or PowerShell, framed as “fixing” a CAPTCHA or verification error. Unlike a malicious attachment, no file is downloaded in the first step, which lets it slide past traditional attachment scanning.
Does multi-factor authentication stop phishing?
It stops most credential-only phishing, but adversary-in-the-middle (AiTM) kits proxy the real MFA challenge in real time and steal the resulting session cookie, bypassing MFA entirely. Phishing-resistant MFA methods (FIDO2 keys, passkeys) close this gap; SMS and push-based MFA do not fully close it.
What’s the difference between SPF, DKIM, and DMARC?
SPF lists which mail servers are allowed to send on behalf of a domain. DKIM cryptographically signs outgoing mail so the receiver can verify it wasn’t altered in transit. DMARC ties the two together and tells receiving servers what to do (monitor, quarantine, or reject) when a message fails both checks.
How often should we run phishing simulation training?
Monthly or bimonthly, with varied lure types, produces materially better results than an annual test. Industry benchmarking shows baseline click rates around 33% before training, dropping to roughly 4% after twelve months of ongoing, varied simulations.
What should I do if I already clicked a phishing link or ran a ClickFix command?
Disconnect the device from the network immediately, report it to your security team, and assume both the account and the endpoint are compromised. Force a password reset and revoke active session tokens for the affected account, then have IT scan the endpoint before reconnecting it.
Are free email security tools good enough for a small business?
Native filtering in Microsoft 365 or Google Workspace catches the majority of bulk and known-bad phishing. Smaller organizations with limited budgets should prioritize DMARC enforcement and phishing-resistant MFA first, since both are largely free, before paying for a third-party filtering layer.
How fast do attackers use a stolen session token after an AiTM attack?
There’s no single validated industry-wide average, but Microsoft’s own incident analysis has documented attackers using a stolen session cookie within roughly five minutes of theft to launch follow-on fraud, underscoring why fast detection and automated session revocation matter more than manual review.
Do I need a SIEM to use the KQL detection query in this guide?
Yes, the query in Step 5 is written for Microsoft Sentinel or Defender XDR’s Kusto Query Language. If you don’t run either, most SIEM platforms (Splunk, Elastic, Wazuh) support an equivalent impossible-travel or multi-geo sign-in detection rule; the underlying logic, flagging one identity authenticating from multiple distant locations in a short window, translates directly.
Related Coverage
- How to Set Up SPF, DKIM, and DMARC: 12 Steps, 90 Min [2026]
- Proofpoint vs Mimecast vs Defender O365: $41 Gap [2026]
- Why Credential Stuffing Attacks Keep Bypassing Multi-Factor Authentication
- Microsoft Defender ShieldBreak Zero-Day: 100% Bypass [2026]
- Build an Incident Response Plan: 12 Steps, 90 Min [2026]
- Data Breaches Top 471M Victims in H1 2026 [2026]
For broader coverage of ransomware, zero-days, and identity threats, see our cybersecurity threats hub. External references used in this guide: the FBI Internet Crime Complaint Center (IC3), IBM’s Cost of a Data Breach Report, the Verizon Data Breach Investigations Report, Check Point Research’s August 2026 threat intelligence report, the Malwarepatrol Security Signals report, and the NIST small business phishing guidance.
