NexlinksField Notes from a CTO & CISO
Menu
Source-led perspectives on Microsoft technology. Explore the October briefing ↗

LINKEDIN ARCHIVE / Security

Device code phishing abuses legitimate sign-in flows

Another reminder that phishing has moved well beyond fake login pages and bad grammar.

Published
By Phil Kinsley
Adapted and republished on Nexlinks. The publication date is the original article date; the text is preserved as historical author commentary.
Date derived from the original LinkedIn post identifier, shown in America/New_York time; the export supplied only a relative age.
Historical author commentary. Statements and links reflect the original period; this import is not a new factual verification of every historical claim.

Another reminder that phishing has moved well beyond fake login pages and bad grammar.

The FBI has warned about Kali365, a phishing-as-a-service platform being used to access Microsoft 365 environments through device code phishing.

What makes this one worth watching is that it abuses legitimate Microsoft flows, so it can look normal to the user and sometimes even to the environment.

This is the kind of thing that is already landing in real tenants, with researchers tracking campaigns targeting Microsoft 365 identities across hundreds of organizations.

The lesson is not “panic about another phishing tool.” The lesson is to stay vigilant around the controls that still matter.

Review risky OAuth consent patterns, device code flow exposure, conditional access coverage, token protection where available, user reporting, sign-in anomalies, and whether your team would actually spot this before it becomes mailbox access, Teams access, or OneDrive access.

Phishing keeps changing shape, but the basics still matter when they are done properly and reviewed often.

Worth a read:

Original publication

Original LinkedIn post ↗

Original writing supplied by the author. Feed cards, repeated article announcements, and provider promotion have been removed. Consult current primary documentation before acting on historical technical guidance.

Further sources

Reference linked in the original post ↗

Continue reading

From vulnerability lists to decisions about exposure ↗

Purview and AI: make the data boundary explicit ↗