>
av.Amit VijayanCYBERSECURITY & RESEARCHLet\u2019s connect
Back to the library

Threat Hunting Playbooks

After the Last Update: Hunting On-Prem Exchange When There Is No Next Patch

AV
Amit Vijayan
10 min read
Thumbnail for: After the Last Update: Hunting On-Prem Exchange When There Is No Next Patch

October 13, 2026 was an ordinary Patch Tuesday with an unordinary footnote. Microsoft shipped security updates for Exchange Server Subscription Edition (SE) and, for the last time, for Exchange 2016 and 2019 under the Extended Security Update (ESU) program. October 2026 was the final month of ESU Period 2, which ran from May through October 2026. From November onward, SE is the only on-premises Exchange that gets security updates. If you still run 2016 or 2019, there is no next patch — not delayed, not behind a paywall. Every vulnerability found in those builds from here on is permanent.

This is Part 4 of the exposed-edge series, and it breaks the pattern of the first three parts. Ivanti, Fortinet, and NetScaler were stories about a patch that existed and a compromise that survived it. Exchange is a story about a patch that will never exist. What follows is not a post-patch check; it is the triage you run when patching has stopped being an option.

What actually ended — and what did not

Exchange 2016 and 2019 both reached end of support on October 14, 2025. ESU bought them a year of Critical and Important updates in two periods, and that year is now over. Microsoft will no longer test those versions for new vulnerabilities, so a future Exchange advisory will simply not list them. The servers keep serving mail. What stops is the entire remediation half of your vulnerability program for them.

Subscription Edition is the only way forward on premises. SE shipped July 1, 2025, is code-equivalent to Exchange 2019 CU15, and follows the Modern Lifecycle Policy: no fixed end date, as long as you stay current and keep the subscription licensing active. Upgrading from Exchange 2019 CU14 or CU15 to SE is an in-place move that works like installing a cumulative update, including in a database availability group. One caution: SE's first full cumulative updates have slipped repeatedly, so do not plan around a future CU saving you. The supported baseline today is SE RTM plus its security updates, and SU11 (KB5128895) is the current one.

Scale the problem before you scope it. The /news/ exposure tracker currently counts 124,185 internet-visible Exchange hosts on Shodan. That number does not break out versions, but the attack surface is not a handful of laggards — and the fraction that just became unpatchable is the fraction attackers will now enumerate first.

October's evidence: two disclosures that frame the hunt

The first is CVE-2026-96940, published out of band on October 2, 2026 as a re-release of September's updates. It is a weak-authorization flaw, CVSS 8.8, that lets an authenticated attacker read other users' mailboxes — messages and attachments — inside the same organization. No cross-tenant access, no admin account required. Microsoft rated it "Exploitation More Likely," its strongest rating short of confirmed exploitation, and listed no workaround — the security update is the only fix. For 2016 and 2019, that fix was ESU-only, and ESU ended eleven days after the October update. This is exactly the shape of the post-support era: it does not break down the front door, it lets someone already inside walk into rooms they should not reach, and on an unpatched server it never gets fixed.

The second is the October 13 update itself, KB5128895 (SE RTM SU11), which fixed six vulnerabilities: one remote code execution, CVE-2026-70571 (CVSS 8.1, a stack-based buffer overflow triggered by a specially crafted email, no user interaction required); one spoofing flaw, CVE-2026-70279 (CVSS 9.3, cross-site scripting through a malicious link that, clicked by an administrator, lets the attacker act with that administrator's privileges); and four elevation-of-privilege flaws, CVE-2026-77910, CVE-2026-87692, CVE-2026-87695, and CVE-2026-87696, including a shared Exchange Control Panel cache manipulation that can plant a malicious add-in in another user's mailbox. Microsoft rated both the RCE and the spoofing flaw "Exploitation More Likely," and none of the six was reported as known-exploited at release. Treat that as a timestamp, not a verdict: "not yet exploited" on a server that will never be patched again is a countdown, not a clearance.

The lineage points the same way. CISA added CVE-2026-42897, an Exchange cross-site scripting flaw, to the Known Exploited Vulnerabilities catalog in May 2026, and added an older Exchange deserialization flaw, CVE-2023-21529, in April 2026 with known ransomware use. Exchange flaws keep landing in KEV long after first disclosure, because the installed base moves slowly and the payoff is high.

The hunt: four checks, in order

Hypothesis: if an on-premises Exchange estate is carrying post-support risk, you will find one of: servers still on 2016/2019 or below the last update, a web shell in an IIS-served directory, an account reading mailboxes it has no business reading, or mail-flow persistence that survives any account cleanup. Work the checks in that order: a clean webshell sweep on a server you have already decided to retire is wasted effort, and a dirty one on a server you plan to keep changes the plan.

Hunt 1 — Inventory first, and be honest about the answer

Run the inventory before anything else, and include every server, not just the ones in the load balancer. Hybrid leftovers count: if mailboxes moved to Exchange Online but a hybrid server still sits internet-facing for management, it is still an Exchange server.

Get-ExchangeServer | Format-Table Name, ServerRole, AdminDisplayVersion -AutoSize

Anything reporting 2016 or 2019 is now permanently unpatchable, regardless of how recently it took the October update. Anything on SE should be at SU11 (KB5128895) or later; anything below that is behind on the only branch that still moves. Run Microsoft's Exchange Server Health Checker against each server as well — it flags the post-update actions (service restarts, schema state, known misconfigurations) that get skipped when an update is treated as "installed, done." If you cannot produce the build list for every server, that is your first finding, and it is more important than any single CVE.

Hunt 2 — Web shells in the directories Exchange itself serves

Exchange's worst historical pattern is the web shell: code dropped into a directory IIS serves, surviving reboots and sometimes upgrades, giving an attacker a mailbox-adjacent foothold they can return to. Hunt by file age and by baseline, not by filename — attackers name shells to blend in.

$exchangeRoot = "C:\Program Files\Microsoft\Exchange Server\V15"
Get-ChildItem $exchangeRoot -Recurse -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date "2026-10-01") } |
  Select-Object FullName, LastWriteTime, Length

Anything modified outside a change window, or in a directory your change records do not explain, goes to the top of the queue — especially files under the FrontEnd HttpProxy paths that serve OWA and ECP, and under the IIS wwwroot tree. Then check the IIS logs: unauthenticated POST requests to OWA or ECP paths, and requests for .aspx files that do not exist on your baseline. The request for a shell that was already deleted still tells you someone knew where to look.

Hunt 3 — The authenticated reader: CVE-2026-96940's shape, without waiting for its exploit

You do not need the exploit for CVE-2026-96940 to hunt its abuse pattern, because the pattern is generic: a low-privilege account reading mailboxes it does not own. On premises, mailbox audit logs are where that shows up. Scope to October onward — the disclosure date is your window — and look for cross-mailbox access by accounts that are not delegates, not administrators, and not the mailbox owner, especially access via Exchange Web Services, the programmatic path for bulk reading.

Search-MailboxAuditLog -Identity <mailbox> -LogonTypes Owner, Delegate, Admin `
  -StartDate (Get-Date "2026-10-01") -EndDate (Get-Date) -ResultSize 5000 |
  Where-Object { $_.LogonUserDisplayName -ne $_.MailboxOwnerDisplayName } |
  Group-Object LogonUserDisplayName |
  Sort-Object Count -Descending |
  Select-Object Name, Count -First 20

One account touching many mailboxes, or many mailboxes touched from one unfamiliar source, is your triage trigger — not a verdict, because service accounts and legitimate delegates do this too. Correlate before concluding: enumerate the account's delegate grants and FullAccess permissions rather than assuming them.

Hunt 4 — Mail-flow persistence: rules, forwarding, and delegates

This is the check most teams skip and attackers count on. A compromised mailbox does not need a web shell to stay useful: an inbox rule that forwards mail externally, a rule that moves security notices into an unused folder and marks them read, a mailbox-level forwarding address, or a transport rule that blind-copies an external address all keep the mailbox productive after the password is changed. Audit the current state, not just change events — rules created before your log retention window never appear in a log hunt.

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-InboxRule -Mailbox $_.Identity -IncludeHidden |
    Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo -or $_.DeleteMessage -or $_.MoveToFolder } |
    Select-Object MailboxOwnerId, Name, Enabled, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder
}
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward
Get-TransportRule | Select-Object Name, WhenChanged, BlindCopyTo, RedirectMessageTo, CopyTo

External forwarding destinations, rules that hide mail rather than forward it, and transport rules changed outside change windows are all findings until explained. A rule that moves mail to RSS Feeds or Deleted Items and marks it read is a classic concealment pattern, easy to miss precisely because the mailbox keeps working normally. When you find one, do not just delete it: preserve the rule definition, the account, and the timeline first, because the rule is evidence about what the attacker was interested in.

What to do with what you find

The decision tree is short. If a server is on 2016 or 2019 and hunts 2–4 came back clean, upgrade it to SE in place or migrate its mailboxes to Exchange Online — and treat "next quarter" as accepting permanent, unpatchable exposure in the meantime, in writing, by someone authorized to accept it. If any hunt came back dirty, that server is not a migration candidate until it is an incident: isolate it, preserve logs and suspicious files, and assume the compromise is wider than the one mailbox or file you found.

If neither upgrade nor migration is possible this month, pull the exposure down. Take OWA, ECP, and EWS off the public internet and put them behind VPN or equivalent access control; an unpatched server that is not internet-facing is no longer the low-hanging target the Shodan count advertises. Turn on mailbox auditing everywhere it is not already on, keep those logs long enough to matter, and block automatic external forwarding by policy where the business allows it.

The through-line of this series has been that the patch is necessary and insufficient. Exchange closes the series by removing the first half of that sentence. There is no patch coming for 2016 and 2019, so make the upgrade-or-isolate decision on evidence instead of deferring it until the next disclosure makes it for you.

Further reading

Keep exploring.

All articles