On August 18, 2026, Huntress researchers investigating an adversary-in-the-middle attack stumbled onto the operator console behind it: a phishing kit its author calls Knight Office. Inside Huntress’s own customer base alone, the same console has been tied to at least nine confirmed breaches of Microsoft 365 and Google Workspace accounts over a two-week span. Pulling the thread wider, researchers found more than 700 emails carrying variations of the same lure, subject line, and template going back to April. None of that volume needed to forge the domain it claimed to protect. It forged something simpler: the recipient.
A Lure Addressed From You, To You
Knight Office’s opening move is a header trick, not a DNS trick. The phishing email forges its From, To, and Return-Path fields so the message appears to have been sent by the recipient’s own address, to the recipient’s own address, a self-addressed piece of mail landing in an inbox that never sent it. Layered on top is a DocuSign-style signature request with an urgent subject line, and researchers found variants that swap a lowercase “l” for an “i” in words like “Important” and “Signature,” a small enough change to slide past keyword-matching spam filters while still reading correctly to a rushed eye. Clicking through does not drop the victim straight onto a fake login page. It routes them first through Monday.com, a legitimate work management platform, then through a compromised Joomla website, before finally landing on the page built to steal something real.
The Device Code Is the Whole Attack
That final page mimics Microsoft’s device-code sign-in flow, the legitimate mechanism people use to authorize a TV, a CLI tool, or another device that cannot easily accept a typed password. The victim enters the code shown to them, completes their normal sign-in exactly as they would on any unremarkable day, including their own MFA step, and in doing so hands Knight Office a live, fully authenticated session token. No password was phished. No MFA prompt was defeated. The kit never needed either, because a valid session token already carries both.
A Backdoor Built From a Security Feature
Stealing the token is not where Knight Office stops. Huntress found that once inside, attackers register a rogue, attacker-controlled device against the victim’s Microsoft Entra ID tenant and bind a Windows Hello for Business passwordless credential to the compromised account. That single step turns a feature meant to make sign-in more secure into a way back in: even after the original stolen session token is revoked, the attacker’s bound WHfB credential keeps working, because it was never tied to the theft that got detected. The warning sign is specific enough to hunt for: a new device enrollment and a fresh WHfB key credential appearing shortly after session-token replay from an unfamiliar IP is not how a legitimate user re-authenticates.
Why DMARC Was Never the Layer Watching for This
DMARC answers a narrow question: is this message authorized, by SPF or DKIM alignment, to claim the domain in its From header? Knight Office’s opening email does claim a domain, technically, since the forged From address still has to resolve to something. But the trick doing the actual work here is not domain spoofing in the sense DMARC was built to police. It is a trust signal aimed at the human reading the message and, just as often, at the mail security stack behind them. Plenty of anti-phishing configurations apply their sharpest scrutiny to mail that claims to be from someone else’s domain, and hold back on messages that appear to originate from inside the recipient’s own tenant, on the assumption that intra-domain mail is safer by default. A message forged to look self-sent can ride that assumption straight past a filter tuned to watch the exits, not the mirror.
This is a different blind spot than the ones this blog has already walked through, the anonymous relay path closed by rejecting Direct Send, or the allow-listed SCL:-1 tag that waves spoofed mail around anti-phishing enforcement entirely. Knight Office does not need either. It needs a recipient’s own address to feel like a safe thing to see in their own inbox, and a device-code page convincing enough to make handing over a live session feel routine.
What This Means for Your Program
Treat “the sender matches my own domain” as a signal to verify, not a reason to relax. If your anti-phishing policy or secure email gateway gives intra-domain mail a lighter review than external mail, that configuration is exactly what a self-spoofed lure is built to exploit. Domain impersonation protection needs to cover messages claiming to be from your own tenant, not just from lookalikes of someone else’s.
Train people to distrust device-code prompts they did not initiate. A device-code sign-in should only ever follow an action the user themselves just took on a new device. A code appearing after clicking a link in an email is not that, and it is worth making that distinction as explicit and repeated as any password-phishing warning.
Hunt for the persistence pattern, not just the initial click. A new device registration and a freshly bound Windows Hello for Business credential following session-token replay from an unrecognized IP is a specific, detectable sequence. Revoking a stolen session token without checking for a rogue device registration behind it leaves the actual backdoor standing.
Remember DMARC protects the domain, not the delivery decision. A domain can have a textbook-strict DMARC policy and still see phishing land, because DMARC was never positioned to evaluate a message’s redirect chain, its device-code page, or the intra-tenant trust heuristics your mail platform applies before your policy even gets consulted.
The Takeaway
Knight Office did not need to break SPF, DKIM, or DMARC to reach 700 inboxes and at least nine confirmed compromises. It needed a header trick that reads as familiar, a redirect chain that looks like ordinary web traffic, and a device-code page built to catch a session token on its way through. DMARC did its job on every one of those messages, evaluating exactly what it was built to evaluate. The attack simply walked in through a door that job was never assigned to guard.
DMARC tells you whether a message is authorized to claim your domain. It cannot tell you whether your own mail platform is quietly trusting messages that only look like they came from inside your walls. Excello Mail gives you continuous, plain-language visibility into your real authentication posture, so you know exactly where DMARC’s coverage ends and the rest of your defense needs to begin. Sign up for free to Excello Mail and see your actual authentication picture today.