nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/azure/persistence_entra_service_principal_created.toml

@@ -0,0 +1,120 @@
+[metadata]
+creation_date = "2020/12/14"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/05/05"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a new service principal is added in Microsoft Entra ID. An application, hosted service, or automated
+tool that accesses or modifies resources needs an identity created. This identity is known as a service principal. For
+security reasons, it's always recommended to use service principals with automated tools rather than allowing them to
+log in with a user identity.
+"""
+false_positives = [
+    """
+    A service principal may be created by a system or network administrator. Verify whether the username, hostname,
+    and/or resource name should be making changes in your environment. Service principal 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.auditlogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Microsoft Entra ID Service Principal Created"
+note = """## Triage and analysis
+
+### Investigating Microsoft Entra ID Service Principal Created
+
+Service Principals are identities used by applications, services, and automation tools to access specific resources. They grant specific access based on the assigned API permissions. Most organizations that work a lot with Azure AD make use of service principals. Whenever an application is registered, it automatically creates an application object and a service principal in an Azure AD tenant.
+
+This rule looks for the addition of service principals. This behavior may enable attackers to impersonate legitimate service principals to camouflage their activities among noisy automations/apps.
+
+#### Possible investigation steps
+
+- Identify the user account that performed the action and whether it should perform this kind of action.
+- Investigate other alerts associated with the user account during the past 48 hours.
+- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user?
+- Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day?
+- Check if this operation was approved and performed according to the organization's change management policy.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Examine the account's commands, API calls, and data management actions in the last 24 hours.
+- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+
+### False positive analysis
+
+If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Disable or limit the account during the investigation and response.
+- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
+    - Identify the account role in the cloud environment.
+    - Assess the criticality of affected services and servers.
+    - Work with your IT team to identify and minimize the impact on users.
+    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
+    - Identify any regulatory or legal ramifications related to this activity.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
+- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
+- Consider enabling multi-factor authentication for users.
+- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+"""
+references = [
+    "https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/",
+    "https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal",
+]
+risk_score = 21
+rule_id = "60b6b72f-0fbc-47e7-9895-9ba7627a8b50"
+setup = """### Microsft Entra ID Audit Logs
+This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the [Microsoft Entra ID Audit Logs integration documentation](https://www.elastic.co/docs/reference/integrations/azure/adlogs).
+"""
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Microsoft Entra ID",
+    "Data Source: Microsoft Entra ID Audit Logs",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Persistence",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.auditlogs
+    and azure.auditlogs.operation_name:"Add service principal"
+    and event.outcome:(success or Success)
+    and not azure.auditlogs.identity: (
+        "Managed Service Identity" or
+        "Windows Azure Service Management API" or
+        "Microsoft Azure AD Internal - Jit Provisioning" or
+        "AAD App Management" or
+        "Power Virtual Agents Service"
+        )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1136"
+name = "Create Account"
+reference = "https://attack.mitre.org/techniques/T1136/"
+[[rule.threat.technique.subtechnique]]
+id = "T1136.003"
+name = "Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1136/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/azure/persistence_graph_eam_addition_or_modification.toml

@@ -0,0 +1,101 @@
+[metadata]
+creation_date = "2025/07/14"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/07/14"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to
+bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and
+sensitive resources by using bring-your-own IdP (BYOIDP) methods.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.graphactivitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "External Authentication Method Addition or Modification in Entra ID"
+note = """## Triage and analysis
+
+### Investigating External Authentication Method Addition or Modification in Entra ID
+
+This rule detects suspicious modifications to external authentication methods (EAMs) in Microsoft Entra ID via Microsoft Graph API. Adversaries may abuse this capability to bypass multi-factor authentication (MFA), enabling persistence or unauthorized access through bring-your-own identity provider (BYOIDP) methods.
+
+### Possible investigation steps
+- Validate that `event.action` is `"Microsoft Graph Activity"` and that `http.request.method` is `"PATCH"`, indicating a configuration change was made.
+- Confirm that `url.path` contains the string `authenticationMethodsPolicy`, which is associated with external authentication settings in Entra ID.
+- Review `user.id` to identify the Azure AD object ID of the user or service principal that initiated the change.
+- Examine `azure.graphactivitylogs.properties.app_id` to determine the application ID that performed the action.
+- Analyze `azure.graphactivitylogs.properties.scopes[]` to assess whether the request used privileged scopes such as `AuthenticationMethod.ReadWrite.All`.
+- Review the geographic origin of the request using `source.geo.*` and the `source.ip` field to identify anomalous locations.
+- Examine `user_agent.original` to determine whether the request was made through a browser or automation (e.g., scripted activity).
+- Correlate `azure.graphactivitylogs.properties.token_issued_at` and `azure.graphactivitylogs.properties.time_generated` to assess whether the change occurred shortly after token issuance.
+- Investigate additional activity by the same `user.id` or `app_id` within a short timeframe (e.g., 30 minutes) to detect related suspicious behavior.
+- Use the `operation_id` or `correlation_id` to pivot across related Graph API or Entra ID activity logs, if available.
+
+### False positive analysis
+- Legitimate administrative activity may trigger this rule, such as configuring FIDO2 or enabling passwordless sign-in methods during onboarding or security upgrades.
+- Some enterprise integrations or federated identity providers may programmatically update EAM settings as part of legitimate operations.
+- Routine security assessments or red team exercises may include changes to authentication policies. Validate with internal teams when in doubt.
+- If appropriate, filter or suppress alerts originating from known trusted service principals or administrative accounts.
+
+### Response and remediation
+- Confirm whether the user or application that made the change was authorized to do so. If not, immediately revoke access and reset credentials as needed.
+- Review the application or automation that triggered the change to ensure it is legitimate. If unauthorized, disable or remove it and rotate secrets or tokens it may have accessed.
+- Audit current external authentication configurations and conditional access policies to ensure no persistent backdoors were introduced.
+- Revoke session tokens associated with the change using Entra ID's portal or Microsoft Graph API, and enforce reauthentication where appropriate.
+- Implement stricter RBAC or conditional access policies to prevent unauthorized EAM changes in the future.
+- Monitor for repeat or similar activity from the same source or identity as part of an ongoing compromise assessment.
+"""
+references = ["https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/"]
+risk_score = 47
+rule_id = "42c97e6e-60c3-11f0-832a-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Data Source: Azure",
+    "Data Source: Microsoft Graph",
+    "Data Source: Microsoft Graph Activity Logs",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Persistence",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: azure.graphactivitylogs and
+    url.path: *authenticationMethodsPolicy* and
+    http.request.method: "PATCH" and
+    http.response.status_code: 200
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1556"
+name = "Modify Authentication Process"
+reference = "https://attack.mitre.org/techniques/T1556/"
+[[rule.threat.technique.subtechnique]]
+id = "T1556.009"
+name = "Conditional Access Policies"
+reference = "https://attack.mitre.org/techniques/T1556/009/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.graphactivitylogs.properties.user_principal_object_id"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/integrations/azure/persistence_identity_protect_alert_followed_by_device_reg.toml

@@ -0,0 +1,107 @@
+[metadata]
+creation_date = "2025/04/30"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies sequence of events where a Microsoft Entra ID protection alert is followed by an attempt to register a new device by the same user principal. This behavior may indicate an adversary using a compromised account to register a device, potentially leading to unauthorized access to resources or persistence in the environment.
+"""
+from = "now-9m"
+index = ["logs-azure.identity_protection-*", "logs-azure.auditlogs-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Microsoft Entra ID Protection Alert and Device Registration"
+note = """## Triage and analysis
+
+### Investigating Microsoft Entra ID Protection Alert and Device Registration
+
+#### Possible investigation steps
+
+- Identify the Risk Detection that triggered the event. A list with descriptions can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection).
+- Identify the user account involved and validate whether the suspicious activity is normal for that user.
+  - Consider the source IP address and geolocation for the involved user account. Do they look normal?
+  - Consider the device used to sign in. Is it registered and compliant?
+- Investigate other alerts associated with the user account during the past 48 hours.
+- Contact the account owner and confirm whether they are aware of this activity.
+- Check if this operation was approved and performed according to the organization's change management policy.
+- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.
+
+### False positive analysis
+- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions.
+- Consider the context of the user account and whether the activity is expected. For example, if the user is a developer or administrator, they may have legitimate reasons for accessing resources from various locations or devices.
+- A Microsoft Entra ID Protection alert may be triggered by legitimate activities such as password resets, MFA changes, or device registrations. If the user is known to perform these actions regularly, it may not indicate a compromise.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Disable or limit the account during the investigation and response.
+- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
+    - Identify the account role in the cloud environment.
+    - Assess the criticality of affected services and servers.
+    - Work with your IT team to identify and minimize the impact on users.
+    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
+    - Identify any regulatory or legal ramifications related to this activity.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
+- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
+- Consider enabling multi-factor authentication for users.
+- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR)."""
+references = [
+    "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema",
+    "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection",
+    "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk",
+    "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk#investigation-framework",
+]
+risk_score = 73
+rule_id = "a6d4e070-b9b9-4294-b028-d9e21ad47413"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Microsoft Entra ID",
+    "Data Source: Microsoft Entra ID Protection Logs",
+    "Data Source: Microsoft Entra ID Audit Logs",
+    "Use Case: Identity and Access Audit",
+    "Resources: Investigation Guide",
+    "Tactic: Persistence",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+sequence with maxspan=5m
+[any where event.dataset == "azure.identity_protection"] by azure.identityprotection.properties.user_principal_name
+[any where event.dataset == "azure.auditlogs" and event.action == "Register device"] by azure.auditlogs.properties.initiated_by.user.userPrincipalName
+'''
+
+
+[[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.005"
+name = "Device Registration"
+reference = "https://attack.mitre.org/techniques/T1098/005/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"

nldcsc_elastic_rules/rules/integrations/azure/persistence_update_event_hub_auth_rule.toml

@@ -0,0 +1,107 @@
+[metadata]
+creation_date = "2020/08/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an Event Hub Authorization Rule is created or updated in Azure. An authorization rule is associated with
+specific rights, and carries a pair of cryptographic keys. When you create an Event Hubs namespace, a policy rule named
+RootManageSharedAccessKey is created for the namespace. This has manage permissions for the entire namespace and it's
+recommended that you treat this rule like an administrative root account and don't use it in your application.
+"""
+false_positives = [
+    """
+    Authorization rule additions or modifications 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. Authorization rule additions
+    or modifications 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 = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Event Hub Authorization Rule Created or Updated"
+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 Event Hub Authorization Rule Created or Updated
+
+Azure Event Hub Authorization Rules manage access to Event Hubs via cryptographic keys, akin to administrative credentials. Adversaries may exploit these rules to gain unauthorized access or escalate privileges, potentially exfiltrating data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal associated with the operation by examining the `azure.activitylogs.operation_name` and `event.outcome` fields.
+- Check the timestamp of the event to determine when the authorization rule was created or updated, and correlate this with any other suspicious activities around the same time.
+- Investigate the specific Event Hub namespace affected by the rule change to understand its role and importance within the organization.
+- Verify if the `RootManageSharedAccessKey` or any other high-privilege authorization rule was involved, as these carry significant risk if misused.
+- Assess the necessity and legitimacy of the rule change by contacting the user or team responsible for the Event Hub namespace to confirm if the change was authorized and aligns with operational needs.
+- Examine any subsequent access patterns or data transfers from the affected Event Hub to detect potential data exfiltration or misuse following the rule change.
+
+### False positive analysis
+
+- Routine administrative updates to authorization rules by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or deployment tools that update authorization rules as part of regular operations may cause false positives. Identify these scripts and exclude their activity from alerts by filtering based on their service principal or user identity.
+- Changes made by trusted third-party services integrated with Azure Event Hub might be flagged. Verify these services and exclude their operations by adding them to an allowlist.
+- Frequent updates during development or testing phases can lead to false positives. Consider setting up separate monitoring profiles for development environments to reduce noise.
+- Legitimate changes made by users with appropriate permissions might be misinterpreted as threats. Regularly review and update the list of authorized users to ensure only necessary personnel have access, and exclude their actions from alerts.
+
+### Response and remediation
+
+- Immediately revoke or rotate the cryptographic keys associated with the affected Event Hub Authorization Rule to prevent unauthorized access.
+- Review the Azure Activity Logs to identify any unauthorized access or data exfiltration attempts that may have occurred using the compromised authorization rule.
+- Implement conditional access policies to restrict access to Event Hub Authorization Rules based on user roles and network locations.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
+- Conduct a security review of all Event Hub Authorization Rules to ensure that only necessary permissions are granted and that the RootManageSharedAccessKey is not used in applications.
+- Enhance monitoring and alerting for changes to authorization rules by integrating with a Security Information and Event Management (SIEM) system to detect 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://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-shared-access-signature"]
+risk_score = 47
+rule_id = "b6dce542-2b75-4ffb-b7d6-38787298ba9d"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Persistence", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+[[rule.threat.technique.subtechnique]]
+id = "T1552.005"
+name = "Cloud Instance Metadata API"
+reference = "https://attack.mitre.org/techniques/T1552/005/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml

@@ -0,0 +1,93 @@
+[metadata]
+creation_date = "2020/08/20"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a user is added as an owner for an Azure application. An adversary may add a user account as an owner
+for an Azure application in order to grant additional permissions and modify the application's configuration using
+another account.
+"""
+from = "now-9m"
+index = ["logs-azure.auditlogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "User Added as Owner for Azure Application"
+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 User Added as Owner for Azure Application
+
+Azure applications often require specific permissions for functionality, managed by assigning user roles. An adversary might exploit this by adding themselves or a compromised account as an owner, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations.
+
+### Possible investigation steps
+
+- Review the Azure audit logs to confirm the operation by filtering for event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" with a successful outcome.
+- Identify the user account that was added as an owner and the account that performed the operation to determine if they are legitimate or potentially compromised.
+- Check the history of activities associated with both the added owner and the account that performed the operation to identify any suspicious behavior or patterns.
+- Verify the application's current configuration and permissions to assess any changes made after the new owner was added.
+- Contact the legitimate owner or administrator of the Azure application to confirm whether the addition of the new owner was authorized.
+- Investigate any recent changes in the organization's user access policies or roles that might explain the addition of a new owner.
+
+### False positive analysis
+
+- Routine administrative actions: Regular maintenance or updates by IT staff may involve adding users as application owners. To manage this, create a list of authorized personnel and exclude their actions from triggering alerts.
+- Automated processes: Some applications may have automated scripts or services that add users as owners for operational purposes. Identify these processes and configure exceptions for their activities.
+- Organizational changes: During mergers or restructuring, there may be legitimate reasons for adding multiple users as application owners. Temporarily adjust the rule to accommodate these changes and review the audit logs manually.
+- Testing and development: In development environments, users may be added as owners for testing purposes. Exclude these environments from the rule or set up a separate monitoring policy with adjusted thresholds.
+
+### Response and remediation
+
+- Immediately revoke the added user's owner permissions from the Azure application to prevent further unauthorized access or configuration changes.
+- Conduct a thorough review of recent activity logs for the affected application to identify any unauthorized changes or data access that may have occurred since the user was added as an owner.
+- Reset credentials and enforce multi-factor authentication for the compromised or suspicious account to prevent further misuse.
+- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals broader compromise.
+- Implement additional monitoring on the affected application and related accounts to detect any further unauthorized access attempts or privilege escalations.
+- Review and update access control policies to ensure that only authorized personnel can modify application ownership, and consider implementing stricter approval processes for such changes.
+- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+risk_score = 21
+rule_id = "774f5e28-7b75-4a58-b94e-41bf060fdd86"
+severity = "low"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1528"
+name = "Steal Application Access Token"
+reference = "https://attack.mitre.org/techniques/T1528/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2020/08/20"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a user is added as an owner for an Azure service principal. The service principal object defines what
+the application can do in the specific tenant, who can access the application, and what resources the app can access. A
+service principal object is created when an application is given permission to access resources in a tenant. An
+adversary may add a user account as an owner for a service principal and use that account in order to define what an
+application can do in the Azure AD tenant.
+"""
+from = "now-9m"
+index = ["logs-azure.auditlogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "User Added as Owner for Azure Service Principal"
+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 User Added as Owner for Azure Service Principal
+
+Azure service principals are crucial for managing application permissions within a tenant, defining access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over application permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity.
+
+### Possible investigation steps
+
+- Review the audit log entry to confirm the event dataset is 'azure.auditlogs' and the operation name is "Add owner to service principal" with a successful outcome.
+- Identify the user account that was added as an owner and gather information about this account, including recent activity and any associated alerts.
+- Determine the service principal involved by reviewing its details, such as the application it is associated with and the permissions it holds.
+- Check the history of changes to the service principal to identify any other recent modifications or suspicious activities.
+- Investigate the context and necessity of the ownership change by contacting the user or team responsible for the service principal to verify if the change was authorized.
+- Assess the potential impact of the ownership change on the tenant's security posture, considering the permissions and access granted to the service principal.
+
+### False positive analysis
+
+- Routine administrative changes may trigger alerts when legitimate IT staff add themselves or others as owners for maintenance purposes. To manage this, create exceptions for known administrative accounts that frequently perform these actions.
+- Automated processes or scripts that manage service principal ownership as part of regular operations can cause false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags.
+- Organizational changes, such as team restructuring, might lead to multiple legitimate ownership changes. During these periods, temporarily adjust the rule sensitivity or create temporary exceptions for specific user groups involved in the transition.
+- Third-party applications that require ownership changes for integration purposes can also trigger alerts. Verify these applications and whitelist their associated service principal changes to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke the added user's ownership from the Azure service principal to prevent unauthorized access and control.
+- Conduct a thorough review of the affected service principal's permissions and access logs to identify any unauthorized changes or access attempts.
+- Reset credentials and update any secrets or keys associated with the compromised service principal to mitigate potential misuse.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement conditional access policies to restrict who can add owners to service principals, ensuring only authorized personnel have this capability.
+- Enhance monitoring and alerting for similar activities by increasing the sensitivity of alerts related to changes in service principal ownership.
+- Document the incident and response actions taken to improve future incident response and refine security policies.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals",
+]
+risk_score = 21
+rule_id = "38e5acdd-5f20-4d99-8fe4-f0a1a592077f"
+severity = "low"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to service principal" and event.outcome:(Success or 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]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+