The attachment is an invoice. Or a contract, or a remittance advice — something boring enough that a finance lead opens it on reflex. Click through, and you land on a Microsoft sign-in page that looks exactly like the one you authenticated against this morning, because the attacker didn’t build it, they copied it. You type your password. Maybe you approve the prompt. And somewhere a session that isn’t yours starts reading your mail.
That’s CSuite, the campaign ANY.RUN published September 30, 2026. The headline writes itself — fake business docs, convincing Microsoft prompts, credential theft, device compromise. The useful question is narrower: which of your controls would have stopped this, and which ones you only think would have.
The chain, stripped of adjectives
Four moves. A document lure arrives, dressed as routine business correspondence rather than the usual “your account is suspended” panic bait. Open it and you’re routed to a credential-harvesting page impersonating Microsoft’s sign-in flow. Credentials get captured. And — this is the part that separates CSuite from a thousand phishing kits — the operation pivots from the cloud identity to the victim’s endpoint.
Most phishing stops at the mailbox. You lose a password, the attacker reads email and sets up a forwarding rule, you reset and move on. CSuite is being described as going after the device too, which means the document isn’t only a signpost to a fake login — it’s also carrying, or leading to, a payload. Treat the lure as both a credential trap and a malware delivery mechanism, because assuming it’s only one of those is how you under-scope the incident response.
The targeting is the other tell. The name is not subtle. This is aimed at people who approve payments and sign things — the business-email-compromise demographic — not a spray across every mailbox in the tenant. That changes your risk math. One compromised finance director is worth more than fifty compromised interns, and the attacker knows it.
Where my skeptical colleague starts pushing
I ran the chain past an engineer on our side who has earned the right to be cynical. The exchange is worth reproducing, because he lands on the questions that actually decide the defence.
“If it’s a fake sign-in page, MFA ends the story. They get the password, they hit the prompt, they don’t have my phone. Done. Why are we writing 600 words about this?”
Because that’s only true if the page is static — a flat clone that pockets your password and sends you an error. If CSuite is running an adversary-in-the-middle proxy, the page relays your login to the real Microsoft endpoint in real time, you complete MFA against the genuine service, and the proxy walks off with the resulting session cookie. No second factor required after that. The token is already minted.
Here’s where I’ll be honest about the limits of the reporting: the public write-up stresses the realism of the sign-in prompt and the device pivot, and I’m not going to tell you it confirms a full AiTM proxy chain when I can’t read that line directly. So design for the worse case. Token theft is the default assumption for any credible 2026 credential-phishing operation, and building your controls around “MFA will save us” is how tenants get owned by attackers who stopped being blocked by MFA years ago.
“Fine. Then Conditional Access with a compliant-device requirement kills it. Stolen cookie, unmanaged machine, access denied. What’s left to argue about?”
That’s the right control, and it’s the one that actually bites. A policy requiring a compliant or Entra-joined device for access to Exchange and SharePoint means a replayed cookie from the attacker’s box fails the device check, cookie or no cookie. This is the single highest-leverage thing in the whole piece. But two caveats keep me from calling it finished.
First, coverage. Device-based CA that exempts “legacy” clients, or carves out a break-glass path someone widened into a highway, leaves exactly the gap a targeted operator probes for. Second — and this is the bit people skip — the device-infection stage is an attempt to become a compliant device. If they land malware on a machine that’s already enrolled and compliant, your CA policy now cheerfully admits them. Compliant-device CA defeats cookie replay from a random VPS. It does not defeat an attacker sitting on the user’s actual, compliant laptop. That’s the whole point of the endpoint pivot.
“So your clever control is undone by the attack it’s supposed to stop. Great. Why bother?”
Because layered controls don’t need to be individually perfect — they need to fail at different points. Compliant-device CA raises the cost enormously and forces the attacker into the noisy, detectable work of compromising an endpoint. That noise is your detection surface. The purity argument — “any control with a gap is worthless” — ignores that the gap costs the attacker real effort and leaves fingerprints. I’ll take a control that converts a silent cookie replay into a loud endpoint compromise every single day.
The controls, ranked by how much they actually matter
Defender for Office 365 is your front door. Safe Attachments detonates that invoice in a sandbox before it reaches the mailbox, and Safe Links rewrites and time-of-click checks the URL to the fake sign-in page. The catch admins forget: Safe Links only re-checks at click time if you haven’t exempted the sender domain, and plenty of tenants have an allow-list from 2022 nobody has audited. Go read yours.
Conditional Access is the control that decides the fight. Phishing-resistant authentication (passkeys, Windows Hello for Business, certificate-based auth) for your BEC-exposed roles neutralises the credential-theft stage entirely — there’s no password to proxy. Pair it with compliant-device enforcement and token protection where your licensing allows. If you do one thing after reading this, it’s enforce phishing-resistant methods on finance and the executive assistants who have calendar and mailbox delegation. They are the real target.
Entra ID Protection catches the sign-in that slips through — anomalous location, unfamiliar sign-in properties, a token replayed from an IP your user has never touched. It’s a backstop, not a gate, and it fires after the fact. Useful for the hunt, not for the block.
Hunting it in your own logs
If you suspect exposure, the signal lives in three places: Entra sign-in logs (risky sign-ins, new devices, impossible travel), mailbox audit logs (new inbox or forwarding rules created right after a suspicious login), and Defender for Endpoint (unexpected processes on the pivoted device). Start with sign-ins flagged by risk detection over the last week. Read-only, paginated, and — critically — you review the output before you touch a single account. You do not pipe a live query straight into a disable command at 2 a.m.
Pay attention to the Compliant column. A high-risk sign-in from a non-compliant device is a cookie replay story. A high-risk sign-in from a device marked compliant is the worse story — the endpoint pivot that your CA policy no longer catches. Cross-reference those device IDs against Defender for Endpoint and go hunting on the machine.
You find all this in entra.microsoft.com under Protection > Risky activities for the identity side, the Microsoft Defender portal for the mail and endpoint side, and Purview Audit for mailbox rule changes. Three consoles, one incident. Nobody said this would be tidy.
CSuite isn’t novel because it invented a technique. It’s dangerous because it chains a believable document, a borrowed login page, and a march onto the endpoint against the exact people who sign the cheques. The password was never the thing worth protecting. The session token and the laptop were.