A new analysis of 2.47 million simulated phishing attacks, reported by SecurityWeek, is forcing a long-overdue reckoning in how organizations measure the human layer of their security program. The core finding: the industry's default success metric — the click rate — is a poor proxy for real-world risk. Organizations that optimize for low click rates while ignoring credential submission rates and user reporting behavior are flying blind against the exact attack chain that leads to business email compromise, ransomware initial access, and account takeover.
After 15+ years of running red team engagements and responding to the intrusions that follow a single successful phish, I can tell you this research confirms what IR teams see in the field: the employee who clicks but reports in 90 seconds is an asset. The employee who never clicks the test but hands credentials to a real attacker on a busy Monday morning is the liability your dashboard never showed you. This post breaks down what the research means, why conventional awareness testing fails, and — most importantly — what detections, hunts, and program changes your SOC should implement now.
Technical Analysis: Why Click-Only Metrics Distort Risk
What the Research Actually Measured
The dataset — 2.47 million simulated phishing interactions — gives us statistically meaningful insight into the full phishing kill chain on the human side:
- Delivery — Did the message reach the inbox?
- Open/Click — Did the user engage with the lure?
- Credential submission — Did the user actually surrender data on the landing page?
- Reporting — Did the user alert the security team, and how fast?
Conventional programs stop measuring at step 2. That's the equivalent of a SOC declaring victory because an attacker scanned the perimeter but ignoring whether they authenticated. The analysis demonstrates that click rates and credential-leak rates do not correlate cleanly — user populations with acceptable click rates still leaked credentials at rates that would be catastrophic against real adversary-in-the-middle (AiTM) phishing kits and OAuth consent phishing campaigns, both of which remain dominant initial-access vectors in 2025–2026 incident data.
The Real Attack Chain This Maps To
Modern credential phishing — the kind we respond to weekly — looks like this from the defender's chair:
- Initial lure: HTML attachment, QR code (quishing), or a URL wrapped through legitimate redirectors (open redirects on trusted domains, URL shorteners, marketing platforms) to defeat Secure Email Gateway (SEG) rewriting.
- Harvesting page: Adversary-in-the-middle framework (e.g., Evilginx-class tooling) proxies the real IdP login, capturing the session token and bypassing MFA push/OTP.
- Post-compromise: Inbox rules created to hide replies, OAuth grants to rogue apps, and lateral phishing from the now-trusted internal mailbox.
A simulation program measuring only clicks tells you nothing about steps 2 and 3 — where the actual damage occurs. The research's core recommendation is to instrument credential submission (who types into the fake page) and report rate/velocity (who tells you, and how quickly) as primary KPIs.
Exploitation Status
This is not a CVE-driven story — there is no patch to deploy. The "vulnerability" is a measurement and program-design flaw present in most enterprise awareness programs today. Phishing remains the #1 initial access vector across the incident response cases Security Arsenal handles, and AiTM phishing kits capable of defeating legacy MFA are commodity tooling, not nation-state exclusives. Every organization running click-rate-only metrics should treat this as a live exposure in their security program.
Detection & Response
The most valuable outcome of reframing your metrics is that it forces telemetry alignment: if you're going to measure credential leaks and reporting, you need the detection pipeline that would catch a real version of the same event. Below are production-ready detections for the observable behaviors in this attack chain.
SIGMA Rules
---
title: Office Application Spawning Browser to Suspicious URL
description: Detects Office processes (Word, Excel, Outlook) launching a browser with a URL in the command line, consistent with a user clicking a link from a phishing email or HTML attachment. Tune the TLD and redirector lists to your environment's baseline.
id: 8f3c1a2e-4b6d-4e5f-9a7c-2d1e0f3b4a5c
status: experimental
references:
- https://attack.mitre.org/techniques/T1566/001/
- https://attack.mitre.org/techniques/T1204/002/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.initial_access
- attack.t1566.001
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\outlook.exe'
- '\winword.exe'
- '\excel.exe'
- '\powerpnt.exe'
- '\msedge.exe'
selection_child:
Image|endswith:
- '\chrome.exe'
- '\firefox.exe'
- '\msedge.exe'
- '\brave.exe'
- '\iexplore.exe'
selection_url:
CommandLine|contains:
- '.zip/'
- '.click/'
- '.top/'
- '.quest/'
- '.cfd/'
- 'urldefense'
- 'safelinks'
- 'bit.ly'
- 't.co/'
condition: selection_parent and selection_child and selection_url
falsepositives:
- Legitimate marketing and vendor emails using URL shorteners or click-tracking domains
- SafeLinks/URL Defense rewritten links from sanctioned senders
level: medium
---
title: Browser Connection to Common Phishing Kit Hosting TLDs
description: Detects browser processes initiating network connections to low-reputation TLDs heavily abused by credential phishing kit operators. Correlate with email telemetry before escalating; this is a hunting-grade rule intended to surface candidate AiTM landing pages.
id: 2b7d4e91-1c3a-4f8e-b6d5-9e0a3c7f2d18
status: experimental
references:
- https://attack.mitre.org/techniques/T1566/002/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.initial_access
- attack.t1566.002
logsource:
category: network_connection
product: windows
detection:
selection_browser:
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
selection_tld:
DestinationHostname|endswith:
- '.cfd'
- '.quest'
- '.bond'
- '.lol'
- '.top'
- '.click'
filter_known_cdn:
DestinationHostname|contains:
- 'cloudflare'
- 'akamai'
condition: selection_browser and selection_tld and not filter_known_cdn
falsepositives:
- Rare legitimate sites on budget TLDs; maintain an allowlist of sanctioned business domains
level: low
---
title: Suspicious Inbox Rule Creation Hiding Phishing Replies
description: Detects creation of inbox rules that delete or move messages and mark them read, a hallmark post-credential-theft behavior to hide attacker replies from the victim. Applies to process or audit telemetry capturing mailbox rule creation (e.g., via EWS/Graph audit forwarded to the SIEM).
id: 6e1a9c04-7d2b-4f5a-a8e3-3c0d2b9f4e71
status: experimental
references:
- https://attack.mitre.org/techniques/T1098/002/
- https://attack.mitre.org/techniques/T1114/002/
author: Security Arsenal
date: 2026/01/15
tags:
- attack.persistence
- attack.t1098.002
- attack.collection
- attack.t1114.002
logsource:
category: process_creation
product: windows
detection:
selection:
CommandLine|contains:
- 'New-InboxRule'
- 'Set-InboxRule'
selection_actions:
CommandLine|contains:
- 'DeleteMessage'
- 'MoveToFolder'
- 'MarkAsRead'
- 'SoftDelete'
condition: selection and selection_actions
falsepositives:
- Helpdesk or admin mailbox management scripts; restrict alerting to non-admin accounts and interactive sessions
level: high
KQL — Microsoft Sentinel / Defender
This hunt ties the story together the way the research demands: it finds users who clicked a URL delivered by email, then checks for subsequent anomalous sign-in activity on those same accounts — the signature of a credential actually being leaked and used, not just a link being clicked.
// Hunt: Users who clicked emailed URLs followed by anomalous sign-ins within 24h
// Requires Defender for Office 365 (EmailEvents, UrlClickEvents) and AAD SigninLogs in Sentinel
let lookback = 14d;
let clickedUsers =
UrlClickEvents
| where TimeGenerated > ago(lookback)
| where ActionType in ("ClickAllowed", "ClickBlocked")
| where IsClickedThrough == true or ActionType == "ClickAllowed"
| join kind=inner (
EmailEvents
| where TimeGenerated > ago(lookback)
| where ThreatTypes has_any ("Phish", "Malware") or SenderFromDomain has_any (".")
| project NetworkMessageId, SenderFromAddress, Subject, DeliveryAction
) on NetworkMessageId
| summarize ClickCount = count(), ClickedUrls = make_set(Url, 10), Subjects = make_set(Subject, 5)
by AccountUpn = tostring(ReportId), bin(TimeGenerated, 1h)
| project ClickWindow = TimeGenerated, AccountUpn, ClickCount, ClickedUrls, Subjects;
clickedUsers
| join kind=inner (
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| where RiskLevelDuringSignIn in ("high", "medium")
or tostring(LocationDetails.countryOrRegion) !in ("US")
or AppDisplayName has_any ("Office 365 Exchange Online", "Microsoft Office")
| project SigninTime = TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName,
ResultType, RiskLevelDuringSignIn, LocationDetails, UserAgent
) on $left.AccountUpn == $right.UserPrincipalName
| where SigninTime between (ClickWindow .. ClickWindow + 24h)
| project ClickWindow, AccountUpn, ClickedUrls, SigninTime, IPAddress, LocationDetails, RiskLevelDuringSignIn, AppDisplayName, UserAgent
| order by ClickWindow desc
For environments without Defender for Office 365, the equivalent pattern runs against CommonSecurityLog (SEG/CEF ingestion) correlated with SigninLogs — the analytic logic (click → suspicious auth within 24h) is what matters, and it's exactly the "credential leak" measurement the research advocates, operationalized as a detection.
Velociraptor VQL
During IR triage of a suspected credential phish, this artifact hunts endpoints for browser processes launched with URLs matching phishing infrastructure patterns and correlates active connections — useful for confirming whether a reported click actually reached a harvesting page.
-- Hunt for browser processes with suspicious URLs on the command line
-- and live connections to low-reputation TLDs (phishing landing page triage)
LET procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(chrome|msedge|firefox|brave)'
AND CommandLine =~ '(?i)(\.cfd|\.quest|\.top|\.click|\.bond|login-|verify-|secure-|account-recov)'
LET conns = SELECT Pid AS ConnPid, Name AS ConnName, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE RemotePort in (443, 8443, 8080)
AND Status =~ 'ESTABLISHED'
SELECT Pid, Name, Username, CommandLine, CreateTime,
RemoteAddress, RemotePort
FROM procs
LEFT JOIN conns ON Pid = ConnPid
Remediation / Hardening Script
Click-rate-only programs persist partly because organizations never verify their email security stack actually blocks what the simulation sends. This PowerShell audits your Defender for Office 365 / Exchange Online anti-phishing posture against the behaviors described above — impersonation protection, SafeLinks click-through blocking, and reporting mailbox configuration (so user reports actually reach the SOC).
#Requires -Modules ExchangeOnlineManagement
# Audit MDO anti-phishing, SafeLinks, and user reporting configuration
# Run as an account with Security Reader / Global Reader minimum
Connect-ExchangeOnline
Write-Host "=== Anti-Phishing Policies: Impersonation & Threshold ===" -ForegroundColor Cyan
Get-AntiPhishPolicy | Select-Object Name, Enabled,
PhishThresholdLevel,
EnableTargetedUserProtection,
EnableTargetedDomainsProtection,
EnableMailboxIntelligence,
EnableMailboxIntelligenceProtection,
EnableFirstContactSafetyTip,
EnableSimilarUsersSafetyTip,
EnableSimilarDomainsSafetyTip,
EnableUnusualCharactersSafetyTip |
Format-Table -AutoSize
Write-Host "=== SafeLinks Policies: Click Tracking & Do-Not-Rewrite ===" -ForegroundColor Cyan
Get-SafeLinksPolicy | Select-Object Name, IsEnabled,
DoNotAllowClickThrough,
EnableSafeLinksForEmail,
EnableSafeLinksForTeams,
EnableSafeLinksForOffice,
TrackClicks |
Format-Table -AutoSize
# DoNotAllowClickThrough should be TRUE — blocks users from proceeding to flagged phish pages
Write-Host "=== User Reported Message Settings (Report Submission to SOC) ===" -ForegroundColor Cyan
Get-ReportSubmissionPolicy | Select-Object Identity,
EnableReportToMicrosoft,
ReportJunkToCustomizedAddress,
ReportNotJunkToCustomizedAddress,
ReportPhishToCustomizedAddress,
ReportJunkAddresses,
ReportPhishAddresses |
Format-List
# Verify ReportPhishAddresses points at your SOC mailbox/ticketing ingestion.
# If users' phish reports die in a default mailbox, your reporting metric is fiction.
Write-Host "=== Audit: Inbox Rules Created in Last 7 Days (post-compromise indicator) ===" -ForegroundColor Cyan
$end = Get-Date
$start = $end.AddDays(-7)
Search-UnifiedAuditLog -StartDate $start -EndDate $end `
-Operations "New-InboxRule","Set-InboxRule" -ResultSize 500 |
Select-Object CreationDate, UserIds, Operations |
Format-Table -AutoSize
Remediation: Rebuilding Your Awareness Program Around What Matters
- Redefine KPIs immediately. Replace "click rate" as the headline metric with: credential submission rate (who entered data into the simulated page), report rate, and median time-to-report. Report all four side-by-side to leadership — the delta between click rate and submission rate is your real exposure story.
- Instrument the landing page. Your simulation platform must capture form submission events, not just page loads. If your current vendor can't distinguish a click from a credential entry, that's a procurement gap.
- Close the reporting loop technically. Verify the "Report Phish" button routes to a monitored SOC destination with automated triage (the script above audits this). A report button that emails an unmonitored mailbox produces a vanity metric and zero defensive value.
- Reward reporters, retrain leakers. Users who click and report quickly reduce organizational risk — treat them as detection sensors. Focus coaching on users who submit credentials and never report; that cohort is your statistically proven risk population.
- Test the real kill chain. Include AiTM-style simulations, QR-code lures, and MFA-push-fatigue scenarios in rotation. A program that only tests static link-clicking is training users for the attacks of five years ago.
- Correlate human telemetry with SOC detections. Feed simulation results to your SOC so analysts know which users are high-risk when a real alert fires — and so simulation events don't trigger incident workflows.
- Deploy the detections above. The click-to-sign-in correlation query converts the research's "credential leak" metric into a live detection. Users who click and then authenticate anomalously are your highest-fidelity phishing incidents.
Executive Takeaways
- Click rate is a vanity metric. 2.47 million simulated attacks prove that clicks don't predict credential compromise — submission and reporting behavior do.
- Your awareness program is a sensor network. Treat users as detection telemetry: reporting speed is arguably the most valuable human-layer control you have.
- AiTM phishing defeats legacy MFA. Session-token theft means "we have MFA" is no longer a complete answer; FIDO2/passkeys for high-risk users should be on your 2026 roadmap.
- Audit the plumbing. Anti-phishing policy, SafeLinks click-through blocking, and report routing must be verified, not assumed (see the audit script above).
- Correlate human and identity telemetry. The click→sign-in pattern is your highest-fidelity phishing detection; build it before you need it.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.