A new data-extortion group disclosed on 9 July 2026 has drawn attention not because of technical sophistication in the conventional sense, but because it bypasses the defences that most Microsoft 365 tenants have invested in, primarily multi-factor authentication, without exploiting any vulnerability and without deploying any malware. The group is tracked as Helix, and its method combines voice phishing, caller ID spoofing, and deliberate abuse of a legitimate Microsoft authentication protocol to obtain valid session tokens for target accounts.
The result is that after a successful Helix operation, there is no malware for endpoint detection tools to catch, no credential theft for password monitoring to surface, no phishing link for email filters to block. The attacker holds a genuine, Microsoft-issued OAuth token for the victim's account, obtained through the victim's own interaction with the real Microsoft login page.
Helix begins by identifying a target employee and their manager. The attacker calls the employee while impersonating the manager, using either the manager's name in conversation or caller ID spoofing to make the incoming number appear to belong to the manager. The call is social engineering in the most straightforward sense: the impersonated manager tells the employee they need them to complete a quick verification step.
In parallel with the phone call, the attacker has already initiated a Device Code Flow authentication request through Microsoft's identity platform. Device Code Flow is a legitimate OAuth mechanism Microsoft built for devices that cannot easily display a browser, such as smart televisions, gaming consoles, and industrial terminals. When a user needs to authenticate on such a device, the device generates a short code and instructs the user to visit microsoft.com/devicelogin and enter the code on a machine with a proper browser. The real Microsoft server then links that browser session to the device's pending authentication request and issues an access token to the device.
Helix uses this mechanism against the employee being called. The attacker's code initiates the device authentication request and obtains the generated code. During the phone call, the attacker, still impersonating the manager, gives the employee the code and the URL and asks them to enter it for the "verification step." The employee visits the real Microsoft login page, authenticates with their real credentials and their real MFA, and enters the code. Microsoft issues a valid access token, which Microsoft then delivers to the attacker's infrastructure, not to any actual device.
The entire transaction runs through Microsoft's own authentication servers. No credentials were stolen. No phishing site was visited. The token is real and will remain valid for the duration of Microsoft's configured token lifetime.
Once Helix holds a valid token, the first move is to register a new multi-factor authentication method for the account. This gives the attacker persistent access that survives a password reset: even if the organisation detects the breach and resets the employee's password, the attacker retains access through the newly registered authenticator until the MFA registration itself is reviewed and revoked.
After establishing persistence, Helix operators enumerate and browse SharePoint. ReliaQuest's analysis of multiple incidents found that the pattern involves reading site pages, reviewing document libraries, and identifying high-value files before committing to bulk exfiltration. In some incidents the move from initial access to bulk download took under an hour. In others the attacker spent days reading email and reviewing SharePoint content quietly before pulling data. The variation suggests deliberate operational choices about what to take and how quickly, rather than a fixed automated playbook.
The stolen data is used for extortion: the attacker contacts the organisation threatening to publish the data unless a payment is made. Unlike ransomware, there is no encryption and no operational disruption. The threat is purely about data exposure. ReliaQuest assessed that Helix likely emerged from the same ecosystem as BlackFile (UNC6671) and ShinyHunters (UNC6661), two groups with overlapping tradecraft and hosting patterns, though attribution remains incomplete.
Device Code Flow abuse exploits a fundamental characteristic of the protocol. MFA is completed by the victim on the real Microsoft login page. The authentication is genuine. The flaw is that the resulting token is delivered to whoever initiated the device code request, which in this attack is the attacker. MFA verifies that the person entering the code is who they claim to be. It does not verify that the device code request itself was initiated by a legitimate device or application.
The defences that block Device Code Flow abuse are not MFA policies but rather Conditional Access policies that restrict which authentication flows are permitted. Microsoft's Conditional Access can block the Device Code Flow entirely for users who have no legitimate need for it, or restrict it to specific managed applications. Organisations that have not configured such restrictions leave the flow available to anyone who can convince an employee to visit microsoft.com/devicelogin and enter a code.
The social engineering step, the vishing call, is what bridges the gap between the technical mechanism and victim action. Employees who understand that no legitimate internal process will ask them to enter a code at a Microsoft URL during an unsolicited phone call are significantly more resistant to this attack than those who do not. That awareness is genuinely hard to build at scale across an organisation, which is part of why Helix's approach is effective.
Despite the absence of malware, Helix operations leave detectable signals in Microsoft 365 audit logs. A new MFA method registration immediately following a Device Code Flow authentication event is a strong signal, particularly when the registration occurs outside of normal business hours or from an unfamiliar location. Bulk SharePoint access, where a user account downloads a large number of files in a compressed time window, is another indicator that most organisations can alert on using Microsoft Defender for Cloud Apps or equivalent tooling.
The Device Code Flow authentication event itself appears in Azure AD sign-in logs with the application name and the country of the IP that initiated the device code request. Comparing the country of that initiation IP against the country of the employee's normal working location provides a further signal when they diverge.
The data exfiltrated in Helix operations, often internal documents, contracts, and communications, is the kind of material that tends to surface on extortion-focused dark web forums and data leak sites. Monitoring for the appearance of your organisation's data in those channels provides a parallel detection path that operates independently of whether the initial access was caught in time. Understanding your organisation's exposure on the dark web is directly relevant to assessing whether a Helix-style operation has already taken place.
The most direct technical control against Device Code Flow abuse is a Conditional Access policy that blocks the flow for user populations that have no operational need for it. Microsoft documents the policy configuration, which targets the Device Code authentication flow specifically, in its identity protection guidance. For organisations where no users authenticate from devices that require Device Code Flow, the policy can apply to all users. For those with specific needs, scoping the block to a security group that excludes the minority of legitimate device-code users is a workable compromise.
Beyond the technical control, reviewing MFA registration events as a security monitoring workflow closes the gap that Helix exploits with its persistence move. An alert on any new authenticator registration, with a short investigation window to confirm it was authorised by the account holder, catches the persistence step even when the initial access was not detected. This kind of identity monitoring workflow is not specific to Helix: it is a sound control against any attack that uses token theft or social engineering to establish foothold in a Microsoft 365 tenant.
Helix represents a continuation of a shift in identity-focused attack techniques that has been underway for several years. The shift is from credential theft, obtaining someone's password and using it, toward token abuse, obtaining a valid authenticated session through legitimate protocol flows and bypassing the credential-checking step entirely. Both approaches end up with the attacker holding access to the target's accounts, but the detection and prevention mechanisms for each are fundamentally different.
Traditional credential theft relies on obtaining a password that can then be used in an authentication flow. Defences against credential theft include MFA, which requires something the attacker does not have even if they have the password, and credential exposure monitoring, which detects when passwords appear in breach data and triggers resets before the exposed password is used. Both of these defences become less relevant when the attack does not use the password at all.
Device Code Flow abuse, as used by Helix, completes MFA as part of the attack. The victim authenticates with their real password and their real second factor. The token that results is genuine. Credential exposure monitoring cannot alert on a password that was never stolen. The defences that work against Helix are upstream of the authentication event: blocking the Device Code Flow protocol for users who do not need it, training employees to recognise the specific social engineering pattern used to solicit code entry, and monitoring for the post-authentication anomalies like new MFA registrations and bulk SharePoint downloads that indicate the flow was abused.
ReliaQuest's attribution of Helix to the same ecosystem as ShinyHunters and BlackFile is notable because it connects a novel technical method, Device Code Flow abuse, to groups with an established track record in data extortion. ShinyHunters has been linked to high-profile breaches at major organisations over several years. BlackFile (UNC6671) has used similar MFA-bypass techniques in previous campaigns. The tradecraft and infrastructure overlap suggests that successful techniques propagate within criminal ecosystems as participants share methods and, in some cases, share infrastructure.
The data extortion model that Helix uses, take data and threaten to publish it rather than encrypting systems, is also worth examining separately from the technical method. Data extortion without ransomware deployment is operationally simpler, leaves no malware on endpoints to detect, and creates a different kind of pressure on victims. The threat is reputational and regulatory rather than operational: the organisation can continue functioning but faces potential exposure of sensitive information, regulatory notification requirements, and the prospect of the stolen data being used in further targeted attacks against its employees, customers, or partners. The absence of operational disruption can also make the incident less urgent in the immediate term, which is sometimes exploited by extortion actors who use the delay to demand larger payments.
For organisations assessing their exposure to Helix-style attacks, the key question is not just whether Device Code Flow is blocked but whether the underlying social engineering preconditions are in place. Helix needs an employee who will enter a code at a Microsoft URL during an unsolicited call. If the employee immediately recognises that pattern as a known attack technique and reports the call rather than complying, the technical exploitation step never happens. The vishing step is simultaneously Helix's most consistent capability and its most trainable-against weak point.
Detecting Device Code Flow abuse in Microsoft 365 environments requires monitoring several specific event types in the Azure Active Directory audit and sign-in logs. The sign-in log entry for a Device Code Flow authentication event includes the authentication protocol field set to "Device Code Flow" and the application name reflecting whichever Microsoft application was specified in the attacker's code request. In Helix's observed campaigns, the application has varied, but Entra admin logs contain enough detail to filter for Device Code Flow authentications and review their source geography against the authenticating user's normal working location.
A detection rule that fires when a Device Code Flow authentication succeeds from a country that is atypical for the authenticating user is a useful first layer. This rule will have false positives for users who legitimately travel, so the alert should prompt investigation rather than automatic remediation. Supplementing the geography check with the MFA registration event is the higher-confidence signal: if a new authenticator is registered within minutes of a Device Code Flow authentication from an unusual location, the probability of abuse is high enough to warrant immediate session revocation and user contact.
The bulk SharePoint download that follows a successful Helix intrusion is detectable through Microsoft Defender for Cloud Apps or through SharePoint audit logs. A volume threshold alert, set to trigger when a user account downloads more than a defined number of files within a short time window, can be tuned to catch the exfiltration step even when the initial access was not detected. The threshold requires tuning against normal patterns for the organisation: a business where SharePoint is used as the primary document repository will have users who legitimately download many files at once, whereas an organisation that uses SharePoint primarily for infrequent document sharing will see lower normal download volumes.
The technical defences against Helix work best when paired with employee awareness of the specific social engineering pattern the group uses. The attack requires the employee to take an action: visit a real Microsoft URL and enter a code. An employee who immediately recognises that pattern as a known attack technique will not complete the step, regardless of how convincing the impersonation call sounds.
The training message does not need to be technically complex. The core behaviour to establish is: no internal process, no IT request, no urgent managerial instruction delivered by phone will ask you to go to a Microsoft login page and enter a code you were given during a phone call. That specific combination of an unsolicited phone call plus a request to enter a code at a Microsoft URL is the attack pattern, and employees who know to treat it as an attack rather than a legitimate request are the most effective defence at the social engineering layer.
Caller ID spoofing, which Helix uses to make calls appear to come from a manager's number, is not trivial to detect in real time. The most practical guidance for employees is to call the purported caller back on a number from the internal directory rather than the number shown on the incoming call display, before completing any unusual authentication request. This step breaks the social engineering dynamic even when caller ID has been spoofed, because the callback goes to the real person whose identity was impersonated.
The combination of employee awareness and technical Conditional Access restrictions creates defence in depth against Device Code Flow abuse. Neither layer is complete on its own: employees can be deceived, and Conditional Access policies can have gaps. Together, they require an attacker to defeat both a policy that should not permit the Device Code Flow and an employee who should recognise the request as suspicious. That combination is significantly harder to defeat than either control alone.
Helix is part of a broader pattern of data-extortion operations that do not involve ransomware deployment. Groups like ShinyHunters, Lapsus$, and their successors have demonstrated that data theft followed by extortion threats can be as financially effective as ransomware without the operational complexity of managing encryption infrastructure, decryption keys, and negotiation panels. For victims, the distinction matters: a data extortion attack does not disrupt operations in the way ransomware does, which can paradoxically reduce the immediate sense of urgency even though the exposure of sensitive data can produce significant regulatory and reputational consequences. Organisations that have invested heavily in ransomware resilience through backup and recovery capabilities need to ensure those investments are complemented by controls against data exfiltration, because the absence of encryption does not mean the absence of serious harm. Monitoring for data appearing on dark web extortion sites and leak forums provides a detection layer that operates after the exfiltration, when perimeter controls have already failed, and is one of the few signals available at that stage of an incident.
The attacks described in this article share a common thread: every one of them either harvests credentials, abuses legitimate identity infrastructure, or exploits the gap between patching timelines and attacker speed. GhostLock and wp2shell give an attacker on an internal machine or a compromised web server a direct route to deeper access. Helix bypasses MFA entirely by abusing Microsoft's own OAuth flows. NetNut makes attribution nearly impossible by routing attack traffic through ordinary home connections.
Defendis monitors the dark web, criminal forums, and breach indices for credentials and data linked to your organisation. When an attacker uses leaked credentials to pivot into your environment, or when data extracted from a compromised system surfaces for sale, Defendis surfaces the exposure with full context so your security team can act before damage compounds.
Book a demo to see how Defendis approaches dark web monitoring for enterprise security teams.
