![\"Illustrative](\"https:\/\/malwaretips.com\/blogs\/wp-content\/uploads\/2026\/10\/skyw4lker-device-code-phishing-scam-microsoft-login-illustration.png\" "\\"\\"")
<\/figure>\nOverview<\/h2>\nA confirmed campaign uses everyday business documents<\/h3>\n
ANY.RUN’s October 27, 2026 investigation<\/a> describes SkyW4lker phishing aimed at Microsoft 365 accounts through commercial offers, contracts, invoices, and other document lures.<\/p>\n Observed emails included password-protected PDF, DOCX, or XLSX attachments, with the password supplied in the message. Document links led through decoy pages toward a sign-in request.<\/p>\n The researchers connected 618 related sandbox analyses between June 23 and October 21. Those are analysis sessions, not a count of successfully compromised people or businesses.<\/p>\n In the device-code route, the attacker supplies a code and directs you to Microsoft’s real authentication page. Completing that process can authorize the attacker’s session.<\/p>\n You may perform your normal multifactor authentication along the way. The problem is whose request you are approving, rather than whether the sign-in page is genuine.<\/p>\n This is impersonation and account-access fraud. Microsoft and the legitimate services used as stepping stones are not identified as the scam operators.<\/p>\n The lead image illustrates that last handoff. Its example address and DEMO-CODE are fictional and nonfunctional; it is not a screenshot recovered from SkyW4lker.<\/p>\n An invoice invites you to check a charge. A proposal asks you to evaluate an opportunity. A contract suggests someone is waiting for your answer.<\/p>\n Each gives the attachment a purpose before you have established who sent it. That matters when your inbox already contains plenty of genuine business documents.<\/p>\n The useful first check is whether you expected this particular task from this particular person. Recognizing a company name is a much weaker test.<\/p>\n If the sender is a known contact, reach them through a conversation or number you used before. An attacker can exploit a convincing name or compromised mailbox.<\/p>\n A protected attachment can appear careful and professional. The password also creates a small task that pulls you further into the sender’s instructions.<\/p>\n But a password delivered alongside a document does not authenticate its author. Anyone who assembled the email could have supplied both.<\/p>\n Do not treat successful unlocking as verification. It only shows that the password opens the supplied file, not that its links lead to an authorized business workflow.<\/p>\n The documented chain can include CAPTCHA gates or a lure hosted through a legitimate service before the phishing page. Each screen adds another apparently routine instruction.<\/p>\n For the reader, the important change is when reviewing a document becomes an account-authorization task. Stop at that change, even if the earlier screens looked normal.<\/p>\n A page hosted on a recognizable platform can still contain instructions written by an untrusted user. The platform’s reputation does not validate that user’s document.<\/p>\n Do not keep clicking to discover whether the next screen is safer. Verification should happen outside the route supplied by the suspicious message.<\/p>\n Device-code sign-in has legitimate uses, such as authorizing a device that cannot conveniently handle the full login process itself.<\/p>\n In phishing, the criminal starts that process and persuades you to finish it. The code connects your approval to the waiting request.<\/p>\n That is why an unexpected code is different from a code you requested while setting up your own device. Its origin matters.<\/p>\n You should be able to explain what device or application you are authorizing and why. A document saying verification is required does not answer those questions.<\/p>\n The address bar may show Microsoft. Your password manager may recognize it. Your usual authentication prompt may behave exactly as expected.<\/p>\n Those checks establish the destination of your credentials. They do not establish that the device code came from a request you intended to authorize.<\/p>\n Microsoft’s device-code phishing explanation<\/a> describes this authorization trap in a separate campaign. The general mechanism explains why the genuine login page is not enough.<\/p>\n Keep MFA enabled. Calling this an MFA bypass without explanation can hide the practical issue: the victim may complete MFA for an attacker-initiated sign-in.<\/p>\n Once authorization succeeds, access and refresh tokens can let the attacker use the account. Closing the document does not automatically invalidate that access.<\/p>\n A password change can be useful, but recovery needs to address sessions, tokens, and changes made inside the account as well.<\/p>\n The result is not necessarily a broken computer or a suspicious installed program. A cloud account can need urgent recovery while the laptop appears perfectly normal.<\/p>\n First, identify the business transaction. Which order, project, or conversation explains why you received this file? Do not rely on a generic reference to your company.<\/p>\n Next, contact the supposed sender through an established channel. Ask whether they sent the exact document and whether it should require a device-code authorization.<\/p>\n If your company has a normal document-sharing system, open it from your bookmark or work portal. Look for the file there without using the email’s navigation.<\/p>\n An unfamiliar file does not become trustworthy because the sender explains away every concern. Their explanations are part of the same unverified conversation.<\/p>\n For finance teams, keep payment decisions outside this exchange. A document-access request should not also become permission to change a supplier’s banking instructions.<\/p>\n If the message feels urgent, tell the real sender you are checking it. A short delay is easier to resolve than unauthorized access to your work account.<\/p>\n Do not paste codes into a sign-in page while asking a colleague whether the request is safe. Approval may finish before that conversation does.<\/p>\nThe genuine login page can approve an attacker’s request<\/h3>\n
The request to watch for<\/h3>\n
\n
How the SkyW4lker Phishing Scam Works<\/h2>\n
Step 1: A familiar work task gets the attachment opened<\/h3>\n
Step 2: The supplied password gives the file a confidential feel<\/h3>\n
Step 3: Intermediate pages make the route feel official<\/h3>\n
Step 4: The attacker hands you a device code<\/h3>\n
Step 5: You sign in correctly, but for the wrong session<\/h3>\n
Step 6: The attacker can keep access after you close the page<\/h3>\n
How to Check the Document Before Approving Anything<\/h2>\n
What to Do if You Entered the Code or Approved Access<\/h2>\n
\n