<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Service_principal - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/service_principal/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Tue, 30 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/service_principal/feed.xml" rel="self" type="application/rss+xml"/><item><title>Entra ID Service Principal Creation for Persistence</title><link>https://feed.craftedsignal.io/briefs/2024-01-30-entra-id-service-principal-creation/</link><pubDate>Tue, 30 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-30-entra-id-service-principal-creation/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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 &quot;Add service principal&quot; operation within the Azure Audit Logs.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to an Azure environment through compromised credentials or a vulnerability.</li>
<li>The attacker authenticates to the Azure portal or uses the Azure CLI/PowerShell with the compromised account.</li>
<li>The 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.</li>
<li>The service principal is configured with specific roles, granting it access to various Azure resources.</li>
<li>The attacker uses the newly created service principal to authenticate and access Azure resources.</li>
<li>The attacker leverages the service principal's permissions to perform malicious activities, such as data exfiltration, resource modification, or lateral movement.</li>
<li>The attacker uses the service principal for long-term persistence, maintaining access even if the initial access vector is remediated.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;Entra ID Service Principal Created&quot; to your SIEM and tune for your environment, focusing on excluding known good service principal creation activities (e.g., from automated deployment pipelines).</li>
<li>Review and audit existing service principals and their assigned roles regularly to identify any suspicious or unauthorized principals.</li>
<li>Monitor Azure Audit Logs for unusual or unauthorized &quot;Add service principal&quot; operations, paying close attention to the identity creating the service principal.</li>
<li>Follow Microsoft's security best practices for identity management in Azure (<a href="https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices">https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices</a>).</li>
</ul>
]]></content:encoded><category domain="severity">low</category><category domain="type">advisory</category><category>azure</category><category>entra_id</category><category>service_principal</category><category>persistence</category></item><item><title>Entra ID Service Principal Sign-in from Unusual Source ASN</title><link>https://feed.craftedsignal.io/briefs/2024-01-entra-id-service-principal-unusual-asn/</link><pubDate>Wed, 03 Jan 2024 14:30:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-entra-id-service-principal-unusual-asn/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker gains unauthorized access to service principal credentials or application secrets.</li>
<li>The attacker uses the compromised credentials to attempt authentication to Entra ID.</li>
<li>The authentication request originates from an unusual ASN not previously associated with the service principal.</li>
<li>Entra ID processes the authentication request and, if successful based on existing policies, grants access.</li>
<li>The service principal, now under attacker control, performs actions based on its assigned permissions. This could include accessing sensitive data, modifying configurations, or escalating privileges.</li>
<li>The attacker leverages the compromised service principal to move laterally within the cloud environment, accessing other resources or identities.</li>
<li>The attacker may exfiltrate sensitive data or deploy malicious applications or scripts.</li>
<li>The attacker may deploy ransomware targeting cloud resources.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule <code>Entra ID Service Principal Sign-in from Unusual ASN</code> to your SIEM, ensuring it is tuned to exclude known benign ASNs for your service principals.</li>
<li>Review sign-in logs for successful authentications by service principals originating from unfamiliar ASNs as per the investigation guide provided in the rule description.</li>
<li>Implement conditional access policies to restrict service principal sign-ins to specific networks or locations.</li>
<li>Rotate application secrets and certificates for any service principal triggering the <code>Entra ID Service Principal Sign-in from Unusual ASN</code> detection.</li>
<li>Monitor 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.</li>
<li>Enrich <code>source.ip</code> addresses from alerts with threat intelligence data to identify residential or low-reputation ASNs, warranting increased scrutiny.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>azure</category><category>entra_id</category><category>service_principal</category><category>initial_access</category></item><item><title>O365 Service Principal Creation Detection</title><link>https://feed.craftedsignal.io/briefs/2024-01-03-o365-service-principal/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-03-o365-service-principal/</guid><description>Detection of new service principal creation in O365 tenants, which can be abused by attackers for unauthorized access, API interaction, and data compromise.</description><content:encoded><![CDATA[<p>This 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li><strong>Initial Access:</strong> 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).</li>
<li><strong>Privilege Escalation:</strong> The attacker escalates privileges within the compromised account to allow for the creation of service principals.</li>
<li><strong>Service Principal Creation:</strong> 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.</li>
<li><strong>Permissions Assignment:</strong> The attacker assigns the newly created service principal with elevated permissions, granting access to critical resources within the O365 environment.</li>
<li><strong>API Access:</strong> The attacker leverages the service principal to interact with Microsoft Graph API or other O365 APIs, bypassing standard user authentication mechanisms.</li>
<li><strong>Data Exfiltration:</strong> The attacker utilizes the API access to exfiltrate sensitive data from various O365 services, such as SharePoint, OneDrive, or Exchange Online.</li>
<li><strong>Persistence:</strong> 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.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the provided Sigma rules to your SIEM and tune them to reduce false positives based on your organization's normal service principal creation activity (<code>rules</code>).</li>
<li>Investigate any alerts generated by the Sigma rules, focusing on the user accounts responsible for creating the service principals and the permissions assigned to them (<code>rules</code>).</li>
<li>Enable and review O365 Management Activity logs to ensure comprehensive monitoring of service principal creation and modification events (<code>data_source</code>).</li>
<li>Implement multi-factor authentication (MFA) for all user accounts, including administrative accounts, to mitigate the risk of initial access through compromised credentials (T1136.003).</li>
<li>Review and enforce the principle of least privilege for service principals, limiting their access to only the resources they require (T1136.003).</li>
<li>Monitor for anomalous API usage patterns associated with service principals, such as unusual data access or exfiltration activities (T1136.003).</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">threat</category><category>cloud</category><category>o365</category><category>service_principal</category><category>persistence</category><category>azuread</category></item><item><title>Entra ID Service Principal Credentials Created by Unusual User</title><link>https://feed.craftedsignal.io/briefs/2024-01-entra-id-sp-credentials/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-entra-id-sp-credentials/</guid><description>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.</description><content:encoded><![CDATA[<p>This 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 <code>azure.auditlogs</code> 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker gains initial access to a user account through compromised credentials or other means (T1078).</li>
<li>Attacker identifies a target service principal with valuable permissions within the Azure environment.</li>
<li>Attacker navigates to the Entra ID portal or uses Azure CLI/PowerShell to manage the target service principal.</li>
<li>Attacker adds a new credential (client secret or certificate) to the service principal using <code>Add service principal credentials</code> operation.</li>
<li>The operation is logged in the Azure Audit Logs with event outcome as success and operation name containing the event.</li>
<li>Attacker uses the newly added credential to authenticate as the service principal and access protected resources (T1098.001).</li>
<li>Attacker leverages the service principal's permissions to perform unauthorized actions, such as data exfiltration or resource modification.</li>
<li>The attacker maintains persistent access to the environment through the rogue service principal credential.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;Entra ID Service Principal Credentials Created by Unusual User&quot; to your SIEM and tune for your environment.</li>
<li>Investigate any alerts generated by the Sigma rule by reviewing the user account, source IP, and credential type.</li>
<li>Review RBAC and Least Privilege: Ensure that only authorized identities have permission to add credentials to service principals (T1098.001).</li>
<li>Enable logging for Azure Audit Logs to provide the data source for the Sigma rules.</li>
<li>Consider implementing access control policies that require approvals for modifying service principals or adding credentials.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>azure</category><category>entra_id</category><category>service_principal</category><category>persistence</category><category>privilege_escalation</category></item></channel></rss>