Key Eater Is Not a Worm. It Is Axiom X in a Loop.

What Todyl reported

All confirmed malicious activity comes from one address, 199.19.77.84, which Todyl attributes with high confidence to a single operator working from one VPS. The operator is not attributed. How it got the first secrets is not known.[1]

Todyl also reports what it did not see. No Microsoft vulnerability is involved. No persistence was set up: no new consents, credentials, roles or users. And although integration credentials of security tools were among those abused, including Todyl’s own integration apps in two MSP tenants, there is no sign that any vendor platform was compromised.[1]

The path: two clusters and a gap

Written in TLCTC notation, with the intervals the report supports:

…
 →[Δt=?]     #4 ||[auth][@External→@MSP]||  [fanout=~33]
 →[Δt≤33h]   #1 + [DRE: C]
 →[Δt≈2.5m]  #4  [propagation=recursive]
 →[Δt=?]     #4 ||[auth][@External→@Customer]||  [fanout=15]

The [fanout=…] and [propagation=recursive] annotations are the interim convention of the replication notation proposal: write the sub-path once and say how often it repeats (more than 33 apps at about 18 organisations, 15 customer tenants), instead of writing 33 sign-ins or pretending the recursion has a known depth. They annotate the path; they do not classify anything.

Counted over the path, the campaign uses two generic vulnerabilities: credentials that work for whoever presents them, and functions that do what the identity behind them is allowed to do. No #2 or #3, because no flaw was exploited. No #7, because no foreign code ran in any victim’s environment. No #10, because no trust artifact was subverted.

Why it is not a worm, and why it spreads anyway

A worm, in TLCTC terms, is a path that repeats a step in which foreign executable content runs in the target, and that content carries the next round itself. R-EXEC places a #7 at every such execution. In Key Eater there is none. The curl and Python clients run on the operator’s VPS, outside every victim’s domain; they are the attacker’s tools, not steps. What reaches the victims is a stream of authenticated API calls.

The spreading comes from Axiom X. Credentials are control elements with two lives: acquiring one is data leaving the system, a [DRE: C] on the step that obtained it; applying one is always #4.[3] When the data that a #1 step discloses are credentials, every turn of the path produces the material for the next turn:

#4 → #1 + [DRE: C] →[Δt≈2.5m] #4 → #1 + [DRE: C] →[Δt≈minutes] #4 → …

That is self-propagation through a credential lifecycle, not through code. It is why the campaign reaches downstream tenants without anything installed, why a worm label would send defenders looking for the wrong artefact, and why the decisive control is the one that makes harvested material worthless (below). Todyl’s diagram draws exactly this: “New secrets” as an asset box, an arrow back to “Sign in as app”, and the label “Reused within minutes”.[1]

Todyl holds AI involvement at low confidence: the speed and consistency fit automated, possibly agentic tooling, while multi-hour idle gaps and the user-agent switch after detection show a person steering it. For the classification this does not matter. Whether a script, an agent or a person sends the request, the request authenticates with a stolen secret and calls a designed function. AI changes the tempo of the loop, not its clusters.

A trusted relationship without a supply chain attack

Todyl lists seven ATT&CK techniques; its attack-chain diagram adds two. Mapped to TLCTC, with this case’s evidence:[5]

Nine technique IDs, two clusters. The last row needs an argument, because the TLCTC ATT&CK mapping starts T1199 at #10, and because an incident that runs from MSPs into their customers will be called a supply chain attack.

Since v2.6, #10 requires that the trust artifact, or the third party issuing it, was subverted before the target accepted it (R-SUPPLY). For federation the core paper is explicit: presenting a credential or assertion to authenticate as another identity is #4, wherever it is presented and however it was obtained; a party honouring an assertion from an issuer that was not subverted is the trust link working as designed, not a step.[3] That is the situation here. The customer tenants accepted tokens that Entra ID issued, correctly, to the MSP’s app, because the attacker presented that app’s secret. Neither Entra ID nor the MSP’s authority to administer its customers was subverted; one of the MSP’s credentials was stolen. The same holds for the security-tool integrations: Todyl found no sign that any vendor platform was compromised.

So the crossing into the customer is #4, annotated with the boundary it crosses: ||[auth][@External→@Customer]||. Internal clusters may cross domain boundaries in multi-tenant and partner contexts; the crossing goes into the notation, the cluster stays the same.[3] The difference has practical weight. A #10 would send the response to the supplier’s build and distribution. A #4 sends it to the credential: where the secret was stored, who could read it, and whether it works for anyone who holds it.

The failures are evidence too

Todyl’s diagram has a legend most incident graphics lack: a dashed red box for a failed path (the GDAP attempt) and a dashed blue box for assessed, not directly confirmed (a password spray from a neighbouring address). TLCTC makes the same two distinctions in its notation.

A cluster assignment asserts that the step succeeded, so failed attempts are not path steps. They are not discarded either. TLCTC+ v0.9 records them as near misses, written [Attempt: …], with no SRE, DRE or BRE:[4]

// GDAP automation app against client tenants
[Attempt: #4 ||[auth][@External→@Customer]||]
// refresh-token replays, 18:12–21:31, blocked by CA
[Attempt: #4]
// retries with expired or rotated secrets
[Attempt: #4]
// Azure CLI password spray, 16 accounts, all failed
[Attempt: #4] [conf=low]

The password spray carries low confidence because its link to the operator is only shared hosting: Todyl rates it low to moderate, and the pattern also fits generic spraying. The application companion counts near misses per cluster as Key Risk Indicators, next to effective compromises.[3] Todyl’s advice points the same way: “Failed attempts matter alongside successful ones”, and detection logic keyed on successful sign-ins will miss the failures. Here the failures are a #4 signal: AADSTS7000215 (invalid secret) and AADSTS7000222 (expired secret) from a hosting provider mean that someone holds your app’s secret history, not only its current secret.

The edge that cannot be detected in time

Each causal transition has an interval, Δt, and the interval bounds the window for detection and response.[3] The edges in this path have very different windows.

From the first #4 to the first collection: up to 33 hours. The first app sign-in was at 08:45 on 1 November, the first Graph search at 17:40 the next day. An alert on service-principal sign-ins from a hosting provider, triaged by a human, fits easily into that window.

From a harvested secret to its use: about 2.5 minutes. Measured as DCS_d = TTD_P90 / Δt, a SOC whose 90th-percentile time to detect is one hour scores 24 on this edge; anything above 1 means detection arrives after the transition. This edge cannot be detected and answered by people. It can be cut by automated response, or prevented by making the harvested material useless, and the second is more robust.

From containment to effect: up to the token lifetime. Removing a secret does not revoke what it already obtained: “Issued tokens otherwise stay valid until expiry,” in Todyl’s words. As in the Binance case, containment has to reach where the authority lives.[6] Here that is in two places: the credential, and every token already issued against it.

Business events: none in the record yet

The victims are not named, and Todyl’s report describes what happened in their tenants, not what followed in their businesses. On the evidence, the path therefore carries no Business Risk Event. The first one is not hard to name: the MSPs held, in their document stores, the credentials and configurations with which they run their customers’ security — MFA and RMM API keys, backup-storage credentials, firewall and VPN configurations, in Todyl’s list of what such files contain. That they have left the MSP is an event in the managed service itself, and it is that service’s BRE₁. In the TLCTC+ catalogue it takes two codes, one per role the material plays: it is held for the customers, and it controls their systems.

What will follow almost certainly is listed here, with TLCTC+ catalogue codes, as expected rather than recorded:[4]

One lever per step, and who holds it

Todyl’s response guidance is thorough. Sorted by the step each measure acts on, it also shows that the levers sit with different owners, and that one of them is not where a customer would look for it:

The last row is the uncomfortable one. Todyl notes that workload-identity Conditional Access requires a separate licence and covers only single-tenant apps registered in your own tenant: not managed identities, not multi-tenant apps, not third-party SaaS. The app that swept 15 customer tenants was a multi-tenant app. The customer can decide which MSP apps exist in its tenant and with what rights; it cannot decide from where the MSP’s app may sign in. That control lives in the MSP’s home tenant and in how the MSP keeps its secrets. A customer’s risk register should therefore name the MSP as the owner of that #4, and the contract should say what the MSP does about it.

What is still open

Three points depend on evidence Todyl does not have yet, and the record should change as it arrives:

• The seed acquisition. Todyl names candidates without tying any of them to the campaign. Secrets taken from a file store or backend with a stolen credential would be #4 → #1 + [DRE: C]; secrets taken by an infostealer would be #7 + [DRE: C], after whatever delivered it. Todyl also mentions tampered builds of a coding-assistant extension served for about eleven hours in Cursor’s extension marketplace on 29 October; if an affected organisation had installed one, that start would be #10 → #7 + [DRE: C]. Todyl has not tied any affected organisation to an install. Until one of these is evidenced, the gap stays ….
• Key Vault. The ARM-then-Key Vault token pattern, followed within minutes by apps that had never been used, suggests a second loop through Key Vault. Whether secrets were actually read there needs the Key Vault audit logs. Until then that step is #1 + [DRE: C] [conf=low], and the confirmed loop runs through SharePoint.
• AI-service tokens. Three Cognitive Services tokens and one Azure ML token were issued at two MSPs. If they were used to consume the victims’ AI resources, that is a further #1. A token being issued, as Todyl notes, does not show that it was used.

One point is settled, although an early update left it open. Todyl first listed the October 2026 ConnectWise Cloud Backup compromise attributed to Storm-0940 as a possible connection, and in its later update assesses it as unrelated.[1]

A secret that works for anyone

Key Eater needs no new category. It is #4 and #1, repeated, with a gap at the start that the investigation has yet to fill. What makes it behave like a worm is a property of the credentials, not of any code: a client secret authenticates whoever presents it, and the documents that the abused apps can read are full of them. Each disclosure feeds the next sign-in, which is Axiom X turned into a loop. The loop stops where acquired credentials stop working for the person who acquired them.

You cannot detect your way past a 2.5-minute edge. You can make sure there is nothing worth taking on the other side of it.