Security researchers disclosed Helix, a new data-extortion threat group that chains voice phishing calls, Microsoft OAuth Device Code Flow abuse, and real-time MFA manipulation into a single attack sequence that ends with authenticated access to corporate SharePoint and OneDrive environments — and exfiltrated data the group uses as extortion leverage. Okta issued a simultaneous advisory warning enterprises of a related vishing surge targeting Microsoft 365 customers.
Helix’s Three-Stage Attack Chain Against Microsoft 365 Environments
Helix opens each attack with a voice phishing call — an attacker impersonating IT support or a security team member, contacting a target employee by phone to establish trust before directing them to take an action that appears to be routine IT assistance. The social engineering stage is deliberate setup for what comes next: rather than directing the victim to a fake login page, Helix uses the trust established in the call to walk the victim through the Device Code Flow authentication process.
The third stage targets MFA directly. Helix manipulates or re-enrolls authentication factors during the attack to prevent the victim from discovering the account access through unexpected login notifications — a control that would otherwise trigger the victim to revoke the attacker’s session before data exfiltration is complete.
Device Code Flow as Helix’s Token Harvesting Mechanism
Microsoft’s OAuth Device Code Flow was designed for keyboard-limited or display-limited devices — smart TVs, gaming consoles, and similar hardware that cannot easily display and submit a full web login form. The flow works by generating a short code that the user enters at Microsoft’s login.microsoftonline.com domain on a separate device, which causes Microsoft to issue an OAuth access token to the waiting client.
Helix abuses this flow by initiating the Device Code authorization request for the target’s M365 account, then social-engineering the victim into entering the generated code at the legitimate Microsoft URL. The victim authenticates to Microsoft’s own infrastructure using their own credentials — there is no fake login page and no credential harvesting from a phishing site — and the resulting access token is delivered to the attacker’s waiting client. The authentication event in Microsoft’s audit logs appears as a legitimate user login because it was initiated by the real user against Microsoft’s real infrastructure.
SharePoint Data as the Primary Extortion Asset in Helix Campaigns
Once Helix holds a valid M365 access token, it targets SharePoint and OneDrive for data exfiltration. Corporate SharePoint environments are high-value extortion targets because they routinely contain contracts, financial records, HR data, engineering documentation, acquisition materials, and other documents that organizations cannot afford to have publicly disclosed or sold to competitors.
The extortion model does not require ransomware deployment or service disruption. A credible threat to release or sell SharePoint contents is often sufficient to generate extortion payments. Unlike ransomware, SharePoint exfiltration does not trigger business continuity incidents immediately — the victim’s systems remain operational, the stolen data is not immediately apparent in production metrics, and the victim may not discover the exfiltration until Helix presents the extortion demand.
Okta’s Simultaneous Advisory on Related M365 Vishing Activity
Okta issued a separate advisory on the same day warning of a vishing surge targeting Microsoft 365 customers. Attackers in the Okta-documented activity call victims and direct them to phishing sites that mirror Microsoft Entra ID login pages — a pattern consistent with Helix’s operational approach and suggesting that either the Helix group is conducting broad campaigns across the M365 enterprise customer base or that multiple actors are simultaneously running vishing campaigns against M365 environments using similar techniques.
The Okta advisory’s simultaneous emergence alongside the Helix disclosure indicates that the vishing-to-M365-access attack pattern has expanded to the point where multiple security firms and identity providers are observing it independently in customer environments.
Why Helix’s Attack Produces No Phishing Page for Security Tools to Detect
Conventional anti-phishing controls operate by detecting fake login pages, analyzing URLs for phishing indicators, and blocking access to known malicious domains. Helix’s Device Code Flow method leaves no phishing page to detect. The victim enters their code at microsoft.com. The authentication happens at Microsoft’s legitimate infrastructure. The access token delivery to the attacker occurs through the OAuth API flow — all of which appears as normal Microsoft authentication traffic to every proxy, DNS filter, and email security tool in the victim’s environment.
The absence of a detectable phishing artifact is what makes Device Code Flow abuse particularly difficult to block with infrastructure-layer controls. Organizations relying on URL filtering and phishing page detection as their primary M365 account protection have limited visibility into attacks that never present a URL for the victim to click.
Blocking or restricting Device Code Flow in Azure Active Directory Conditional Access policies is an available countermeasure for organizations that do not have devices in their environment requiring the keyboard-less authentication flow the feature was designed for.
