The Device-Code Vishing Detection Huntress Should Run Tonight. KQL Inside.

Patrick Duggan
9 minutes ago
5 min read

The auth itself may not look terrible. The damage is what the token gets used for in the next fifteen minutes.

May 5, 2026 · Patrick Duggan, DugganUSA LLC

On May 3rd, Microsoft published the device-code vishing chain — the same attack pattern we'd warned Medtronic about six weeks earlier when it was still pre-disclosure. The mechanic is well-documented now: attacker calls the victim, walks them through microsoft.com/devicelogin, victim enters the attacker's code, attacker walks out with a refresh token for the victim's tenant.

Microsoft's writeup is excellent. What Microsoft didn't ship is a hunting query you can paste into your tenant's Sentinel workspace tonight to start finding it. So we wrote one. Three of them, actually. Public gist, MIT-license, copy-paste shape.

Full KQL: [https://gist.github.com/pduggusa/4913816e3b10678b8b1c5d0a18258f42](https://gist.github.com/pduggusa/4913816e3b10678b8b1c5d0a18258f42)

This post explains what the queries do, how to tune them, and why the second-stage chain is the part that matters.

Why device-code is the soft target

Device-code authentication exists for a reason — Azure CLI, kubectl, conference room sign-ins, IoT devices, anything that can't render a normal browser flow. The protocol itself is fine. The vish chain abuses two facts:

Most users have never done a device-code flow in their work tenant. The protocol is uncommon enough that an anomaly fires on the protocol alone for users with no prior pattern.
Microsoft's own UX tells the victim "this is a normal Microsoft sign-in" — because, technically, it is. The victim has no opt-in moment where the system says "a remote third party is requesting your credentials." The attacker's social-engineering hook is the entire fail point.

Most environments we've audited see device-code auths at well under 0.1% of total interactive sign-ins. That's the mathematical opening for detection — anything that surfaces above that floor is worth looking at.

Query 1 — the core anomaly hunt

The first query in the gist hits SigninLogs and joins against a 30-day per-user baseline. It's looking for:

Successful authentication where AuthenticationProtocol =~ "deviceCode" (case-insensitive)
Country anomaly versus the user's normal pattern
High-risk country list (tunable per tenant — defaults RU/CN/KP/IR/BY/SY/CU)
Unmanaged device — TrustType not in Workplace/AzureAd/ServerAd
Non-compliant device per Intune
New user signature — fewer than 5 prior sign-ins in 30 days

Each signal carries a weight. The default scoring lands at 30 + 50 + 25 + 15 + 20 = 140 max, with a 40-point threshold to fire. Tune by raising the threshold for FP-sensitive environments, lowering it for hunt-aggressive shops.

Output: ranked table of suspicious device-code authentications with the contributing signals, sortable by score.

Query 2 — the post-auth blast radius (this is the actual money shot)

This is the second query in the gist, and it's where most production detections live or die. The auth itself may pass weak heuristics. What the token does afterward is where the campaign-instance signature lives.

The query joins device-code sign-ins against a 15-minute follow-on window, looking for any of:

Exchange shenanigans — new inbox rules, mailbox permission grants, transport rules, auto-reply config changes, bulk file downloads
OAuth consent grants — new app consents, service-principal creates, role assignments
Mail or file bulk access — MailItemsAccessed, FileSyncDownloaded, SearchQueryInitiatedExchange

If a device-code auth from a new IP is followed within 15 minutes by an inbox rule that forwards mail to an external address, that is the campaign-instance signature. The operator can rotate IPs and countries; they can't rotate the protocol pattern, and they can't avoid using the access they just stole.

This is where Huntress's MDR posture earns its keep — the second-stage hunt is exactly what an MDR analyst pool watches for. Customers running this query against their own data should pre-stage incident response when it fires.

Query 3 — Defender XDR variant for tenants without Sentinel

Same logic against the Defender XDR Advanced Hunting tables (AADSignInEventsBeta, IdentityLogonEvents). Smaller blast radius because the post-auth join is harder without OfficeActivity / AuditLogs, but the core deviceCode-protocol-plus-anomaly catch survives.

Tuning notes

Things every tenant will need to customize:

High-risk country list — your defaults are not our defaults. A defense contractor in Virginia has different concerns than a media company with a Beijing bureau.
App allowlist — Azure CLI (AppId 04b07795-8ddb-461a-bbee-02f9e1bf7b46), kubectl, Visual Studio Code, Teams Rooms devices legitimately use deviceCode. Exclude those AppIds explicitly.
Baseline window — 30 days is fine for active users. Sparse-signing exec accounts may need 60–90 to avoid every legit sign-in firing as anomalous.
Score threshold — 40 is hunt-aggressive. 80 is alert-clean. Most tenants land at 60.

Why we're publishing this

Three reasons.

One: we said this was the attack vector against Medtronic six weeks before it was confirmed. The receipts are on the wall. The next step from "we predicted it" is "here's the detection so the next victim doesn't get hit." That's the discipline.

Two: Huntress is an MDR with broad customer coverage. They could be running this query against every tenant they manage by morning and surface anomalies in the dashboards customers already pay for. The gist is MIT-licensed. Take it. Run it. Adjust the knobs. Surface the findings.

Three: paywalls on detection content are the part of the threat-intel industry that helps adversaries the most. Huntress is good people. So is Microsoft. So is Mandiant. They all have reasons to gate the actionable hunt content behind paid subscriptions. We don't have those reasons. The mission is clean up the internet, give back more than we take. This is what that looks like in KQL.

What you can do with it tonight

If you have Sentinel: paste Query 1 into a new Analytics Rule, threshold at 60. Paste Query 2 as a Hunting Query and schedule daily. Wire both to a logic-app playbook that pages on-call.

If you have Defender XDR but no Sentinel: paste Query 3 into Advanced Hunting. Save it as a Custom Detection Rule. Tune the threshold over a week of false-positive review.

If you have neither: this is the hunt that should land in your roadmap conversation with your MSSP / MDR. Bring the gist to the next renewal.

The 95% ceiling

False-positive rate on any single signal in this hunt is real. The cross-correlation — device-code auth + new IP + post-auth high-velocity action within 15 minutes — is the signature that survives operator IP rotation and country-shopping. Tune the knobs. Stack the signals. Don't fire-and-forget.

Five percent of any complex assessment is wrong. We just take notes and publish the queries.

— Patrick Duggan, DugganUSA LLC, Minneapolis · 2026-05-05

Receipts & references:

Full KQL — public gist
DugganUSA — We Predicted Medtronic. The Receipts. (May 2 2026)
DugganUSA — Microsoft Just Published the Vish Chain We Warned Medtronic About (May 3 2026)
DugganUSA STIX feed (free): https://analytics.dugganusa.com/api/v1/stix-feed

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com