security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Rule Tuning] Tuning Azure Service Principal Credentials Added (#4570)

Browse Source 
* tuning 'Azure Service Principal Credentials Added'

* updated patch version

* added investigation guide

* updating patch version

* updating patch version
This commit is contained in:
Terrance DeJesus
2025-04-16 13:58:17 -04:00
committed by GitHub
parent 1a6669e5a6
commit ba16e27edb
8 changed files with 235 additions and 93 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/azure/impact_azure_service_principal_credentials_added.toml
-92
View File
@@ -1,92 +0,0 @@
[metadata]
creation_date = "2021/05/05"
integration = ["azure"]
maturity = "production"
updated_date = "2025/01/15"
[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies when new Service Principal credentials have been added in Azure. In most organizations, credentials will be
added to service principals infrequently. Hijacking an application (by adding a rogue secret or certificate) with
granted permissions will allow the attacker to access data that is normally protected by MFA requirements.
"""
false_positives = [
"""
Service principal credential additions may be done by a system or network administrator. Verify whether the
username, hostname, and/or resource name should be making changes in your environment. Credential additions from
unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
from the rule.
""",
]
from = "now-25m"
index = ["filebeat-*", "logs-azure*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Azure Service Principal Credentials Added"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Azure Service Principal Credentials Added
Azure Service Principals are identities used by applications or services to access Azure resources securely. They are typically granted specific permissions, and credentials are rarely updated. Adversaries may exploit this by adding unauthorized credentials, gaining access to sensitive data without triggering MFA. The detection rule monitors audit logs for successful additions of service principal credentials, flagging potential unauthorized access attempts.
### Possible investigation steps
- Review the Azure audit logs to identify the specific service principal for which credentials were added, focusing on entries with the operation name "Add service principal credentials" and a successful outcome.
- Determine the identity of the user or application that performed the credential addition by examining the associated user or application ID in the audit log entry.
- Investigate the permissions and roles assigned to the affected service principal to assess the potential impact of unauthorized access.
- Check for any recent changes or unusual activity associated with the service principal, such as modifications to permissions or unexpected resource access patterns.
- Correlate the event with other security logs and alerts to identify any related suspicious activities or potential indicators of compromise within the environment.
- Contact the owner or responsible team for the service principal to verify if the credential addition was authorized and legitimate.
### False positive analysis
- Routine credential updates for service principals used in automated deployment processes can trigger alerts. To manage this, identify and document these processes, then create exceptions for known service principals involved in regular updates.
- Credential additions by authorized IT personnel during scheduled maintenance or upgrades may be flagged. Implement a change management process to log and verify these activities, allowing you to exclude them from triggering alerts.
- Integration of new third-party applications that require service principal credentials might cause false positives. Maintain an inventory of approved third-party integrations and exclude their credential additions from monitoring.
- Development and testing environments often see frequent credential changes. Segregate these environments from production in your monitoring setup to reduce unnecessary alerts.
- Credential rotations as part of security best practices can be mistaken for unauthorized additions. Establish a schedule for credential rotations and configure your monitoring to recognize these as legitimate activities.
### Response and remediation
- Immediately revoke the newly added credentials for the affected Azure Service Principal to prevent unauthorized access.
- Conduct a thorough review of the audit logs to identify any unauthorized activities performed using the compromised Service Principal credentials.
- Reset and update the credentials for the affected Service Principal, ensuring they are stored securely and access is restricted to authorized personnel only.
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential addition and any potential data access.
- Implement additional monitoring on the affected Service Principal and related resources to detect any further suspicious activities.
- Review and tighten the permissions granted to the Service Principal to ensure they follow the principle of least privilege.
- Consider enabling conditional access policies or additional security measures, such as IP whitelisting, to enhance protection against similar threats in the future.
## Setup
The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://www.fireeye.com/content/dam/collateral/en/wp-m-unc2452.pdf"]
risk_score = 47
rule_id = "f766ffaf-9568-4909-b734-75d19b35cbf4"
severity = "medium"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Identity and Access Audit", "Tactic: Impact", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add service principal credentials" and event.outcome:(success or Success)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1496"
name = "Resource Hijacking"
reference = "https://attack.mitre.org/techniques/T1496/"
[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"
rules/integrations/azure/persistence_azure_service_principal_credentials_added.toml
+117
View File
@@ -0,0 +1,117 @@
[metadata]
creation_date = "2021/05/05"
integration = ["azure"]
maturity = "production"
updated_date = "2025/03/26"
[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies when new Service Principal credentials have been added in Microsoft Entra ID. In most organizations,
credentials will be added to service principals infrequently. Hijacking an application (by adding a rogue secret or
certificate) with granted permissions will allow the attacker to access data that is normally protected by MFA
requirements.
"""
false_positives = [
"""
Service principal credential additions may be done by a system or network administrator. Verify whether the
username, hostname, and/or resource name should be making changes in your environment. Credential additions from
unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
from the rule.
""",
]
from = "now-9m"
index = ["filebeat-*", "logs-azure*"]
language = "kuery"
license = "Elastic License v2"
name = "Microsoft Entra ID Service Principal Credentials Added by Rare User"
note = """## Triage and analysis
### Investigating Microsoft Entra ID Service Principal Credentials Added by Rare User
This rule identifies the addition of new credentials (client secrets or certificates) to a Microsoft Entra ID (formerly Azure AD) service principal by a user who has not previously performed this operation in the last 10 days. Adversaries who obtain temporary or persistent access to a user account may add rogue credentials to service principals in order to maintain unauthorized access to cloud resources.
This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that detects rare users performing sensitive identity-related actions in Entra ID.
#### Possible Investigation Steps
- Identify the Actor: Review the `azure.auditlogs.properties.initiated_by.user.user_principal_name` and `azure.auditlogs.properties.initiated_by.user.id` fields to identify the user account performing the action. Determine if this user typically manages service principals.
- Check for Known Admin or Automation Context: Validate if the action was expected (e.g., part of a deployment pipeline or credential rotation process). Investigate whether this is a known administrative account or an automated service principal maintainer.
- Inspect Credential Type: Determine if a certificate or client secret was added, and assess its expiration time, usage scope, and whether it aligns with internal practices.
- Correlate with Other Events: Look for surrounding events such as creation of new service principals, assignment of roles or permissions, or suspicious application sign-ins that could indicate persistence or privilege escalation.
- Analyze Source of Activity: Review `source.ip` and `user_agent.original` fields to assess whether the request came from a trusted network or device. Unexpected geolocations, hosting providers, or Linux CLI-based user agents may indicate unauthorized activity.
### False Positive Analysis
- Routine Administrative Tasks: This alert may trigger when legitimate administrators or DevOps engineers rotate credentials for service principals as part of normal operations.
- First-Time Actions by Known Accounts: If a new user joins the team or an existing user is performing this task for the first time in the observed period, it may be expected behavior. Verify with the relevant team.
### Response and Remediation
- Revoke Unauthorized Credentials: If suspicious, disable or delete the newly added service principal credential immediately.
- Investigate User Account: Review the login history, IP address usage, and other activity from the initiating user to determine whether the account is compromised.
- Audit Affected Service Principal: Evaluate the permissions granted to the service principal to understand the potential impact of misuse.
- Review RBAC and Least Privilege: Ensure that only authorized identities have permission to add credentials to service principals. Tighten IAM role definitions if necessary.
- Enable Just-in-Time or Approval-Based Access: Consider implementing access control policies that require approvals for modifying service principals or adding credentials.
### Additional Information
For more information on securing Microsoft Entra ID applications and service principals, refer to:
- [Hardening Microsoft 365 and Azure AD – Google Threat Intelligence](https://cloud.google.com/blog/topics/threat-intelligence/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452)
- [Azure AD Privilege Escalation – Dirkjan Mollema](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)
- [Microsoft Entra Best Practices](https://learn.microsoft.com/en-us/entra/fundamentals/security-best-practices)
"""
references = [
"https://cloud.google.com/blog/topics/threat-intelligence/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452",
"https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/",
]
risk_score = 47
rule_id = "f766ffaf-9568-4909-b734-75d19b35cbf4"
severity = "medium"
tags = [
"Domain: Cloud",
"Data Source: Azure",
"Data Source: Microsoft Entra ID",
"Data Source: Microsoft Entra ID Audit Logs",
"Use Case: Identity and Access Audit",
"Tactic: Persistence",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.dataset: "azure.auditlogs"
and azure.auditlogs.operation_name:"Add service principal credentials"
and event.outcome: "success"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.001"
name = "Additional Cloud Credentials"
reference = "https://attack.mitre.org/techniques/T1098/001/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = [
"azure.auditlogs.properties.target_resources.0.display_name",
"azure.auditlogs.properties.initiated_by.user.id",
]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"