{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/service_principal/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Microsoft Entra ID","Microsoft Azure"],"_cs_severities":["low"],"_cs_tags":["azure","entra_id","service_principal","persistence"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis rule detects the creation of new service principals within Microsoft Entra ID. Service principals are identities used by applications, services, and automation tools to access specific resources within Azure. While legitimate use of service principals is common for automation and application access, adversaries can create them to establish persistence mechanisms or to masquerade as legitimate services or applications. This activity is often performed to maintain unauthorized access to cloud resources and evade detection by blending in with normal automated processes. Identifying anomalous service principal creation can help prevent malicious actors from maintaining a foothold within an Azure environment. The rule focuses on detecting the \u0026quot;Add service principal\u0026quot; operation within 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 environment through compromised credentials or a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure portal or uses the Azure CLI/PowerShell with the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands to create a new service principal within the Entra ID tenant. This involves assigning a name, application ID, and defining the roles and permissions for the service principal.\u003c/li\u003e\n\u003cli\u003eThe service principal is configured with specific roles, granting it access to various Azure resources.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created service principal to authenticate and access Azure resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the service principal's permissions to perform malicious activities, such as data exfiltration, resource modification, or lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the service principal for long-term persistence, maintaining access even if the initial access vector is remediated.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to maintain persistent access to Azure resources. Depending on the assigned roles and permissions, the attacker can perform a wide range of malicious activities, including data exfiltration, resource manipulation, and further compromise of the environment. The impact is limited to the permissions granted to the created service principal but can be significant if the service principal is assigned highly privileged roles. Since this is an Entra ID event, all organizations utilizing Azure services are potentially in scope.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Entra ID Service Principal Created\u0026quot; to your SIEM and tune for your environment, focusing on excluding known good service principal creation activities (e.g., from automated deployment pipelines).\u003c/li\u003e\n\u003cli\u003eReview and audit existing service principals and their assigned roles regularly to identify any suspicious or unauthorized principals.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Audit Logs for unusual or unauthorized \u0026quot;Add service principal\u0026quot; operations, paying close attention to the identity creating the service principal.\u003c/li\u003e\n\u003cli\u003eFollow Microsoft's security best practices for identity management in Azure (\u003ca href=\"https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices\"\u003ehttps://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices\u003c/a\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-30-entra-id-service-principal-creation/","summary":"An adversary may create a new service principal in Microsoft Entra ID to establish persistence and potentially impersonate legitimate services or applications, blending in with normal activity.","title":"Entra ID Service Principal Creation for Persistence","url":"https://feed.craftedsignal.io/briefs/2024-01-30-entra-id-service-principal-creation/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Microsoft Entra ID"],"_cs_severities":["medium"],"_cs_tags":["azure","entra_id","service_principal","initial_access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies potentially malicious activity within Microsoft Entra ID (formerly Azure AD) by monitoring service principal sign-ins. Specifically, it flags instances where a service principal authenticates from an autonomous system number (ASN) that is not typically associated with that principal within a defined history window (10 days). Attackers compromising service principal credentials or application secrets may attempt to authenticate from unfamiliar networks, such as hosting providers, VPNs, or residential IPs, to gain initial access, move laterally, or deploy ransomware within the tenant. The rule focuses on identifying new network paths for non-interactive workload identities, improving the chances of catching malicious activity early in the attack chain. This detection is based on the Elastic detection rule released on 2026/04/06.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains unauthorized access to service principal credentials or application secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to attempt authentication to Entra ID.\u003c/li\u003e\n\u003cli\u003eThe authentication request originates from an unusual ASN not previously associated with the service principal.\u003c/li\u003e\n\u003cli\u003eEntra ID processes the authentication request and, if successful based on existing policies, grants access.\u003c/li\u003e\n\u003cli\u003eThe service principal, now under attacker control, performs actions based on its assigned permissions. This could include accessing sensitive data, modifying configurations, or escalating privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised service principal to move laterally within the cloud environment, accessing other resources or identities.\u003c/li\u003e\n\u003cli\u003eThe attacker may exfiltrate sensitive data or deploy malicious applications or scripts.\u003c/li\u003e\n\u003cli\u003eThe attacker may deploy ransomware targeting cloud resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging compromised service principal credentials can result in significant damage, including data breaches, service disruptions, and financial losses. The potential impact extends to any resources accessible by the compromised service principal, potentially affecting critical business applications and data. If undetected, this activity can lead to full tenant compromise and significant remediation costs. Lateral movement and privilege escalation can further amplify the impact, affecting more resources and data within the environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eEntra ID Service Principal Sign-in from Unusual ASN\u003c/code\u003e to your SIEM, ensuring it is tuned to exclude known benign ASNs for your service principals.\u003c/li\u003e\n\u003cli\u003eReview sign-in logs for successful authentications by service principals originating from unfamiliar ASNs as per the investigation guide provided in the rule description.\u003c/li\u003e\n\u003cli\u003eImplement conditional access policies to restrict service principal sign-ins to specific networks or locations.\u003c/li\u003e\n\u003cli\u003eRotate application secrets and certificates for any service principal triggering the \u003ccode\u003eEntra ID Service Principal Sign-in from Unusual ASN\u003c/code\u003e detection.\u003c/li\u003e\n\u003cli\u003eMonitor Entra ID audit logs for changes to application permissions, client secrets, or ownership, especially before a suspicious sign-in, as described in the rule's triage steps.\u003c/li\u003e\n\u003cli\u003eEnrich \u003ccode\u003esource.ip\u003c/code\u003e addresses from alerts with threat intelligence data to identify residential or low-reputation ASNs, warranting increased scrutiny.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-entra-id-service-principal-unusual-asn/","summary":"Detects Entra ID service principal sign-ins from a source ASN that is unusual based on a history window, potentially indicating compromised credentials or a rogue application.","title":"Entra ID Service Principal Sign-in from Unusual Source ASN","url":"https://feed.craftedsignal.io/briefs/2024-01-entra-id-service-principal-unusual-asn/"},{"_cs_actors":["NOBELIUM Group"],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Office 365","Azure Active Directory","Microsoft Graph API","SharePoint","OneDrive","Exchange Online"],"_cs_severities":["high"],"_cs_tags":["cloud","o365","service_principal","persistence","azuread"],"_cs_type":"threat","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis threat brief focuses on the detection of newly created service principal accounts within Microsoft Office 365 environments. The creation of service principals is a legitimate administrative function, but malicious actors can exploit them to gain persistent access to cloud resources. Attackers, like the NOBELIUM group, can use compromised or maliciously created service principals to interact with APIs, access sensitive data, and perform unauthorized operations on behalf of the organization. These actions can lead to significant data breaches, lateral movement, and further compromise of the O365 tenant. This activity is often associated with advanced persistent threat (APT) groups targeting cloud environments for long-term access and data exfiltration. The detection strategy leverages O365 management activity logs to identify suspicious creation events, allowing for proactive investigation and mitigation of potential threats.\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 Attacker gains initial access to an O365 account, possibly through phishing or credential stuffing (not directly observed in the provided data, but a common precursor).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates privileges within the compromised account to allow for the creation of service principals.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService Principal Creation:\u003c/strong\u003e A new service principal is created within the Azure Active Directory, using commands or API calls. The creation event is logged within the O365 management activity logs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePermissions Assignment:\u003c/strong\u003e The attacker assigns the newly created service principal with elevated permissions, granting access to critical resources within the O365 environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAPI Access:\u003c/strong\u003e The attacker leverages the service principal to interact with Microsoft Graph API or other O365 APIs, bypassing standard user authentication mechanisms.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker utilizes the API access to exfiltrate sensitive data from various O365 services, such as SharePoint, OneDrive, or Exchange Online.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The service principal acts as a persistent backdoor, allowing the attacker to regain access to the environment even if the initial compromised account is remediated.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack involving a rogue service principal can lead to significant data breaches, with potential exposure of sensitive corporate data, customer information, and intellectual property. The number of victims depends on the permissions assigned to the malicious service principal and the scope of data accessible within the O365 environment. Affected sectors include any organization relying on O365 for business operations, but especially those with sensitive data like finance, healthcare, and government. If the attack succeeds, organizations face reputational damage, financial losses, legal liabilities, and operational disruption.\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 them to reduce false positives based on your organization's normal service principal creation activity (\u003ccode\u003erules\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on the user accounts responsible for creating the service principals and the permissions assigned to them (\u003ccode\u003erules\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable and review O365 Management Activity logs to ensure comprehensive monitoring of service principal creation and modification events (\u003ccode\u003edata_source\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all user accounts, including administrative accounts, to mitigate the risk of initial access through compromised credentials (T1136.003).\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for service principals, limiting their access to only the resources they require (T1136.003).\u003c/li\u003e\n\u003cli\u003eMonitor for anomalous API usage patterns associated with service principals, such as unusual data access or exfiltration activities (T1136.003).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-03-o365-service-principal/","summary":"Detection of new service principal creation in O365 tenants, which can be abused by attackers for unauthorized access, API interaction, and data compromise.","title":"O365 Service Principal Creation Detection","url":"https://feed.craftedsignal.io/briefs/2024-01-03-o365-service-principal/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Entra ID","Azure"],"_cs_severities":["medium"],"_cs_tags":["azure","entra_id","service_principal","persistence","privilege_escalation"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eThis detection identifies when new Service Principal credentials (client secrets or certificates) are added in Microsoft Entra ID by a user who has not previously performed this action in the last 10 days. Attackers who gain access to a user account may add rogue credentials to service principals to maintain unauthorized access to cloud resources, bypassing MFA requirements. This activity may indicate an attacker attempting to establish persistence or escalate privileges within the Azure environment. The rule leverages the \u003ccode\u003eazure.auditlogs\u003c/code\u003e dataset to identify unusual activity related to service principal credential management. This is a New Terms rule that detects rare users performing sensitive identity-related actions in Entra ID.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a user account through compromised credentials or other means (T1078).\u003c/li\u003e\n\u003cli\u003eAttacker identifies a target service principal with valuable permissions within the Azure environment.\u003c/li\u003e\n\u003cli\u003eAttacker navigates to the Entra ID portal or uses Azure CLI/PowerShell to manage the target service principal.\u003c/li\u003e\n\u003cli\u003eAttacker adds a new credential (client secret or certificate) to the service principal using \u003ccode\u003eAdd service principal credentials\u003c/code\u003e operation.\u003c/li\u003e\n\u003cli\u003eThe operation is logged in the Azure Audit Logs with event outcome as success and operation name containing the event.\u003c/li\u003e\n\u003cli\u003eAttacker uses the newly added credential to authenticate as the service principal and access protected resources (T1098.001).\u003c/li\u003e\n\u003cli\u003eAttacker leverages the service principal's permissions to perform unauthorized actions, such as data exfiltration or resource modification.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the environment through the rogue service principal credential.\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 and resources within the Azure environment. The impact includes potential data breaches, financial loss, and reputational damage. By compromising a service principal, attackers can bypass multi-factor authentication (MFA) and other security controls, leading to privilege escalation and lateral movement. If successful, the attacker could access data normally protected by MFA requirements.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;Entra ID Service Principal Credentials Created by Unusual User\u0026quot; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the user account, source IP, and credential type.\u003c/li\u003e\n\u003cli\u003eReview RBAC and Least Privilege: Ensure that only authorized identities have permission to add credentials to service principals (T1098.001).\u003c/li\u003e\n\u003cli\u003eEnable logging for Azure Audit Logs to provide the data source for the Sigma rules.\u003c/li\u003e\n\u003cli\u003eConsider implementing access control policies that require approvals for modifying service principals or adding credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-entra-id-sp-credentials/","summary":"Anomalous addition of credentials to an Entra ID service principal by a user not typically performing this action can indicate potential persistence and privilege escalation by an attacker.","title":"Entra ID Service Principal Credentials Created by Unusual User","url":"https://feed.craftedsignal.io/briefs/2024-01-entra-id-sp-credentials/"}],"language":"en","title":"CraftedSignal Threat Feed - Service_principal","version":"https://jsonfeed.org/version/1.1"}