CYBERRAKSHAK LABS Β· RESEARCH #027

🚨 Your Microsoft 365 account can be compromised without the attacker knowing your password.

CyberRakshakLabs analysis of a Microsoft 365 identity campaign using fake IT support, passkey and SSO lures, AiTM and device-code abuse, MFA persistence and cloud reconnaissance.

By Vivek Kumar Β· Published 10 September 2026
RESEARCH#027
CATEGORYIdentity Security / Threat Intelligence
CRL ASSESSMENTHIGH
RESEARCH LEVELDeep Research
PUBLISHED2026-09-10
Source & social links:
LinkedIn Post β†—WhatsApp β†—YouTube β†—
How CyberRakshakLabs researches threats β†’
MFA is not the whole security boundary.
An attacker may never need your password if they can convince a legitimate employee to authenticate an attacker-controlled session.
HIGHCRL Threat Assessment
8Observed attack-chain phases
1Identity compromise can expose many cloud resources

Executive Summary

Microsoft 365 account compromise is evolving. The activity analysed here shows how attackers can manipulate the authentication process itself instead of relying only on password theft.

Microsoft has described a campaign in which threat actors impersonate corporate IT helpdesk personnel and contact employees through phone calls or SMS. The story is often framed around passkeys, MFA or SSO configuration, creating pressure to complete an authentication step.

The victim is then guided toward a Microsoft-looking authentication workflow. Behind the scenes, the attacker may be using Adversary-in-the-Middle (AiTM) phishing or abusing the OAuth device-code authentication flow.

The core lesson: MFA can protect an account from an attacker β€” but it cannot protect a user who is tricked into authenticating the attacker.

1. What Is Happening?

The opening can sound completely normal:

β€œHello, I'm calling from IT support. We need to update your Microsoft 365 passkey/MFA settings.”

The contact may arrive on a personal phone number or by SMS. That matters because the initial social-engineering interaction can occur outside traditional corporate endpoint telemetry.

Microsoft reports that attackers use fake authentication websites and organization-specific URLs to make the interaction appear legitimate. The passkey or SSO story is often the lure; the underlying objective can be token access, authentication abuse and cloud reconnaissance.

2. The Passkey Story May Be the Lure β€” Not the Objective

What the employee hears

β€œYou need to register your new passkey.”
β€œYour MFA settings must be updated.”
β€œSSO will stop working unless you act now.”

What the attacker may actually want

AiTM phishing, a device-code session, access tokens, authentication persistence and a foothold into Microsoft 365 resources.

Microsoft has observed both AiTM and device-code techniques in this activity. The key social-engineering trick is to make the victim perform a legitimate authentication action for an attacker-controlled session.

3. How Device-Code Phishing Works

Device-code authentication is a legitimate OAuth authentication mechanism designed for devices or applications with limited input capabilities. The security problem appears when an attacker starts the flow and convinces the victim to enter the attacker's code on a legitimate Microsoft authentication page.

Attacker starts authentication→Generates device code→Fake IT instructions→Victim enters code→Victim completes MFA→Attacker receives token

The victim may genuinely believe they authenticated their own Microsoft 365 session. In reality, they may have authenticated the attacker's session. Microsoft notes that device-code abuse can provide an attacker with a valid token without requiring theft of the victim's browser cookie.

4. Why MFA Doesn't Automatically Stop the Attack

Consider an employee who receives an unexpected request to approve a Microsoft 365 login. The Microsoft authentication page may be genuine. The MFA approval may also be genuine.

The critical question is who initiated the authentication flow.

The security question is not only β€œDo we have MFA?”

It is β€œIs our MFA process resistant to phishing and authentication-flow manipulation?”

Microsoft recommends phishing-resistant authentication such as FIDO2/passkeys and recommends controlling device-code authentication where it is unnecessary.

5. Attackers Can Add Their Own MFA

Initial access may only be the beginning. Microsoft observed attackers registering additional authentication methods, including phone numbers, Authenticator applications and software-based OTP methods.

Persistence warning: A new authentication method immediately following a suspicious sign-in should be treated as a high-value identity security event.

The attacker is effectively trying to turn a temporary compromise into a repeatable way back into the account.

6. Microsoft Graph Becomes a Reconnaissance Tool

Microsoft Graph provides legitimate APIs for interacting with Microsoft 365 resources. Once an attacker controls an identity, those same capabilities can become a powerful reconnaissance source.

Identity & permissions

Users, groups, directory roles, authentication methods, applications, service principals and OAuth permissions.

Cloud resources

SharePoint sites, OneDrive resources, mailbox folders, emails and attachments.

A single API request can look legitimate. The security signal emerges when defenders correlate the sequence:

Identity→Permissions→Applications→Mailboxes→SharePoint→OneDrive
7. The Attackers Are Not Necessarily Loud

Cloud collection does not have to look like a huge burst of activity. Microsoft observed SharePoint and OneDrive access at scale and described cases where collection was deliberately paced below 1,000 files or messages per hour.

That creates an important detection lesson: a SOC that only searches for extreme spikes such as β€œ10,000 files downloaded in five minutes” can miss a low-and-slow collection pattern.

Detection mindset: measure behaviour against the user's historical baseline, not only against a fixed volume threshold.
8. The Complete Attack Chain
01

Social Engineering

Fake IT helpdesk call or SMS creates urgency around MFA, SSO or passkey configuration.

02

Authentication Lure

The employee receives a Microsoft-looking authentication experience.

03

AiTM / Device Code

The attacker attempts to obtain credentials/session tokens or an attacker-controlled device-code session.

04

Account Access

An authenticated session or token gives the attacker a cloud foothold.

05

MFA Persistence

Additional authentication methods may be registered.

06

Cloud Recon

Graph is used to map users, groups, roles, applications, permissions and resources.

07

Data Collection

Emails, attachments, SharePoint, OneDrive and other business files become targets.

08

Potential Exfiltration

Sensitive information can ultimately leave the organization's control.

9. What Information Could Be Valuable?

The attacker does not necessarily need an administrator account. Depending on permissions, an ordinary employee identity can expose valuable business information.

πŸ“§ Email

Customer communications, contracts, invoices, internal discussions and attachments.

πŸ“ SharePoint

Policies, project documents, reports, presentations and business records.

☁️ OneDrive

Work files, spreadsheets, presentations and confidential documents.

πŸ‘₯ Identity data

Users, groups, roles and organisational structure.

πŸ” Application data

OAuth applications, service principals and permission relationships.

πŸ’° Business & IP

Invoices, procurement documents, payment discussions, product plans, designs and research.

This makes Microsoft 365 identity compromise a potential business-data compromise, not merely an email-security incident.

10. Why Personal Devices Make Investigation Harder

The initial phishing call or SMS may arrive on an employee's personal mobile device. If that device is not enrolled in corporate endpoint security, the organisation may have little or no endpoint telemetry showing the first interaction.

Investigators may instead have to reconstruct the opening of the incident from:

Unusual sign-in
New MFA method
Device-code authentication
Token activity
Graph enumeration
SharePoint downloads
OneDrive access
Mailbox activity

The employee's recollection of the unsolicited call or SMS can therefore become an important part of the forensic timeline.

11. What Should SOC Teams Hunt For?
AreaHunt for
IdentityImpossible or unusual sign-ins, anonymous/proxy infrastructure, unfamiliar locations, new authentication methods and unexpected Authenticator or phone/OTP registrations.
Microsoft GraphSudden directory enumeration, role discovery, application/OAuth permission discovery, large API request volumes and unusual paging activity.
SharePoint / OneDriveUnusual file access, access outside normal patterns, new locations, automated retrieval, high-volume collection and unusual user agents.
ExchangeLarge-scale mailbox access, attachment collection, suspicious inbox rules, unusual REST API activity and unexpected forwarding behaviour.

Microsoft specifically recommends correlating Graph activity with SharePoint, OneDrive, Exchange and mailbox activity rather than investigating each signal independently.

12. What Should an Organisation Do After Suspected Compromise?

Do not simply reset the password and close the ticket. Treat the incident as a potential identity-and-cloud investigation.

1. Disable or contain the compromised account
2. Remove unauthorized authentication methods
3. Revoke active sessions/tokens
4. Force reauthentication
5. Review sign-in history
6. Review authentication-method changes
7. Investigate OAuth applications and permissions
8. Review Microsoft Graph activity
9. Review Exchange mailbox activity
10. Review SharePoint/OneDrive access
11. Determine what information was accessed
12. Search for persistence

Microsoft's response guidance emphasises validating and removing unauthorized authentication methods, revoking sessions and investigating token issuance/sign-in activity after suspected compromise.

13. Prevention: What Organisations Should Change

πŸ” 1 Β· Use phishing-resistant MFA

Prefer FIDO2 security keys, passkeys and other phishing-resistant authentication methods where supported.

🚫 2 · Control device-code authentication

If the organisation does not need device-code flow, block or restrict it. Where it is required, document and tightly scope the exception.

πŸ‘€ 3 Β· Protect MFA registration

Monitor who registered a new method, when, from where, and whether a suspicious sign-in preceded the change.

πŸ”Ž 4 Β· Monitor cloud behaviour

Correlate sign-in β†’ token β†’ Graph β†’ mailbox β†’ SharePoint β†’ OneDrive rather than treating login as the end of the security story.

πŸ“Š 5 Β· Build behaviour-based detection

Consider user, device, location, token, authentication method, API behaviour, resource accessed, volume, time and historical baseline.

πŸ›‘οΈ 6 Β· Review app consent

Restrict user consent where appropriate, require admin approval and regularly review high-privilege Graph permissions.

14. Employee Awareness: The Simplest Control
IT support should never pressure you into approving an authentication request that you did not initiate.

Be suspicious if someone asks you to:

❌ Enter a device code they provide over the phone
❌ Approve an unexpected MFA request
❌ Register a new Authenticator after an unsolicited call
❌ Follow an unexpected SMS authentication link
❌ β€œFix” Microsoft 365 access immediately under pressure
❌ Share an authentication code with someone claiming to be IT
STOP β†’ END THE CALL β†’ CONTACT IT THROUGH THE OFFICIAL CHANNEL
15. MITRE ATT&CK Mapping
TechniqueRelevance
T1566 – PhishingSocial-engineering and authentication lures.
T1528 – Steal Application Access TokenTheft or abuse of OAuth/application access tokens.
T1098 – Account ManipulationAdding attacker-controlled authentication mechanisms.
T1087.004 – Cloud Account DiscoveryEnumerating cloud identities.
T1526 – Cloud Service DashboardDiscovery of cloud services and resources.
T1530 – Data from Cloud StorageCollection from cloud storage such as SharePoint/OneDrive.

The exact technique mapping depends on the telemetry and attack sequence confirmed during an investigation.

16. Reported Campaign Indicators

The source material reports these domains as campaign-related indicators:

passkeyhelpdesk[.]com
secure-passkey[.]com
setupmypasskey[.]com
add-passkey[.]com
integratedsso[.]com
oktasession[.]com
keysyncos[.]com
IOC handling note: These indicators are reported campaign-related domains from the source material. They should not be treated as proof that every organisation encountering one has been compromised. Ingest them into appropriate controls such as SIEM, EDR/XDR, DNS security, secure web gateway, email security or a threat-intelligence platform, with normal validation and expiry procedures.
17. The Bigger Security Lesson
STEAL PASSWORD→LOGIN→ATTACK

The older mental model is being challenged by cloud identity attacks.

MANIPULATE USER→ABUSE AUTHENTICATION→OBTAIN TOKEN→PERSIST→DISCOVER→COLLECT

The attacker may never deploy malware, exploit a server or crack a password. They may simply convince a legitimate employee to perform a legitimate authentication action on their behalf.

18. CyberRakshakLabs Threat Assessment

Threat Level

πŸ”΄ HIGH

Primary Risk

Identity compromise leading to cloud-resource access and persistence.

Secondary risks

Cloud data theft
Business email compromise
Account persistence
OAuth abuse
Sensitive document exposure
Internal reconnaissance
Follow-on fraud
Further social engineering

Most important defensive priorities

1. Phishing-resistant MFA
2. Device-code control
3. Authentication-method monitoring
4. Token/session visibility
5. Microsoft Graph monitoring
6. SharePoint/OneDrive monitoring
7. Exchange activity monitoring
8. Employee awareness

19. Final CyberRakshakLabs Takeaway

The biggest mistake is thinking: β€œWe have MFA, so we're safe.”
MFA remains one of the most important identity controls. But attackers are increasingly targeting the human and authentication workflow around MFA.

The security question is no longer simply:

β€œDid MFA stop the attacker?”

β€œWho did the employee just authenticate?”

Because sometimes the attacker doesn't need your password. They don't need to defeat MFA. They just need you to approve their login.

VERIFY β†’ AUTHENTICATE β†’ MONITOR β†’ DETECT β†’ REVOKE β†’ RESPOND

Research Basis & Official References

Primary technical basis: Microsoft Security Research's September 9, 2026 analysis of passkey-themed social engineering, AiTM/device-code abuse, MFA persistence, Microsoft Graph reconnaissance and cloud data collection.

Microsoft Security Blog β€” Passkey-themed social engineering leads to identity and cloud compromise β†—

Microsoft Learn β€” Configure Security Defaults for Microsoft Entra ID β†—

Microsoft Learn β€” Block authentication flows with Conditional Access β†—

Campaign indicators and several contextual details in this article are presented as reported threat-intelligence indicators. They should be independently validated before being used for blocking or attribution.

Think Before You Click. Stay Aware. Stay Secure.

CyberRakshakLabs β€” Threat Intelligence for a Safer Tomorrow.