Threat actors don't need your password or MFA to compromise your users

Cybersift is observing a modern type of phishing attacks on Office 365 users which deviate from the typical fake login web page, we analysts are typically accustomed to seeing. The new phishing attack utilizes device registration to compromise the victim’s account, meaning that the threat actor does not require to steal your password to gain entry.

But this modern phishing attack is smarter than you might think.

Case Study

We analyzed a phishing email which utilized a device registration compromise. We’ll go into the technical details step by step.

1. Initial Phishing Email

The initial phishing email was delivered using a QR Code phishing technique (Qishing) which manipulates the user into scanning it using their mobile device (this bit is important).

The email is asking the user to scan the QR code to “view a shared file”. Please keep in mind that the sender might actually be a know/trusted user which was compromised and replied to a legitimate previous thread.

This is most likely to bypass Microsoft’s email protection system, since technically, the email does not have any links/attachments a part from a simple image.

2. Scanning the QR Code

Upon scanning the QR Code, it will direct the user to a controlled service webpage in order to generate the magic token (a special token used to identify the user’s session).

The URL contains a base64 text with containing the user’s email, which is utilized to create this magic token (for device registration). It will show a reCAPTCHA textbox mimicking Cloudflare.

After the magic token is generated, the user will be redirected to another website.

3. Verification Step

At this point, there are multiple things happening in the background, to activate the backend script, the user will click another fake Microsoft reCAPTCHA checkbox. These scripts will check

• The user agent (this is important)

• Generation of the device registration code.

At this point, when we clicked the checkbox, we were redirected to amazon.com. Looking at the source code, the site seems to be user-agent aware, meaning that it only goes to the next step if the device is a mobile user agent. This is meant to throw off any automated scanners and analysts. This came from a QR Code, so the victim is expected to scan it using a mobile device.

4. Confirmed Compromised

At this step, we had to change our user agent to a mobile device to get through the last part of this phishing

The malicious site will generate a legitimate magic code to register the rogue device to the victim’s Microsoft account.

Once copied, we clicked on the “Continue to Microsoft” button which actually goes to a legitimate Microsoft website.

At this point, the user has successfully validated the code, effectively 'opening the door' for the attacker.

Once you sign in, the device will be successfully registered without the threat actor ever knowing your password.

Once signed in, the threat actor has full access to the victim’s O365 Account.

Why is this a detection nightmare?

Security teams will struggle to detect these types of compromises due to the device being manually registered by the victim. So the login IP address will be of the victim rather than the threat actor.

To detect this type of threat, we created “A suspicious device has been added to the O365 environment” which triggers when an Add device event is detected and the DeviceId is not already known in o365-known_device_ids, which is populated via login events.

Securing your Microsoft environment against these evolving threats requires a proactive defense. The most effective mitigation is to disable device code flows via Conditional Access policies or using Mobile Application Management policies. As attackers move beyond simple password theft and session hijacking, detection becomes increasingly difficult, making robust, policy-based prevention your strongest line of defense.

-Written by Emanuel Falzon