Entra_id — CraftedSignal Threat Feed

Entra ID Excessive Account Lockouts Detected

hello@craftedsignal.io — Wed, 22 Apr 2026 18:43:05 +0000

This alert identifies a surge in failed Microsoft Entra ID sign-in attempts (error code 50053) due to account lockouts, suggesting potential brute-force attacks. Attackers often employ password spraying, credential stuffing, or automated guessing to compromise accounts. This detection uses a threshold-based approach to identify coordinated campaigns targeting multiple users. The Entra ID Smart Lockout feature triggers error code 50053, utilizing IP-based tracking to differentiate between “familiar” and “unfamiliar” locations, with lockouts primarily originating from unfamiliar IPs. Successful exploitation can lead to unauthorized access to sensitive data, lateral movement within the network, and potential data exfiltration.

Attack Chain

Initial Access: The attacker attempts to gain access to Entra ID accounts using compromised or guessed credentials.
Password Spraying/Credential Stuffing: The attacker performs password spraying attacks by attempting common passwords across multiple accounts, or credential stuffing attacks by using lists of breached credentials obtained from other sources.
Authentication Failure: The sign-in attempts fail due to incorrect credentials, resulting in authentication failure events in Entra ID sign-in logs.
Smart Lockout Triggered: Entra ID’s Smart Lockout feature detects the repeated failed sign-in attempts from unfamiliar IPs, triggering account lockouts and generating error code 50053.
Account Lockout: The target user accounts are locked out, preventing legitimate users from accessing their accounts.
Potential Enumeration: Prior to the lockouts, the attacker may perform username enumeration, resulting in error code 50034 (user not found) in the sign-in logs.
MFA Bypass Attempt (if applicable): If MFA is not enforced or bypassed, the attacker may attempt to gain access using single-factor authentication.
Account Compromise (if successful): If the attacker successfully guesses the password before lockout or bypasses MFA, the account is compromised, allowing unauthorized access to resources.

Impact

A successful brute-force attack against Entra ID can lead to widespread account compromise. This could result in unauthorized access to sensitive data, business disruption, and potential financial loss. An attacker could leverage compromised accounts to move laterally within the network, escalate privileges, and exfiltrate data. This attack can affect any organization using Microsoft Entra ID for identity and access management.

Recommendation

Deploy the Sigma rule “Entra ID Excessive Account Lockouts Detected” to your SIEM to detect high counts of failed sign-in attempts resulting in account lockouts.
Investigate alerts generated by the Sigma rule by pivoting to the raw logs in Discover or Timeline using the provided query and focusing on event.dataset: "azure.signinlogs" and azure.signinlogs.properties.status.error_code: 50053.
Block suspicious source IPs identified in the investigation using Conditional Access named locations to prevent further brute-force attempts.
Implement Conditional Access policies to block legacy authentication protocols like IMAP, SMTP, and POP, which are often targeted in password spraying attacks.
Review and enhance Conditional Access policies to ensure comprehensive MFA coverage and prevent MFA bypass attempts.

Entra ID ADRS Token Request by Microsoft Authentication Broker

hello@craftedsignal.io — Fri, 10 Apr 2026 17:57:29 +0000

This detection identifies potentially malicious activity within Microsoft Entra ID (Azure AD) involving the Microsoft Authentication Broker (MAB). Specifically, it focuses on OAuth 2.0 token requests where MAB (application ID 29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (DRS) (resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user. The presence of the adrs_access scope within the authentication processing details signals an attempt to interact with the ADRS (Azure Device Registration Service), an action not typically associated with standard user sign-ins. This behavior could indicate an attacker attempting to abuse device registration mechanisms to achieve persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. The Volexity report from April 2025 highlights similar OAuth workflow targeting.

Attack Chain

Attacker compromises user credentials through phishing or other means.
Attacker leverages the compromised credentials to initiate an OAuth 2.0 authentication flow.
The Microsoft Authentication Broker is used to request an access token.
The request targets the Device Registration Service (DRS) with resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9.
The OAuth scope includes adrs_access, indicating an attempt to access ADRS functionalities.
The request is made using a refresh token, suggesting an attempt to establish persistent access.
Successful token acquisition allows the attacker to manipulate device registration or acquire a Primary Refresh Token (PRT).
The attacker uses the PRT or device registration to maintain unauthorized access to resources.

Impact

Successful exploitation could allow an attacker to maintain persistent access to an organization’s cloud resources, even after a user changes their password or is removed from the organization. This can lead to data exfiltration, lateral movement, and further compromise of sensitive information. The number of potentially affected users depends on the scope of the initial compromise and the effectiveness of the attacker’s persistence mechanisms. This attack targets any organization using Microsoft Entra ID.

Recommendation

Deploy the Sigma rule “Entra ID ADRS Token Request by Microsoft Authentication Broker” to your SIEM and tune it for your environment to detect suspicious ADRS access attempts.
Investigate any alerts generated by the Sigma rule, focusing on the user principal and the origin of the request.
Review Conditional Access policies to ensure they are sufficient to prevent unauthorized access to sensitive resources.
Monitor Entra ID audit logs for device registrations or changes to user’s device registration status as suggested in the rule’s triage steps.
Correlate with primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse, as mentioned in the rule’s triage.
Consider adjusting the rule or adding exceptions for specific applications or user accounts that legitimately require access to the Device Registration Service, based on false positive analysis.

Entra ID Federated Identity Credential Issuer Modified

hello@craftedsignal.io — Wed, 18 Mar 2026 21:22:55 +0000

This detection identifies modifications to the issuer URL within a federated identity credential on an Entra ID application. Federated identity credentials enable applications to authenticate using tokens from external identity providers (e.g., GitHub Actions, AWS) without managing secrets. An attacker can exploit this by changing the issuer to an attacker-controlled identity provider, enabling them to generate valid tokens and authenticate as the application’s service principal. This technique provides persistent access to Azure resources with the application’s permissions, effectively bypassing traditional secret-based authentication. The detection logic focuses on the “Update application” event within Entra ID audit logs, specifically targeting changes to the “FederatedIdentityCredentials” property. It is applicable to environments using Azure and Entra ID and is relevant for defenders aiming to prevent unauthorized access and maintain the integrity of their cloud infrastructure.

Attack Chain

An attacker compromises an Entra ID account with sufficient privileges to modify application registrations.
The attacker navigates to the Entra ID portal or uses PowerShell/Azure CLI to locate a target application with federated identity credentials configured.
The attacker modifies the “Issuer” URL of an existing Federated Identity Credential within the application registration. They replace the legitimate issuer URL with a URL controlled by the attacker.
The attacker configures their own identity provider to issue tokens that match the application’s expected audience and subject claims.
The attacker crafts a malicious token from their identity provider, impersonating the legitimate service principal.
The attacker uses the crafted token to authenticate to Azure resources, bypassing normal authentication controls.
The attacker leverages the application’s permissions to access sensitive data, modify configurations, or deploy malicious code.
The attacker maintains persistent access to the Azure environment by continuing to use the compromised federated identity configuration.

Impact

Successful exploitation allows an attacker to gain persistent access to Azure resources with the permissions of the compromised application. This could lead to data breaches, unauthorized modifications to critical infrastructure, and deployment of malicious code within the cloud environment. The impact is significant because it bypasses traditional authentication methods and relies on a trust relationship established with an external identity provider. The rule is rated high severity because it directly addresses a persistence and privilege escalation technique that can severely impact the confidentiality, integrity, and availability of cloud resources.

Recommendation

Enable the Azure integration with Microsoft Entra ID Audit Logs data stream to ingest data in your Elastic Stack deployment, as required by the rule setup instructions.
Deploy the provided Sigma rule to your SIEM to detect unauthorized modifications to federated identity credential issuers in Entra ID (Entra ID Federated Identity Credential Issuer Modified).
Review azure.auditlogs.properties.initiated_by.user.userPrincipalName and ipAddress logs to determine the source of detected changes, as recommended in the rule’s triage notes.
Implement conditional access policies and PIM (Privileged Identity Management) to protect application management operations within Entra ID, as suggested in the rule’s response and remediation guidance.