{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/azure/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Entra ID"],"_cs_severities":["high"],"_cs_tags":["azure","entra_id","credential_access","brute_force"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis 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 \u0026ldquo;familiar\u0026rdquo; and \u0026ldquo;unfamiliar\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker attempts to gain access to Entra ID accounts using compromised or guessed credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePassword Spraying/Credential Stuffing:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Failure:\u003c/strong\u003e The sign-in attempts fail due to incorrect credentials, resulting in authentication failure events in Entra ID sign-in logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSmart Lockout Triggered:\u003c/strong\u003e Entra ID\u0026rsquo;s Smart Lockout feature detects the repeated failed sign-in attempts from unfamiliar IPs, triggering account lockouts and generating error code 50053.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Lockout:\u003c/strong\u003e The target user accounts are locked out, preventing legitimate users from accessing their accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePotential Enumeration:\u003c/strong\u003e Prior to the lockouts, the attacker may perform username enumeration, resulting in error code 50034 (user not found) in the sign-in logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMFA Bypass Attempt (if applicable):\u003c/strong\u003e If MFA is not enforced or bypassed, the attacker may attempt to gain access using single-factor authentication.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Compromise (if successful):\u003c/strong\u003e If the attacker successfully guesses the password before lockout or bypasses MFA, the account is compromised, allowing unauthorized access to resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Entra ID Excessive Account Lockouts Detected\u0026rdquo; to your SIEM to detect high counts of failed sign-in attempts resulting in account lockouts.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule by pivoting to the raw logs in Discover or Timeline using the provided query and focusing on \u003ccode\u003eevent.dataset: \u0026quot;azure.signinlogs\u0026quot; and azure.signinlogs.properties.status.error_code: 50053\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eBlock suspicious source IPs identified in the investigation using Conditional Access named locations to prevent further brute-force attempts.\u003c/li\u003e\n\u003cli\u003eImplement Conditional Access policies to block legacy authentication protocols like IMAP, SMTP, and POP, which are often targeted in password spraying attacks.\u003c/li\u003e\n\u003cli\u003eReview and enhance Conditional Access policies to ensure comprehensive MFA coverage and prevent MFA bypass attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T18:43:05Z","date_published":"2026-04-22T18:43:05Z","id":"/briefs/2024-01-30-entra-id-lockouts/","summary":"A high volume of failed Microsoft Entra ID sign-in attempts resulting in account lockouts indicates potential brute-force attacks, such as password spraying or credential stuffing, targeting user accounts.","title":"Entra ID Excessive Account Lockouts Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-30-entra-id-lockouts/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.8,"id":"CVE-2026-32168"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["azure","privilege escalation","vulnerability","cve-2026-32168"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-32168 is a critical vulnerability affecting the Azure Monitor Agent. Disclosed on April 14, 2026, this vulnerability stems from improper input validation within the agent. A locally authorized attacker can exploit this flaw to elevate their privileges on the system. Given the widespread use of Azure Monitor Agent for collecting monitoring data in cloud and hybrid environments, this vulnerability poses a significant risk. Successful exploitation would allow an attacker to gain elevated control over systems managed by the agent. This vulnerability impacts any organization utilizing Azure Monitor Agent, potentially granting attackers the ability to pivot to other resources or cause data breaches.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial authorized access to a system with Azure Monitor Agent installed.\u003c/li\u003e\n\u003cli\u003eAttacker identifies the locally exploitable improper input validation vulnerability (CVE-2026-32168) in the Azure Monitor Agent.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious input designed to exploit the input validation flaw.\u003c/li\u003e\n\u003cli\u003eThe attacker interacts with the Azure Monitor Agent, providing the crafted malicious input.\u003c/li\u003e\n\u003cli\u003eThe agent processes the malicious input without proper validation.\u003c/li\u003e\n\u003cli\u003eThe improper input leads to the agent executing commands or accessing resources with elevated privileges.\u003c/li\u003e\n\u003cli\u003eAttacker leverages the elevated privileges to perform unauthorized actions.\u003c/li\u003e\n\u003cli\u003eAttacker gains control of the system, potentially leading to data exfiltration or further lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-32168 allows an attacker to elevate privileges on systems running the Azure Monitor Agent. This could lead to a compromise of sensitive data, disruption of monitoring services, and potential lateral movement to other systems within the environment. The specific impact depends on the permissions of the account under which the Azure Monitor Agent is running and the resources it has access to. Given the broad adoption of Azure Monitor Agent in enterprise environments, this vulnerability has the potential to affect numerous organizations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch or update provided by Microsoft to remediate CVE-2026-32168 on all systems running the Azure Monitor Agent as soon as possible, referencing the Microsoft Security Response Center advisory (\u003ca href=\"https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32168\"\u003ehttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32168\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eMonitor for suspicious activity related to the Azure Monitor Agent, such as unexpected process executions or file modifications, using the provided Sigma rules.\u003c/li\u003e\n\u003cli\u003eReview and harden the permissions of the account under which the Azure Monitor Agent is running to minimize the potential impact of successful exploitation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-15T12:00:00Z","date_published":"2026-04-15T12:00:00Z","id":"/briefs/2026-04-azure-monitor-agent-privesc/","summary":"CVE-2026-32168 is an improper input validation vulnerability in Azure Monitor Agent that allows a locally authorized attacker to elevate privileges.","title":"Azure Monitor Agent Improper Input Validation Vulnerability (CVE-2026-32168)","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-monitor-agent-privesc/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.8,"id":"CVE-2026-32192"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cve-2026-32192","azure","monitor agent","privilege escalation","deserialization"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-32192 is a critical vulnerability affecting the Azure Monitor Agent, a component used for collecting monitoring data in Azure environments. This vulnerability stems from the insecure deserialization of untrusted data, allowing an attacker with local access and authorization to escalate their privileges on the affected system. The vulnerability was published on April 14, 2026. An attacker could potentially leverage this to gain higher-level access to the system, potentially leading to further lateral movement or data compromise. Defenders should prioritize patching this vulnerability to prevent exploitation and privilege escalation within their Azure environments. This vulnerability matters because successful exploitation could lead to unauthorized access to sensitive data, system configuration changes, or other malicious activities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system with the Azure Monitor Agent installed and has local user privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts malicious serialized data designed to exploit the deserialization vulnerability in the Azure Monitor Agent.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages an authorized channel to inject the malicious serialized data into the Azure Monitor Agent\u0026rsquo;s processing pipeline.\u003c/li\u003e\n\u003cli\u003eThe Azure Monitor Agent attempts to deserialize the crafted data without proper validation.\u003c/li\u003e\n\u003cli\u003eDuring deserialization, the malicious data triggers the execution of attacker-controlled code.\u003c/li\u003e\n\u003cli\u003eThe attacker-controlled code elevates the attacker\u0026rsquo;s privileges to a higher level, such as SYSTEM or root.\u003c/li\u003e\n\u003cli\u003eThe attacker uses their elevated privileges to perform unauthorized actions, such as installing malware, accessing sensitive data, or modifying system configurations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-32192 allows a local attacker with low privileges to escalate their privileges to SYSTEM or root on the affected machine. This could lead to complete system compromise, including data theft, malware installation, and disruption of services. The impact is significant due to the widespread use of Azure Monitor Agent in Azure environments, making numerous systems potentially vulnerable.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch released by Microsoft to address CVE-2026-32192 on all systems running the Azure Monitor Agent as soon as possible, as referenced in the vulnerability advisory \u003ca href=\"https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32192\"\u003ehttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32192\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Detect Suspicious Azure Monitor Agent Process Creation\u0026rdquo; to detect potential exploitation attempts by monitoring for unusual process executions initiated by the Azure Monitor Agent.\u003c/li\u003e\n\u003cli\u003eEnable process creation logging to facilitate the detection of malicious activity stemming from the Azure Monitor Agent based on the rules provided.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-15T12:00:00Z","date_published":"2026-04-15T12:00:00Z","id":"/briefs/2026-04-azure-monitor-agent-privilege-escalation/","summary":"CVE-2026-32192 allows a locally authorized attacker to escalate privileges on a host running the Azure Monitor Agent via deserialization of untrusted data.","title":"Azure Monitor Agent Deserialization Vulnerability (CVE-2026-32192) Allows Local Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-monitor-agent-privilege-escalation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","entra_id","persistence","oauth"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003eadrs_access\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker compromises user credentials through phishing or other means.\u003c/li\u003e\n\u003cli\u003eAttacker leverages the compromised credentials to initiate an OAuth 2.0 authentication flow.\u003c/li\u003e\n\u003cli\u003eThe Microsoft Authentication Broker is used to request an access token.\u003c/li\u003e\n\u003cli\u003eThe request targets the Device Registration Service (DRS) with resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9.\u003c/li\u003e\n\u003cli\u003eThe OAuth scope includes \u003ccode\u003eadrs_access\u003c/code\u003e, indicating an attempt to access ADRS functionalities.\u003c/li\u003e\n\u003cli\u003eThe request is made using a refresh token, suggesting an attempt to establish persistent access.\u003c/li\u003e\n\u003cli\u003eSuccessful token acquisition allows the attacker to manipulate device registration or acquire a Primary Refresh Token (PRT).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the PRT or device registration to maintain unauthorized access to resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could allow an attacker to maintain persistent access to an organization\u0026rsquo;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\u0026rsquo;s persistence mechanisms. This attack targets any organization using Microsoft Entra ID.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Entra ID ADRS Token Request by Microsoft Authentication Broker\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious ADRS access attempts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the user principal and the origin of the request.\u003c/li\u003e\n\u003cli\u003eReview Conditional Access policies to ensure they are sufficient to prevent unauthorized access to sensitive resources.\u003c/li\u003e\n\u003cli\u003eMonitor Entra ID audit logs for device registrations or changes to user\u0026rsquo;s device registration status as suggested in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eCorrelate with primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse, as mentioned in the rule\u0026rsquo;s triage.\u003c/li\u003e\n\u003cli\u003eConsider 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T17:57:29Z","date_published":"2026-04-10T17:57:29Z","id":"/briefs/2026-06-adrs-token-request/","summary":"Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker requests access to the Device Registration Service on behalf of a user principal, potentially indicating an attempt to abuse device registration for unauthorized persistence.","title":"Entra ID ADRS Token Request by Microsoft Authentication Broker","url":"https://feed.craftedsignal.io/briefs/2026-06-adrs-token-request/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":true,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"threat","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies a specific attack sequence targeting Azure Arc-connected Kubernetes clusters. It focuses on the scenario where a service principal authenticates to Microsoft Entra ID and subsequently requests credentials for an Azure Arc-connected Kubernetes cluster. The \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action is used to retrieve tokens that enable kubectl access through the Arc Cluster Connect proxy. This sequence is particularly concerning when the service principal authenticates externally and immediately accesses Arc cluster credentials, especially from unexpected locations or Autonomous System Numbers (ASNs). This behavior, observed in attacks like those described by IBM X-Force in 2025, can lead to attackers gaining unauthorized access to and control over Kubernetes clusters. Defenders should investigate such events, particularly when the sign-in originates from an unexpected location or ASN.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains unauthorized access to a service principal\u0026rsquo;s credentials (e.g., through credential stuffing, phishing, or exposed secrets).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService Principal Authentication:\u003c/strong\u003e The attacker uses the compromised service principal credentials to authenticate to Microsoft Entra ID (Azure AD) using the \u003ccode\u003eServicePrincipalSignInLogs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Listing Request:\u003c/strong\u003e Immediately following successful authentication, the attacker leverages the service principal to initiate a request to list the cluster user credentials for an Azure Arc-connected Kubernetes cluster, triggering the \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e in the Activity Logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Retrieval:\u003c/strong\u003e The attacker retrieves the Arc cluster credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProxy Tunnel Establishment:\u003c/strong\u003e The attacker uses the retrieved credentials to establish a proxy tunnel into the Kubernetes cluster via the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKubernetes Access:\u003c/strong\u003e With the tunnel established, the attacker can now execute kubectl commands, perform unauthorized actions within the cluster, such as creating, reading, updating, and deleting (CRUD) secrets and configmaps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement \u0026amp; Privilege Escalation:\u003c/strong\u003e The attacker exploits vulnerabilities or misconfigurations within the Kubernetes cluster to move laterally to other resources, escalate privileges, and gain further control.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or Ransomware Deployment:\u003c/strong\u003e The attacker exfiltrates sensitive data from the Kubernetes cluster or deploys ransomware to encrypt critical data, impacting business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this attack chain can lead to complete compromise of Azure Arc-connected Kubernetes clusters. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and potentially deploy ransomware. The IBM X-Force team has documented cases of attackers using similar techniques for hybrid escalation and persistence. This can impact organizations across all sectors utilizing Azure Arc for managing Kubernetes clusters, potentially affecting dozens or hundreds of clusters per victim organization.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM and tune for your environment to detect the sequence of service principal sign-in followed by Arc cluster credential access.\u003c/li\u003e\n\u003cli\u003eReview Azure AD Audit Logs for recent changes to service principals, focusing on new credentials, federated identities, and owner changes, based on the investigation steps outlined in the rule\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eEnable conditional access policies to restrict service principal authentication by location to prevent logins from unexpected regions, as suggested in the rule\u0026rsquo;s note.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e events to identify potential unauthorized access attempts.\u003c/li\u003e\n\u003cli\u003eRotate service principal credentials regularly and revoke active sessions and tokens for the SP as outlined in the rule\u0026rsquo;s response and remediation steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-11-24-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Azure AD followed by listing credentials for an Azure Arc-connected Kubernetes cluster, indicating potential adversary activity with stolen service principal secrets to establish a proxy tunnel into Kubernetes clusters.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-11-24-azure-arc-credential-access/"},{"_cs_actors":[],"_cs_cves":[{"cvss":10,"id":"CVE-2026-33105"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["azure","kubernetes","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-33105, discovered in April 2026, is a critical vulnerability affecting Microsoft Azure Kubernetes Service (AKS). This vulnerability stems from an improper authorization mechanism, allowing an unauthorized attacker to elevate privileges within the network. With a CVSS v3.1 score of 10.0, this flaw represents a severe risk. Successful exploitation could grant attackers complete control over the AKS cluster, potentially impacting all workloads and data managed by the service. Given the widespread adoption of AKS for container orchestration, this vulnerability poses a significant threat to organizations relying on Azure\u0026rsquo;s Kubernetes infrastructure. Defenders should prioritize patching and implement detection measures to mitigate potential exploitation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker gains initial access to the network where the AKS cluster is deployed.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the improper authorization vulnerability (CVE-2026-33105) within the AKS control plane.\u003c/li\u003e\n\u003cli\u003eUsing the vulnerability, the attacker bypasses intended access controls.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges, gaining administrative rights within the AKS cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to access sensitive resources, such as Kubernetes secrets and configuration files.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys malicious containers or modifies existing deployments to further compromise the environment.\u003c/li\u003e\n\u003cli\u003eThe attacker gains control over the worker nodes in the AKS cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses compromised worker nodes to move laterally within the network, potentially targeting other Azure services or on-premises resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-33105 allows an attacker to gain full control over an Azure Kubernetes Service cluster. This includes the ability to deploy, modify, and delete workloads, access sensitive data, and potentially pivot to other Azure resources or on-premises networks. Given the critical nature of many applications hosted on Kubernetes, this could lead to significant data breaches, service disruptions, and financial losses. The lack of specific victim numbers makes it impossible to assess the scale of damage, however any unpatched AKS cluster is potentially at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch released by Microsoft to address CVE-2026-33105 on all AKS clusters immediately (\u003ca href=\"https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33105)\"\u003ehttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33105)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the blast radius of a potential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor AKS audit logs for suspicious activity indicative of privilege escalation attempts.\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect suspicious processes connecting to the Kubernetes API server, and tune it for your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T00:16:05Z","date_published":"2026-04-03T00:16:05Z","id":"/briefs/2026-04-azure-kubernetes-privesc/","summary":"CVE-2026-33105 is a critical vulnerability in Microsoft Azure Kubernetes Service that allows an unauthorized attacker to elevate privileges over a network due to improper authorization.","title":"CVE-2026-33105 - Microsoft Azure Kubernetes Service Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-kubernetes-privesc/"},{"_cs_actors":[],"_cs_cves":[{"cvss":10,"id":"CVE-2026-33107"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["ssrf","azure","databricks","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-33107 describes a critical server-side request forgery (SSRF) vulnerability affecting Azure Databricks. This vulnerability allows an unauthenticated attacker to potentially elevate their privileges within the network. Successful exploitation could allow an attacker to access sensitive data, modify configurations, or potentially gain complete control over the Databricks environment. The vulnerability was published on April 2nd, 2026. Due to the nature of SSRF, this vulnerability could be exploited remotely, making it a high-risk issue for organizations utilizing Azure Databricks. This vulnerability matters because it can lead to significant data breaches, service disruption, and compromise of sensitive resources managed within the Azure Databricks environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an endpoint within the Azure Databricks environment vulnerable to SSRF.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request targeting an internal resource. The request is designed to exploit the SSRF vulnerability.\u003c/li\u003e\n\u003cli\u003eThe Databricks server, processing the crafted request, unwittingly sends it to the specified internal resource.\u003c/li\u003e\n\u003cli\u003eThe internal resource responds to the Databricks server with data intended only for internal consumption.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the SSRF vulnerability to bypass authentication or authorization checks, gaining access to the internal resource.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges by abusing the compromised internal resource or service. This may involve modifying configurations, accessing restricted data, or executing privileged commands.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the elevated privileges to move laterally within the network, compromising additional resources.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, denial of service, or complete control of the Azure Databricks environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-33107 could lead to significant privilege escalation within an Azure Databricks environment. An attacker could potentially gain unauthorized access to sensitive data, modify critical system configurations, or even achieve complete control over the Databricks cluster. This could result in data breaches, service disruptions, and substantial financial losses. The exact number of potential victims and the scope of the impact would depend on the specific configurations and data stored within the targeted Azure Databricks environment. Given the critical nature of Databricks for data analytics, the impact on organizations relying on this service can be substantial.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the security update provided by Microsoft to patch CVE-2026-33107 immediately on all Azure Databricks instances.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the impact of potential SSRF exploits.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Suspicious Databricks Outbound Connections\u003c/code\u003e to identify potential SSRF attempts.\u003c/li\u003e\n\u003cli\u003eMonitor webserver logs for unusual outbound connections originating from Azure Databricks servers.\u003c/li\u003e\n\u003cli\u003eReview and restrict access to internal resources within the Azure Databricks environment.\u003c/li\u003e\n\u003cli\u003eImplement strict input validation and sanitization on all user-supplied data to prevent SSRF attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T00:16:05Z","date_published":"2026-04-03T00:16:05Z","id":"/briefs/2026-04-azure-databricks-ssrf/","summary":"A server-side request forgery (SSRF) vulnerability, identified as CVE-2026-33107, exists in Azure Databricks, allowing an unauthorized attacker to elevate privileges over a network.","title":"Azure Databricks SSRF Vulnerability (CVE-2026-33107) Allows Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-databricks-ssrf/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.6,"id":"CVE-2026-32173"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["azure","sre","authentication","information-disclosure"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-32173 identifies a critical improper authentication vulnerability within the Azure SRE Agent. This flaw enables an unauthenticated attacker to potentially gain unauthorized access to sensitive information traversing the network. The vulnerability was published on 2026-04-02 and has a CVSS v3.1 score of 8.6, indicating a high severity.  The vulnerability affects systems utilizing the Azure SRE Agent and could expose confidential data to unauthorized parties. Successful exploitation would allow an attacker to eavesdrop on network communications and extract sensitive information handled by the agent. Defenders should prioritize patching and monitoring systems running the Azure SRE Agent.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker identifies a vulnerable Azure SRE Agent instance.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious network request targeting the vulnerable endpoint on the agent.\u003c/li\u003e\n\u003cli\u003eDue to the improper authentication, the agent processes the request without proper authorization.\u003c/li\u003e\n\u003cli\u003eThe agent retrieves sensitive information that it is normally restricted from disclosing.\u003c/li\u003e\n\u003cli\u003eThe agent transmits the sensitive information back to the attacker over the network.\u003c/li\u003e\n\u003cli\u003eThe attacker captures and analyzes the disclosed data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the disclosed information for further reconnaissance or exploitation activities within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-32173 allows unauthorized disclosure of sensitive information handled by the Azure SRE Agent. This can lead to data breaches, credential compromise, and lateral movement within the Azure environment. The extent of the impact depends on the type and volume of information the SRE Agent handles. Organizations using affected versions of the agent are at risk of exposing internal configurations, credentials, or other confidential data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch provided by Microsoft for CVE-2026-32173 as soon as possible to remediate the vulnerability (\u003ca href=\"https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32173)\"\u003ehttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32173)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious activity targeting Azure SRE Agent endpoints using the \u0026ldquo;Detect Azure SRE Agent Information Disclosure Attempt\u0026rdquo; Sigma rule.\u003c/li\u003e\n\u003cli\u003eReview access controls and network segmentation to limit the blast radius in case of successful exploitation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T00:16:04Z","date_published":"2026-04-03T00:16:04Z","id":"/briefs/2026-04-azure-sre-auth-bypass/","summary":"An improper authentication vulnerability (CVE-2026-32173) in the Azure SRE Agent allows an unauthorized attacker to disclose sensitive information over the network, potentially leading to data breaches or further compromise.","title":"Azure SRE Agent Improper Authentication Vulnerability (CVE-2026-32173)","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-sre-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.1,"id":"CVE-2026-32211"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["azure","information-disclosure","vulnerability"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-32211 is a critical vulnerability affecting Azure MCP Server. The vulnerability stems from a missing authentication check for a critical function. Discovered in early April 2026 and assigned a CVSS v3.1 score of 9.1, this flaw allows an unauthenticated attacker to potentially disclose sensitive information over the network. This could impact the confidentiality of data managed by the MCP server. Defenders need to address this vulnerability to prevent unauthorized access to potentially sensitive information residing on or managed by the affected Azure MCP Server instances. The scope of impact depends on the specific deployment and the sensitivity of the data handled by the MCP server.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies an Azure MCP Server instance exposed on the network.\u003c/li\u003e\n\u003cli\u003eAttacker sends a specially crafted request to the vulnerable function within the MCP Server.\u003c/li\u003e\n\u003cli\u003eDue to the missing authentication, the server processes the request without verifying the attacker\u0026rsquo;s identity.\u003c/li\u003e\n\u003cli\u003eThe vulnerable function executes and retrieves sensitive information.\u003c/li\u003e\n\u003cli\u003eThe server sends the requested information back to the attacker over the network.\u003c/li\u003e\n\u003cli\u003eAttacker analyzes the disclosed information for further exploitation or to gain a deeper understanding of the system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the disclosed information to pivot to other systems or escalate privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-32211 allows an unauthenticated attacker to disclose sensitive information. The impact of this vulnerability is significant due to the potential exposure of confidential data handled by the Azure MCP Server. While the specific scope of impact depends on the targeted MCP server\u0026rsquo;s configuration and role, a successful attack could lead to data breaches, unauthorized access to resources, and further compromise of the affected environment. Organizations using vulnerable versions of Azure MCP Server are at risk until the patch provided by Microsoft is applied.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the security update provided by Microsoft to patch CVE-2026-32211 on all affected Azure MCP Server instances immediately. Refer to the Microsoft advisory \u003ca href=\"https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32211\"\u003ehttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-32211\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious requests to Azure MCP Server instances originating from untrusted sources to detect potential exploitation attempts.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the blast radius of potential compromises and restrict access to sensitive resources.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided to detect exploitation attempts in network logs.\u003c/li\u003e\n\u003cli\u003eReview and enforce strong authentication policies for all Azure services and applications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T00:16:04Z","date_published":"2026-04-03T00:16:04Z","id":"/briefs/2026-04-azure-mcp-info-disclosure/","summary":"CVE-2026-32211 is a critical vulnerability in Azure MCP Server due to missing authentication for a critical function, allowing an unauthorized attacker to disclose information over the network.","title":"Azure MCP Server Missing Authentication Vulnerability (CVE-2026-32211)","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-mcp-info-disclosure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["azure","cloud","anomaly-detection"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies Azure Activity Logs activity originating from a city that is atypical for the specific event action being performed. The underlying mechanism is a machine learning job, \u003ccode\u003eazure_activitylogs_rare_event_action_for_a_city_ea\u003c/code\u003e, designed to surface anomalous geolocation patterns. The rule is triggered when the anomaly score exceeds 50. Such deviations can indicate compromised credentials used by an attacker operating from a different geography than the authorized user. This activity can be an early indicator of account abuse, potentially preceding broader impact such as data exfiltration or resource exploitation. The rule is designed to be used with Elastic Stack version 9.4.0 and later.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Compromise:\u003c/strong\u003e An attacker obtains valid Azure credentials (username/password or service principal keys) through phishing, credential stuffing, or other means.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker uses the compromised credentials to log in to the Azure environment from an unusual geographic location (city).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eActivity Log Generation:\u003c/strong\u003e The login and subsequent actions generate Azure Activity Logs entries.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Access/Modification:\u003c/strong\u003e The attacker performs actions such as adding privileged role assignments, creating virtual machines, modifying network configurations, or accessing Key Vault secrets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Potential):\u003c/strong\u003e The attacker may use the initially compromised account to discover and access other resources or accounts within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Resource Exploitation (Potential):\u003c/strong\u003e The attacker exfiltrates sensitive data or uses compromised resources for malicious purposes like cryptocurrency mining.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, modification of critical infrastructure, and deployment of malicious resources within the Azure environment. The impact can range from data breaches and financial losses to disruption of services. While the risk score of this detection is low, further investigation is required to determine the extent and nature of the malicious activity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the associated Machine Learning job (\u003ccode\u003eazure_activitylogs_rare_event_action_for_a_city_ea\u003c/code\u003e) and ensure that the Azure Activity Logs integration is properly configured to provide the necessary data.\u003c/li\u003e\n\u003cli\u003eReview the investigation guide within the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field to understand possible investigation steps, including validating user presence in the region and enriching the source IP.\u003c/li\u003e\n\u003cli\u003eImplement response and remediation steps outlined in the rule \u003ccode\u003enote\u003c/code\u003e field such as revoking active sessions, resetting passwords, and reverting changes executed from the unusual city.\u003c/li\u003e\n\u003cli\u003eConfigure Conditional Access policies with country allowlists and named egress IP ranges, as recommended in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field, to prevent logins from unexpected locations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T13:35:13Z","date_published":"2026-04-02T13:35:13Z","id":"/briefs/2026-06-unusual-azure-city/","summary":"A machine learning job detected Azure Activity Logs activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the event action, indicating potential compromised credentials.","title":"Unusual City for Azure Activity Logs Event","url":"https://feed.craftedsignal.io/briefs/2026-06-unusual-azure-city/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["azure","entra_id","federated_identity","persistence","privilege_escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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\u0026rsquo;s service principal. This technique provides persistent access to Azure resources with the application\u0026rsquo;s permissions, effectively bypassing traditional secret-based authentication. The detection logic focuses on the \u0026ldquo;Update application\u0026rdquo; event within Entra ID audit logs, specifically targeting changes to the \u0026ldquo;FederatedIdentityCredentials\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an Entra ID account with sufficient privileges to modify application registrations.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Entra ID portal or uses PowerShell/Azure CLI to locate a target application with federated identity credentials configured.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the \u0026ldquo;Issuer\u0026rdquo; URL of an existing Federated Identity Credential within the application registration. They replace the legitimate issuer URL with a URL controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker configures their own identity provider to issue tokens that match the application\u0026rsquo;s expected audience and subject claims.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious token from their identity provider, impersonating the legitimate service principal.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the crafted token to authenticate to Azure resources, bypassing normal authentication controls.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the application\u0026rsquo;s permissions to access sensitive data, modify configurations, or deploy malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the Azure environment by continuing to use the compromised federated identity configuration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable 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.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized modifications to federated identity credential issuers in Entra ID (\u003ccode\u003eEntra ID Federated Identity Credential Issuer Modified\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eazure.auditlogs.properties.initiated_by.user.userPrincipalName\u003c/code\u003e and \u003ccode\u003eipAddress\u003c/code\u003e logs to determine the source of detected changes, as recommended in the rule\u0026rsquo;s triage notes.\u003c/li\u003e\n\u003cli\u003eImplement conditional access policies and PIM (Privileged Identity Management) to protect application management operations within Entra ID, as suggested in the rule\u0026rsquo;s response and remediation guidance.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-18T21:22:55Z","date_published":"2026-03-18T21:22:55Z","id":"/briefs/2026-03-entra-id-federated-issuer-modified/","summary":"Modification of the issuer URL of a federated identity credential in Entra ID can allow an attacker to authenticate as the application's service principal, granting persistent access to Azure resources by pointing to an attacker-controlled identity provider and bypassing normal authentication.","title":"Entra ID Federated Identity Credential Issuer Modified","url":"https://feed.craftedsignal.io/briefs/2026-03-entra-id-federated-issuer-modified/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","azure-arc","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies a specific attack chain targeting Azure Arc-connected Kubernetes clusters. The attack begins with a service principal authenticating to Microsoft Entra ID and immediately requesting credentials for an Azure Arc-connected Kubernetes cluster. This \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action retrieves tokens enabling \u003ccode\u003ekubectl\u003c/code\u003e access via the Arc Cluster Connect proxy. This behavior is indicative of adversaries using stolen service principal secrets to gain unauthorized access and establish a proxy tunnel into Kubernetes environments. The rule prioritizes external service principal authentications (excluding managed identities) followed by Arc cluster credential access, particularly when sign-in origins are from unexpected locations or Autonomous System Numbers (ASNs). This activity was observed in attacks documented by IBM X-Force and Microsoft, as referenced below.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises or obtains valid credentials for an Azure Service Principal.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to Microsoft Entra ID using the compromised service principal credentials, generating a ServicePrincipalSignInLogs event in Azure.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to list cluster user credentials for a connected Kubernetes cluster using the compromised service principal. This generates an Azure Activity Log event: \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf successful, the \u003ccode\u003elistClusterUserCredential\u003c/code\u003e action provides the attacker with tokens to access the Kubernetes cluster through the Arc Cluster Connect proxy.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to interact with the Kubernetes cluster via \u003ccode\u003ekubectl\u003c/code\u003e proxied through Azure Arc.\u003c/li\u003e\n\u003cli\u003eThe attacker performs reconnaissance within the Kubernetes cluster to identify valuable targets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create, read, update, or delete (CRUD) sensitive Kubernetes resources, such as secrets or configmaps.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to escalate privileges within the cluster or pivot to other resources within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromise of service principal credentials and subsequent access to Azure Arc-connected Kubernetes clusters can lead to significant data breaches, service disruption, and unauthorized resource access. Successful exploitation allows attackers to gain control over Kubernetes clusters, potentially leading to lateral movement within the environment, exfiltration of sensitive data, and deployment of malicious workloads. The number of victims and specific sectors targeted vary based on the attacker\u0026rsquo;s objectives and the compromised environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect the described attack chain, tuning the \u003ccode\u003emaxspan\u003c/code\u003e value based on observed authentication patterns and network latency.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on unexpected sign-in locations or ASNs for the service principal (refer to the investigation fields in the rule definition).\u003c/li\u003e\n\u003cli\u003eImplement regular rotation of service principal credentials and enforce multi-factor authentication where possible (refer to Microsoft Entra ID documentation).\u003c/li\u003e\n\u003cli\u003eReview and restrict Azure role assignments for service principals on Arc-connected clusters to minimize potential impact from compromised credentials (refer to Azure RBAC documentation).\u003c/li\u003e\n\u003cli\u003eEnable logging for Azure sign-in logs and activity logs to ensure the data sources are available for the detection rule (refer to Azure Monitor documentation).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-17T15:06:47Z","date_published":"2026-03-17T15:06:47Z","id":"/briefs/2024-01-02-azure-arc-credential-access/","summary":"Detects a service principal authenticating to Microsoft Entra ID and then listing credentials for an Azure Arc-connected Kubernetes cluster within a short time window, indicating potential unauthorized access to Kubernetes clusters via stolen service principal secrets.","title":"Azure Service Principal Sign-In Followed by Arc Cluster Credential Access","url":"https://feed.craftedsignal.io/briefs/2024-01-02-azure-arc-credential-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","policy-modification","attack.privilege-escalation","attack.credential-access","attack.persistence","attack.defense-impairment","attack.t1548","attack.t1556"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eCompromised or malicious actors may attempt to modify Azure Conditional Access (CA) policies to weaken security controls, elevate privileges, or establish persistence within the Azure environment. Conditional Access policies are critical for enforcing organizational security standards, and unauthorized changes can have significant security implications. This activity is detected through Azure Audit Logs by monitoring for \u0026ldquo;Update conditional access policy\u0026rdquo; events. Defenders should investigate any modifications to Conditional Access policies to ensure they are legitimate and align with security best practices. Detecting and responding to unauthorized CA policy modifications is crucial for maintaining the integrity and security of the Azure environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access through compromised credentials or other means (not specified in source).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker leverages existing privileges or exploits vulnerabilities to gain sufficient permissions to modify Conditional Access policies (e.g., through a compromised Global Administrator account).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Enumeration:\u003c/strong\u003e The attacker enumerates existing Conditional Access policies to identify targets for modification using tools like Azure PowerShell or the Azure portal.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Modification:\u003c/strong\u003e The attacker modifies a Conditional Access policy, for example, by weakening MFA requirements, excluding specific users or groups from the policy, or disabling the policy altogether.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e By weakening or disabling Conditional Access policies, the attacker establishes a persistent foothold in the environment, allowing them to bypass security controls and maintain unauthorized access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e With weakened MFA or other access controls, the attacker gains easier access to sensitive credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefense Impairment:\u003c/strong\u003e The modification of CA policies impairs the organization\u0026rsquo;s defense mechanisms, making it easier for the attacker to perform malicious activities undetected.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of Conditional Access policies can lead to significant security breaches, including unauthorized access to sensitive data, privilege escalation, and persistent compromise of the Azure environment. The number of affected users and resources depends on the scope of the modified policies. Organizations may experience data loss, financial losses, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;CA Policy Updated by Non Approved Actor\u0026rdquo; Sigma rule to your SIEM to detect unauthorized modifications to Conditional Access policies within your Azure environment.\u003c/li\u003e\n\u003cli\u003eReview the \u003ccode\u003eproperties.message\u003c/code\u003e field in the Azure Audit Logs for \u0026ldquo;Update conditional access policy\u0026rdquo; events and compare \u0026ldquo;old\u0026rdquo; vs \u0026ldquo;new\u0026rdquo; values to understand the nature of the changes.\u003c/li\u003e\n\u003cli\u003eImplement strict role-based access control (RBAC) to limit the number of users who can modify Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule and verify whether the user identity, user agent, and/or hostname should be making changes in your environment.\u003c/li\u003e\n\u003cli\u003eEnable multi-factor authentication (MFA) for all users, especially those with administrative privileges, to reduce the risk of credential compromise (related to attack.credential-access tag).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-29T12:00:00Z","date_published":"2024-05-29T12:00:00Z","id":"/briefs/2024-05-29-azure-ca-policy-update/","summary":"An unauthorized actor modifies an Azure Conditional Access policy, potentially leading to privilege escalation, credential access, persistence, or defense impairment.","title":"Unauthorized Modification of Azure Conditional Access Policy","url":"https://feed.craftedsignal.io/briefs/2024-05-29-azure-ca-policy-update/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","certificate-based-authentication","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eCertificate-Based Authentication (CBA) in Azure Active Directory allows users and services to authenticate using digital certificates instead of passwords. While intended to enhance security, misconfiguration or malicious use of CBA can lead to significant security risks. Attackers can exploit CBA to gain unauthorized access, establish persistent footholds, and escalate privileges within the Azure environment. This involves manipulating authentication policies to favor or require certificate authentication, potentially bypassing other security controls. Detection of CBA enablement is crucial as it can be a precursor to more sophisticated attacks targeting cloud resources.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure AD account with sufficient privileges to modify authentication policies (e.g., Global Administrator).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the Azure AD authentication methods policy to enable certificate-based authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker registers a certificate authority (CA) in Azure AD, which will be used to issue certificates for authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts or compromises a certificate that is trusted by the registered CA.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the crafted certificate to authenticate to Azure AD, bypassing traditional password-based authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly gained access to provision new resources, modify existing configurations, or access sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating service principals or applications that authenticate using certificates, allowing them to maintain access even if the initial account is compromised.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CBA can lead to full compromise of an Azure AD tenant. Attackers can gain access to sensitive data, disrupt services, and deploy malicious applications. The lack of multi-factor authentication on certificate-based logins significantly increases the risk of unauthorized access. The impact can range from data breaches and financial losses to complete operational shutdown, depending on the scope of the compromised resources.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule to detect when certificate-based authentication is enabled in Azure AD (\u003ccode\u003eAuthentication Methods Policy Update\u003c/code\u003e in Audit Logs).\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for modifications to authentication methods policies, paying close attention to changes related to certificate-based authentication.\u003c/li\u003e\n\u003cli\u003eImplement strong certificate management practices, including proper key storage, certificate revocation, and monitoring of certificate usage.\u003c/li\u003e\n\u003cli\u003eInvestigate any unexpected changes to Azure AD authentication policies or the registration of new certificate authorities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-04-29T14:30:00Z","date_published":"2024-04-29T14:30:00Z","id":"/briefs/2024-04-azure-ad-cba-enabled/","summary":"Enabling certificate-based authentication (CBA) in Azure Active Directory can be abused by attackers to establish persistence, escalate privileges, and impair defenses.","title":"Azure AD Certificate-Based Authentication Enabled","url":"https://feed.craftedsignal.io/briefs/2024-04-azure-ad-cba-enabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","identity-protection","suspicious-browser"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe \u0026ldquo;suspiciousBrowser\u0026rdquo; risk event in Azure Identity Protection signals unusual sign-in patterns indicative of potential account compromise or other malicious activity. This alert is triggered when the same browser is used to access multiple tenants from different countries, which is an atypical behavior for legitimate users. This type of activity could be caused by malware, credential theft, or an attacker attempting to blend in with normal user behavior after gaining unauthorized access. This detection is important for defenders because it can highlight early stages of an attack, potentially preventing lateral movement, data exfiltration, or other damaging actions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a user\u0026rsquo;s credentials through phishing, malware, or other means (T1566, T1190).\u003c/li\u003e\n\u003cli\u003eThe attacker configures a browser with the stolen credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the same browser to attempt sign-ins to multiple Azure tenants from different geographical locations, attempting to blend in with typical user activity.\u003c/li\u003e\n\u003cli\u003eAzure Identity Protection detects the \u0026ldquo;suspiciousBrowser\u0026rdquo; risk event based on the anomalous sign-in activity.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker may gain access to sensitive data and resources within the targeted tenants.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised accounts to escalate privileges and move laterally within the organization (T1078, T1068).\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or deploy ransomware (T1003, T1486).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack exploiting suspicious browser activity can lead to unauthorized access to multiple Azure tenants, potentially impacting numerous organizations. The compromise of user accounts can result in data breaches, financial losses, and reputational damage. The scope of the impact depends on the level of access granted to the compromised accounts and the sensitivity of the data stored within the targeted tenants.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect \u0026ldquo;suspiciousBrowser\u0026rdquo; risk events in your Azure environment and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate sessions flagged by this detection in the context of other sign-ins from the same user to identify false positives.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) to mitigate the impact of compromised credentials.\u003c/li\u003e\n\u003cli\u003eMonitor user sign-in activity for unusual patterns, such as sign-ins from multiple geographical locations within a short period.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-31T12:00:00Z","date_published":"2024-01-31T12:00:00Z","id":"/briefs/2024-01-31-suspicious-azure-browser/","summary":"A suspicious browser activity alert indicates anomalous behavior based on suspicious sign-in activity across multiple tenants from different countries in the same browser, potentially indicating compromised credentials or other malicious activity.","title":"Azure Identity Protection Suspicious Browser Activity","url":"https://feed.craftedsignal.io/briefs/2024-01-31-suspicious-azure-browser/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Firewall"],"_cs_severities":["medium"],"_cs_tags":["azure","firewall","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe modification or deletion of Azure Firewall rule collections (Application, NAT, and Network) can indicate malicious activity within an Azure environment. Threat actors may target these rules to bypass security controls, allowing unauthorized network traffic, enabling data exfiltration, or facilitating lateral movement. Monitoring these changes is crucial for maintaining the integrity of network security policies and detecting potential breaches. This activity directly impacts an organization\u0026rsquo;s ability to enforce its security posture, potentially exposing sensitive resources to unauthorized access.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure environment, potentially through compromised credentials or a vulnerability in an application.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Azure Firewall resources to identify rule collections (Application, NAT, and Network) that can be modified or deleted.\u003c/li\u003e\n\u003cli\u003eThe attacker uses valid Azure credentials or exploits a misconfiguration to authenticate to the Azure Resource Manager API.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious request to modify the target rule collection, potentially altering allowed ports, IP addresses, or protocols.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker crafts a request to delete an entire rule collection, effectively disabling its associated security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the request to the Azure Resource Manager API, executing the change to the firewall configuration.\u003c/li\u003e\n\u003cli\u003eThe modified or deleted rule collection now allows unauthorized traffic to bypass the firewall, potentially enabling lateral movement or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the newly opened network paths to achieve their final objective, such as deploying ransomware or accessing sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification or deletion of Azure Firewall rule collections can have significant consequences. Unauthorized traffic could bypass security controls, enabling data exfiltration, lateral movement, or the deployment of malware. This could lead to data breaches, service disruptions, and financial losses. The impact depends on the scope of the modified or deleted rule collection and the resources it protects.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Firewall Rule Collection Modified or Deleted\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized changes to firewall configurations.\u003c/li\u003e\n\u003cli\u003eReview Azure Activity Logs for any events matching the \u003ccode\u003eoperationName\u003c/code\u003e values specified in the Sigma rule to identify suspicious activity.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts, especially those with permissions to manage firewall resources, to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly audit Azure role-based access control (RBAC) assignments to ensure the principle of least privilege is followed and that only authorized users have permissions to modify firewall configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-31T12:00:00Z","date_published":"2024-01-31T12:00:00Z","id":"/briefs/2024-01-azure-firewall-rule-collection-modification/","summary":"An attacker may modify or delete Azure Firewall rule collections (Application, NAT, and Network) to impair defenses and potentially enable malicious traffic.","title":"Azure Firewall Rule Collection Modification or Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-firewall-rule-collection-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","identity_protection","sign-in","account_compromise","risk_detection"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies Azure Active Directory sign-ins that exhibit properties unfamiliar to the user, such as new locations, devices, or browsers. This activity can indicate account compromise, lateral movement, or other malicious behavior. The detection leverages Azure Identity Protection\u0026rsquo;s risk detection capabilities, specifically the \u0026lsquo;unfamiliarFeatures\u0026rsquo; event. While a user legitimately changing devices or locations can trigger this, repeated or high-risk instances should be investigated. The alert is generated by Azure\u0026rsquo;s risk detection service, which analyzes sign-in patterns and flags anomalous events based on historical data.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a user\u0026rsquo;s credentials through phishing, credential stuffing, or other means (T1566, T1110).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to sign in to Azure AD using the compromised credentials (T1078).\u003c/li\u003e\n\u003cli\u003eThe sign-in originates from a location, device, or network that is not typical for the user (T1078).\u003c/li\u003e\n\u003cli\u003eAzure Identity Protection detects the unfamiliar sign-in properties and generates a \u0026lsquo;unfamiliarFeatures\u0026rsquo; risk event.\u003c/li\u003e\n\u003cli\u003eThe security operations team receives an alert based on the Sigma rule, indicating a potentially compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to access sensitive resources or data within the Azure environment (T1078).\u003c/li\u003e\n\u003cli\u003eThe attacker could attempt to escalate privileges within the environment to gain broader access (T1068).\u003c/li\u003e\n\u003cli\u003eThe attacker may establish persistence within the environment to maintain access even if the initial compromise is detected (T1098).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to unauthorized access to sensitive data, privilege escalation, and persistent access to the Azure environment. This can result in data breaches, financial loss, and reputational damage. The number of affected users and the severity of the impact will depend on the scope of the attacker\u0026rsquo;s access and the sensitivity of the data they are able to access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Unfamiliar Sign-In Properties\u0026rdquo; to your SIEM and tune for your environment to detect potentially compromised accounts.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts for the \u0026ldquo;Unfamiliar Sign-In Properties\u0026rdquo; Sigma rule by reviewing the user\u0026rsquo;s sign-in history and recent activity logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) to mitigate the risk of credential compromise (T1110).\u003c/li\u003e\n\u003cli\u003eEducate users about phishing and other social engineering tactics to prevent credential theft (T1566).\u003c/li\u003e\n\u003cli\u003eReview and enforce conditional access policies to restrict access based on location, device, and other factors.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-30-azure-unfamiliar-signin/","summary":"This alert detects Azure AD sign-ins with properties unfamiliar to the user, indicating potential account compromise or unauthorized access.","title":"Azure AD Sign-In with Unfamiliar Properties","url":"https://feed.craftedsignal.io/briefs/2024-01-30-azure-unfamiliar-signin/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","device-registration","policy-change"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe device registration policy in Azure Active Directory controls which devices can be registered or joined to the Azure AD tenant. Modification of this policy can weaken security controls, allowing unauthorized devices to access corporate resources. This activity is often associated with threat actors attempting to escalate privileges or impair existing defenses. This brief focuses on detecting changes to the Azure AD device registration policies using Azure Audit Logs, providing detection engineers with the ability to monitor and alert on potentially malicious modifications to this critical security control.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker compromises an account with sufficient privileges to modify Azure AD policies, such as a Global Administrator or Privileged Role Administrator.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure PowerShell/CLI to interact with Azure AD.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the device registration policy, potentially allowing non-compliant devices to register or join the domain. This may involve changing settings related to multi-factor authentication, device compliance, or allowed operating systems.\u003c/li\u003e\n\u003cli\u003eThe Azure AD Audit Logs record an event with ActivityDisplayName equal to \u0026lsquo;Set device registration policies\u0026rsquo; under the \u0026lsquo;Policy\u0026rsquo; Category.\u003c/li\u003e\n\u003cli\u003eThe attacker registers a rogue device that does not meet the organization\u0026rsquo;s security standards.\u003c/li\u003e\n\u003cli\u003eThe rogue device gains access to sensitive corporate resources, bypassing intended security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the rogue device to perform further malicious activities, such as data exfiltration or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the device registration policy can lead to unauthorized devices accessing sensitive corporate resources, bypassing multi-factor authentication or device compliance requirements. This can result in data breaches, privilege escalation, and further compromise of the Azure AD environment. The impact can be severe if the attacker leverages the policy change to register multiple rogue devices, creating a persistent backdoor into the organization\u0026rsquo;s resources.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Changes to Device Registration Policy\u0026rdquo; to your SIEM and tune for your environment to detect unauthorized modifications to device registration policies (rule).\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs for any unexpected \u0026ldquo;Set device registration policies\u0026rdquo; events (logsource).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all administrative accounts to prevent unauthorized policy changes (TTP).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-device-registration-policy-change/","summary":"Monitoring changes to the device registration policy can detect potential privilege escalation or defense impairment attempts by malicious actors aiming to weaken security controls related to device management in Azure Active Directory.","title":"Azure AD Device Registration Policy Changes Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-device-registration-policy-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory","AD FS"],"_cs_severities":["medium"],"_cs_tags":["cloud","azure","adfs","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat involves the creation of a rogue AD FS service instance within the Azure AD Hybrid Health Service to spoof AD FS signing logs. The attacker leverages the Azure AD Hybrid Health Service to create a new AD FS service and adds a fake server instance. This method allows the attacker to manipulate AD FS logging information without needing to compromise an on-premises AD FS server. The attack can be performed programmatically through HTTP requests to Azure, making it scalable and difficult to trace back to traditional on-premises attack vectors. This technique is particularly concerning because it undermines the integrity of AD FS logs, a crucial component for security monitoring and incident response.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCompromise Azure Account:\u003c/strong\u003e The attacker gains access to an Azure account, potentially through stolen credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProvision Rogue AD Health Service:\u003c/strong\u003e The attacker programmatically provisions a new AD Health Service within the compromised Azure environment, specifically targeting AD FS.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCreate Fake Server Instance:\u003c/strong\u003e Within the newly created AD Health Service, the attacker creates a fake server instance, mimicking a legitimate AD FS server. The \u003ccode\u003eResourceId\u003c/code\u003e will contain \u003ccode\u003eAdFederationService\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eManipulate Logs:\u003c/strong\u003e Using the fake server instance, the attacker injects or alters AD FS signing logs, creating a false narrative of user authentication events.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpersonate Users/Bypass Authentication:\u003c/strong\u003e The attacker uses the manipulated logs to impersonate legitimate users or bypass authentication controls in applications relying on AD FS.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement/Privilege Escalation:\u003c/strong\u003e Using the falsely acquired credentials or authentication tokens, the attacker moves laterally within the network, escalating privileges to access sensitive resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/System Compromise:\u003c/strong\u003e The attacker exfiltrates sensitive data or gains control over critical systems using the compromised accounts and manipulated logs.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to spoof AD FS signing logs, potentially leading to unauthorized access, data breaches, and system compromise. The compromised logs can be used to cover the attacker\u0026rsquo;s tracks, making detection and incident response more difficult. Organizations relying on Azure AD Hybrid Health for AD FS monitoring are at risk of having their security posture undermined. The number of potential victims is substantial, as many organizations use AD FS for authentication and rely on its logs for security monitoring.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAzure Active Directory Hybrid Health AD FS New Server\u003c/code\u003e to your SIEM to detect the creation of new AD FS server instances within the Azure AD Hybrid Health Service. Tune the rule for your environment to minimize false positives.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for any unusual activity related to the \u003ccode\u003eMicrosoft.ADHybridHealthService\u003c/code\u003e resource provider and the \u003ccode\u003eMicrosoft.ADHybridHealthService/services/servicemembers/action\u003c/code\u003e operation, specifically the \u003ccode\u003eAdministrative\u003c/code\u003e category.\u003c/li\u003e\n\u003cli\u003eReview and validate all AD FS server instances registered within the Azure AD Hybrid Health Service to ensure their legitimacy.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to prevent unauthorized access and mitigate the risk of initial compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-azuread-adfs-spoofing/","summary":"A threat actor can create a new, rogue AD Health ADFS service within Azure and then create a fake server instance, which can be leveraged to spoof AD FS signing logs without compromising on-prem AD FS servers.","title":"Spoofing AD FS Signing Logs via Azure AD Hybrid Health Service","url":"https://feed.craftedsignal.io/briefs/2024-01-23-azuread-adfs-spoofing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers often target cloud environments to establish persistence and maintain unauthorized access. One technique involves adding their own authentication methods to compromised user accounts. By registering a new security info, such as a phone number or email address, an attacker can bypass multi-factor authentication and regain access even if the original credentials are changed. This activity is typically logged within Azure Audit Logs, specifically under the \u0026lsquo;Authentication Methods\u0026rsquo; service and \u0026lsquo;UserManagement\u0026rsquo; category. Detecting these changes is crucial for identifying potentially compromised accounts and preventing further damage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access to the Azure environment is gained, potentially through credential phishing or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target user account with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker accesses the Azure Active Directory (Azure AD) settings for the compromised user.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the \u0026ldquo;Security info\u0026rdquo; section of the user\u0026rsquo;s profile.\u003c/li\u003e\n\u003cli\u003eThe attacker registers a new authentication method, such as a phone number or email address, controlled by the attacker. This action generates an audit log event with OperationName \u0026ldquo;User registered security info\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker can now use the newly added authentication method to bypass multi-factor authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to access sensitive data, applications, or resources within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the Azure environment, even if the original account password is changed.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful addition of rogue authentication methods allows attackers to maintain persistent access to compromised accounts within Azure environments. This can lead to data breaches, unauthorized access to sensitive applications, privilege escalation, and lateral movement within the cloud infrastructure. The impact can range from data exfiltration to complete control over the targeted Azure resources.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect changes to authentication methods within Azure audit logs (logsource: azure, service: auditlogs).\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where the \u003ccode\u003eOperationName\u003c/code\u003e is \u003ccode\u003eUser registered security info\u003c/code\u003e in the Azure Audit Logs, as this indicates a change in authentication method.\u003c/li\u003e\n\u003cli\u003eReview the referenced Microsoft documentation on privileged account security to understand best practices for securing administrative accounts (references).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-23-azure-auth-method-change/","summary":"An attacker may add an authentication method to a compromised Azure account for persistent access, which can be detected by monitoring changes to authentication methods in Azure audit logs.","title":"Azure Authentication Method Change Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-23-azure-auth-method-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","privileged-identity-management","invalid-license"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies scenarios where an organization lacks the necessary Microsoft Entra Premium P2 or Microsoft Entra ID Governance licenses required for proper Privileged Identity Management (PIM) functionality. Attackers may attempt to exploit misconfigured or unlicensed PIM deployments to gain unauthorized privileged access to critical Azure resources. This detection is crucial as it indicates a compliance issue that can be leveraged to escalate privileges, bypass security controls, and potentially lead to data breaches or system compromise. The absence of appropriate licensing hinders the effectiveness of PIM controls, creating opportunities for malicious actors to operate undetected. Defenders need to ensure appropriate licenses are in place.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an Azure environment lacking a valid Microsoft Entra Premium P2 or Microsoft Entra ID Governance license for Privileged Identity Management (PIM).\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to activate a privileged role within the Azure environment through PIM.\u003c/li\u003e\n\u003cli\u003eDue to the invalid license, the PIM activation process may not enforce proper multi-factor authentication (MFA) or approval workflows.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to the privileged role without proper authorization or auditing.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised privileged role to access sensitive Azure resources, such as virtual machines, databases, or storage accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions, such as data exfiltration, modification of system configurations, or deployment of malware.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to establish persistence within the Azure environment by creating rogue user accounts or modifying existing access controls.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe impact of an invalid PIM license can be severe. Organizations may experience unauthorized access to critical Azure resources, leading to data breaches, system compromise, and compliance violations. The absence of proper PIM controls can enable attackers to escalate privileges, bypass security measures, and operate undetected within the Azure environment. Identifying invalid PIM licenses is crucial for maintaining the security and integrity of Azure deployments.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003einvalidLicenseAlertIncident\u003c/code\u003e events in Azure PIM logs (logsource: azure, service: pim).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of \u003ccode\u003einvalidLicenseAlertIncident\u003c/code\u003e to determine the scope of the issue and potential unauthorized access.\u003c/li\u003e\n\u003cli\u003eVerify that all Azure subscriptions utilizing PIM have valid Microsoft Entra Premium P2 or Microsoft Entra ID Governance licenses.\u003c/li\u003e\n\u003cli\u003eImplement automated monitoring to proactively identify and alert on invalid PIM licenses.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-22T12:00:00Z","date_published":"2024-01-22T12:00:00Z","id":"/briefs/2024-01-invalid-pim-license/","summary":"Detection of unauthorized access or privilege escalation attempts within Azure environments due to invalid or missing Microsoft Entra Premium P2 or Microsoft Entra ID Governance licenses for Privileged Identity Management (PIM).","title":"Azure Privileged Identity Management (PIM) Invalid License Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-invalid-pim-license/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Kubernetes Service"],"_cs_severities":["medium"],"_cs_tags":["azure","kubernetes","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers targeting Azure Kubernetes Service (AKS) environments may attempt to remove event logs to cover their tracks and hinder forensic investigations. This activity, which involves deleting Kubernetes events, directly impairs a defender\u0026rsquo;s ability to detect malicious behavior within the cluster. By removing evidence of their actions, attackers can prolong their presence within the environment and increase the potential for further compromise. This technique is relevant for defenders monitoring AKS environments for intrusion activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure environment, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure Kubernetes Service (AKS) cluster with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Kubernetes event logs to identify those they wish to remove.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a command to delete specific Kubernetes events using kubectl or the Azure CLI. The API call used for the deletion is MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record the event deletion, which is the source of the detection.\u003c/li\u003e\n\u003cli\u003eThe attacker repeats steps 3-4 to remove additional event logs, further obscuring their activities.\u003c/li\u003e\n\u003cli\u003eThe attacker continues with their primary objective, such as deploying malicious containers, exfiltrating data, or establishing persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful deletion of Kubernetes events can significantly hinder incident response efforts. Without access to event logs, defenders may struggle to identify the scope and timeline of an attack, potentially leading to incomplete remediation and prolonged exposure. The impact includes increased dwell time for attackers within the compromised environment, as well as a greater likelihood of successful data breaches or system disruptions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect event deletion activity within AKS environments.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of the MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE operation in Azure Activity Logs, as indicated in the rule definition.\u003c/li\u003e\n\u003cli\u003eImplement robust RBAC policies within AKS to minimize the number of users and service accounts with permissions to delete Kubernetes events.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:30:00Z","date_published":"2024-01-09T18:30:00Z","id":"/briefs/2024-01-azure-kubernetes-events-deleted/","summary":"Adversaries may delete events in Azure Kubernetes to evade detection, which this rule detects via the MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE operation.","title":"Azure Kubernetes Events Deleted","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-events-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","privilege-escalation","credential-access","persistence","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe unauthorized removal of a Conditional Access (CA) policy in Azure Active Directory can significantly weaken an organization\u0026rsquo;s security posture. Conditional Access policies are critical for enforcing multi-factor authentication, device compliance, and other security controls based on user, location, device, and application conditions. When a non-approved actor removes such a policy, it can open the door for privilege escalation, credential access, and persistence by malicious actors. This activity is often performed after an initial compromise to disable security controls and move laterally within the environment. Identifying and responding to such removals promptly is essential to maintain a strong security posture.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: The attacker gains initial access to an account with sufficient privileges to view and modify Azure Active Directory settings. This could be through phishing, password spraying, or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker escalates privileges within Azure AD to gain the necessary permissions to manage Conditional Access policies. This might involve adding themselves to a privileged role or exploiting misconfigurations in existing roles.\u003c/li\u003e\n\u003cli\u003eDiscovery: The attacker enumerates existing Conditional Access policies to identify targets for removal. They may focus on policies that enforce MFA or restrict access based on location.\u003c/li\u003e\n\u003cli\u003eDefense Evasion: The attacker disables or modifies logging configurations to reduce the likelihood of detection.\u003c/li\u003e\n\u003cli\u003ePolicy Removal: The attacker removes the targeted Conditional Access policy using the Azure portal, PowerShell, or the Azure CLI. The audit logs will record a \u0026ldquo;Delete conditional access policy\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eCredential Access: With the CA policy removed, the attacker may attempt to access sensitive resources or applications without MFA, potentially gaining access to credentials or sensitive data.\u003c/li\u003e\n\u003cli\u003ePersistence: The attacker establishes persistence by creating new user accounts or modifying existing ones to maintain access even if their initial entry point is discovered.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker leverages the compromised credentials and weakened security controls to move laterally to other systems and resources within the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful removal of a Conditional Access policy can lead to widespread compromise. Attackers can bypass multi-factor authentication, gain unauthorized access to sensitive data, and escalate privileges within the organization. The impact can range from data breaches and financial losses to reputational damage and compliance violations. Depending on the scope of the compromised policy, the number of affected users could range from dozens to thousands.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect the \u0026ldquo;Delete conditional access policy\u0026rdquo; event in Azure audit logs, indicating a CA policy removal.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure Active Directory role assignments to minimize the risk of unauthorized privilege escalation.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication for all user accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for unusual activity, such as changes to user accounts, role assignments, and Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of CA policy removal to determine the scope of the compromise and take appropriate remediation steps.\u003c/li\u003e\n\u003cli\u003eReview and harden Conditional Access policies to ensure they are effectively protecting critical resources and applications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T15:00:00Z","date_published":"2024-01-09T15:00:00Z","id":"/briefs/2024-01-09-azure-ca-policy-removal/","summary":"An unauthorized actor removes a Conditional Access policy in Azure, potentially weakening the organization's security posture and enabling privilege escalation or credential access.","title":"Unauthorized Removal of Azure Conditional Access Policy","url":"https://feed.craftedsignal.io/briefs/2024-01-09-azure-ca-policy-removal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Privileged Identity Management"],"_cs_severities":["high"],"_cs_tags":["azure","pim","stale_account"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe \u0026ldquo;staleSignInAlertIncident\u0026rdquo; event in Azure Privileged Identity Management (PIM) signifies that an account assigned a privileged role has not signed in for a prolonged period. This alert is crucial for defenders because inactive privileged accounts can become attractive targets for attackers. If an account is compromised and not actively used, the breach can go unnoticed for an extended time, increasing the attacker\u0026rsquo;s dwell time and potential for lateral movement or data exfiltration. Monitoring for this event allows organizations to identify potentially compromised accounts and enforce stricter security measures like password resets, MFA enforcement, or temporary role revocation. The alert helps maintain a secure privileged access environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies an organization using Azure PIM.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises a user account that is assigned a privileged role, but is currently inactive, using techniques such as password spraying or phishing.\u003c/li\u003e\n\u003cli\u003eDue to the account\u0026rsquo;s inactivity, the compromise remains unnoticed by the legitimate owner or security monitoring tools.\u003c/li\u003e\n\u003cli\u003eThe attacker activates the privileged role assignment in Azure PIM, granting them elevated permissions within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to perform reconnaissance, identify valuable assets, and potentially create new administrative accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the Azure environment, accessing sensitive data and resources that are normally restricted.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data or deploys malicious code to disrupt services.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by creating backdoors or modifying access controls to ensure continued access even after the initial compromise is detected.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised stale accounts in Azure PIM can lead to significant data breaches, service disruptions, and reputational damage. Attackers can leverage the elevated privileges associated with these accounts to gain unauthorized access to critical resources, exfiltrate sensitive data, or deploy ransomware. The impact can range from data loss to complete system compromise, depending on the scope of the privileged roles assigned to the stale account. The financial implications can be substantial, including regulatory fines, incident response costs, and lost revenue.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule to detect \u003ccode\u003estaleSignInAlertIncident\u003c/code\u003e events in your Azure PIM logs, enabling rapid identification of potentially compromised stale accounts.\u003c/li\u003e\n\u003cli\u003eInvestigate any triggered alerts to determine the legitimacy of the account\u0026rsquo;s inactivity and potential compromise scenarios.\u003c/li\u003e\n\u003cli\u003eImplement automated workflows to disable or remove privileged role assignments for accounts that trigger the \u003ccode\u003estaleSignInAlertIncident\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eReview and enforce strong password policies and multi-factor authentication (MFA) for all accounts with privileged roles in Azure PIM.\u003c/li\u003e\n\u003cli\u003eImplement regular access reviews to identify and remove unnecessary privileged role assignments, minimizing the attack surface.\u003c/li\u003e\n\u003cli\u003eConsult Microsoft\u0026rsquo;s documentation on configuring security alerts for potential stale accounts in privileged roles to understand the context and recommended actions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:42:00Z","date_published":"2024-01-03T18:42:00Z","id":"/briefs/2024-01-azure-pim-stale-account/","summary":"Detection of stale accounts in Azure Privileged Identity Management (PIM) through the 'staleSignInAlertIncident' event, indicating potential compromised or unused privileged accounts.","title":"Azure PIM Account Stale Sign-in Alert","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-stale-account/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","firewall","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies potentially malicious modifications or deletions of Azure firewalls. Azure firewalls are critical components for network security, controlling inbound and outbound traffic based on defined rules. An attacker who gains sufficient privileges within an Azure environment may attempt to disable or modify these firewalls to facilitate lateral movement, data exfiltration, or other malicious activities. This activity is particularly concerning as it represents a direct attempt to weaken the victim\u0026rsquo;s security posture. The activity is detected via Azure Activity Logs. While legitimate administrative actions can trigger this alert, any unexpected or unauthorized changes to firewall configurations should be investigated promptly.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to an Azure environment, possibly through compromised credentials or exploiting a vulnerability in an application.\u003c/li\u003e\n\u003cli\u003eAttacker escalates privileges within the Azure subscription to gain permissions to manage network resources, including firewalls.\u003c/li\u003e\n\u003cli\u003eAttacker identifies the Azure firewalls in the target environment using Azure Resource Manager APIs or the Azure portal.\u003c/li\u003e\n\u003cli\u003eAttacker modifies firewall rules to allow unauthorized traffic, such as opening ports for command and control communication or disabling security rules. This is achieved via the \u003ccode\u003eMICROSOFT.NETWORK/AZUREFIREWALLS/WRITE\u003c/code\u003e operation.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker deletes the Azure firewall using the \u003ccode\u003eMICROSOFT.NETWORK/AZUREFIREWALLS/DELETE\u003c/code\u003e operation, effectively removing network protections.\u003c/li\u003e\n\u003cli\u003eAttacker validates that their changes have been successfully applied by testing network connectivity or by reviewing the firewall configuration.\u003c/li\u003e\n\u003cli\u003eAttacker performs malicious activities such as lateral movement, data exfiltration, or deploying additional resources without firewall restrictions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification or deletion of Azure firewalls can have severe consequences. An attacker can bypass network security controls, leading to data breaches, unauthorized access to sensitive resources, and the potential for widespread disruption. This can result in financial losses, reputational damage, and regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized firewall modifications or deletions in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on unfamiliar user identities and user agents.\u003c/li\u003e\n\u003cli\u003eReview Azure RBAC roles and permissions to ensure the principle of least privilege is enforced, limiting the ability of users and service principals to modify or delete firewalls.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for other suspicious activities, such as unusual resource deployments or changes to security settings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:30:00Z","date_published":"2024-01-03T18:30:00Z","id":"/briefs/2024-01-azure-firewall-modified-or-deleted/","summary":"An Azure firewall was created, modified, or deleted, potentially indicating malicious activity aimed at impairing network defenses.","title":"Azure Firewall Modification or Deletion Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-firewall-modified-or-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","bitlocker","key-retrieval","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers with access to Azure Active Directory, either through compromised credentials or an insider threat, can retrieve BitLocker recovery keys stored within the Azure environment. This allows them to decrypt volumes protected with BitLocker encryption. While retrieving BitLocker keys is a legitimate administrative function, anomalous or unauthorized access can indicate malicious activity. Attackers may leverage this to gain unauthorized access to encrypted data, escalate privileges, or move laterally within the compromised environment. Defenders need to monitor BitLocker key retrieval events for unusual patterns or unauthorized access attempts to detect and prevent potential data breaches or other malicious activities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains unauthorized access to an Azure Active Directory account with sufficient privileges, possibly via credential phishing or password spraying (T1078.004).\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation (if needed): The attacker escalates privileges within Azure AD if the initially compromised account lacks the necessary permissions to read BitLocker keys.\u003c/li\u003e\n\u003cli\u003eDiscovery: The attacker uses Azure AD tools or PowerShell cmdlets to identify devices with BitLocker encryption enabled.\u003c/li\u003e\n\u003cli\u003eKey Retrieval: The attacker uses the Azure portal or PowerShell to retrieve the BitLocker recovery key for a specific device. This generates an audit log event.\u003c/li\u003e\n\u003cli\u003eOffline Access: The attacker uses the retrieved BitLocker recovery key to unlock the encrypted drive on a compromised system or a copied disk image.\u003c/li\u003e\n\u003cli\u003eData Exfiltration or Lateral Movement: With the drive unlocked, the attacker can access sensitive data, install malware, or use the system for lateral movement within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful BitLocker key retrieval can lead to unauthorized access to sensitive data stored on encrypted drives. This could result in data breaches, financial loss, reputational damage, and legal liabilities. The impact depends on the sensitivity and volume of data stored on the encrypted volumes, as well as the attacker\u0026rsquo;s subsequent actions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect BitLocker key retrieval events in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eReview Azure AD access logs for suspicious activity related to user accounts that have permissions to read BitLocker keys (reference: Sigma rule).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges in Azure AD, to prevent unauthorized access (T1078.004).\u003c/li\u003e\n\u003cli\u003eImplement Conditional Access policies to restrict access to sensitive Azure resources, including BitLocker recovery keys, based on factors such as location, device, and user risk.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit Azure AD roles and permissions to ensure that users only have the necessary privileges to perform their job functions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:29:00Z","date_published":"2024-01-03T18:29:00Z","id":"/briefs/2024-01-bitlocker-key-retrieval/","summary":"An adversary with sufficient privileges in Azure Active Directory may attempt to retrieve BitLocker keys to decrypt drives for lateral movement or data exfiltration.","title":"Azure AD Bitlocker Key Retrieval","url":"https://feed.craftedsignal.io/briefs/2024-01-bitlocker-key-retrieval/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe compromise of privileged accounts within cloud environments is a significant risk. Azure Privileged Identity Management (PIM) is designed to mitigate this risk by enforcing time-bound and approval-based role activation. This brief focuses on the detection of PIM elevation requests that are either approved or denied. While legitimate administrator actions will trigger these events, unexpected or unauthorized approvals/denials, especially those occurring outside of normal business hours or originating from unusual locations, warrant immediate investigation. This activity can indicate attempts at unauthorized privilege escalation, lateral movement, or data exfiltration within the Azure environment. Monitoring these events provides an opportunity to identify and respond to potential breaches before significant damage can occur.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a low-privileged Azure account, possibly through credential phishing or password reuse.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to activate a privileged role (e.g., Global Administrator, Security Administrator) through Azure PIM.\u003c/li\u003e\n\u003cli\u003eThe PIM request triggers an approval workflow, requiring authorization from designated approvers.\u003c/li\u003e\n\u003cli\u003eAn attacker compromises an approver account, enabling them to approve their own malicious PIM request or deny a legitimate one.\u003c/li\u003e\n\u003cli\u003eAlternatively, an unwitting approver approves a malicious request, potentially due to social engineering.\u003c/li\u003e\n\u003cli\u003eUpon approval, the attacker\u0026rsquo;s account is temporarily elevated to the requested privileged role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to perform malicious actions, such as creating new accounts, modifying security policies, or accessing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to maintain persistence by creating backdoor accounts or modifying access controls, potentially circumventing PIM restrictions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to full control over the Azure environment, potentially impacting hundreds or thousands of users and services. A compromised Global Administrator role grants the attacker the ability to access and modify all resources within the Azure tenant, leading to data breaches, service disruptions, and financial losses. The targeted sectors include any organization leveraging Azure PIM for privileged access management.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAzure PIM Elevation Approved or Denied\u003c/code\u003e to your SIEM to detect unusual PIM activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any PIM approval or denial events occurring outside of normal business hours or originating from unexpected locations, focusing on the \u003ccode\u003eproperties.message\u003c/code\u003e field in the logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts, especially those with approval permissions for PIM requests.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit PIM role assignments and approval workflows to ensure they align with the principle of least privilege.\u003c/li\u003e\n\u003cli\u003eEnable alerting on changes to PIM policies and configurations to detect any unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for suspicious activity following PIM role activation, looking for actions associated with common attack techniques (e.g., account creation, policy modification).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:27:00Z","date_published":"2024-01-03T18:27:00Z","id":"/briefs/2024-01-azure-pim-elevation/","summary":"Detection of Azure Privileged Identity Management (PIM) elevation approvals or denials, which, if unexpected, may indicate unauthorized privilege escalation or malicious activity within an Azure environment.","title":"Azure PIM Elevation Approved or Denied","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-elevation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","mfa","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe absence of multi-factor authentication (MFA) during the activation of privileged roles in Azure Privileged Identity Management (PIM) poses a significant security risk. When roles can be activated without MFA, attackers who have already compromised a user account can escalate their privileges without needing to bypass an MFA challenge. This scenario circumvents a critical security control, making the environment vulnerable to lateral movement, data exfiltration, and other malicious activities. This brief is based on Sigma rule 94a66f46-5b64-46ce-80b2-75dcbe627cc0, published on 2023-09-14. Defenders need to monitor PIM configurations to ensure that MFA is enforced for all privileged role activations, mitigating the risk of unauthorized access and privilege escalation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a user account, potentially through phishing or credential stuffing.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a privileged role within Azure PIM that the compromised user is eligible to activate.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to activate the privileged role using the compromised user\u0026rsquo;s credentials.\u003c/li\u003e\n\u003cli\u003eDue to misconfiguration, MFA is not required for the role activation process.\u003c/li\u003e\n\u003cli\u003eThe attacker successfully activates the privileged role without providing a second factor of authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the newly acquired privileges to access sensitive resources and data within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious actions such as creating new accounts, modifying configurations, or exfiltrating data.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating backdoors or modifying access control policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe absence of MFA during PIM role activation can lead to significant damage, potentially affecting all resources within the Azure environment accessible to the compromised privileged role. Successful exploitation allows attackers to bypass a critical security control, leading to privilege escalation, data breaches, and system compromise. The impact spans data confidentiality, integrity, and availability, and could result in regulatory fines, reputational damage, and financial losses.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Roles Activation Doesn\u0026rsquo;t Require MFA\u0026rdquo; to your SIEM and tune for your environment to detect instances where privileged roles are activated without MFA based on \u003ccode\u003eriskEventType: 'noMfaOnRoleActivationAlertIncident'\u003c/code\u003e in Azure PIM logs.\u003c/li\u003e\n\u003cli\u003eReview and enforce MFA policies for all privileged role activations within Azure PIM, as recommended in the Microsoft documentation (\u003ca href=\"https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts#roles-dont-require-multi-factor-authentication-for-activation\"\u003ehttps://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts#roles-dont-require-multi-factor-authentication-for-activation\u003c/a\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:23:00Z","date_published":"2024-01-03T18:23:00Z","id":"/briefs/2024-01-azure-pim-no-mfa/","summary":"Detection of Azure Privileged Identity Management (PIM) roles being activated without requiring multi-factor authentication, potentially leading to unauthorized privilege escalation and persistence.","title":"Azure PIM Role Activation Without MFA","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-no-mfa/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","appid","uri","application","serviceprincipal","credential-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may modify the AppID URI of an application in Azure to facilitate various malicious activities, including gaining unauthorized access, establishing persistence, accessing credentials, escalating privileges, or maintaining stealth within the environment. The AppID URI serves as a unique identifier for an application within the Azure Active Directory (Azure AD) ecosystem. Changes to this URI could indicate that an attacker is attempting to impersonate a legitimate application or service, potentially bypassing security controls and gaining elevated access. Monitoring for these changes is crucial for defenders to identify and respond to potentially malicious activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure account, possibly through compromised credentials or exploiting a vulnerability (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available applications and service principals within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target application with a high-value AppID URI.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the AppID URI of the target application, potentially to impersonate another service or application (T1552).\u003c/li\u003e\n\u003cli\u003eThis change might be done to allow the attacker to request tokens for that application.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified AppID URI to request access tokens, potentially gaining unauthorized access to resources (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired access tokens to move laterally within the Azure environment and access sensitive data or systems.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by using the modified application for continued unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of an AppID URI can lead to significant security breaches, including unauthorized access to sensitive data, privilege escalation, and persistent compromise of the Azure environment. An attacker can impersonate legitimate applications, bypassing security controls and potentially affecting numerous resources and users. The scope of the impact depends on the permissions and access levels associated with the compromised application.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Application AppID Uri Configuration Changes\u0026rdquo; to your SIEM to detect unauthorized modifications to AppID URIs (rule provided below).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the AppID URI changes.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit application permissions and configurations to identify and remediate any misconfigurations.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for other suspicious activities related to application and service principal management.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T17:24:00Z","date_published":"2024-01-03T17:24:00Z","id":"/briefs/2024-01-azure-appid-uri-change/","summary":"Detection of configuration changes to an application's AppID URI in Azure, potentially indicating malicious activity related to initial access, persistence, credential access, privilege escalation, or stealth.","title":"Detect Application AppID URI Configuration Changes in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-appid-uri-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","kubernetes","admission-controller","persistence","privilege-escalation","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKubernetes Admission Controllers are critical components that intercept and potentially modify requests to the Kubernetes API server. These controllers rely on admission webhooks (MutatingAdmissionWebhook or ValidatingAdmissionWebhook) deployed within the cluster. A malicious actor can abuse these webhooks to establish persistence by modifying pod creation operations and injecting malicious containers into new pods via MutatingAdmissionWebhook. Alternatively, ValidatingAdmissionWebhook can be used to intercept API server requests, potentially exposing secrets and sensitive information. This activity allows for credential access and privilege escalation, impacting the overall security posture of the Kubernetes cluster.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.\u003c/li\u003e\n\u003cli\u003eThe malicious webhook is deployed to the cluster, configured to modify pod specifications.\u003c/li\u003e\n\u003cli\u003eWhen new pods are created, the webhook injects a malicious container into the pod specification before deployment.\u003c/li\u003e\n\u003cli\u003eThe malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.\u003c/li\u003e\n\u003cli\u003eThe webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising the Kubernetes Admission Controller can lead to persistent access within the cluster. The attacker can inject malicious containers into numerous pods, potentially affecting all applications deployed in the cluster. Sensitive information, like secrets, can be stolen, enabling lateral movement and privilege escalation within the Azure environment. The impact ranges from data breaches to complete cluster compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Kubernetes Admission Controller Configuration Change\u0026rdquo; to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e and \u003ccode\u003eMICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e operations to identify potential abuse.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:30:00Z","date_published":"2024-01-03T15:30:00Z","id":"/briefs/2024-01-azure-kubernetes-admission-controller/","summary":"An adversary can exploit Kubernetes Admission Controllers in Azure to achieve persistence, privilege escalation, or credential access by manipulating webhook configurations.","title":"Malicious Azure Kubernetes Admission Controller Configuration","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-admission-controller/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","application","deletion","impact","t1489"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection focuses on identifying instances where an application is deleted within an Azure environment. While legitimate application deletions occur as part of IT administration, malicious actors might delete applications to disrupt services, remove evidence of their presence, or prepare for a larger attack by removing security controls or access points. This activity is logged within Azure Activity Logs and includes events such as \u0026ldquo;Delete application\u0026rdquo; and \u0026ldquo;Hard Delete application\u0026rdquo;. Monitoring these events can provide early warning of potential security incidents or compliance violations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e An attacker gains unauthorized access to an Azure account, potentially through compromised credentials or exploiting a vulnerability in an application.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e The attacker escalates their privileges within the Azure environment to gain sufficient permissions to manage and delete applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReconnaissance:\u003c/strong\u003e The attacker identifies target applications for deletion, potentially those critical for business operations or those used for security controls.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDisable Monitoring (Optional):\u003c/strong\u003e The attacker attempts to disable logging or monitoring related to application management to avoid detection.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApplication Deletion:\u003c/strong\u003e The attacker initiates the deletion of the targeted application using the Azure portal, Azure CLI, or PowerShell.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfirmation/Hard Delete:\u003c/strong\u003e Depending on the application\u0026rsquo;s configuration and Azure policies, the attacker may need to confirm the deletion or perform a \u0026ldquo;hard delete\u0026rdquo; to permanently remove the application.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCover Tracks:\u003c/strong\u003e The attacker attempts to remove any remaining logs or traces of their activity to hinder forensic investigation.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e Service disruption or data loss due to the deleted application.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deletion of an Azure application can lead to significant service disruption, data loss, and potential financial damages. The impact depends on the criticality of the deleted application and the organization\u0026rsquo;s disaster recovery capabilities. Successful deletion can interrupt business processes, impacting both internal users and external customers. It may also lead to reputational damage and compliance violations if the application handled sensitive data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect application deletion events in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eReview user roles and permissions in Azure Active Directory (Entra ID) and enforce the principle of least privilege.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges.\u003c/li\u003e\n\u003cli\u003eEnable auditing and logging for all Azure resources, including application management activities.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected application deletion events promptly to determine the root cause and potential impact.\u003c/li\u003e\n\u003cli\u003eEstablish a process for reviewing and approving application deletion requests to prevent accidental or malicious deletions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:27:00Z","date_published":"2024-01-03T15:27:00Z","id":"/briefs/2024-01-azure-app-deletion/","summary":"This alert identifies when an application is deleted within an Azure environment, which could indicate malicious activity or unintended misconfiguration leading to service disruption.","title":"Detection of Azure Application Deletion","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-app-deletion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","password-reset","privilege-escalation","initial-access","persistence","credential-access","stealth"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on detecting user-initiated password resets within Azure Active Directory (Azure AD). While legitimate password resets are common, monitoring this activity can help identify potentially malicious behavior, such as an attacker attempting to gain unauthorized access to an account or an insider threat actor escalating privileges. Attackers may leverage compromised credentials or social engineering to initiate password resets, bypassing multi-factor authentication (MFA) if it is not properly configured or enforced. This detection is important for defenders because successful password resets can lead to a complete account takeover, allowing attackers to access sensitive data, resources, and systems.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a user\u0026rsquo;s credentials through phishing, credential stuffing, or malware.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to log in to an Azure AD-protected resource using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker fails to authenticate, either because they do not have the correct password or MFA is enabled.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a password reset request using the \u0026ldquo;Forgot password\u0026rdquo; feature or a similar mechanism.\u003c/li\u003e\n\u003cli\u003eAzure AD sends a password reset verification code or link to the user\u0026rsquo;s registered email address or phone number.\u003c/li\u003e\n\u003cli\u003eIf the attacker controls the registered email address or phone number (due to prior compromise), they can access the verification code or link.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the verification code or link to set a new password for the user\u0026rsquo;s Azure AD account.\u003c/li\u003e\n\u003cli\u003eThe attacker logs in to the Azure AD account with the new password, gaining unauthorized access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful password resets by attackers can lead to complete account takeover, allowing them to access sensitive data, resources, and systems protected by Azure AD. This can result in data breaches, financial loss, reputational damage, and disruption of business operations. The impact depends on the privileges and permissions assigned to the compromised account.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ePassword Reset By User Account\u003c/code\u003e to your SIEM to detect user-initiated password resets in Azure AD audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected password resets, especially those initiated by users who have not recently requested a password change.\u003c/li\u003e\n\u003cli\u003eReview and enforce multi-factor authentication (MFA) policies to prevent attackers from bypassing password-based authentication.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for suspicious activity related to password resets, such as multiple failed login attempts followed by a successful reset.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-03-azure-user-password-reset/","summary":"Detects when a user successfully resets their own password in Azure Active Directory, which may indicate malicious activity or account compromise.","title":"Azure AD User Password Reset Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-user-password-reset/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","azure","entra","guest-account"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe conversion of a user account from \u0026ldquo;Guest\u0026rdquo; to \u0026ldquo;Member\u0026rdquo; within Azure Active Directory (Azure AD) can represent a significant privilege escalation. While legitimate use cases exist for such conversions, malicious actors can abuse this functionality to gain unauthorized access and persistence. By elevating a guest account, which typically has limited permissions, to a member account, attackers can inherit the broader access rights associated with the latter, potentially compromising sensitive data and systems. Monitoring this activity is crucial as it can be indicative of insider threats or compromised administrative accounts used to manipulate user roles.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCompromise Initial Account:\u003c/strong\u003e An attacker gains initial access, possibly through phishing or credential stuffing, to an account with sufficient privileges to modify user attributes in Azure AD.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIdentify Target Guest Account:\u003c/strong\u003e The attacker identifies a guest account within the Azure AD environment that could provide valuable access if converted to a member account.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eModify UserType Attribute:\u003c/strong\u003e Using the compromised account, the attacker modifies the \u003ccode\u003eUserType\u003c/code\u003e attribute of the target guest account from \u0026ldquo;Guest\u0026rdquo; to \u0026ldquo;Member\u0026rdquo; via the Azure AD portal, PowerShell, or the Microsoft Graph API. This action generates an \u0026ldquo;Update user\u0026rdquo; event in the Azure AD audit logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInherit Member Privileges:\u003c/strong\u003e Once the \u003ccode\u003eUserType\u003c/code\u003e is changed to \u0026ldquo;Member\u0026rdquo;, the account inherits the privileges and group memberships associated with member accounts within the organization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e Leveraging the newly acquired member privileges, the attacker moves laterally within the Azure AD environment, accessing resources and services that were previously inaccessible.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration or System Compromise:\u003c/strong\u003e The attacker uses the elevated privileges to exfiltrate sensitive data, compromise critical systems, or establish persistent backdoors for future access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful conversion of a guest account to a member account can lead to significant privilege escalation, potentially granting attackers access to sensitive data, critical systems, and confidential resources. This can lead to data breaches, financial losses, reputational damage, and disruption of business operations. The impact depends on the permissions assigned to member accounts and the sensitivity of the resources they can access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;User State Changed From Guest To Member\u0026rdquo; Sigma rule to your SIEM to detect unauthorized user type conversions in Azure AD audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of user type changes from \u0026ldquo;Guest\u0026rdquo; to \u0026ldquo;Member\u0026rdquo; to verify their legitimacy, focusing on the user performing the action and the reason for the change (as captured by the Azure AD audit logs).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate the risk of account compromise and unauthorized access.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all user accounts to minimize the potential impact of a successful privilege escalation attack.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-azure-guest-member/","summary":"An adversary may convert a guest user account to a member account in Azure Active Directory to elevate privileges and gain persistent access to resources.","title":"Azure AD Guest to Member User Type Conversion","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-guest-member/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","global_admin","privilege_escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe presence of an excessive number of Global Administrator accounts in an Azure tenant poses a significant security risk. While the source does not attribute this activity to a specific threat actor, the risk event indicates a potential compromise of existing accounts, internal privilege abuse, or misconfiguration within the Azure environment. The alert triggers when the number of Global Administrator assignments exceeds a predefined threshold within Privileged Identity Management (PIM). Attackers may abuse highly privileged accounts to gain broad control over the Azure environment, deploy malicious workloads, exfiltrate data, or establish persistence.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker compromises a low-privilege user account through phishing or credential stuffing.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker attempts to elevate privileges by exploiting misconfigured permissions or vulnerabilities within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGlobal Admin Role Assignment:\u003c/strong\u003e The attacker assigns the Global Administrator role to multiple accounts, including the compromised account, either directly or through PIM bypass.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With Global Administrator privileges, the attacker moves laterally within the Azure environment, accessing sensitive resources and data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker exfiltrates sensitive data from cloud storage, databases, or virtual machines.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistent access by creating backdoors, modifying access controls, or deploying rogue applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCovering Tracks:\u003c/strong\u003e The attacker attempts to remove audit logs or disable security features to hide their activity.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe compromise of Global Administrator accounts can lead to significant damage, including data breaches, financial loss, and reputational damage. Excessive admin accounts significantly widen the attack surface and increase the likelihood of successful attacks. The impact includes unauthorized access to sensitive data, disruption of business operations, and potential regulatory fines.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Too Many Global Admins\u0026rdquo; to your SIEM and tune the threshold for your environment to detect excessive Global Administrator assignments in Azure PIM.\u003c/li\u003e\n\u003cli\u003eReview and reduce the number of Global Administrator accounts to the minimum necessary.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all privileged accounts.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for suspicious activity related to role assignments and privilege elevation.\u003c/li\u003e\n\u003cli\u003eRegularly review and update PIM policies to ensure appropriate access controls.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-too-many-global-admins/","summary":"Detection of an excessive number of Global Administrator accounts assigned within an Azure tenant, indicating potential privilege escalation or compromised accounts.","title":"Excessive Global Administrator Accounts in Azure PIM","url":"https://feed.craftedsignal.io/briefs/2024-01-too-many-global-admins/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","pim","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003ePrivileged Identity Management (PIM) is a critical component of Azure Active Directory, enabling organizations to manage, control, and monitor access to important resources. Attackers often target PIM configurations to escalate privileges, establish persistence, or move laterally within a compromised environment. This activity focuses on detecting changes to PIM role settings, which could indicate malicious activity aimed at weakening security controls. Defenders must monitor these changes to prevent unauthorized access and maintain the integrity of their Azure environment. This includes understanding who is making these changes, the scope of the modifications, and whether the changes align with established security policies.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e The attacker gains initial access to an account with sufficient privileges to view PIM settings.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates existing PIM role settings within the Azure Active Directory environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eModification:\u003c/strong\u003e The attacker modifies existing PIM role settings, such as extending the maximum activation time or removing approval requirements, using the Azure portal, PowerShell, or the Azure CLI.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e By modifying PIM settings, the attacker escalates their privileges, granting themselves elevated access to sensitive resources or administrative functions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by creating new or modifying existing role assignments to maintain access even if their initial account is compromised.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With escalated privileges, the attacker moves laterally to access other resources or accounts within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Impact:\u003c/strong\u003e The attacker leverages their escalated privileges to exfiltrate sensitive data, disrupt services, or cause other damage.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of PIM settings can have severe consequences, including unauthorized access to sensitive data, disruption of critical services, and privilege escalation leading to complete compromise of the Azure environment. A single compromised PIM setting can affect multiple users and resources, amplifying the impact of the attack. Early detection of PIM setting modifications can prevent attackers from gaining a foothold and causing significant damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect changes to PIM settings based on the \u003ccode\u003eproperties.message\u003c/code\u003e field within Azure audit logs.\u003c/li\u003e\n\u003cli\u003eRegularly review Azure audit logs for events related to PIM configuration changes, paying close attention to the user accounts making the changes and the scope of the modifications.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all accounts with privileges to manage PIM settings.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege by granting users only the minimum permissions required to perform their job functions.\u003c/li\u003e\n\u003cli\u003eEstablish a baseline of normal PIM settings and alert on any deviations from this baseline.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule by correlating them with other security events and user activity.\u003c/li\u003e\n\u003cli\u003eImplement automated responses to detected PIM setting modifications, such as disabling the affected user account or reverting the changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-azure-pim-settings-change/","summary":"Detects unauthorized or malicious modifications to Privileged Identity Management (PIM) settings within Azure environments, potentially leading to privilege escalation, persistence, and stealthy access by attackers.","title":"Detection of Privileged Identity Management (PIM) Settings Modifications","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-pim-settings-change/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","cloud","service principal","persistence","lateral movement"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe creation of service principals in Azure can be a legitimate administrative task, but it can also be an indicator of malicious activity. Attackers may create service principals to establish persistence, move laterally within the Azure environment, or gain unauthorized access to resources. This activity is particularly concerning when performed by unfamiliar users or from unusual locations. Monitoring for unexpected service principal creation is crucial for detecting potential security breaches in Azure environments. This alert focuses on detecting the \u0026ldquo;Add service principal\u0026rdquo; message within Azure Activity Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure account, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure CLI with the compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to create a new service principal using tools like Azure CLI or PowerShell.\u003c/li\u003e\n\u003cli\u003eAzure Activity Logs record the \u0026ldquo;Add service principal\u0026rdquo; event.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns roles and permissions to the newly created service principal, granting it access to specific resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the service principal for lateral movement, accessing resources or services within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe service principal is used for persistence, allowing the attacker to maintain access even if the initial access method is revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful creation and misuse of a service principal can lead to unauthorized access to sensitive data, resources, and services within the Azure environment. The impact can range from data breaches and service disruption to complete control over the Azure subscription, potentially affecting hundreds or thousands of resources and users. The attacker can leverage the compromised service principal to perform actions with the permissions assigned to it, leading to significant damage and financial loss.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Service Principal Created\u0026rdquo; to your SIEM and tune for your environment to detect suspicious service principal creations.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u0026ldquo;Azure Service Principal Created\u0026rdquo; rule (logsource: azure) by verifying the user identity, user agent, and hostname associated with the event.\u003c/li\u003e\n\u003cli\u003eReview and audit existing service principals and their assigned permissions to identify any anomalies or overly permissive configurations.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts to reduce the risk of credential compromise and unauthorized access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-azure-sp-creation/","summary":"Detects the creation of a service principal in Azure, which could indicate potential attacker activity for lateral movement or persistence.","title":"Detection of Azure Service Principal Creation","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-sp-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["attack.defense-impairment","attack.t1578.003","azure"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAn attacker can create a new AD Health ADFS service and a fake server to spoof AD FS signing logs. This involves adding a rogue AD FS service to Azure AD Hybrid Health. Once the attacker no longer requires the spoofed logs, they may delete the service to remove traces of their activity or to hinder investigations. This is achieved via HTTP requests to Azure, specifically targeting the deletion of the AD FS service instance. This activity is logged within Azure Activity Logs, providing an opportunity for detection. Defenders should monitor for unexpected deletions of AD FS service instances within their Azure AD environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure tenant with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker provisions a new, rogue AD FS service within the Azure AD Hybrid Health Service.\u003c/li\u003e\n\u003cli\u003eThe attacker creates a fake server or modifies an existing one to generate spoofed AD FS signing logs.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the spoofed logs to conduct malicious activity, potentially bypassing security controls.\u003c/li\u003e\n\u003cli\u003eOnce the malicious activity is complete, the attacker initiates the deletion of the rogue AD FS service.\u003c/li\u003e\n\u003cli\u003eThe attacker sends an HTTP request to Azure to delete the service using the \u003ccode\u003eMicrosoft.ADHybridHealthService/services/delete\u003c/code\u003e operation.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record the deletion event with CategoryValue set to \u0026lsquo;Administrative\u0026rsquo; and ResourceProviderValue as \u0026lsquo;Microsoft.ADHybridHealthService\u0026rsquo;.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful deletion of the AD FS service instance can hinder forensic investigations and potentially mask malicious activity within the Azure AD environment. This can lead to delayed incident response and make it more difficult to identify the source and scope of the attack. The impact depends on the sophistication of the attacker and the extent to which they leveraged the spoofed logs for malicious purposes.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect the deletion of AD FS service instances in Azure AD Hybrid Health (Azure Activity Logs).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of \u003ccode\u003eMicrosoft.ADHybridHealthService/services/delete\u003c/code\u003e operations where the \u003ccode\u003eResourceId\u003c/code\u003e contains \u003ccode\u003eAdFederationService\u003c/code\u003e in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for unexpected or unauthorized modifications to AD FS service configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-azuread-adfs-delete/","summary":"Threat actors may delete Azure AD Hybrid Health AD FS service instances after using them to spoof AD FS signing logs for defense evasion.","title":"Azure AD Hybrid Health AD FS Service Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azuread-adfs-delete/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","service principal","stealth","cloud"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe removal of a service principal within an Azure environment can be indicative of various activities, ranging from legitimate administrative tasks to malicious actions undertaken by threat actors attempting to cover their tracks. While service principals are routinely removed as part of lifecycle management, unauthorized or unexpected removals should be investigated promptly. This detection focuses on identifying such removals through Azure Activity Logs, allowing security teams to quickly respond to potentially suspicious events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to an Azure account through compromised credentials or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a service principal used for malicious purposes or to maintain persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to remove the service principal to evade detection or disrupt incident response efforts.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the necessary commands or uses the Azure portal to initiate the service principal removal. This action is logged in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record an event with the message \u0026ldquo;Remove service principal\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe detection rule triggers based on the \u0026ldquo;Remove service principal\u0026rdquo; message in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eSecurity analysts investigate the event, examining the user identity, user agent, and hostname associated with the removal.\u003c/li\u003e\n\u003cli\u003eIf the removal is deemed unauthorized or suspicious, further incident response procedures are initiated.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful removal of a service principal by a malicious actor can disrupt legitimate applications relying on that principal for authentication and authorization. It can also hinder incident response efforts by eliminating a potential avenue for investigation or remediation. The impact can range from service disruptions to prolonged breaches if the attacker successfully covers their tracks. The number of affected applications and the severity of the disruption depend on the role and permissions associated with the removed service principal.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Service Principal Removed\u0026rdquo; to your SIEM and tune for your environment, focusing on identifying legitimate administrator activity to reduce false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instance of service principal removal, focusing on the user identity, user agent, and hostname from the Azure Activity Logs to determine legitimacy.\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs for related activities occurring before and after the service principal removal.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:27:00Z","date_published":"2024-01-03T14:27:00Z","id":"/briefs/2024-01-azure-service-principal-removed/","summary":"Detection of a service principal removal in Azure, potentially indicating malicious activity or an attempt to remove evidence of a compromise.","title":"Azure Service Principal Removal Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-service-principal-removed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["cloud","azure","application","uri","modification","persistence","credential-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may modify application URIs within Azure Active Directory to redirect users or applications to malicious resources, obtain unauthorized access, or establish persistence. The modification of an application\u0026rsquo;s URI can be a subtle but effective technique for gaining a foothold in an environment. By manipulating the URI settings, attackers can redirect traffic to attacker-controlled servers, intercept credentials, or perform other malicious actions. This activity is often difficult to detect because it can blend in with legitimate administrative tasks. Investigation is merited if URIs for domain names no longer exist, are not using HTTPS, have wildcards at the end of the domain, are not unique to that app, or point to domains that the organization does not control.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure account with sufficient privileges to modify application registrations.\u003c/li\u003e\n\u003cli\u003eThe attacker navigates to the Azure Active Directory portal.\u003c/li\u003e\n\u003cli\u003eThe attacker locates a target application registration.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the application\u0026rsquo;s URI settings, such as the reply URLs or identifier URIs.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the URI to point to a malicious server or a phishing page.\u003c/li\u003e\n\u003cli\u003eUsers or applications are redirected to the malicious URI when attempting to authenticate or access the application.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts credentials or performs other malicious actions.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining control over the application\u0026rsquo;s URI settings.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack could lead to credential theft, data breaches, or unauthorized access to sensitive resources. By compromising application URIs, attackers can redirect users to phishing pages, intercept credentials, or gain a foothold in the environment for further exploitation. This activity can be difficult to detect and can have a significant impact on the organization\u0026rsquo;s security posture.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to your SIEM to detect suspicious modifications to application URIs in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u003ccode\u003eApplication URI Configuration Changes\u003c/code\u003e to determine if the URI modification is legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for any changes to application URI settings (as indicated by \u003ccode\u003eproperties.message: Update Application Sucess- Property Name AppAddress\u003c/code\u003e) and validate the legitimacy of the changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:21:00Z","date_published":"2024-01-03T14:21:00Z","id":"/briefs/2024-01-03-azure-app-uri-modification/","summary":"Detection of Azure application URI modifications that can be indicative of malicious activity, such as using dangling URIs, non-HTTPS URIs, wildcard domains, or URIs pointing to uncontrolled domains, potentially leading to initial access, stealth, persistence, credential access, and privilege escalation.","title":"Azure Application URI Configuration Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-03-azure-app-uri-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis activity involves the removal of a user from an Azure Active Directory (Azure AD) group that possesses the ability to modify Conditional Access (CA) policies. Conditional Access policies are critical for enforcing organizational security standards and access controls. The removal of users from these groups can be an attempt by a malicious actor to disrupt security measures, escalate privileges, or establish persistence within the Azure environment. An attacker with sufficient privileges may remove legitimate administrators from CA policy modification groups to bypass multi-factor authentication or other controls, potentially gaining unauthorized access to sensitive resources. This activity is of concern to defenders as it can be a precursor to more significant compromises.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure AD account with sufficient privileges, possibly through credential theft or account compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates Azure AD groups to identify those with permissions to manage or modify Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target user account that is a member of the identified privileged group.\u003c/li\u003e\n\u003cli\u003eThe attacker uses Azure AD administrative tools or PowerShell cmdlets to remove the target user from the privileged group.\u003c/li\u003e\n\u003cli\u003eThe Azure Audit Logs record the event \u0026ldquo;Remove member from group\u0026rdquo; related to the targeted group and user.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies Conditional Access policies to weaken security controls, such as disabling multi-factor authentication or allowing access from untrusted locations.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the weakened security posture to gain unauthorized access to sensitive resources or data.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new, attacker-controlled accounts with high privileges or by modifying existing accounts to bypass security controls.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful removal of a user from a Conditional Access policy modification group can lead to significant security breaches. Attackers can weaken or disable MFA requirements, bypass location-based restrictions, and gain unauthorized access to sensitive applications and data. This can result in data exfiltration, financial loss, and reputational damage. The scope of the impact depends on the permissions assigned through the compromised Conditional Access policies.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;User Removed From Group With CA Policy Modification Access\u0026rdquo; to your SIEM to detect unauthorized removal of users from critical groups with CA modification access (logsource: azure, service: auditlogs).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the context of the user removed and the target group (Sigma rule).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all administrative accounts, including those with permissions to manage Conditional Access policies.\u003c/li\u003e\n\u003cli\u003eReview and audit Azure AD group memberships regularly, especially for groups with elevated privileges.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for suspicious activity related to group membership changes and Conditional Access policy modifications (logsource: azure, service: auditlogs).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-group-removal/","summary":"An attacker removes a user from a privileged Azure Active Directory group with permissions to modify Conditional Access policies, potentially leading to privilege escalation, persistence, or defense evasion.","title":"User Removed from Group with Conditional Access Policy Modification Access","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-group-removal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","pim","privileged-identity-management","role-based-access-control","initial-access","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert identifies a condition where users have been assigned privileged roles within Azure\u0026rsquo;s Privileged Identity Management (PIM) but are not actively utilizing those roles. This situation can arise from various factors, including misconfiguration of PIM settings, over-allocation of privileged roles due to process gaps or lack of oversight, or the presence of dormant accounts with elevated privileges. Such unused roles represent a potential security risk, as they can be exploited by malicious actors or misused inadvertently, especially if MFA or conditional access policies are not enforced. Regularly auditing and addressing unused PIM roles is crucial for maintaining a strong security posture and optimizing license utilization.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn administrator assigns a privileged role to a user within Azure PIM.\u003c/li\u003e\n\u003cli\u003eThe user is granted the role but does not activate or use it to perform any privileged actions.\u003c/li\u003e\n\u003cli\u003eAzure PIM monitors role usage and detects the lack of activity for the assigned role.\u003c/li\u003e\n\u003cli\u003eThe \u0026ldquo;redundantAssignmentAlertIncident\u0026rdquo; event is triggered within the Azure PIM logs.\u003c/li\u003e\n\u003cli\u003eAn attacker gains access to the user\u0026rsquo;s account through credential compromise or other means.\u003c/li\u003e\n\u003cli\u003eThe attacker activates the unused privileged role.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the now-active privileged role to perform unauthorized actions, such as modifying system configurations, accessing sensitive data, or escalating privileges further.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration or system compromise, without being detected due to the pre-existing role assignment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe presence of unused privileged roles can lead to significant security breaches and compliance violations. An attacker exploiting an unused role can gain immediate access to sensitive resources and perform unauthorized actions, potentially leading to data breaches, system outages, or financial losses. The number of affected users and resources depends on the scope of the unused role and the attacker\u0026rsquo;s objectives. Failure to identify and address these unused roles can also result in unnecessary license costs and increased attack surface.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003eredundantAssignmentAlertIncident\u003c/code\u003e events indicating unused PIM roles in Azure (see \u0026ldquo;Roles Are Not Being Used\u0026rdquo; rule).\u003c/li\u003e\n\u003cli\u003eInvestigate all detected instances of unused PIM roles to determine the reason for inactivity and potential risks.\u003c/li\u003e\n\u003cli\u003eRevoke the assigned role if the user no longer requires it, or provide training and guidance to ensure proper role utilization.\u003c/li\u003e\n\u003cli\u003eReview and refine PIM role assignment policies to minimize the allocation of unnecessary privileges.\u003c/li\u003e\n\u003cli\u003eImplement regular audits of PIM role assignments to identify and address unused roles promptly.\u003c/li\u003e\n\u003cli\u003eConfigure security alerts within Azure PIM to receive notifications about unused roles and other potential security incidents.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-pim-role-not-used/","summary":"Detection of assigned but unused privileged roles in Azure's Privileged Identity Management (PIM) service, indicating potential misconfiguration, license overuse, or dormant privileged access that could be exploited.","title":"Unused Privileged Identity Management (PIM) Roles in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-role-not-used/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","initial-access","persistence","stealth","azure"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert detects instances where a user attempts to invite an external guest user to an Azure environment but fails due to insufficient permissions. This activity can signify several potential security risks, including unauthorized privilege escalation attempts by internal users or malicious insiders attempting to expand access without proper authorization. While legitimate failed attempts may occur, repeated or targeted failures should be investigated. The activity is logged within the Azure Audit Logs. Detecting this activity is crucial for maintaining control over user access and preventing potential data breaches. The relevant log data resides within Azure\u0026rsquo;s audit logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn internal user (either compromised or malicious) attempts to invite an external guest user via the Azure portal or API.\u003c/li\u003e\n\u003cli\u003eThe Azure Active Directory service checks the inviter\u0026rsquo;s permissions against the organization\u0026rsquo;s guest invitation policies.\u003c/li\u003e\n\u003cli\u003eThe system determines the user lacks the necessary permissions to invite guest users.\u003c/li\u003e\n\u003cli\u003eAzure Audit Logs record the \u0026ldquo;Invite external user\u0026rdquo; event with a \u0026ldquo;failure\u0026rdquo; status.\u003c/li\u003e\n\u003cli\u003eThe failed invitation attempt is blocked, preventing the external user from gaining access.\u003c/li\u003e\n\u003cli\u003eThe attacker may retry the invitation with different accounts or methods, attempting to bypass access controls.\u003c/li\u003e\n\u003cli\u003eIf successful through other means (not detected by this rule), the guest user could be used for lateral movement or data exfiltration.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation could grant unauthorized access to sensitive data and resources within the Azure environment. While this specific detection focuses on failed attempts, repeated failures may indicate a concerted effort to bypass security controls. If successful, unauthorized guest users could be used for lateral movement, data exfiltration, or other malicious activities. The number of affected resources depends on the permissions granted to the guest user if the invitation had been successful.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Guest User Invited By Non Approved Inviters\u0026rdquo; to your SIEM to detect unauthorized invitation attempts within Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine the legitimacy of the invitation attempt and the intent of the user.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for user roles and permissions within Azure Active Directory.\u003c/li\u003e\n\u003cli\u003eMonitor for repeated failed invitation attempts from the same user account (correlate with the Azure Audit Logs data).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-guest-invite-failure/","summary":"Detection of a failed attempt to invite an external guest user by an Azure user lacking the necessary permissions, potentially indicating privilege escalation or malicious insider activity.","title":"Unauthorized Guest User Invitation Attempt in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-guest-invite-failure/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","conditional-access","privilege-escalation","attack.privilege-escalation","attack.t1548"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief addresses the creation of a new Conditional Access (CA) policy within Azure Active Directory (Azure AD) by an actor not authorized to perform such actions. Conditional Access policies are critical security controls that enforce organizational policies based on various conditions, such as user identity, location, device, and application. Unauthorized modification or creation of these policies can lead to significant security breaches, allowing attackers to bypass security controls, escalate privileges, and gain unauthorized access to sensitive resources. This activity is detected via Azure Audit Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access to an account with sufficient privileges to interact with Azure AD, potentially through compromised credentials or an insider threat.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (If Needed):\u003c/strong\u003e The attacker escalates privileges within Azure AD to a role that permits the creation or modification of Conditional Access policies.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Creation:\u003c/strong\u003e The attacker creates a new Conditional Access policy using the Azure portal, PowerShell, or Azure CLI.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePolicy Configuration:\u003c/strong\u003e The attacker configures the CA policy to weaken security controls, such as disabling MFA for specific users, locations, or applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBypass Security Controls:\u003c/strong\u003e The newly created or modified CA policy allows the attacker to bypass intended security controls, granting them unauthorized access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e With bypassed security controls, the attacker moves laterally within the network, accessing sensitive resources and data.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Impact:\u003c/strong\u003e The attacker achieves their final objective, such as exfiltrating sensitive data or causing disruption to business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe creation of unauthorized Conditional Access policies can have severe consequences, including unauthorized access to sensitive data, privilege escalation, and circumvention of security controls. The impact can range from data breaches and financial loss to reputational damage and disruption of critical business services. If successful, attackers could gain complete control over the Azure AD environment, affecting all connected services and applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized CA policy creation events in Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eReview Azure AD role assignments to ensure least privilege and restrict CA policy management to authorized personnel only.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to identify the actor and the details of the created CA policy.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users, especially those with administrative privileges, to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor Azure AD audit logs for other suspicious activities, such as changes to user accounts, group memberships, and application registrations.\u003c/li\u003e\n\u003cli\u003eEstablish a baseline of expected CA policy configurations and alert on deviations from this baseline.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-ca-policy-add/","summary":"An unauthorized actor created a new Conditional Access policy in Azure AD, potentially leading to privilege escalation and unauthorized access.","title":"Unauthorized Conditional Access Policy Creation in Azure AD","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-ca-policy-add/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","alerts","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may disable PIM alerts within Azure environments to weaken security monitoring and maintain a low profile while escalating privileges. This involves modifying alert settings within the Azure Privileged Identity Management service to prevent notifications of suspicious or unauthorized activity. This technique enables attackers to operate with reduced scrutiny, making it easier to establish persistence and move laterally within the compromised environment. Successful disabling of PIM alerts allows malicious actors to abuse privileged roles without triggering immediate alarms. This allows for potentially long-term access and control over critical resources.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: The attacker gains initial access to an Azure account, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation: The attacker attempts to escalate privileges within the Azure Active Directory, potentially by exploiting misconfigured roles or vulnerabilities.\u003c/li\u003e\n\u003cli\u003ePIM Access: The attacker accesses the Azure Privileged Identity Management (PIM) service.\u003c/li\u003e\n\u003cli\u003eAlert Configuration Discovery: The attacker enumerates existing PIM alert configurations to identify the alerts to be disabled.\u003c/li\u003e\n\u003cli\u003eAlert Modification: The attacker modifies the alert settings, setting them to disabled. This is often done through the Azure portal or via API calls.\u003c/li\u003e\n\u003cli\u003ePersistence: With alerts disabled, the attacker can maintain persistence by assigning themselves privileged roles without generating notifications.\u003c/li\u003e\n\u003cli\u003eLateral Movement: The attacker leverages the newly acquired privileged roles to move laterally within the Azure environment, accessing sensitive resources and data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling PIM alerts significantly reduces an organization\u0026rsquo;s visibility into privileged access activities. This can lead to delayed detection of malicious activities, enabling attackers to maintain a persistent presence, escalate privileges, and exfiltrate sensitive data without triggering alarms. The impact includes potential data breaches, financial losses, and reputational damage. The lack of alerts hinders incident response efforts and prolongs the duration of the attack, compounding the damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect instances where PIM alerts are disabled by monitoring \u003ccode\u003eauditlogs\u003c/code\u003e for \u003ccode\u003eproperties.message: Disable PIM Alert\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eRegularly review PIM alert configurations to ensure critical alerts are enabled and properly configured.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate initial access (T1078).\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege to limit the scope of potential damage from compromised accounts.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for unusual activity related to PIM configuration changes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-pim-alerts-disabled/","summary":"An adversary disables Privileged Identity Management (PIM) alerts in Azure to evade detection and maintain persistent access with escalated privileges.","title":"Privileged Identity Management (PIM) Alerting Disabled","url":"https://feed.craftedsignal.io/briefs/2024-01-03-pim-alerts-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","pim","role-activation","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief addresses suspicious activity within Azure Privileged Identity Management (PIM), specifically the repeated activation of privileged roles by the same user. The alert, triggered by \u0026lsquo;sequentialActivationRenewalsAlertIncident\u0026rsquo; events, suggests that an attacker may be attempting to escalate privileges or maintain persistent access to sensitive resources. This activity can be indicative of compromised credentials or malicious insider activity. The detection is based on Azure PIM logs and aims to identify deviations from normal user behavior related to role activation. Defenders should investigate these alerts promptly to determine the legitimacy of the role activations and mitigate potential risks.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Access: An attacker gains initial access to an Azure account, possibly through compromised credentials (T1078).\u003c/li\u003e\n\u003cli\u003ePrivilege Discovery: The attacker identifies available privileged roles within Azure PIM.\u003c/li\u003e\n\u003cli\u003eRole Activation Request: The attacker initiates a request to activate a privileged role.\u003c/li\u003e\n\u003cli\u003eRole Activation: The attacker successfully activates the privileged role.\u003c/li\u003e\n\u003cli\u003eResource Access: With the activated role, the attacker accesses sensitive resources or performs privileged actions.\u003c/li\u003e\n\u003cli\u003eRepeated Activation: The attacker deactivates and reactivates the same role shortly after, potentially to bypass monitoring or maintain persistent access.\u003c/li\u003e\n\u003cli\u003eLateral Movement (Optional): The attacker uses the elevated privileges to move laterally within the Azure environment.\u003c/li\u003e\n\u003cli\u003eData Exfiltration or System Damage (Impact): The attacker achieves their ultimate objective, such as exfiltrating sensitive data or causing damage to systems.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could lead to unauthorized access to critical resources, data breaches, and significant damage to the organization\u0026rsquo;s Azure environment. The repeated activation of privileged roles can be used to bypass security controls and maintain persistent access, making it difficult to detect malicious activity. A single compromised account with PIM access can lead to widespread impact across the entire Azure infrastructure.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Roles Activated Too Frequently\u0026rdquo; to your SIEM and tune it based on your environment to reduce false positives (logsource: azure, service: pim).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule \u0026ldquo;Roles Activated Too Frequently\u0026rdquo;, focusing on the context of the role activated and the user involved.\u003c/li\u003e\n\u003cli\u003eReview the active time period for roles in PIM to ensure they are not set too short, which can lead to frequent legitimate activations and false positives, as noted in the \u003ccode\u003efalsepositives\u003c/code\u003e section.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users, especially those with privileged roles, to mitigate the risk of credential compromise (T1078).\u003c/li\u003e\n\u003cli\u003eMonitor Azure Active Directory sign-in logs for suspicious activity, such as logins from unusual locations or devices.\u003c/li\u003e\n\u003cli\u003eImplement least privilege principles and regularly review role assignments to minimize the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-pim-role-activation/","summary":"Detection of frequent role activation in Azure Privileged Identity Management (PIM) by the same user may indicate potential privilege escalation or account compromise.","title":"Frequent Azure PIM Role Activation Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-role-activation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","privileged-account","initial-access","persistence","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of new privileged account creation within Azure environments. Attackers often create new admin accounts to establish persistence, escalate privileges, or move laterally within a compromised environment. Monitoring for such activity is crucial, especially given that compromised accounts are a common entry point for various attacks. This activity, if malicious, can lead to significant data breaches, service disruptions, and reputational damage. This detection focuses on identifying \u0026ldquo;Add user\u0026rdquo; and \u0026ldquo;Add member to role\u0026rdquo; events within Azure audit logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure environment, possibly through compromised credentials (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages their access to enumerate existing accounts and roles within the Azure Active Directory.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new user account with elevated privileges, such as Global Administrator or other custom administrative roles.\u003c/li\u003e\n\u003cli\u003eThe attacker assigns the newly created user account to one or more privileged roles, granting it administrative access to the Azure environment. This action is logged as \u0026ldquo;Add member to role\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created privileged account to perform reconnaissance, identify sensitive data, or deploy malicious applications.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining access through the newly created account, even if the initial entry point is detected and remediated.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain control over critical resources and services within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the privileged account to exfiltrate sensitive data, deploy ransomware, or disrupt critical business operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful creation of a privileged account can provide an attacker with persistent access and the ability to escalate privileges, leading to widespread damage. The attacker can gain control over critical resources, exfiltrate sensitive data, deploy ransomware, or disrupt business operations. This can lead to significant financial losses, reputational damage, and legal liabilities. While the scope and number of victims are unknown, all organizations using Azure Active Directory are potentially at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect privileged account creation events within Azure Audit Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of privileged account creation to determine whether the activity is legitimate.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, especially those with privileged roles, to mitigate the risk of credential compromise (T1110).\u003c/li\u003e\n\u003cli\u003eRegularly review and audit user account privileges to identify and remove unnecessary or excessive permissions.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for suspicious activities, such as unusual sign-in attempts, changes to security settings, and modifications to privileged roles.\u003c/li\u003e\n\u003cli\u003eImplement alerting for changes to privileged roles and groups within Azure AD.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-privileged-account-creation/","summary":"Detects the creation of new privileged accounts in Azure environments, potentially indicating initial access, persistence, privilege escalation, or stealth activities by malicious actors.","title":"Detection of Privileged Account Creation in Azure","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-privileged-account-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["high"],"_cs_tags":["azure","privilege-escalation","persistence","initial-access","stealth"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat involves the elevation of user permissions within an Azure environment to manage all Azure subscriptions. While legitimate administrators may perform this action, unauthorized elevation of permissions can grant an attacker significant control over the entire Azure environment. This could be an insider threat or a compromised account being used to broaden access. The activity is logged within Azure Activity Logs, providing an opportunity for detection. Defenders should be aware of this potential escalation path and monitor for unexpected or unauthorized permission changes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure account, potentially through compromised credentials (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure CLI/PowerShell with the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to elevate their permissions using the \u003ccode\u003eMICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION\u003c/code\u003e operation.\u003c/li\u003e\n\u003cli\u003eAzure Activity Logs record the attempt to elevate permissions.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker gains management access to all Azure subscriptions within the tenant.\u003c/li\u003e\n\u003cli\u003eThe attacker can then provision resources, modify configurations, and access data within those subscriptions.\u003c/li\u003e\n\u003cli\u003eThe attacker might establish persistence by creating new user accounts with elevated privileges or modifying existing roles.\u003c/li\u003e\n\u003cli\u003eThe attacker can then exfiltrate sensitive data or disrupt services within the Azure environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful elevation of permissions to manage all Azure subscriptions allows an attacker to control all resources, data, and configurations within the Azure environment. This can lead to data breaches, service disruptions, financial loss, and reputational damage. The scope of impact depends on the sensitivity of the data stored within Azure and the criticality of the services hosted there.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized \u003ccode\u003eMICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION\u003c/code\u003e operations in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of \u003ccode\u003eMICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION\u003c/code\u003e immediately, as outlined in the rule description.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for Azure role assignments.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for other suspicious activities, such as unusual resource creation or modification.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-subscription-elevation/","summary":"An attacker elevates their Azure subscription permissions to manage all subscriptions, potentially leading to unauthorized access and control over the environment.","title":"Azure Subscription Permission Elevation via Activity Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-subscription-elevation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure"],"_cs_severities":["medium"],"_cs_tags":["attack.stealth","azure"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe removal of an owner from an Azure application or service principal can be indicative of malicious activity. An attacker who has gained initial access to an Azure environment might attempt to remove owners from service principals or applications to hinder incident response, establish persistence, or escalate their privileges. This action could be part of a broader attack aimed at compromising cloud resources and data. Detecting this activity is crucial for identifying potentially compromised accounts and preventing further damage within the Azure environment. The activity is logged within the Azure Activity Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an Azure account through compromised credentials or by exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates available applications and service principals within the Azure environment to identify potential targets.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies an application or service principal with elevated permissions that would be beneficial to compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to remove the existing owner from the target application or service principal via the Azure portal, PowerShell, or Azure CLI.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record an event indicating \u0026ldquo;Remove owner from service principal\u0026rdquo; or \u0026ldquo;Remove owner from application\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker may assign themselves as the new owner or further modify the permissions of the application or service principal to achieve their objectives.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised application or service principal to access sensitive resources, exfiltrate data, or deploy malicious workloads.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful removal of an owner from an Azure application or service principal can lead to a significant compromise of cloud resources. This action can disrupt normal operations, allow unauthorized access to sensitive data, and provide a persistent foothold for attackers within the Azure environment. The lack of an owner can prevent proper oversight and incident response, potentially leading to prolonged compromise and increased damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Owner Removed From Application or Service Principal\u0026rdquo; to your SIEM and tune for your environment to detect suspicious owner removal activity in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on unfamiliar user identities and unusual user agents in the Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise, which is often the initial access vector.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit the permissions assigned to applications and service principals to identify and remediate any excessive or unnecessary privileges.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-owner-removed/","summary":"An adversary may remove an owner from an Azure application or service principal to weaken access controls, persist in the environment, or escalate privileges.","title":"Azure Owner Removed from Application or Service Principal","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-owner-removed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","mfa","credential-access","persistence","defense-impairment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers may disable multi-factor authentication (MFA) within Azure Active Directory (Azure AD) to bypass security controls and gain unauthorized access to user accounts and resources. This activity can occur after initial compromise or as part of an insider threat scenario. The disabling of MFA typically manifests as a successful \u0026ldquo;Disable Strong Authentication\u0026rdquo; event within the Azure Active Directory activity logs. Defenders should monitor for these events, especially when initiated by accounts that do not typically perform administrative functions, as it may indicate malicious activity aimed at weakening the organization\u0026rsquo;s security posture and establishing persistence.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an account with sufficient privileges in Azure AD, possibly through credential compromise or phishing.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses Azure AD PowerShell modules.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies target user accounts for which they wish to disable MFA.\u003c/li\u003e\n\u003cli\u003eThe attacker disables MFA for the targeted user accounts, resulting in an \u0026ldquo;Disable Strong Authentication.\u0026rdquo; event in the Azure AD activity logs.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to authenticate to the targeted user accounts without MFA.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker gains access to sensitive resources, such as email, files, or applications.\u003c/li\u003e\n\u003cli\u003eThe attacker may then move laterally within the environment, accessing additional resources and escalating privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eDisabling MFA can significantly weaken an organization\u0026rsquo;s security posture, leading to unauthorized access to sensitive data and systems. Successful exploitation could result in data breaches, financial loss, and reputational damage. The impact is widespread, affecting any organization that relies on Azure AD for identity and access management, impacting potentially thousands of users and applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect instances of MFA being disabled in Azure AD activity logs, focusing on \u0026ldquo;Disable Strong Authentication\u0026rdquo; events (\u003ccode\u003eeventSource: AzureActiveDirectory\u003c/code\u003e, \u003ccode\u003eeventName: 'Disable Strong Authentication.'\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of MFA being disabled, especially if the activity is performed by unusual accounts.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) policies and monitor for unauthorized changes to MFA settings.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for Azure AD roles and permissions.\u003c/li\u003e\n\u003cli\u003eEnable logging for Azure Active Directory activity and sign-in logs (\u003ccode\u003eproduct: azure\u003c/code\u003e, \u003ccode\u003eservice: activitylogs\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-azure-mfa-disabled/","summary":"An adversary may disable multi-factor authentication (MFA) in Azure Active Directory to weaken an organization's security posture and bypass authentication mechanisms, potentially gaining unauthorized access to sensitive resources and maintaining persistence.","title":"Azure AD MFA Disabled to Bypass Authentication","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-mfa-disabled/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory","Microsoft Entra ID Protection"],"_cs_severities":["high"],"_cs_tags":["azure","identity-protection","atypical-travel","account-compromise","credential-theft"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe Atypical Travel detection in Azure Identity Protection is designed to identify instances where a user signs in from two geographically distant locations within a time frame that makes legitimate travel improbable. This anomaly indicates that an attacker may have compromised a user\u0026rsquo;s credentials and is attempting to access resources from a different location. The alert is triggered by the \u0026lsquo;unlikelyTravel\u0026rsquo; risk event type within Azure\u0026rsquo;s risk detection service. This capability helps defenders identify compromised accounts and prevent further damage such as data exfiltration or lateral movement within the environment. The detection is based on comparing current sign-in locations against the user\u0026rsquo;s historical sign-in patterns, making it more accurate and less prone to false positives compared to simple geo-location based alerts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Compromise:\u003c/strong\u003e An attacker obtains a user\u0026rsquo;s credentials through phishing, credential stuffing, or malware.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access (Location A):\u003c/strong\u003e The attacker uses the compromised credentials to sign in from a location that may be atypical for the user.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSuccessful Authentication (Location A):\u003c/strong\u003e The attacker successfully authenticates and gains access to Azure resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation (Optional):\u003c/strong\u003e If the compromised account has sufficient permissions, the attacker attempts to escalate privileges within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement (Optional):\u003c/strong\u003e The attacker uses the compromised account to move laterally to other resources or accounts within the Azure environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSecond Sign-in (Location B):\u003c/strong\u003e Within a short timeframe, the attacker (or another attacker using the same credentials) signs in from a geographically distant location (Location B).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAtypical Travel Alert:\u003c/strong\u003e Azure Identity Protection detects the unlikely travel scenario based on the two geographically improbable sign-ins.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Access/Data Exfiltration:\u003c/strong\u003e The attacker accesses sensitive resources or exfiltrates data from the environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful Atypical Travel attack can lead to unauthorized access to sensitive data, privilege escalation, lateral movement within the Azure environment, and potentially data exfiltration. The number of victims depends on the scope of the compromised user\u0026rsquo;s access and the attacker\u0026rsquo;s objectives. Organizations in all sectors are potentially at risk, as attackers often target user accounts with elevated privileges or access to critical data. The financial impact can include the cost of incident response, data breach notifications, and potential regulatory fines.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect Atypical Travel events (logsource: azure, service: riskdetection).\u003c/li\u003e\n\u003cli\u003eInvestigate flagged sessions in the context of other sign-ins from the user, as suggested by the false positives guidance.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and enforce conditional access policies to restrict access based on location and other factors.\u003c/li\u003e\n\u003cli\u003eMonitor user accounts for unusual activity, such as changes in sign-in patterns or resource access.\u003c/li\u003e\n\u003cli\u003eImplement account lockout policies to prevent brute-force attacks against user accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T18:21:00Z","date_published":"2024-01-02T18:21:00Z","id":"/briefs/2024-01-azure-atypical-travel/","summary":"The Atypical Travel detection in Azure Identity Protection identifies potentially compromised user accounts by detecting geographically improbable sign-in activity, indicative of account compromise or misuse.","title":"Azure Identity Protection Atypical Travel Anomaly","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-atypical-travel/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","privileged-access","role-assignment"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis alert focuses on the addition of users to privileged roles within Azure Active Directory (Azure AD). An attacker who gains initial access to an account may attempt to escalate privileges to gain broader control over the Azure environment. This can be achieved by adding the compromised account or a new attacker-controlled account to a highly privileged role. This activity often occurs after an initial compromise and is a critical step in establishing persistence and expanding access within the target environment. Successful role assignment allows the attacker to perform actions normally restricted to administrators, potentially leading to data exfiltration, service disruption, or further lateral movement. This activity is visible in the Azure Audit Logs.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an Azure AD account through credential phishing or password spraying (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies potential target roles with high privileges within the Azure AD environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to add the compromised account, or a new account under their control, to one of these privileged roles.\u003c/li\u003e\n\u003cli\u003eThe attacker executes an \u0026ldquo;Add eligible member\u0026rdquo; action, either permanent or eligible, within Azure AD, which is logged in the audit logs.\u003c/li\u003e\n\u003cli\u003eAzure AD processes the request and, if successful, grants the new role assignment to the target account.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly acquired privileges to access sensitive resources, modify configurations, or deploy malicious applications.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new administrative accounts or modifying existing configurations to maintain access even if the initial compromised account is remediated.\u003c/li\u003e\n\u003cli\u003eThe attacker performs data exfiltration or causes disruption to the Azure environment based on their objectives.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful addition of a user to a privileged role can grant the attacker complete control over the Azure AD environment. This may allow them to access sensitive data, disrupt critical services, and deploy malicious applications. The impact can range from data breaches and financial loss to complete compromise of the organization\u0026rsquo;s cloud infrastructure. The scope depends on the role assigned, but global administrator roles can cause catastrophic damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;User Added To Privilege Role\u0026rdquo; to your SIEM to detect suspicious role assignments in Azure AD Audit Logs.\u003c/li\u003e\n\u003cli\u003eReview Azure AD audit logs for any \u0026ldquo;Add eligible member\u0026rdquo; events (permanent or eligible) to identify potentially malicious role assignments.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all users, especially those with administrative privileges, to mitigate the risk of initial access compromise (T1110).\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege to limit the scope of access for each user and role (T1068).\u003c/li\u003e\n\u003cli\u003eRegularly audit and review user role assignments to identify and remove unnecessary privileges.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T15:30:00Z","date_published":"2024-01-02T15:30:00Z","id":"/briefs/2024-01-azure-role-assignment/","summary":"Detection of a user being added to a privileged role in Azure AD, potentially indicating privilege escalation or persistence by an attacker.","title":"Azure AD Privileged Role Assignment","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-role-assignment/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["azure","pim","role-assignment","attack.initial-access","attack.stealth","attack.t1078","attack.persistence","attack.privilege-escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThe unauthorized assignment of privileged roles outside of Azure Privileged Identity Management (PIM) represents a significant security risk. Attackers may attempt to bypass PIM controls to gain persistent access, escalate privileges, or move laterally within the Azure environment. Detecting these anomalous role assignments is crucial for identifying potentially compromised accounts or malicious insiders. This activity is a common tactic used by attackers to establish persistence and maintain control over cloud resources. Monitoring for this behavior can help security teams quickly identify and respond to potential breaches, limiting the impact of successful attacks. This activity can be associated with lateral movement, privilege escalation, and persistence within the cloud environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a compromised user account or service principal within the Azure environment.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to identify existing privileged roles and permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker bypasses PIM to directly assign themselves a privileged role (e.g., Global Administrator, Security Administrator) using Azure CLI, PowerShell, or the Azure portal.\u003c/li\u003e\n\u003cli\u003eThe attacker elevates their permissions without triggering PIM alerts or requiring approval.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly assigned privileged role to access sensitive data, modify configurations, or create new resources.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating new accounts or modifying existing ones with elevated privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally to other Azure resources or subscriptions using their increased access.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, service disruption, or deployment of malicious code.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising privileged roles within Azure can have severe consequences, potentially impacting all resources within the affected Azure Active Directory tenant. Successful attacks can lead to unauthorized data access, service disruption, financial loss, and reputational damage. The scope of the impact depends on the level of privilege gained by the attacker and the sensitivity of the targeted resources. Without proper detection and response, organizations may remain unaware of the breach, allowing attackers to maintain persistent access and continue their malicious activities undetected.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u003ccode\u003eRoles Assigned Outside PIM\u003c/code\u003e to your SIEM to detect unauthorized role assignments within your Azure environment.\u003c/li\u003e\n\u003cli\u003eInvestigate all instances flagged by the Sigma rule \u003ccode\u003eRoles Assigned Outside PIM\u003c/code\u003e to determine the legitimacy of the role assignment and the identity of the assigner.\u003c/li\u003e\n\u003cli\u003eImplement controls to restrict the ability to assign privileged roles outside of PIM, as described in the Microsoft documentation reference.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege to minimize the potential impact of compromised accounts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-azure-pim-role-assigned-outside/","summary":"Detection of privilege role assignments outside of Azure Privileged Identity Management (PIM) can indicate potential attacker activity related to initial access, stealth, persistence, or privilege escalation within the Azure environment.","title":"Azure PIM - Role Assignment Outside of Privileged Identity Management","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-pim-role-assigned-outside/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["medium"],"_cs_tags":["azure","federation","privilege-escalation","persistence","initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers can modify federation settings on Azure domains to gain unauthorized access and establish persistence. This involves manipulating the trust relationships between the Azure Active Directory and external identity providers. By altering these settings, an attacker can potentially bypass normal authentication mechanisms, assume identities, and maintain a foothold within the environment. This activity is typically carried out by users or applications with administrative privileges, making it crucial to monitor and validate any changes made to the federation settings. Detecting such modifications can be challenging due to the legitimate use of these settings by system administrators. This activity falls under tactics such as privilege escalation, persistence, initial access, and stealth.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to an account with sufficient privileges to manage Azure Active Directory settings, such as a Global Administrator or Privileged Role Administrator.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses PowerShell/CLI to interact with Azure resources.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing domain federation settings to understand the current configuration and identify potential targets for modification.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the federation settings on the domain using commands like \u003ccode\u003eSet-MsolDomainFederationSettings\u003c/code\u003e or through the Azure portal interface. This may involve altering the trusted certificate, changing the issuer URI, or modifying other federation parameters.\u003c/li\u003e\n\u003cli\u003eThe attacker tests the modified federation settings to ensure they can successfully authenticate using the altered configuration.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified federation settings to impersonate users or applications, gaining unauthorized access to protected resources and services.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating backdoors or alternate authentication methods using the modified federation settings.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of Azure domain federation settings can lead to significant consequences, including unauthorized access to sensitive data, privilege escalation, and long-term persistence within the Azure environment. Attackers could potentially compromise entire domains, impacting all users and applications relying on the affected Azure Active Directory. This can result in data breaches, service disruptions, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Azure Domain Federation Settings Modified\u0026rdquo; to detect suspicious modifications to federation settings in Azure audit logs.\u003c/li\u003e\n\u003cli\u003eRegularly review and validate changes to Azure domain federation settings, focusing on unfamiliar users and unexpected modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure audit logs for the \u0026ldquo;Set federation settings on domain\u0026rdquo; event to identify potential tampering.\u003c/li\u003e\n\u003cli\u003eEnforce multi-factor authentication (MFA) for all accounts with administrative privileges to reduce the risk of unauthorized access.\u003c/li\u003e\n\u003cli\u003eImplement the principle of least privilege, granting users only the necessary permissions to perform their tasks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-azure-federation-modification/","summary":"An attacker may modify Azure domain federation settings to establish persistence, escalate privileges, or gain unauthorized access to resources.","title":"Azure Domain Federation Settings Modified","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-federation-modification/"}],"language":"en","title":"CraftedSignal Threat Feed — Azure","version":"https://jsonfeed.org/version/1.1"}