Microsoft Entra ID - CraftedSignal Threat Feed

Microsoft Entra ID Guest Account Promoted to Member

hello@craftedsignal.io — Thu, 18 Jun 2026 15:40:23 +0000

A sophisticated threat actor, having already established initial access to an organization's Microsoft Entra ID tenant through the compromise of a guest account, can achieve persistent access and elevate privileges by converting the compromised guest account to a member account. This high-impact technique, observed in campaigns targeting cloud environments, leverages the "Update user" operation to modify the UserType attribute. By changing an account from 'Guest' to 'Member', attackers gain full directory read access, bypass external-identity Conditional Access policies, and make the account appear as a standard internal employee, effectively masking their continued presence. This method of persistence is particularly insidious as it often avoids detection mechanisms designed for explicit role assignments, offering a stealthier way to maintain control and facilitate further malicious activities such as reconnaissance and data exfiltration. Defenders must monitor for these specific user attribute changes to detect such advanced persistence.

Attack Chain

Initial Access: An attacker compromises an existing legitimate guest account within an Entra ID tenant, typically through methods like phishing, credential stuffing, or supply chain compromise targeting an external partner.
Privilege Escalation/Compromise: The attacker subsequently compromises an administrator account or gains sufficient permissions within the Entra ID tenant to modify user properties.
UserType Modification: Using the compromised administrative privileges, the attacker executes an "Update user" operation within Entra ID, specifically targeting the previously compromised guest account.
Property Update: During this "Update user" operation, the UserType attribute of the guest account is changed from Guest to Member.
Enhanced Permissions: This conversion automatically grants the now-modified account full directory read access, which is typically restricted for external guest accounts.
Conditional Access Bypass: The conversion also removes external-identity-specific Conditional Access restrictions, allowing the account to operate with fewer security constraints.
Stealthy Persistence: The newly converted "Member" account is virtually indistinguishable from a standard internal employee account, establishing persistent access that often bypasses detection mechanisms for explicit role assignments.
Post-Exploitation: The attacker leverages the "Member" account for broader reconnaissance, directory enumeration (e.g., via Graph API /users, /groups, /applications), data exfiltration, or further lateral movement within the organization's cloud environment.

Impact

Successful exploitation results in an attacker maintaining stealthy, persistent access to the victim organization's Microsoft Entra ID environment. The compromised account gains full directory read access, enabling extensive reconnaissance and mapping of cloud resources and user identities. Furthermore, the bypass of external-identity Conditional Access policies allows the attacker to operate with fewer restrictions, potentially facilitating data exfiltration, further privilege escalation, and lateral movement into integrated cloud applications. This technique leads to long-term compromise, making detection and remediation challenging as the account appears benign.

Recommendation

Deploy the Sigma rules in this brief to your SIEM and tune for your environment.
Ensure comprehensive logging for azure.auditlogs events is enabled and ingested into your security monitoring platform.
Investigate all Update user operations where UserType changes from Guest to Member by examining the initiated_by field for authorization.
Proactively review azure.signinlogs.* for any directory enumeration patterns (e.g., access to Graph API /users, /groups, /applications) originating from recently converted accounts.
Implement strict change management processes for all B2B collaboration migrations or organizational restructuring that involves legitimate Guest-to-Member conversions, ensuring proper documentation and approval.

Microsoft Entra ID Temporary Access Pass (TAP) Abuse for MFA Bypass and Persistence

hello@craftedsignal.io — Thu, 18 Jun 2026 15:39:09 +0000

This threat details the abuse of the Temporary Access Pass (TAP) feature within Microsoft Entra ID by malicious actors. An attacker who has gained User Administrator or Authentication Administrator privileges can exploit these roles to create a TAP for any target Entra ID user account. TAPs are a powerful credential, as they are time-limited, allow for passwordless authentication, and crucially, bypass all existing Multi-Factor Authentication (MFA) requirements, including phishing-resistant methods. Threat actors leverage this capability to sign into compromised accounts without needing the original password, and critically, register new, persistent authentication methods (such as FIDO2 security keys or Microsoft Authenticator app registrations) before the TAP expires. This establishes a durable backdoor, enabling continued unauthorized access, lateral movement, and potential data exfiltration, even if the initial compromise vector is remediated and the TAP itself expires.

Attack Chain

Attacker gains User Administrator or Authentication Administrator privileges within Microsoft Entra ID through an undisclosed initial access vector.
Leveraging these elevated administrative privileges, the attacker creates a Temporary Access Pass (TAP) for a target Entra ID user account, which is recorded in azure.auditlogs.
The generated TAP acts as a time-limited, single-use passcode that bypasses all existing MFA policies and requirements for the target account.
The attacker uses the newly issued TAP to successfully sign into the target user account, as evidenced by entries in azure.signinlogs with "Temporary Access Pass" as the authentication method.
During the active session authenticated by the TAP, the attacker registers one or more new, persistent authentication methods (e.g., FIDO2 security key, Microsoft Authenticator app) for the compromised account.
Upon expiration or revocation of the TAP, the attacker retains persistent access to the target account via the newly registered authentication methods, bypassing the original password and MFA setup.
With persistent access, the attacker can proceed with objectives such as data exfiltration, lateral movement within the cloud environment, or further privilege escalation.

Impact

The successful exploitation of the Entra ID TAP feature can lead to complete account compromise, effectively bypassing all MFA protections in place, including phishing-resistant methods. Attackers can establish long-term persistence within an organization's cloud environment by registering new authentication methods, rendering password changes or MFA resets ineffective without careful post-incident remediation. This can result in unauthorized access to sensitive data, financial systems, or critical infrastructure, and enable further lateral movement within the compromised cloud tenancy. While specific victim numbers are not provided, organizations heavily reliant on Microsoft Entra ID for identity management are at risk, particularly those with insufficiently protected administrative accounts.

Recommendation

Deploy the Sigma rules provided in this brief to your SIEM, specifically the rules detecting 'Microsoft Entra ID Temporary Access Pass Creation', 'Microsoft Entra ID Sign-in Using Temporary Access Pass', and 'New Authentication Method Registration in Entra ID'.
Enable comprehensive logging for azure.auditlogs and azure.signinlogs within Microsoft Entra ID to ensure telemetry is available for the detection rules.
Regularly audit the assignments for 'User Administrator' and 'Authentication Administrator' roles in Microsoft Entra ID, ensuring least privilege and strong protections for these accounts.
Implement strict change management processes for all identity-related administrative actions to identify unauthorized TAP creations in azure.auditlogs.

Microsoft 365 OAuth Device Code Phishing Exploits Non-Compliant Devices

hello@craftedsignal.io — Thu, 18 Jun 2026 15:37:29 +0000

Threat actors are increasingly utilizing sophisticated phishing techniques, specifically targeting the OAuth device code flow within Microsoft 365, to circumvent multi-factor authentication (MFA). Campaigns observed leveraging tools like Kali365 and tradecraft similar to Storm-2372, dating back at least to early 2025 according to referenced reports, lure victims into authorizing access on attacker-controlled or personal non-compliant devices. This method exploits the legitimate device code authentication mechanism by directing users to genuine Microsoft endpoints to complete their login and MFA, while the attacker's phishing kit polls the token endpoint in the background to harvest an MFA-satisfied access token. This approach bypasses traditional MFA protections by manipulating the authorization process itself, granting attackers persistent access and enabling subsequent malicious activities such as reconnaissance and data exfiltration.

Attack Chain

Initial Access / Phishing Lure: Attackers distribute phishing lures (e.g., email, instant message) containing a unique device code and instructions for the victim to visit a legitimate Microsoft verification URL (e.g., microsoft.com/devicelogin).
Device Code Entry: The victim navigates to the genuine Microsoft verification URL and, as instructed by the lure, enters the attacker-provided device code.
Authentication and MFA: The victim is prompted to authenticate with their Microsoft 365 credentials and completes multi-factor authentication (MFA) on a legitimate Microsoft login page.
Token Harvesting: Concurrently, the attacker's phishing kit, having initiated the device code flow, continuously polls the token endpoint. Upon successful authentication and MFA by the victim, the kit intercepts and harvests the resulting MFA-satisfied refresh token and access token. This often occurs from a device not compliant with the organization's security policies.
Unauthorized Access: The attacker uses the harvested tokens to gain unauthorized access to the victim's Microsoft 365 resources (e.g., Exchange Online, SharePoint Online, Microsoft Teams, OneDrive).
Persistence Establishment: To maintain access, attackers may register a new device to the compromised user's account, establishing Primary Refresh Token (PRT) persistence that survives password changes.
Reconnaissance and Lateral Movement: With persistent access, the attacker performs reconnaissance within the victim's environment, enumerating mailboxes, files, and other cloud resources, and potentially moving laterally to other connected applications or services.
Impact and Exfiltration: Finally, the attacker may exfiltrate sensitive data, initiate further attacks, or manipulate cloud resources based on their objectives.

Impact

Successful device code phishing attacks result in complete bypass of multi-factor authentication, granting attackers MFA-satisfied access tokens that provide persistent and unauthorized entry to critical Microsoft 365 services such as Exchange Online, SharePoint Online, and Teams. This leads to immediate compromise of user accounts, enabling data exfiltration, email account takeover, and access to sensitive documents. Attackers can also establish long-term persistence by registering new devices, making detection and remediation more challenging. While no specific victim counts or industry sectors are provided in the source, the technique is broadly applicable to any organization utilizing Microsoft 365, posing a significant risk of intellectual property theft, financial fraud, and business disruption.

Recommendation

Deploy the Sigma rule "M365 OAuth Device Code Grant from Non-Compliant Device" to your SIEM to detect anomalous device code authentication originating from unmanaged endpoints.
Monitor o365.audit logs for RequestType: "Cmsi:Cmsi" events, paying close attention to o365.audit.DeviceProperties (especially Value: "False") and the associated source.ip and source.as.organization.name for unusual origins.
Implement Conditional Access policies in Microsoft Entra ID to restrict device code authentication to only necessary users and applications, and enforce requirements for compliant or hybrid-joined devices.
Deploy the Sigma rule "M365 Suspicious Device Registration by User" to identify attempts by threat actors to establish persistence post-compromise by registering new devices.
Educate users about the risks of device code phishing, emphasizing vigilance against unsolicited requests to enter codes on authentication pages and the importance of verifying the authenticity of login prompts.
For confirmed compromises, immediately revoke all refresh tokens for the affected user, reset their credentials, and review azure.signinlogs, azure.graphactivitylogs, and azure.auditlogs for post-compromise activity and remove any unauthorized device registrations.

Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN

hello@craftedsignal.io — Fri, 29 May 2026 10:36:02 +0000

This detection identifies suspicious Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service (DRS) from autonomous system numbers (ASNs) associated with VPNs, residential proxies, or hosting egress. This activity is often observed in OAuth phishing and adversary-in-the-middle (AitM) device registration attacks. Successful exploitation leads to unauthorized device joins or primary refresh token (PRT) acquisition, enabling persistent access to the victim's Entra ID resources. The detection logic focuses on identifying broker-to-DRS sign-ins originating from suspicious ASNs, a technique used by threat actors to stage device registration from attacker-controlled infrastructure after a user has completed the initial authentication flow.

Attack Chain

The attacker crafts a phishing email containing a malicious link or attachment.
The victim clicks the link and is redirected to a fake login page impersonating Microsoft Entra ID.
The victim enters their credentials on the fake login page, which are then stolen by the attacker.
The attacker uses the stolen credentials to initiate a Microsoft Authentication Broker request to the Device Registration Service (DRS) from a VPN, proxy, or hosting ASN (e.g. 399629, 14061, 136787).
The Microsoft Authentication Broker attempts to register a device with the Entra ID tenant.
The Device Registration Service processes the request, potentially granting the attacker control over the registered device.
The attacker obtains a Primary Refresh Token (PRT) for the compromised account.
The attacker uses the PRT to maintain persistent access to the victim's Entra ID resources, bypassing multi-factor authentication.

Impact

Compromised Entra ID accounts can lead to significant data breaches, unauthorized access to sensitive information, and disruption of business operations. Attackers can use stolen credentials and PRTs to gain persistent access to cloud resources, impersonate legitimate users, and move laterally within the organization's network. Successful device registration enables attackers to bypass security controls and maintain long-term access, making detection and remediation challenging. The use of VPNs and proxies obfuscates the attacker's true location, hindering investigations and attribution.

Recommendation

Deploy the Sigma rule Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN to your SIEM and tune for your environment to detect malicious sign-in activity.
Investigate any sign-ins matching the rule criteria by reviewing azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.app_display_name, and source.as.organization.name.
Compare ASN organizations against approved VPN, MDM, and automation egress in your environment as noted in the rule's false_positives section.
Review Entra ID audit logs for device registration activity around the same timestamp and correlate azure.signinlogs.properties.session_id with other sign-ins for the same user as described in the rule's note section.
Consider implementing Conditional Access policies for the Microsoft Authentication Broker and device registration requirements as described in the rule's note section.

Storm-2949 Abuses SSPR for Cloud-Wide Data Exfiltration

hello@craftedsignal.io — Mon, 18 May 2026 23:34:36 +0000

Storm-2949 conducted a multi-layered attack targeting cloud infrastructure by exploiting compromised identities rather than relying on traditional malware. Starting in May 2026, the actor targeted specific users through social engineering, abusing Microsoft's Self-Service Password Reset (SSPR) to bypass MFA and gain persistent access to Microsoft Entra ID. Once inside, they moved laterally through the victim's Microsoft 365 applications, file-hosting services, and Azure-hosted production environments, exfiltrating sensitive data. This campaign highlights the increasing focus of threat actors on cloud identities and control plane access, using legitimate administrative features for malicious purposes. The attack leveraged the Microsoft Graph API for directory discovery, enumerating users and applications within the tenant to identify high-value targets.

Attack Chain

Initial Access via Social Engineering: Storm-2949 initiates the SSPR process for targeted users, then uses social engineering (e.g., impersonating IT support) to trick them into approving MFA prompts.
MFA Bypass: Once the user approves the prompts, the attacker resets the password and removes existing authentication methods (phone numbers, email addresses, Microsoft Authenticator registrations).
Persistence via New MFA Enrollment: The attacker re-enables MFA and registers a new authentication method on their own device, granting themselves persistent access.
Directory Discovery: Using compromised credentials, the attacker conducts directory discovery using Microsoft Graph API to enumerate users and applications within the tenant.
Privilege Escalation: The attacker identifies privileged accounts to target for further compromise.
Lateral Movement: Leveraging control-plane access, the actor moves laterally across cloud and endpoint environments.
Access Cloud Resources: The attacker accesses sensitive cloud resources such as Key Vaults and storage accounts.
Data Exfiltration: The actor exfiltrates sensitive data from Microsoft 365 applications, file-hosting services, and Azure-hosted production environments.

Impact

The Storm-2949 campaign resulted in the exfiltration of sensitive data from multiple areas of the victim organization's cloud infrastructure, including Microsoft 365 applications and Azure-hosted environments. The attackers specifically targeted high-value assets, including those within SaaS, PaaS, and IaaS layers. The compromise of IT personnel and senior leadership suggests significant potential for widespread damage. The number of affected users and the total volume of exfiltrated data are not specified in the report.

Recommendation

Implement robust MFA policies and educate users about social engineering tactics targeting SSPR. Deploy the rule Detect SSPR Abuse via Authentication Method Changes to identify potential MFA bypass attempts.
Monitor Microsoft Graph API usage for unusual enumeration activities. Deploy the rule Detect Microsoft Graph API Directory Enumeration to identify suspicious user and application enumeration patterns.
Review and harden Azure role-based access control (RBAC) policies to limit lateral movement.
Implement behavior-based detections across endpoints, cloud environments, and identities, like those provided by Microsoft Defender XDR.
Regularly review and audit user accounts, especially those with elevated privileges, for any unauthorized changes to authentication methods or permissions.

Tycoon2FA AiTM Phishing via Microsoft Entra ID Sign-Ins

hello@craftedsignal.io — Mon, 18 May 2026 09:26:29 +0000

This rule detects Microsoft Entra ID sign-ins indicative of Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) attacks. Tycoon2FA is designed to bypass multi-factor authentication (MFA) by relaying authentication requests and capturing session cookies, primarily targeting Microsoft 365 and Gmail accounts. The activity is characterized by the Microsoft Authentication Broker (app ID 29d9ed98-a469-4536-ade2-f981bc1d605e) requesting tokens for Microsoft Graph (00000003-0000-0000-c000-000000000000) or Exchange Online (00000002-0000-0ff1-ce00-000000000000), or the Office web client application (app ID 4765445b-32c6-49b0-83e6-1d93765276ca) authenticating to itself, in conjunction with Node.js-style user agents (node, axios, undici). Defenders should baseline legitimate automation and developer tooling using these patterns to minimize false positives.

Attack Chain

The victim receives a phishing email or message designed to mimic a legitimate Microsoft 365 login page.
The victim clicks the link and is redirected to a Tycoon2FA-controlled server acting as a proxy.
The victim enters their credentials, which are captured by the Tycoon2FA proxy.
The Tycoon2FA proxy initiates a legitimate sign-in attempt to Microsoft Entra ID using the stolen credentials and relays the MFA request to the victim.
The victim completes MFA, and the Tycoon2FA proxy captures the session cookie.
The attacker uses the stolen session cookie to bypass MFA and gain access to the victim's Microsoft 365 account, impersonating the user.
The attacker leverages this access to perform actions such as reading emails, accessing files, or initiating further attacks.

Impact

Successful exploitation leads to account compromise and unauthorized access to sensitive data within Microsoft 365 and Gmail environments. This can result in data breaches, financial loss, and reputational damage. Tycoon2FA is a phishing-as-a-service (PhaaS) platform, enabling even less sophisticated attackers to successfully bypass MFA, potentially affecting a large number of users.

Recommendation

Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect potential AiTM attacks targeting Microsoft Entra ID.
Monitor Microsoft Entra ID sign-in logs for the specific application IDs (29d9ed98-a469-4536-ade2-f981bc1d605e, 4765445b-32c6-49b0-83e6-1d93765276ca) and resource IDs (00000002-0000-0ff1-ce00-000000000000, 00000003-0000-0000-c000-000000000000) associated with Tycoon2FA, as described in the overview.
Investigate sign-ins originating from unusual user agents, especially those containing "node", "axios", or "undici" when used in conjunction with the Microsoft Authentication Broker or Office web client application.
Review conditional access policies and MFA configurations to ensure they are effectively preventing AiTM attacks.
Educate users about phishing techniques and the importance of verifying login pages and MFA requests.