Tech Engine Australia warning on hacker executing Microsoft 365 device code phishing
Cyber Security

Can Hackers Access Microsoft 365 Without Your Password? Device Code Phishing Explained

Yes. Device code phishing can give an attacker access to a Microsoft 365 account without revealing its password. The employee signs in through Microsoft’s genuine website, but unknowingly authorises a connection the attacker started.

The attack can also succeed when the employee completes an MFA check during that sign-in. Nothing needs to be downloaded, and the password does not have to be entered on a fake website.

The critical question is what the sign-in authorises. A genuine Microsoft page cannot tell you whether the person who sent you there should be trusted.

How device code phishing works

Device code sign-in has a legitimate purpose. It lets someone authenticate an application or device that cannot conveniently display a normal sign-in screen. The person enters a short code in a browser on another device, then signs in.

In a phishing attack, the criminal starts that process and persuades someone else to complete it:

  1. The attacker starts a sign-in request. Microsoft generates a code associated with that request.
  2. The attacker sends the code to an employee. A message may present it as a meeting code or a step needed to access content.
  3. The employee enters it on Microsoft’s genuine page. They sign in and complete any required authentication.
  4. The attacker’s application receives authentication tokens. Those tokens can provide access within the permissions and policies that apply.

The code connects the employee’s authentication to the attacker’s request. It is not a password reset code or an MFA code the employee is being asked to disclose.

For a simple example, consider a fake Teams invitation that instructs the recipient to enter a supplied code before joining. The recipient thinks they are accessing a meeting. They are actually completing a separate sign-in initiated by someone else.

Microsoft documented this use of fake Teams invitations in its February 2025 report on the group then tracked as Storm-2372.

Why checking the website and completing MFA is not enough

Checking a website address remains useful against fake login pages. Here, however, the Microsoft sign-in page may be real. The deception concerns the purpose of the request.

MFA can work exactly as configured: the legitimate employee proves their identity. If they complete authentication for the attacker-initiated request and policy permits it, that successful authentication can enable the attacker’s access.

This is why describing every such incident as “hackers breaking MFA” is misleading. The employee may have completed the security check for the wrong connection.

Keep MFA enabled. Review the application named in a sign-in prompt and whether you initiated the activity. If a message unexpectedly asks you to enter a device code, verify the request through a known contact method.

Your Microsoft 365 support provider should explain which device sign-in processes your staff genuinely need. Recognising an approved process is more useful than simply being told to watch for suspicious emails.

What the attacker could access

Authentication tokens let applications access services without repeatedly asking for a password. An access token applies to particular resources and permissions. Where issued, a refresh token can support obtaining further access tokens, subject to validity and security controls.

That does not automatically give an attacker unrestricted access to your entire Microsoft 365 environment. The consequences depend on the affected account, application permissions, requested resources and organisational policies.

Potential exposure includes email and cloud files. In the Storm-2372 campaign, Microsoft observed attackers searching and extracting email, then using compromised accounts to send further phishing messages internally.

For a business, the concern extends beyond the original employee. Messages from a compromised colleague may appear credible to other staff. Assessing the incident therefore requires checking what was accessed and whether the account was used to target anyone else.

Block unnecessary device code sign-ins

Ask your IT provider whether your organisation uses device code authentication and where. Microsoft recommends blocking the flow wherever possible, with documented exceptions for necessary uses.

Microsoft Entra Conditional Access can target device code flow. Your provider should review sign-in logs, identify legitimate dependencies and test the proposed policy before enforcement. Report-only mode helps show which sign-ins a policy would affect without immediately blocking them.

An exception needs an owner and a reason. Allowing a broad group of employees to bypass the restriction can leave more access open than the original business requirement justified.

The review should answer three questions:

  • Which accounts or applications require device code sign-in?
  • What would break if the flow were blocked?
  • Who reviews exceptions and investigates unexpected use?

This is work to include when discussing cyber security services. Ask your provider to confirm licensing, policy coverage and monitoring responsibilities.

Give staff a clear instruction: do not enter an unsolicited device code simply because a message says it is needed for a meeting or document. Use a known route to verify the request.

If someone has already entered a code

Report it immediately, even if the employee never disclosed a password. Keep the original message and record when the interaction occurred.

Receiving a code or opening a page is not the same as completing authorisation. Tell IT exactly what happened, including whether the employee signed in, approved MFA or clicked a confirmation.

If access may have been granted, the response should include revoking affected sessions and refresh tokens, reviewing sign-ins and checking account activity. IT may need to restrict the account while investigating.

Do not treat a password change as proof that the incident is contained. Token revocation can also take time to take effect. The responder needs to assess remaining access and any changes made to the account.

When arranging managed IT services in Brisbane, establish who can take these actions urgently and how employees reach them.

Check your Microsoft 365 sign-in controls

At Tech Engine Australia, we help businesses manage Microsoft 365 and strengthen cyber security. If you need IT support in Melbourne or across our Australian service areas, talk to our team about device code sign-ins, access policies and incident response. We’ll help you identify practical changes for your business.