https://feed.craftedsignal.io/tags/service-principal/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 03 Jan 2024 14:30:00 +0000https://feed.craftedsignal.io/briefs/2024-01-azure-sp-creation/Wed, 03 Jan 2024 14:30:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-azure-sp-creation/Detects the creation of a service principal in Azure, which could indicate potential attacker activity for lateral movement or persistence.The 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 “Add service principal” message within Azure Activity Logs.

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.

]]>mediumadvisoryazurecloudservice principalpersistencelateral movementhttps://feed.craftedsignal.io/briefs/2024-01-azure-service-principal-removed/Wed, 03 Jan 2024 14:27:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-azure-service-principal-removed/Detection of a service principal removal in Azure, potentially indicating malicious activity or an attempt to remove evidence of a compromise.The 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.

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.

]]>mediumadvisoryazureservice principalstealthcloud