Attack Chain

Since the advisory lacks specifics, we will describe a generalized attack chain based on the potential vulnerabilities:

1. Initial Access: The attacker gains initial access to a target environment, possibly through compromised credentials or a separate vulnerability.
2. Privilege Escalation: The attacker exploits a vulnerability within one of the Microsoft cloud products (Azure, Microsoft 365 Copilot, Dynamics 365, or Power Apps) to elevate their privileges to a higher level, potentially gaining administrative rights.
3. Code Injection: Leveraging the escalated privileges, the attacker injects malicious code into a vulnerable component of the cloud service.
4. Code Execution: The injected code is executed, allowing the attacker to perform arbitrary actions within the context of the compromised service.
5. Lateral Movement: The attacker uses the compromised service as a pivot point to move laterally within the cloud environment, targeting other resources and services.
6. Data Exfiltration/Manipulation: Once established within the environment, the attacker exfiltrates sensitive data or manipulates data for malicious purposes.
7. Spoofing Attacks: The attacker leverages the compromised environment to launch spoofing attacks, potentially targeting other users or systems with phishing emails or other deceptive tactics.
8. Persistence: The attacker establishes persistence within the cloud environment to maintain access even after the initial vulnerability is patched.

Impact

Successful exploitation of these vulnerabilities could have significant consequences, including unauthorized access to sensitive data, disruption of critical business processes, and financial losses. The number of potential victims is substantial, given the widespread use of Microsoft cloud services across various sectors. A successful attack could result in data breaches, service outages, and reputational damage.

Recommendation

• Monitor logs from Microsoft Azure, Microsoft 365 Copilot, Microsoft Dynamics 365, and Microsoft Power Apps for suspicious activity indicative of privilege escalation, code execution, and spoofing attacks.
• Enable and review audit logs within the affected Microsoft cloud services to identify anomalous user behavior and potential security breaches.
• Deploy the Sigma rules provided in this brief to your SIEM and tune them for your specific environment to detect potential exploitation attempts.
• Follow Microsoft’s official security advisories and apply any available patches or mitigations as soon as they are released.

Attack Chain

1. An attacker gains initial access to a user’s credentials through phishing, malware, or other means (T1566, T1190).
2. The attacker configures a browser with the stolen credentials.
3. The 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.
4. Azure Identity Protection detects the “suspiciousBrowser” risk event based on the anomalous sign-in activity.
5. If successful, the attacker may gain access to sensitive data and resources within the targeted tenants.
6. The attacker leverages the compromised accounts to escalate privileges and move laterally within the organization (T1078, T1068).
7. The attacker exfiltrates sensitive data or deploy ransomware (T1003, T1486).

Impact

A 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.

Recommendation

• Deploy the provided Sigma rule to detect “suspiciousBrowser” risk events in your Azure environment and tune for your environment.
• Investigate sessions flagged by this detection in the context of other sign-ins from the same user to identify false positives.
• Enforce multi-factor authentication (MFA) to mitigate the impact of compromised credentials.
• Monitor user sign-in activity for unusual patterns, such as sign-ins from multiple geographical locations within a short period.

Attack Chain

1. Initial access to the Azure environment is gained, potentially through credential phishing or other means.
2. The attacker identifies a target user account with sufficient privileges.
3. The attacker accesses the Azure Active Directory (Azure AD) settings for the compromised user.
4. The attacker navigates to the “Security info” section of the user’s profile.
5. The 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 “User registered security info”.
6. The attacker can now use the newly added authentication method to bypass multi-factor authentication.
7. The attacker leverages the compromised account to access sensitive data, applications, or resources within the Azure environment.
8. The attacker maintains persistent access to the Azure environment, even if the original account password is changed.

Impact

Successful 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.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect changes to authentication methods within Azure audit logs (logsource: azure, service: auditlogs).
• Investigate any instances where the OperationName is User registered security info in the Azure Audit Logs, as this indicates a change in authentication method.
• Review the referenced Microsoft documentation on privileged account security to understand best practices for securing administrative accounts (references).

Attack Chain

1. The attacker identifies an Azure environment lacking a valid Microsoft Entra Premium P2 or Microsoft Entra ID Governance license for Privileged Identity Management (PIM).
2. The attacker attempts to activate a privileged role within the Azure environment through PIM.
3. Due to the invalid license, the PIM activation process may not enforce proper multi-factor authentication (MFA) or approval workflows.
4. The attacker gains unauthorized access to the privileged role without proper authorization or auditing.
5. The attacker leverages the compromised privileged role to access sensitive Azure resources, such as virtual machines, databases, or storage accounts.
6. The attacker performs malicious actions, such as data exfiltration, modification of system configurations, or deployment of malware.
7. The attacker attempts to establish persistence within the Azure environment by creating rogue user accounts or modifying existing access controls.

Impact

The 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.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect invalidLicenseAlertIncident events in Azure PIM logs (logsource: azure, service: pim).
• Investigate any detected instances of invalidLicenseAlertIncident to determine the scope of the issue and potential unauthorized access.
• Verify that all Azure subscriptions utilizing PIM have valid Microsoft Entra Premium P2 or Microsoft Entra ID Governance licenses.
• Implement automated monitoring to proactively identify and alert on invalid PIM licenses.

Attack Chain

1. Attacker gains initial access to an Azure environment, possibly through compromised credentials or exploiting a vulnerability in an application.
2. Attacker escalates privileges within the Azure subscription to gain permissions to manage network resources, including firewalls.
3. Attacker identifies the Azure firewalls in the target environment using Azure Resource Manager APIs or the Azure portal.
4. Attacker 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 MICROSOFT.NETWORK/AZUREFIREWALLS/WRITE operation.
5. Alternatively, the attacker deletes the Azure firewall using the MICROSOFT.NETWORK/AZUREFIREWALLS/DELETE operation, effectively removing network protections.
6. Attacker validates that their changes have been successfully applied by testing network connectivity or by reviewing the firewall configuration.
7. Attacker performs malicious activities such as lateral movement, data exfiltration, or deploying additional resources without firewall restrictions.

Impact

Successful 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.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized firewall modifications or deletions in Azure Activity Logs.
• Investigate any alerts triggered by the Sigma rule, focusing on unfamiliar user identities and user agents.
• Review 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.
• Monitor Azure Activity Logs for other suspicious activities, such as unusual resource deployments or changes to security settings.

Attack Chain

1. An attacker gains initial access to a low-privileged Azure account, possibly through credential phishing or password reuse.
2. The attacker attempts to activate a privileged role (e.g., Global Administrator, Security Administrator) through Azure PIM.
3. The PIM request triggers an approval workflow, requiring authorization from designated approvers.
4. An attacker compromises an approver account, enabling them to approve their own malicious PIM request or deny a legitimate one.
5. Alternatively, an unwitting approver approves a malicious request, potentially due to social engineering.
6. Upon approval, the attacker’s account is temporarily elevated to the requested privileged role.
7. The attacker leverages the elevated privileges to perform malicious actions, such as creating new accounts, modifying security policies, or accessing sensitive data.
8. The attacker attempts to maintain persistence by creating backdoor accounts or modifying access controls, potentially circumventing PIM restrictions.

Impact

Successful 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.

Recommendation

• Deploy the Sigma rule Azure PIM Elevation Approved or Denied to your SIEM to detect unusual PIM activity.
• Investigate any PIM approval or denial events occurring outside of normal business hours or originating from unexpected locations, focusing on the properties.message field in the logs.
• Implement multi-factor authentication (MFA) for all Azure accounts, especially those with approval permissions for PIM requests.
• Regularly review and audit PIM role assignments and approval workflows to ensure they align with the principle of least privilege.
• Enable alerting on changes to PIM policies and configurations to detect any unauthorized modifications.
• Monitor Azure Audit Logs for suspicious activity following PIM role activation, looking for actions associated with common attack techniques (e.g., account creation, policy modification).

Attack Chain

1. An attacker gains initial access to a user account, potentially through phishing or credential stuffing.
2. The attacker identifies a privileged role within Azure PIM that the compromised user is eligible to activate.
3. The attacker attempts to activate the privileged role using the compromised user’s credentials.
4. Due to misconfiguration, MFA is not required for the role activation process.
5. The attacker successfully activates the privileged role without providing a second factor of authentication.
6. The attacker leverages the newly acquired privileges to access sensitive resources and data within the Azure environment.
7. The attacker performs malicious actions such as creating new accounts, modifying configurations, or exfiltrating data.
8. The attacker establishes persistence by creating backdoors or modifying access control policies.

Impact

The 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.

Recommendation

• Deploy the Sigma rule “Roles Activation Doesn’t Require MFA” to your SIEM and tune for your environment to detect instances where privileged roles are activated without MFA based on riskEventType: 'noMfaOnRoleActivationAlertIncident' in Azure PIM logs.
• Review and enforce MFA policies for all privileged role activations within Azure PIM, as recommended in the Microsoft documentation (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).

Attack Chain

1. Initial Access: An attacker gains unauthorized access to an Azure account, potentially through compromised credentials or exploiting a vulnerability in an application.
2. Privilege Escalation (Optional): The attacker escalates their privileges within the Azure environment to gain sufficient permissions to manage and delete applications.
3. Reconnaissance: The attacker identifies target applications for deletion, potentially those critical for business operations or those used for security controls.
4. Disable Monitoring (Optional): The attacker attempts to disable logging or monitoring related to application management to avoid detection.
5. Application Deletion: The attacker initiates the deletion of the targeted application using the Azure portal, Azure CLI, or PowerShell.
6. Confirmation/Hard Delete: Depending on the application’s configuration and Azure policies, the attacker may need to confirm the deletion or perform a “hard delete” to permanently remove the application.
7. Cover Tracks: The attacker attempts to remove any remaining logs or traces of their activity to hinder forensic investigation.
8. Impact: Service disruption or data loss due to the deleted application.

Impact

The 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’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.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect application deletion events in Azure Activity Logs.
• Review user roles and permissions in Azure Active Directory (Entra ID) and enforce the principle of least privilege.
• Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges.
• Enable auditing and logging for all Azure resources, including application management activities.
• Investigate any detected application deletion events promptly to determine the root cause and potential impact.
• Establish a process for reviewing and approving application deletion requests to prevent accidental or malicious deletions.

Attack Chain

1. An attacker gains initial access to an Azure account, possibly through compromised credentials or exploiting a vulnerability.
2. The attacker attempts to assign the ‘User Access Administrator’ role to themselves or another account they control.
3. This assignment generates an ‘Administrative’ audit log event with the OperationName ‘Assigns the caller to user access admin’.
4. The attacker now has the ability to manage user access to all Azure subscriptions within the tenant.
5. The attacker creates new user accounts with elevated privileges within the subscriptions.
6. The attacker leverages the newly created accounts to access sensitive resources and data.
7. The attacker performs reconnaissance activities to identify critical assets and data stores.
8. The attacker exfiltrates sensitive data or deploys malicious workloads within the compromised subscriptions.

Impact

A successful privilege escalation to the ‘User Access Administrator’ role can have severe consequences. It grants the attacker complete control over the Azure subscriptions, allowing them to access sensitive data, disrupt services, and potentially compromise the entire cloud environment. The number of affected subscriptions depends on the scope of the compromised account. This attack targets any organization utilizing Azure subscriptions and is particularly impactful for those storing sensitive data or running critical applications in the cloud.

Recommendation

• Deploy the provided Sigma rule “Azure Subscription Permission Elevation Via AuditLogs” to your SIEM and tune it for your environment to detect the ‘Assigns the caller to user access admin’ event in the Azure Audit Logs.
• Investigate any detected instances of this event to determine if the privilege elevation was authorized and legitimate.
• Review and enforce the principle of least privilege for all Azure accounts to minimize the impact of potential compromises; reference the Microsoft Entra documentation for guidance.
• Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to prevent unauthorized access via compromised credentials.

Attack Chain

1. Initial Compromise: An attacker compromises a low-privilege user account through phishing or credential stuffing.
2. Privilege Escalation: The attacker attempts to elevate privileges by exploiting misconfigured permissions or vulnerabilities within the Azure environment.
3. Global Admin Role Assignment: The attacker assigns the Global Administrator role to multiple accounts, including the compromised account, either directly or through PIM bypass.
4. Lateral Movement: With Global Administrator privileges, the attacker moves laterally within the Azure environment, accessing sensitive resources and data.
5. Data Exfiltration: The attacker exfiltrates sensitive data from cloud storage, databases, or virtual machines.
6. Persistence: The attacker establishes persistent access by creating backdoors, modifying access controls, or deploying rogue applications.
7. Covering Tracks: The attacker attempts to remove audit logs or disable security features to hide their activity.

Impact

The 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.

Recommendation

• Deploy the Sigma rule “Too Many Global Admins” to your SIEM and tune the threshold for your environment to detect excessive Global Administrator assignments in Azure PIM.
• Review and reduce the number of Global Administrator accounts to the minimum necessary.
• Implement multi-factor authentication (MFA) for all privileged accounts.
• Monitor Azure audit logs for suspicious activity related to role assignments and privilege elevation.
• Regularly review and update PIM policies to ensure appropriate access controls.

Attack Chain

1. An attacker gains initial access to an Azure account, possibly through compromised credentials or a vulnerable application.
2. The attacker authenticates to the Azure portal or uses Azure CLI with the compromised credentials.
3. The attacker executes commands to create a new service principal using tools like Azure CLI or PowerShell.
4. Azure Activity Logs record the “Add service principal” event.
5. The attacker assigns roles and permissions to the newly created service principal, granting it access to specific resources.
6. The attacker leverages the service principal for lateral movement, accessing resources or services within the Azure environment.
7. The service principal is used for persistence, allowing the attacker to maintain access even if the initial access method is revoked.

Impact

Successful 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.

Recommendation

• Deploy the Sigma rule “Azure Service Principal Created” to your SIEM and tune for your environment to detect suspicious service principal creations.
• Investigate any alerts generated by the “Azure Service Principal Created” rule (logsource: azure) by verifying the user identity, user agent, and hostname associated with the event.
• Review and audit existing service principals and their assigned permissions to identify any anomalies or overly permissive configurations.
• Implement multi-factor authentication (MFA) for all user accounts to reduce the risk of credential compromise and unauthorized access.

Attack Chain

1. The attacker gains unauthorized access to an Azure account through compromised credentials or other means.
2. The attacker identifies a service principal used for malicious purposes or to maintain persistence.
3. The attacker attempts to remove the service principal to evade detection or disrupt incident response efforts.
4. The 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.
5. The Azure Activity Logs record an event with the message “Remove service principal”.
6. The detection rule triggers based on the “Remove service principal” message in the Azure Activity Logs.
7. Security analysts investigate the event, examining the user identity, user agent, and hostname associated with the removal.
8. If the removal is deemed unauthorized or suspicious, further incident response procedures are initiated.

Impact

Successful 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.

Recommendation

• Deploy the Sigma rule “Azure Service Principal Removed” to your SIEM and tune for your environment, focusing on identifying legitimate administrator activity to reduce false positives.
• Investigate any detected instance of service principal removal, focusing on the user identity, user agent, and hostname from the Azure Activity Logs to determine legitimacy.
• Review Azure AD audit logs for related activities occurring before and after the service principal removal.

Attack Chain

1. An administrator assigns a privileged role to a user within Azure PIM.
2. The user is granted the role but does not activate or use it to perform any privileged actions.
3. Azure PIM monitors role usage and detects the lack of activity for the assigned role.
4. The “redundantAssignmentAlertIncident” event is triggered within the Azure PIM logs.
5. An attacker gains access to the user’s account through credential compromise or other means.
6. The attacker activates the unused privileged role.
7. The attacker leverages the now-active privileged role to perform unauthorized actions, such as modifying system configurations, accessing sensitive data, or escalating privileges further.
8. The attacker achieves their objective, such as data exfiltration or system compromise, without being detected due to the pre-existing role assignment.

Impact

The 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’s objectives. Failure to identify and address these unused roles can also result in unnecessary license costs and increased attack surface.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect redundantAssignmentAlertIncident events indicating unused PIM roles in Azure (see “Roles Are Not Being Used” rule).
• Investigate all detected instances of unused PIM roles to determine the reason for inactivity and potential risks.
• Revoke the assigned role if the user no longer requires it, or provide training and guidance to ensure proper role utilization.
• Review and refine PIM role assignment policies to minimize the allocation of unnecessary privileges.
• Implement regular audits of PIM role assignments to identify and address unused roles promptly.
• Configure security alerts within Azure PIM to receive notifications about unused roles and other potential security incidents.

Attack Chain

1. An internal user (either compromised or malicious) attempts to invite an external guest user via the Azure portal or API.
2. The Azure Active Directory service checks the inviter’s permissions against the organization’s guest invitation policies.
3. The system determines the user lacks the necessary permissions to invite guest users.
4. Azure Audit Logs record the “Invite external user” event with a “failure” status.
5. The failed invitation attempt is blocked, preventing the external user from gaining access.
6. The attacker may retry the invitation with different accounts or methods, attempting to bypass access controls.
7. If successful through other means (not detected by this rule), the guest user could be used for lateral movement or data exfiltration.

Impact

A 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.

Recommendation

• Deploy the Sigma rule “Guest User Invited By Non Approved Inviters” to your SIEM to detect unauthorized invitation attempts within Azure Audit Logs.
• Investigate any alerts generated by the Sigma rule to determine the legitimacy of the invitation attempt and the intent of the user.
• Review and enforce the principle of least privilege for user roles and permissions within Azure Active Directory.
• Monitor for repeated failed invitation attempts from the same user account (correlate with the Azure Audit Logs data).

Attack Chain

1. An attacker gains initial access to a Linux system through various means, such as exploiting a vulnerability or compromising credentials.
2. The attacker uses a utility like cp, cat, or curl to access sensitive files such as /var/run/secrets/kubernetes.io/serviceaccount/token or /root/.ssh/id_rsa.
3. Auditd logs the file access event, capturing details about the process, user, and file path.
4. The detection rule identifies the suspicious process based on its name, executable path (e.g., /tmp/*), or command-line arguments.
5. The rule checks if the accessed file is in the list of sensitive identity files.
6. If both conditions are met, the rule triggers an alert, indicating potential unauthorized access to sensitive credentials.
7. The attacker exfiltrates the stolen credentials or uses them to move laterally within the network.
8. The attacker uses the stolen credentials to access cloud resources or other sensitive systems.

Impact

Successful exploitation can lead to the compromise of sensitive credentials, allowing attackers to gain unauthorized access to critical systems and data. This can result in data breaches, service disruptions, and financial losses. The targeted files contain credentials for Kubernetes clusters, cloud environments (AWS, Azure, Google Cloud), and SSH keys, potentially impacting a wide range of resources. The impact is particularly severe in environments where these credentials are used for managing critical infrastructure or accessing sensitive data.

Recommendation

• Deploy the Auditd Manager integration with the specified audit rules in the provided setup steps to monitor access to sensitive identity files on Linux systems. Ensure auditd is properly configured and running (auditctl -l) to generate the necessary logs.
• Deploy the Sigma rules provided to detect suspicious processes accessing sensitive identity files and tune them for your environment by excluding legitimate processes or users as needed.
• Investigate alerts generated by the Sigma rules, focusing on the process name, executable, parent command line, and the accessed file path to determine the legitimacy of the access.
• Review and harden file permissions on shared credential stores to prevent unauthorized access. Rotate exposed keys and tokens and invalidate cloud sessions if a compromise is suspected, as suggested in the rule’s documentation.

Attack Chain

1. Initial Access: The attacker gains initial access to an Azure account, potentially through compromised credentials or exploiting a vulnerability.
2. Privilege Escalation: The attacker attempts to escalate privileges within the Azure Active Directory, potentially by exploiting misconfigured roles or vulnerabilities.
3. PIM Access: The attacker accesses the Azure Privileged Identity Management (PIM) service.
4. Alert Configuration Discovery: The attacker enumerates existing PIM alert configurations to identify the alerts to be disabled.
5. Alert Modification: The attacker modifies the alert settings, setting them to disabled. This is often done through the Azure portal or via API calls.
6. Persistence: With alerts disabled, the attacker can maintain persistence by assigning themselves privileged roles without generating notifications.
7. Lateral Movement: The attacker leverages the newly acquired privileged roles to move laterally within the Azure environment, accessing sensitive resources and data.

Impact

Disabling PIM alerts significantly reduces an organization’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.

Recommendation

• Deploy the provided Sigma rule to detect instances where PIM alerts are disabled by monitoring auditlogs for properties.message: Disable PIM Alert.
• Regularly review PIM alert configurations to ensure critical alerts are enabled and properly configured.
• Implement multi-factor authentication (MFA) for all user accounts, especially those with administrative privileges, to mitigate initial access (T1078).
• Enforce the principle of least privilege to limit the scope of potential damage from compromised accounts.
• Monitor Azure audit logs for unusual activity related to PIM configuration changes.

Attack Chain

1. Initial Access: An attacker gains initial access to an Azure account, possibly through compromised credentials (T1078).
2. Privilege Discovery: The attacker identifies available privileged roles within Azure PIM.
3. Role Activation Request: The attacker initiates a request to activate a privileged role.
4. Role Activation: The attacker successfully activates the privileged role.
5. Resource Access: With the activated role, the attacker accesses sensitive resources or performs privileged actions.
6. Repeated Activation: The attacker deactivates and reactivates the same role shortly after, potentially to bypass monitoring or maintain persistent access.
7. Lateral Movement (Optional): The attacker uses the elevated privileges to move laterally within the Azure environment.
8. Data Exfiltration or System Damage (Impact): The attacker achieves their ultimate objective, such as exfiltrating sensitive data or causing damage to systems.

Impact

Successful exploitation could lead to unauthorized access to critical resources, data breaches, and significant damage to the organization’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.

Recommendation

• Deploy the Sigma rule “Roles Activated Too Frequently” to your SIEM and tune it based on your environment to reduce false positives (logsource: azure, service: pim).
• Investigate any alerts generated by the Sigma rule “Roles Activated Too Frequently”, focusing on the context of the role activated and the user involved.
• Review 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 falsepositives section.
• Implement multi-factor authentication (MFA) for all users, especially those with privileged roles, to mitigate the risk of credential compromise (T1078).
• Monitor Azure Active Directory sign-in logs for suspicious activity, such as logins from unusual locations or devices.
• Implement least privilege principles and regularly review role assignments to minimize the attack surface.

Attack Chain

1. An attacker gains initial access to an Azure environment, possibly through compromised credentials (T1078.004).
2. The attacker leverages their access to enumerate existing accounts and roles within the Azure Active Directory.
3. The attacker attempts to create a new user account with elevated privileges, such as Global Administrator or other custom administrative roles.
4. The 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 “Add member to role”.
5. The attacker uses the newly created privileged account to perform reconnaissance, identify sensitive data, or deploy malicious applications.
6. The attacker establishes persistence by maintaining access through the newly created account, even if the initial entry point is detected and remediated.
7. The attacker escalates privileges to gain control over critical resources and services within the Azure environment.
8. The attacker uses the privileged account to exfiltrate sensitive data, deploy ransomware, or disrupt critical business operations.

Impact

Successful 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.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect privileged account creation events within Azure Audit Logs.
• Investigate any detected instances of privileged account creation to determine whether the activity is legitimate.
• Implement multi-factor authentication (MFA) for all user accounts, especially those with privileged roles, to mitigate the risk of credential compromise (T1110).
• Regularly review and audit user account privileges to identify and remove unnecessary or excessive permissions.
• Monitor Azure Audit Logs for suspicious activities, such as unusual sign-in attempts, changes to security settings, and modifications to privileged roles.
• Implement alerting for changes to privileged roles and groups within Azure AD.

Attack Chain

1. The attacker gains initial access to an Azure account, potentially through compromised credentials (T1078.004).
2. The attacker authenticates to the Azure portal or uses Azure CLI/PowerShell with the compromised account.
3. The attacker attempts to elevate their permissions using the MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION operation.
4. Azure Activity Logs record the attempt to elevate permissions.
5. If successful, the attacker gains management access to all Azure subscriptions within the tenant.
6. The attacker can then provision resources, modify configurations, and access data within those subscriptions.
7. The attacker might establish persistence by creating new user accounts with elevated privileges or modifying existing roles.
8. The attacker can then exfiltrate sensitive data or disrupt services within the Azure environment.

Impact

Successful 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.

Recommendation

• Deploy the provided Sigma rule to your SIEM to detect unauthorized MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION operations in Azure Activity Logs.
• Investigate any detected instances of MICROSOFT.AUTHORIZATION/ELEVATEACCESS/ACTION immediately, as outlined in the rule description.
• Implement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise.
• Review and enforce the principle of least privilege for Azure role assignments.
• Monitor Azure Activity Logs for other suspicious activities, such as unusual resource creation or modification.

Attack Chain

1. The attacker gains initial access to an Azure account through compromised credentials or by exploiting a vulnerability.
2. The attacker enumerates available applications and service principals within the Azure environment to identify potential targets.
3. The attacker identifies an application or service principal with elevated permissions that would be beneficial to compromise.
4. The attacker attempts to remove the existing owner from the target application or service principal via the Azure portal, PowerShell, or Azure CLI.
5. The Azure Activity Logs record an event indicating “Remove owner from service principal” or “Remove owner from application”.
6. If 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.
7. The attacker leverages the compromised application or service principal to access sensitive resources, exfiltrate data, or deploy malicious workloads.

Impact

Successful 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.

Recommendation

• Deploy the Sigma rule “Azure Owner Removed From Application or Service Principal” to your SIEM and tune for your environment to detect suspicious owner removal activity in Azure Activity Logs.
• Investigate any alerts generated by the Sigma rule, focusing on unfamiliar user identities and unusual user agents in the Azure Activity Logs.
• Implement multi-factor authentication (MFA) for all Azure accounts to reduce the risk of credential compromise, which is often the initial access vector.
• Regularly review and audit the permissions assigned to applications and service principals to identify and remediate any excessive or unnecessary privileges.

Attack Chain

1. An attacker gains unauthorized access to a user’s Azure account, potentially through credential theft or phishing (T1140).
2. The attacker authenticates to the user’s Microsoft 365 account.
3. The attacker creates a new inbox rule or modifies an existing one using the Exchange admin center, PowerShell, or the Microsoft Graph API.
4. The rule is configured to automatically delete emails containing specific keywords related to financial transactions or security alerts (T1566).
5. Alternatively, the rule might forward all emails from specific internal addresses to an external account controlled by the attacker.
6. The attacker uses the manipulated inbox to conceal their activities, such as unauthorized financial transactions or data exfiltration.
7. The legitimate user remains unaware of the attacker’s actions due to the automatic deletion or redirection of relevant emails.
8. The attacker maintains persistence by ensuring the inbox rule remains active and undetected, allowing for continued unauthorized access and activity.

Impact

Successful exploitation allows attackers to conceal malicious activity within the compromised account, intercept sensitive information, and maintain persistence. This can lead to significant financial losses due to BEC, data breaches, and reputational damage. Undetected inbox manipulation can also hinder incident response efforts by preventing security teams from identifying and containing the attack in a timely manner.

Recommendation

• Deploy the Sigma rule “Suspicious Inbox Manipulation Rules” to your SIEM and tune the falsepositives list with known good inbox rule behaviors in your organization.
• Investigate any triggered alerts by examining the details of the created/modified inbox rules, focusing on their conditions and actions.
• Review user sign-in logs for unusual activity preceding the creation of suspicious inbox rules, as described in the Microsoft documentation (https://learn.microsoft.com/en-us/entra/architecture/security-operations-user-accounts#unusual-sign-ins).

Attack Chain

1. An attacker compromises a low-privilege user account within the Azure AD tenant or uses existing compromised credentials.
2. The attacker attempts to invite an external guest user to the tenant using the compromised account.
3. The Azure AD audit logs record the “Invite external user” operation under the UserManagement category.
4. The audit log event is generated, capturing details such as the user who initiated the invitation (InitiatedBy) and the target guest user’s information.
5. The detection logic evaluates if the InitiatedBy user is within the list of approved guest inviters.
6. If the inviting user is not on the approved list, the detection rule triggers, indicating a potentially unauthorized guest invitation.
7. The attacker may then attempt to leverage the newly invited guest account for lateral movement or data exfiltration.
8. The attacker uses the guest account to access resources and data within the Azure AD environment, potentially leading to data breaches or other security incidents.

Impact

The successful exploitation of this vulnerability can lead to unauthorized access to sensitive data and resources within the Azure AD tenant. While the precise number of potential victims is unknown, the impact could range from a limited breach affecting a small set of resources to a widespread compromise impacting the entire organization. The addition of unauthorized guest accounts can facilitate lateral movement, data exfiltration, and other malicious activities, leading to significant financial and reputational damage.

Recommendation

• Implement the provided Sigma rule to detect unauthorized guest user invitations in Azure AD audit logs and tune the filter with a list of approved inviters.
• Review and restrict the number of users authorized to invite guest users to the Azure AD tenant based on business needs.
• Implement multi-factor authentication (MFA) for all user accounts, including guest accounts, to prevent unauthorized access (related to audit logs).
• Regularly audit Azure AD logs for any suspicious activity related to user management (related to audit logs).