Short answer: yes. An attacker can get into a Microsoft 365 account without ever learning your password. Your MFA can be working perfectly and it can still happen.
The technique is called device code phishing. A campaign called Skyw4lker, written up by ANY.RUN and published by The Hacker News on October 28, 2026, is a current example. If you use Microsoft 365 for your business, it’s worth fifteen minutes of your time.
One note on the source: that article is a contributed piece from a security vendor, and part of it is a sales pitch for their tools. I’m using only the description of how the attack works. The log checks and the policy below are standard Microsoft 365 practice, not something the article walks through.
What happened, in plain English
Most people picture phishing as a fake login page that steals your password. Device code phishing works differently. According to the article, the attacker starts a real, legitimate sign-in request with Microsoft and then convinces the victim to complete it. The resulting tokens give the attacker access to whatever that account can reach.
Think of a token as a wristband you get at a venue after the door staff checks your ticket. Once someone has the wristband, nobody checks the ticket again. Here, you did the ticket check yourself, on the attacker’s behalf.
In the Skyw4lker campaign, the bait is a password-protected document that looks like a contract or a service proposal. That’s believable if you deal with vendors and quotes. The document sends you to a page hosted on Google Sites, which then leads into a real Microsoft sign-in flow. The article says the attacker doesn’t need to copy Microsoft’s login page. The sign-in is genuine. The trick is getting you to approve a request the attacker started.
The article also says the page’s code collects details like your IP address and location, and keeps checking in with the attacker’s server while it waits for you to finish signing in.
The campaign has mainly targeted U.S. organizations in manufacturing, technology and healthcare, per the article. Nothing about the technique is tied to one country, and a small Canadian business that sends and receives contracts has the same kind of inbox.
How to tell if it affects you
If you have Microsoft 365, the exposure exists by default. Unless someone has set up a rule against it, Microsoft’s device code sign-in is allowed. Most small businesses never use it, so it’s open for no benefit.
The article makes a point that matters for checking: the organization may see a valid authentication event without seeing the malicious context behind it. In the logs, a successful sign-in looks like a successful sign-in. So the question to ask isn’t “did something fail?” It’s “did a sign-in happen in a way that none of my people ever do?”
What to do today
1. Look at your sign-in logs
You need admin access to the Microsoft Entra admin center (the part of Microsoft 365 that handles identity). Open the sign-in logs. When an analyst reviews them for this kind of attack, these are the things to check:
- Authentication protocol. Add that column or filter if it’s available. Look for sign-ins that used the device code method. If nobody in your company has ever used it on purpose, any hit is worth a closer look.
- Location and IP address. Is the sign-in from somewhere the user doesn’t normally work? Remember, a successful sign-in from a strange place is the thing to chase, not a failed one.
- Timing. Ask the user whether they opened a document or a link around that time, especially a contract or proposal from someone they didn’t expect.
- The app that was signed into. Does it match something the person actually does?
Menu names in Microsoft’s admin portals change from time to time, so if a column has moved, Microsoft’s own documentation for Entra sign-in logs will show you where it lives now.
2. Block device code sign-in with Conditional Access
Conditional Access is Microsoft’s rule engine for sign-ins. It generally needs Entra ID P1, which is included in plans such as Microsoft 365 Business Premium. Check your licence first.
The policy, in plain terms:
- Create a new Conditional Access policy.
- Apply it to all users. Exclude one emergency admin account that you’ve kept for break-glass situations, and store its credentials safely offline.
- Under conditions, choose the authentication flows setting and select device code flow.
- Under the grant controls, choose block access.
- Turn it on in report-only mode first. Give it some days, check the logs for anything legitimate that would have been blocked, then switch it to on.
If you do have a real need for device code sign-in, such as certain meeting-room hardware or command-line tools, allow that narrowly rather than leaving it open for everyone.
3. Tell your people one simple thing
If a document or web page leads you to a Microsoft sign-in you didn’t start, and especially if it asks you to enter a code, stop. Don’t type it in. A password-protected “contract” you weren’t expecting is a reason to phone the sender on a number you already have.
Signs something already went wrong
- A device code sign-in in your logs that nobody can explain.
- A successful sign-in from an unfamiliar location or IP address, close to the time someone opened a suspicious document.
- A user who remembers entering a code or approving a Microsoft prompt after clicking through from a document.
- Anything odd inside the mailbox afterward, such as email rules you didn’t create, sent messages you don’t recognize, or unfamiliar sign-in methods added to the account.
I want to be careful here. The article doesn’t list these mailbox signs, and they’re general account-takeover indicators. But they’re the standard things to check once you suspect someone is in.
If you find something
Changing the password isn’t enough on its own, because the attacker holds tokens, not just a password. The usual response is:
- Revoke the user’s active sessions and sign them out everywhere.
- Then reset the password.
- Review the account’s MFA methods and remove any you don’t recognize.
- Check the mailbox for forwarding rules and anything sent from the account.
- Work out what that account could reach: email, files, shared drives. That’s what the attacker could see.
The article notes that a compromised Microsoft 365 account can expose sensitive communications, intellectual property, operational information and regulated data. If client or patient information was in that mailbox, you may have reporting duties. That’s a conversation for your IT provider or a privacy lawyer, and the Office of the Privacy Commissioner of Canada is the official source for the rules. Phishing can also be reported to the Canadian Anti-Fraud Centre.
If the logs look murky and you can’t tell whether a sign-in was legitimate, treat it as real until proven otherwise. Cleaning up a false alarm costs you an hour. Missing a real one costs a lot more.
