Dracula Enters Microsoft 365: Sucking Access via Device Code Phishing
- Javier Conejo del Cerro
- 22 dic 2025
- 3 Min. de lectura
Dracula never breaks the door. He waits to be invited inside. In late 2025, a Russia-linked phishing campaign followed that same rule, abusing Microsoft 365’s device code authentication flow to gain full account access without exploiting vulnerabilities or deploying malware. Tracked as UNK_AcademicFlare, this campaign shows how modern identity attacks no longer rely on technical flaws, but on social engineering that turns legitimate authentication features into a silent bloodline feeding attackers persistent access.
Phase 1 — The Candlelit Approach
The attack begins quietly, long before any authentication step. Threat actors leverage compromised email accounts belonging to government and military organizations, using them to initiate benign, professional-looking outreach. Targets include government officials, military personnel, think tanks, higher education institutions, and transportation organizations across the United States and Europe.
Rather than rushing the interaction, attackers invest time in rapport building, discussing the victim’s area of expertise and proposing fictitious meetings, interviews, or collaborative discussions. This slow, contextual approach lowers suspicion and positions the attacker as a credible peer rather than an obvious intruder.
At this stage, no malicious payloads are delivered. Trust is the weapon.
Phase 2 — The False Mirror
Once the victim agrees to engage, the attacker shares a link to what appears to be a preparatory document containing meeting questions or discussion topics. The URL is hosted on a Cloudflare Worker, carefully crafted to impersonate the sender’s Microsoft OneDrive environment.
The page instructs the victim to copy a short authentication code and click “Next” to access the document. Everything looks routine. The branding is familiar. The sender is trusted. The victim believes they are simply opening a shared file.
This is the mirror: it reflects legitimacy while hiding intent.
Phase 3 — The Bite: Device Code Phishing
When the victim follows the instructions, they are redirected to Microsoft’s legitimate device code login page. There is no fake login form. No typosquatting. No credential harvesting site.
By entering the provided device code, the victim unknowingly authorizes a session that generates a valid Microsoft 365 access token, which is immediately retrieved by the attacker. With that token, the adversary gains full control of the victim’s Microsoft 365 account.
This compromises all data accessible under the account’s permissions, including Outlook/Exchange email, OneDrive and SharePoint files, Teams chats and files, calendars, and contacts. No alerts are triggered. No passwords are changed. The door was opened willingly.
This technique mirrors earlier Russia-aligned activity associated with Storm-2372, APT29, UTA0304, and UTA0307, and has also been adopted by e-crime groups such as TA2723, enabled by widely available kits like Graphish and SquarePhish. What was once a state-aligned tradecraft is now broadly accessible.
Phase 4 — Feeding Without Noise
Because the access is token-based and fully legitimate, attackers can operate quietly inside the tenant. Email monitoring, document access, internal reconnaissance, and follow-on phishing can all be conducted without deploying malware or triggering traditional endpoint detections.
This is what makes device code phishing so dangerous: it bypasses endpoint security entirely and shifts the battle to identity and authentication control. The victim’s environment does not appear “infected” — it is simply owned.
This campaign reinforces a hard truth of modern cloud security: identity is the perimeter. Device code authentication, while legitimate and useful, becomes a liability when exposed broadly and combined with convincing social engineering.
To keep Dracula out, organizations must block device code authentication using Conditional Access Authentication Flows wherever possible. If business requirements demand its use, access should be tightly restricted through allow-lists based on users, operating systems, or IP ranges. Visibility into token issuance and authentication flows is no longer optional.
In the end, the attackers didn’t steal credentials. They stole permission. And once invited inside, they never needed to knock again.
The Hacker News
Comentarios