The Watch

Why the mechanism matters more than the kit

The OAuth device authorization grant exists for devices that cannot render a login form: smart TVs, kiosks, CLI tools on headless boxes. The device asks Microsoft for a code, the human types that code into the real login.microsoftonline.com page on a phone or laptop, and Microsoft hands the requesting device an access token and a refresh token. Nothing in that sequence breaks when the requesting device belongs to an attacker. The lure only has to persuade a target to enter a code they were told came from IT.

That is why the two kits now circulating, Kali365 and EvilTokens, are scaling across hundreds of M365 tenants with AI-written lures and automated token capture. There is no credential to steal and no proxy to fingerprint, and the user genuinely completes MFA. The attacker walks away with a refresh token, which survives a password reset and keeps minting access tokens until it is explicitly revoked.

Where the guidance diverges

This is the week's most important disagreement in defensive advice. One line of reporting, anchored on the Kratos/SneakyLog AiTM ecosystem, pushes FIDO2 and passkeys against adversary-in-the-middle phishing. Against a proxy that replays credentials, it works. Device-code abuse is not a proxy attack. The user authenticates directly with Microsoft using whatever strong factor was deployed, and the token is issued to the attacker's device anyway. Phishing-resistant MFA raises the bar on one vector while leaving this one wide open.

The Zimbra campaign reported in parallel is the same class from a different vendor. After exploiting the mail server, the actor mints a Zimbra application passcode of the kind legacy IMAP and ActiveSync clients use, and that passcode bypasses MFA entirely. Patching the server does not revoke it. Two unrelated products, one shared failure: a legitimate secondary credential path the identity controls were never asked to evaluate.

The move

Blocking the device-code flow is a single Conditional Access policy and, for most tenants, an afternoon of work. The hard part is enumerating the handful of genuine kiosk and shared-display scenarios that need an exception before flipping it. The residual risk is any token already issued, which is why the hunt matters as much as the block. Hunt for anomalous token issuance, new device registrations, and stealthy inbox forwarding rules across the last 60 days. Those are the signals that separate a clean tenant from a quiet one.

A refresh token stolen through a flow you approved by design will outlive your password reset, your MFA re-enrollment, and your incident report.

Treat this as the template, not the incident. Every identity platform in production has at least one legacy or convenience authentication path — app passwords, legacy protocol passcodes, service-account secrets, device-code grants — enabled by default and never revisited. That inventory is now a standing deliverable, not a project.

The detection math, stated plainly

CrowdStrike's SANDWORM_MODE research is the clearest artifact of the pattern. The npm worm it describes uses living-off-the-land techniques. The propagation logic is functionally identical to a release pipeline: reconnaissance resembles dev health checks, propagation mimics git and registry operations, destruction overlaps with cleanup scripts. Of 14 observed behaviors, only 2 met the alerting bar. The events that would correlate into a chain arrive 48 to 96 hours apart. That is beyond the retention window many teams keep on build hosts, so the correlation silently never happens.

The recommended hunt is specific and cheap: process-tree ancestry, looking for a node.js parent process acting on narrowly scoped paths and commands. The query is writable today against existing data, assuming retention on CI/CD and registry systems runs past 96 hours first.

Same idea, different layer of the stack

China-linked JadeProx reaches the same evasion from the endpoint side. Its TriBack Loader pairs a legitimately signed program with a malicious DLL and an encrypted payload, then executes via Windows callback functions rather than thread creation, which is the route most EDR engines actually profile. Two of four variants drop AdaptixC2 beacons. A Claude-Pro-themed lure delivers a previously undocumented backdoor named Beagle. Targeting spans government, healthcare, and education across South-East Asia and Latin America. Investigators found the cluster only because the operators left an Alibaba Cloud staging server exposed. The discovery margin was that thin.

The third data point has no fix. Ukraine's CERT tied a campaign to a legitimate Notepad++ 8.8.3 distribution weaponized through a malicious plugin that extracts a password-protected RAR and loads a C2 client. The developers dispute that any vulnerability exists; plugin loading is documented, expected behavior. Both positions are correct, and that is the problem: no patch will ever close this, so behavioral detection is the entire control.

The move

The question is not whether the EDR is good. It is which of these three execution paths it actually alerts on. Callback-function execution and signed-binary DLL sideloading are both straightforward purple-team tests. Where they fire, coverage exists. Where they do not, the detection gets written now rather than during an incident. Pair that with the DNS and proxy blocklist work on sylverixstrategy[.]com and license[.]claude-pro[.]com, both NameSilo-registered, and a 90-day retro-hunt behind it.

If an attacker's technique is indistinguishable from your build pipeline, your only remaining advantage is knowing exactly what your build pipeline normally does.

The volume is now a machine-speed phenomenon

Oracle's quarterly cycle carried 1,449 fixes. The Linux kernel team published 432 CVEs in 48 hours. That is 1,881 in a single window, and the reporting points at AI-assisted bug hunting as a driver on both sides. Akamai's Jan Schaumann put the consequence bluntly: triaging individual kernel changes at this rate is infeasible, and CVEs were always a flawed prioritization mechanism even before the volume arrived.

The regulatory answer landed in the same period. CISA revoked BOD 22-01, the KEV-driven, deadline-per-CVE model, and replaced it with BOD 26-04, which mandates risk-based prioritization: exploitability, asset exposure, and business impact instead of count and severity score. For federal agencies that is a compliance change. For everyone else it is regulatory cover to rebuild a vulnerability program that auditors held to the old model.

Two numbers that prove volume is not the problem

The strongest argument for exposure-weighted triage comes from this cycle's exploitation data, not its patch counts. More than 167,000 Palo Alto GlobalProtect instances remain reachable and unpatched against CVE-2026-0257. A fix shipped in May. CISA set a three-day KEV mandate. Qilin ransomware affiliates are chaining it now. That is not a triage failure. It is a remediation-execution failure on a vulnerability already at the top of every list.

Running the other direction: the Zimbra flaw used in the year-long espionage campaign against NATO-adjacent defense, energy, law enforcement, and finance organizations scored just CVSS 6.1. A severity-sorted queue buries it. A zero-click exploit that harvests 90 days of mail, passwords, and 2FA tokens belongs at the top of one. CVSS measures technical severity, not business consequence, and this cycle produced clean evidence in both directions.

Speed is the third input. watchTowr honeypots recorded SharePoint exploitation within hours of a public proof-of-concept. Any SLA measured in weeks is measuring the wrong thing for internet-facing assets.

The move

The programs adapting to this sort the queue on three inputs they can actually source: known exploitation and exploit-prediction signals, internet reachability from an outside-in scan, and business criticality from asset owners. They set SLAs in hours for exploited-and-exposed assets, weeks for internal, best-effort for the long tail, and they publish the tail explicitly so leadership understands the permanently non-empty queue is the designed state.

They also staff it deliberately. The emerging 'VulnOps' framing is worth borrowing for the headcount conversation: this is a continuous engineering function with pipelines and automation, not a monthly report someone produces alongside other duties.

A vulnerability queue is never empty. That is the new baseline, and any SLA that pretends otherwise is fiction.