At 06:13:04 UTC on October 15, 2026, an application registered to a backup vendor began authenticating against Microsoft 365 tenants in GUID order.
Not by revenue. Not by geography. Not by contract tier. By GUID.
That single detail is worth more than the number everyone quoted. The number was 173. One hundred and seventy-three tenants. Mailboxes read. Documents touched. Teams chat enumerated. Directory objects pulled. The window closed at 08:34 UTC. Two hours and twenty-one minutes. Then the application went quiet, and it has stayed quiet since.
Here is what the coverage missed while it was counting tenants: somewhere in that window, a Python script added a new client secret to a second application. That secret does not expire until 2028.
I have been doing forensic work on ledgers and contracts for eighteen years. I have written audit findings on integer overflow in sharding logic, on wash-trading patterns in 500 Uniswap V2 pairs, on broken IPFS hashes across fifteen NFT collections. Every one of those investigations followed the same arc: the public narrative latched onto a number, and the number was never the story. The story was always the residual artifact โ the thing the attacker left behind that outlived the news cycle.
In this incident, the residual artifact has a two-year shelf life.
That is the anomaly I want to open with. Not 173. Not 141 minutes. The date 2028.
An opportunistic crew does not set a credential expiry two years out. Ransomware affiliates operate on a clock measured in hours, because detection probability compounds with every hour the credential sits live. A two-year horizon is a statement of intent about dwell time. It says: we expect to come back. It says: we expect the rotation cadence to be slower than our patience.
And here is the part that should genuinely unsettle anyone reading this from inside a crypto fund: the tenants in that list were not abstract. They were small and mid-sized businesses managed by managed service providers. Crypto funds are small and mid-sized businesses managed by managed service providers. So are token issuers, market makers, custody startups, and every DeFi protocol with a legal entity and a payroll department.
The breach was not on-chain. The blast radius is.
What a Backup Product Actually Buys
Start with the product, because the product explains the permissions, and the permissions explain the breach.
ConnectWise Cloud Backup is a SaaS backup service sold to managed service providers, who resell it to their end clients. The structure is B2B2C, wrapped in one more layer: ConnectWise invoices the MSP, the MSP invoices the SMB. That channel shape matters enormously, and I will come back to it.
What the product does is unglamorous and genuinely valuable. It protects Microsoft 365 data. Exchange Online mailboxes. OneDrive for Business. SharePoint sites and document libraries. Teams chat and channel messages. Directory data.
Read that list again and notice what it is not. It is not a subset. It is not a scoped projection of the tenant. It is the entire collaboration surface of a modern company, in one continuous pull, under one application identity.
That is not a misconfiguration. The permission breadth is the product. A backup tool that asks you to manually select folders is a backup tool nobody buys. The entire commercial promise is zero-touch: install the app, consent once, and everything is protected forever, including the mailbox of the employee who gets fired on a Friday and deletes eleven years of correspondence on a Saturday.
So the MSP consents. The consent screen is long. The MSP clicks through it, because the alternative is an unprotected client and an insurance liability.
I want to be precise about what has just happened, because the industry consistently blurs it. The client did not grant a user access. The client granted an application access. The application then holds that access continuously, across every tenant that consented, without a human in the loop, forever, until someone remembers to revoke it.
In 2017 I audited the Zilliqa genesis block smart contracts as a junior analyst in Manila. I found an integer overflow in the transaction batching logic of the sharding protocol, drafted a patch, and submitted it through GitHub. The project delayed mainnet by two weeks. What I took from that experience was not the vulnerability. It was the habit of citing the exact contract address and the exact version, because a finding without a locator is an opinion.
So let me locate this one. The failure is not in the code. There is no CVE. There is no protocol defect. There is no misconfiguration to point at in a config diff. The stolen object was a client assertion โ a private_key_jwt, the credential an application uses to prove its own identity to Microsoft's identity platform.
That distinction is the whole ballgame, and almost nobody is explaining it correctly.
The Credential That Isn't a Password
When an attacker steals a user password, the remediation playbook is well-worn. Force a reset. Enforce MFA. Hunt for persistence in the mailbox rules and the OAuth consent grants. Every SOC on earth can run that playbook in their sleep.
A client assertion is a different animal.
A client assertion is a signed JWT. The application holds a private key. It signs a short-lived token asserting "I am this application, and here is proof." Microsoft validates the signature against a registered public certificate or key, and issues an access token. No user is involved. No MFA prompt fires. No interactive sign-in appears in the logs as anything a human would recognize as suspicious, because no human was there.
This is why the attack worked at 06:13 UTC on a Thursday morning and nobody noticed for hours.
The critical asymmetry, and I want this in bold because it is the single most under-reported fact in the entire incident: to steal this credential, the attacker did not need to break Microsoft. They needed to break one vendor's key storage.
Compare the two attack surfaces honestly.
Compromising Entra ID requires nation-state resources, zero-days in a hardened identity platform, and years of patience. It has been attempted. It is extraordinarily difficult.
Compromising a vendor's stored secret requires finding one of the following: an unrotated CI/CD pipeline variable, a KMS policy with an over-broad principal, a configuration file in a container image, a backup archive on object storage, an engineer's local .env file, a third-party secrets manager with weak access control, or a support ticket with a screenshot in it.
Those are not comparable problems. They differ by two orders of magnitude in cost.
This is the economics of supply chain attack in one sentence: attack the weakest link, harvest every downstream node simultaneously. The vendor spends years building a product that a thousand MSPs trust. The attacker spends a week finding where the vendor keeps a string of characters. The asymmetry is not a bug in the attacker's favor. It is the structural incentive that guarantees this will keep happening.
And note what the attacker inherited. They did not get one tenant. They got a consent grant that had already been replicated across 173 tenants by the normal operation of the business. The product's distribution model is the attack's distribution model. Every MSP that onboarded a client added a row to the attacker's target list.
Now let me talk about how that list was traversed, because this is where the forensics get interesting.
Fingerprint: Sorted by GUID
The observed behavior: the application authenticated against tenants in ascending GUID order. The interval between tenant authentications was measured in seconds. The full window ran 06:13 to 08:34 UTC.
GUIDs are random. A GUID โ a globally unique identifier โ has no semantic ordering. It is not alphabetical by company name. It is not chronological. It carries no information about size, industry, or contract value. Sorting by GUID is something you do for exactly one reason: you have a pre-existing list in a database table, and you ran a SELECT with an ORDER BY clause, or you iterated an array you already had in memory.
This is not enumeration. This is batch processing of a known target set.
That distinction changes the severity assessment, and the public reporting has not caught up to it. If the attacker had been enumerating โ discovering tenants by probing โ the traffic pattern would look completely different. Enumeration produces bursts and lulls. It produces error storms: 404s, 401s, consent-required failures, throttling responses. It produces a ragged, high-variance inter-arrival distribution because the attacker is reacting to what they find.
What was observed instead is a metronome. Ordered iteration, low inter-arrival variance, clean execution.
I built a Python script in 2020 that tracked over 500 Uniswap V2 liquidity pools, looking for wash trading ahead of public listings. The signal I was hunting for was exactly this shape. Wash trading does not look like organic volume because organic volume has burstiness โ real traders cluster around news, around candles, around each other. Synthetic volume is generated by a loop, and loops have variance near zero. Sixty percent of the new pairs I examined showed that signature before listing. It is why I stopped trusting liquidity depth as a metric and started trusting inter-arrival distributions instead.
The same feature engineering applies here. In 2026 I trained a model on five years of on-chain data to detect synthetic volume across new Layer 2 networks. The features that carried the most weight were never the raw volumes. They were ordering entropy and inter-arrival time variance. Ordered traversal with low variance is the fingerprint of a machine working through a list it already owns.
Which forces an uncomfortable conclusion: the tenant list itself was compromised, not just the credential.
There are two plausible sources. First, the attacker pulled it from ConnectWise's own customer database or MSP management plane alongside the secret. Second, and more elegant, the application's own directory read permissions allowed it to enumerate the tenants it had access to โ meaning the credential and the map were the same object.
Either way, the containment question changes. If only the secret leaked, rotation closes the incident. If the tenant map leaked, rotation closes nothing โ the attacker knows exactly who to come back for, and now they know which MSPs are slow to rotate.
The Application Promoted Itself
Here is the part of the timeline that should have generated far more alarm than it did.
During the window, the application added itself to the Global Administrator role.
Read that again. An application. Granted itself. Global Administrator. In a customer tenant.
Global Administrator is the highest privilege tier in Microsoft's cloud. It is the role that can grant any permission, read any data, change any policy, and remove any other administrator. In a well-governed tenant, obtaining it requires a human with privileged role access, a justification, and โ in mature environments โ a privileged access management workflow with approval gates.
The application did it without any of that. Which means the application held AppRoleAssignment.ReadWrite.All or a functional equivalent โ the permission to write app role assignments.
That is a structural defect in the multi-tenant application authorization model, and it is not ConnectWise's invention. Any application holding role-assignment write permission can grant itself anything. The permission exists because applications legitimately need to provision access for other applications. The blast radius of that legitimacy is total.
I have watched the on-chain world make this exact mistake for a decade. A proxy admin key that can upgrade the implementation can also upgrade itself into a drainer. A governance multisig with a 2-of-3 threshold where two of the three keys live on one engineer's laptop is a single point of failure wearing the costume of decentralization. The pattern is invariant across both industries: the mechanism that makes a system administrable is the mechanism that makes it capturable.
There is no way to build a system that can be fixed and cannot be seized. There is only a choice about who holds the seizure capability and how loudly that capability is audited.
What happened next is the part I find genuinely novel, and I have not seen it analyzed anywhere.
The application ran a Python script. That script added a new client secret to two other applications.
Application one was an MSP management application โ the tooling an MSP uses to administer its client base. That is lateral movement into the control plane of the reseller. Compromise the MSP's management app, and you do not have 173 tenants anymore. You have the ability to onboard new ones.
Application two was Huntress Security Platform.
Two Secrets, One Gatekeeper
Sit with that for a moment.
Huntress is a security vendor. It sells managed detection and response to exactly the population that was being attacked โ small and mid-sized businesses, largely through MSP channels. Its agents run on endpoints. Its platform watches for the kind of behavior that was occurring.
And the attacker planted a credential in it.
This is not opportunistic lateral movement. Opportunistic lateral movement goes after file servers and finance systems, because that is where the money is. Planting a two-year credential inside a detection vendor is a targeted strike on the observer.
I call this decapitation of the gatekeeper, and it is the clearest signal in the entire incident that we are not dealing with a commodity crew.
Consider the operational logic. If you intend to return in eighteen months and harvest, the first thing you must neutralize is the telemetry. You do not need to disable the platform โ that generates alerts. You need an identity inside it. An application credential that can read detection state, or suppress a rule, or query which endpoints are covered. Something quiet. Something that does not expire until 2028.
The attacker is not hiding from the defenders. The attacker is enrolling as one.
I have seen this pattern before, in a different medium. In 2021 I worked through the Bored Ape Yacht Club metadata structure and found inconsistencies between the IPFS hashes and the on-chain records โ fifteen projects with broken metadata links, holders holding tokens whose provenance did not survive scrutiny. Metadata holds the provenance the price ignored. Nobody looked, because the price was going up.
The lesson transfers directly. The security platform is metadata for the enterprise. It is the record that says what happened and what is safe. Compromise the metadata layer and every downstream judgment inherits the corruption silently. No alert fires, because the alerting system has been told everything is fine.
And note the expiry again. 2028. Two years and change from the event date.
Three possibilities, and I do not have enough evidence to rank them definitively. One: the attacker set a long expiry as cover, expecting to be caught and wanting persistence across a partial remediation. Two: the operator genuinely plans a multi-year campaign. Three: the expiry was chosen to look like a legitimate provisioning event โ a service account created by an admin who was setting things up properly, not an intruder covering tracks.
Option three is the most disturbing, because it means the attacker understands that security teams triage by anomaly, and a 2028 expiry on a service principal is not anomalous. It is Tuesday.
The 141-Minute Arithmetic
Let me do the math that nobody did, because it reframes what this incident actually was.
The window is 06:13 to 08:34 UTC. That is 141 minutes. Call it 8,460 seconds. Spread across 173 tenants, that is roughly 49 seconds per tenant.
Now ask the question the headlines did not ask: what can you actually exfiltrate in 49 seconds?
Assume, generously, that the attacker had a symmetric gigabit connection and that Microsoft Graph imposed no throttling whatsoever. One gigabit is 125 megabytes per second. Forty-nine seconds yields approximately 6 gigabytes per tenant.
Six gigabytes sounds like a lot until you price it against the data estate. A single Exchange Online mailbox in an active SMB runs one to fifty gigabytes. A SharePoint site library routinely exceeds a hundred. Add OneDrive, add Teams attachments, add the directory export, and a modest 200-person tenant is comfortably in the terabyte range.
So the arithmetic gives us an absolute ceiling of roughly six gigabytes per tenant under perfect conditions โ and real conditions are far worse. Microsoft throttles per-tenant and per-app. Graph imposes concurrency limits. Large mailbox exports are asynchronous jobs that take hours to stage. Nothing about this workload is a straight pipe.
The realistic pull per tenant in 49 seconds is measured in hundreds of megabytes, not gigabytes.
Which means this was not a data harvest. This was a permission validation pass with persistence planted underneath it.
The attacker was answering a set of operational questions. Does the token work after the tenant is hit? Does the scope actually cover mail? Does the directory read return anything useful? Is there a conditional access policy that fires? Is there an alert? And crucially: does the second-stage script execute cleanly in a tenant we have never touched?
That is reconnaissance. And the reason it matters is that reconnaissance precedes something.
I want to be careful here, because it is easy to overclaim. I cannot prove data was not taken. I can prove the window is too short for bulk exfiltration, and I can prove that the artifact left behind โ a credential valid into 2028 โ is inconsistent with a smash-and-grab. Those two facts point in one direction.
The event is not over. The event has not started.
That is the sentence I would put at the top of any board memo on this incident, and it is the sentence that appears in none of the coverage I have read.
Where Secrets Actually Live
There is a question underneath all of this that the industry refuses to ask out loud, and I want to ask it directly.
Where was the client assertion stored?
I do not know, and neither does anyone publishing about this, because the vendor has not said. But I can enumerate the candidate locations from experience, and the list is not reassuring.
It could have been a CI/CD pipeline variable โ a secret configured in a build system so the deployment can authenticate. Those are frequently readable by anyone with repository write access, and repository write access is often granted more liberally than production database access.
It could have been a KMS or HSM entry with an over-broad key policy. The cryptography is perfect. The policy that says which principals can call Decrypt is written by a human at 6 p.m. on a Friday.
It could have been a configuration file baked into a container image, in which case it lives in every registry that image was pushed to, and in every cluster that pulled it, and in every developer's local Docker cache.
It could have been in a third-party secrets manager, which is fine, except that the secrets manager is itself an application with its own client assertion, and now we are three layers deep in a trust chain where every layer is somebody's weakest link.
It could have been on an engineer's laptop. It happens constantly. It is the single most common root cause of application credential compromise across the entire SaaS industry, and it is almost never disclosed as such because "an engineer's laptop" does not appear in a press release.
The point is not which one it was. The point is that all of them are cheaper to attack than Microsoft's identity platform, and the industry's security budgets are allocated as though the opposite were true.
Every dollar of identity security spending is aimed at the front door โ MFA, conditional access, phishing-resistant credentials, session token protection. Almost none of it is aimed at the back door where the machine credentials live, because machine credentials do not have users, and security tooling is built around users.
An application that authenticates at 06:13 UTC with a valid signed assertion is, from the perspective of every control in the stack, a well-behaved application doing its job.
The Infinite Approval
Now the part of this analysis that I think matters most for the readers I actually write for.
Everyone covering this incident has filed it under SaaS supply chain security. That is technically correct and analytically useless, because it frames the problem as somebody else's problem. A backup vendor got breached. Rotate your secrets. Move on.
Here is the reframe. The client assertion is an infinite approval.
If you have spent any time in DeFi, you know the pattern exactly. A user signs an approve transaction granting a protocol an unlimited allowance on a token. The protocol needs it โ otherwise every swap requires two transactions and the UX collapses. The user clicks through the confirmation because the alternative is friction. The allowance then sits on-chain, permanently, revocable by the user in principle and revoked by the user in practice approximately never.
When that protocol's contract is exploited, the attacker does not need the user's private key. The user already gave away the capability, months earlier, in a transaction they do not remember signing, and there is no expiry on the grant.
Now substitute the vocabulary and read it again. A client consents to an application, granting full read access to the entire collaboration estate. The application needs it โ otherwise backup is not zero-touch and the product does not sell. The MSP clicks through the consent screen because the alternative is an unprotected client. The grant then sits in the tenant, permanently, revocable by the customer in principle and revoked in practice approximately never.
When the vendor's key storage is compromised, the attacker does not need the customer's password. The customer already gave away the capability, months earlier, on a consent screen nobody remembers, and there is no expiry on the grant.
This is the same architecture. It is the same failure. And in both industries, the product management incentive that produced the grant is the exact same incentive: friction kills conversion.
I have been arguing for years that liquidity fragmentation is not a real problem โ it is a narrative manufactured by people selling aggregators. The same skepticism applies to the security posture of delegated trust. The "decentralized" framing is doing enormous marketing work while the underlying capability grant is as centralized as it gets: one key, one holder, one point of failure, no customer-side revocation.
Here is the specific gap that should worry every fund with crypto exposure. In the token approval model, the user can revoke unilaterally. The transaction is on-chain, the allowance is readable, and revocation is a single call. It is inconvenient, but it is possible.
In the multi-tenant SaaS model, the customer frequently cannot revoke independently. The application holds the grant. The vendor holds the credential. The customer's only lever is to remove the application entirely, which means losing the backup โ which means losing the thing they bought the application for. The customer's revocation right is theoretical, and the vendor's custody obligation is the only real control in the system.
That is a worse trust model than DeFi, and DeFi's trust model is not good.
The Measurement Regime That Cannot See This
There is a second-order failure here that will cause more damage over the next five years than the breach itself.
No CVE was assigned. No protocol was broken. No configuration was wrong. The product worked exactly as designed, and the design was the vulnerability.
Run that against the standard enterprise security questionnaire and watch what happens.
How many critical vulnerabilities are open? Zero. What is your mean time to patch? Under SLA. Do you produce an SBOM? Yes. Do you have a vulnerability disclosure program? Yes. Are you SOC 2 Type II? Yes.
Every box is checked. And every box is checked by a framework that has no field for "where do you store the client assertion, who can read it, when was it last rotated, and can a customer revoke it without deleting the application?"
The entire apparatus of modern security assurance โ CVE, CVSS, SBOM, patch SLAs, pen test reports โ is a measurement regime built to find defects in code. It is structurally blind to defects in custody.
A vulnerability management program cannot detect a risk that has no vulnerability identifier.
This is not a ConnectWise problem. It is an industry-wide epistemic failure. The procurement questionnaires that were supposed to protect the 173 tenants asked the wrong questions, and they asked them confidently, and the answers came back green.
I rebuilt my fund's correlation matrix during the Luna collapse in 2022, after liquidating 40% of our high-risk DeFi positions in a matter of hours. What that exercise taught me was not that leverage is dangerous โ everyone knows that. It taught me that the dangerous exposures are the ones that do not appear on any single counterparty's risk report. Celsius and Three Arrows were not obviously linked in either entity's disclosures. The link existed in the correlation structure, invisible to anyone looking at one node at a time.
The same blindness is operating here. Each MSP looked at its own tenant and saw a compliant backup vendor with a clean questionnaire. Each customer looked at its MSP and saw a competent provider. Each vendor looked at its own pipeline and saw a rotated secret. The risk lived in the edges, and nobody was measuring the edges.
That is what a systemic risk actually is: an exposure that is individually rational at every node and collectively catastrophic at the network level.
What I'm Watching Next Week
The forensic question that will determine the severity of this incident is not "what was taken." It is "what is still live."
Three signals to monitor.
First, new credential additions on service principals across MSP-managed tenants. The attacker's second-stage script added client secrets to two applications. Scripts are not surgical. If the same tooling ran against a broader target set, there will be additional service principal credential additions in the same narrow time band, and they will share a creation timestamp signature. Query for credentials added between 06:13 and 08:34 UTC on October 15, and do not restrict the query to the 173 known tenants. The known list is the list the vendor confirmed. It is not the list the attacker had.
Second, application-only authentication events against mail and directory scopes where the calling application is not in the tenant's expected application inventory. The defining characteristic of this attack is that no human signed in. Any detection rule that keys on user sign-in anomalies will return nothing. The detection surface is the service principal, and most SOCs do not monitor it with the same rigor as user identity.
Third, and most urgently, rotation completion rates. A credential valid until 2028 does not care that the incident was disclosed in October 2026. If even a fraction of the affected MSPs rotate the primary secret but not the downstream application credentials the script planted, the persistence survives the remediation. Following the exit liquidity to its cold storage is the whole game โ the disclosed credential is the visible pool, and the undisclosed second-stage credential is where the value actually went.
I have a prediction, and I will state it plainly so it can be scored. Within thirty days, the count of affected tenants will exceed 173, because the 173 figure reflects what ConnectWise could confirm from its own logs, and log retention across MSP management planes is uneven. Within ninety days, at least one downstream application credential planted during that 141-minute window will be discovered in active use. And within a year, this incident will be cited in a regulatory proceeding about vendor custody of delegated credentials, because the 2028 expiry is the kind of artifact that makes a compelling exhibit.
The question I would put to every crypto fund reading this is not whether your MSP was in the 173. It is whether you could answer, today, with evidence rather than confidence, where your application credentials live, who can read them, when they were last rotated, and whether you can revoke them without deleting the product.
If the answer involves the phrase "our vendor handles that," you have just described the exact trust model that failed.
The ledger never sleeps, but it only records what was written to it. Everything else โ the consent grant, the client assertion, the secret with the 2028 expiry โ lives in a database nobody is auditing, in a tenant nobody is watching, under an application name that looks exactly like the one that is supposed to be there.
A Short Systemic Risk Checklist
Four questions. Ask them about every application that holds delegated access to your organization, and ask them about every counterparty that holds delegated access on your behalf.
One. Does the credential expire, and is the expiry shorter than your incident response cycle? A secret that outlives your remediation window is a secret the attacker keeps.
Two. Can you revoke without removing? If the only way to kill the grant is to delete the application, you do not have revocation. You have a hostage negotiation.
Three. Can the application escalate its own role? If any application in your tenant holds role-assignment write permission, assume it can become Global Administrator, and assume that is true for every tenant it touches.
Four. Do you have a log that would show a GUID-ordered traversal? If your retention window is shorter than the attacker's dwell time โ and 2028 is longer than almost everyone's retention window โ you will not find what already happened. You will only find what happens next.
That is the shape of the problem. Not a vulnerability. A custody arrangement. And the industry has spent twenty years building tooling to find the former while ignoring the latter entirely.