
The MSP Security Gap
The login that skipped the password
The scenario:
Your client’s finance director signs in Monday morning as always. Password, MFA, done. What they cannot see: someone else is in the same account from another country, and was never asked for either.
How it unfolds:
Two weeks earlier, the director downloaded a free PDF tool at home on a personal laptop, signed in to webmail once from the same machine. The tool carried an infostealer.
It did not want passwords. It wanted the browser’s session cookies, the tokens that say “this person already proved who they are”. The attacker loads the stolen cookie into their own browser and the cloud session resumes for them: no password, no MFA prompt, no new sign-in event worth noticing.
From there it is quiet reading: the inbox, the payment runs, the deal folder. Session token theft is now one of the most common paths into M365 tenants precisely because it steps around the controls everyone spent five years deploying.
Infostealers made this industrial. Logs holding fresh session cookies sell in bulk within hours of the theft, so the person using the cookie is rarely the person who stole it. By the time the session is in use, the malware behind it has often been cleaned off the original machine already.
The warning signs:
Concurrent sessions from impossible locations, without new sign-in events.
Mailbox activity in hours the user was demonstrably offline.
Personal, unmanaged devices signing in to business accounts.
Free tool downloads on machines that also touch company email.
Stop it:
Block business sign-ins from unmanaged devices with conditional access. This is the control the whole attack depends on avoiding.
Shorten session lifetimes for finance and admin roles, so stolen cookies expire fast.
On any infostealer suspicion, revoke sessions and reset, in that order. A password reset alone leaves the stolen session alive.
-
P.S. The sign-in log looks clean because there was no sign-in, only a session resumed somewhere it should not be. What gives it away is behavior: the same account acting from two worlds at once. Behavioural correlation across identity and endpoint is precisely the layer most SMB stacks are missing.
Patch first this week:
This week’s KEV additions, ranked by what MSPs run across client fleets. Verified against NVD, CISA, and vendor advisories.
• Microsoft Windows IKE Service Extensions CVE-2026-33824 (9.8)
A double free in the Windows IKE Extension. An attacker sends crafted IKE packets and runs code on the machine. No credentials, no VPN account, no user interaction, straight over the network. Microsoft shipped the fix in the April 2026 Patch Tuesday, which is the uncomfortable part. This has been patchable for four months, and CISA moved it to KEV because attackers found the clients who did not apply it.
Who runs it: any Windows Server terminating IKEv2 VPN through Routing and Remote Access, which in most fleets is the branch office boxes nobody has rebooted since spring.
Fix: apply the April 2026 or any later cumulative update. Anything current is already covered. KEV August 18. Federal deadline was August 21, now passed. Before you close the ticket, check what the IKE listener has been reachable from, because a four-month exposure window on a 9.8 is not a patch-and-move-on job.
• Microsoft SharePoint CVE-2026-55040 (9.1)
Weak authentication in on-premises SharePoint. A remote unauthenticated attacker forges a valid JWT and acts as any site user, including an administrator. The exploit is on GitHub, published by the researcher who demonstrated the chain at Pwn2Own, and attacks started shortly after it went public.
Who runs it: clients still hosting SharePoint on-premises rather than in Microsoft 365, usually the ones with a document set too awkward to migrate.
Affected and fixed: SharePoint Enterprise Server 2016 below 16.0.5561.1001, SharePoint Server 2019 below 16.0.10417.20175, and Subscription Edition below 16.0.19725.20434. Microsoft patched on July 14. KEV August 18. Federal deadline was August 21, now passed. If the server was internet facing and unpatched since mid July, treat administrator accounts and site permissions as suspect before you sign it off.
• Broadcom VMware vCenter CVE-2026-59310 (9.8)
A directory traversal flaw in the vCenter Syslog server. An attacker with network access to vCenter escapes the intended path and executes code. Reporting on the campaign describes attackers using it to establish reverse SSH access, which means persistence rather than a smash and grab.
Who runs it: any client whose virtualization sits on VMware, so compromise here is not one server, it is the management plane for all of them.
Affected and fixed: vCenter 9.1.x below 9.1.0.0300, 9.0.x below 9.0.2.0100, and 8.0 below 8.0 U3k. Cloud Foundation 5.x, 9.0.x.x and 9.1.x.x, and vSphere Foundation 9.0.x.x and 9.1.x.x are also listed. Broadcom released fixes on July 29. KEV August 18. Federal deadline was August 21, now passed. vCenter should never have been reachable from the internet, and this is the week to prove that for each client rather than assume it.
• Apple macOS Screen Sharing CVE-2026-65400 (9.8)
An authentication flaw in Screen Sharing. An attacker on the network authenticates without valid credentials and lands with root. Reporting describes internet-exposed Macs on port 5900 being taken over and used to run a Monero miner, so the first symptom a client reports will be a slow machine rather than a breach.
Who runs it: every Mac in a mixed fleet, which for most MSPs means the design team, the founders, and whoever asked nicely.
Affected and fixed: macOS Sonoma below 14.8.9, macOS Sequoia below 15.7.9, and macOS Tahoe below 26.6.1. Apple shipped the fixes on August 6. KEV August 18. Federal deadline was August 21, now passed. Patching closes it. Scanning for port 5900 open to the internet across your client estates closes the next one too.