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

nldcsc_elastic_rules/rules/integrations/azure/ml_azure_event_failures.toml

@@ -0,0 +1,124 @@
+[metadata]
+creation_date = "2025/10/06"
+integration = ["azure"]
+maturity = "production"
+min_stack_comments = "New job added"
+min_stack_version = "9.3.0"
+updated_date = "2025/12/08"
+
+[rule]
+anomaly_threshold = 50
+author = ["Elastic"]
+description = """
+A machine learning job detected a significant spike in the rate of a particular failure in the Azure Activity Logs messages. Spikes
+in failed messages may accompany attempts at privilege escalation, lateral movement, or discovery.
+"""
+false_positives = [
+    """
+    Spikes in failures can also be due to bugs in cloud automation scripts or workflows; changes to cloud
+    automation scripts or workflows; adoption of new services; changes in the way services are used; or changes to IAM
+    privileges.
+    """,
+]
+from = "now-60m"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "azure_activitylogs_high_distinct_count_event_action_on_failure"
+name = "Spike in Azure Activity Logs Failed Messages"
+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 Spike in Azure Activity Logs Failed Messages
+
+This rule flags an unusual surge in failed control‑plane operations recorded in the platform’s activity logs, highlighting abrupt increases in a specific failure type. It matters because concentrated failures frequently accompany probing for privileges, discovery, or staged lateral movement. Adversaries often script through the management API to list subscriptions, role assignments, or policy definitions and then attempt role updates or assignment creations at scale, generating clusters of authorization and scope‑validation failures as they enumerate tenants and test permission boundaries.
+
+### Possible investigation steps
+
+- Categorize the spike by failure reason (authorization, policy, scope validation, throttling, or availability) and pivot to the initiating identities, apps, and source IPs to see whether a single principal or distributed automation is driving it.
+- Correlate these failures with Entra ID sign‑in logs and Conditional Access evaluations for the same principals to determine whether authentication, token, or policy blocks explain the surge.
+- Review recent RBAC changes (role assignments/definitions), PIM activations, and deny/policy assignments around the spike to spot attempted privilege escalation or scope misconfiguration.
+- Map the affected resource providers and scopes (tenant, subscription, resource group) to identify reconnaissance patterns such as wide listing followed by repeated unauthorized write attempts.
+- Confirm benign causes such as expired service principal credentials, broken pipelines, or provider outages with owners, and if intent is suspect promptly disable the principal, revoke tokens, and rotate secrets.
+
+### False positive analysis
+
+- Expired or rotated service principal credentials in scheduled automation led to repeated Azure management operations with invalid tokens, spiking AuthorizationFailed entries until the secret was updated.
+- A planned rollout of Azure Policy with a deny effect or the application of resource locks temporarily blocked routine deployments across multiple scopes, generating a concentrated burst of failed write operations during the change window.
+
+### Response and remediation
+
+- Temporarily disable the Entra ID service principal or user driving the spike, revoke all refresh/access tokens, and apply a Conditional Access block for management API access from its source IP ranges to halt further control‑plane attempts.
+- Pause implicated automation by stopping the Azure DevOps pipeline or Automation Account runbook, invalidate any associated PATs or shared secrets, and rotate the application/client secret or federated credentials tied to the identity.
+- Back out unauthorized changes by removing newly created role assignments, deny assignments, or policy assignments introduced during the window, and restore intended RBAC at the affected subscriptions, management groups, and resource groups via IaC state.
+- Recover by fixing the misconfiguration or credentials, validating successful test operations (e.g., list and create where permitted) in a non‑production subscription, and then re‑enable automation with least‑privilege scopes while monitoring for a return to normal failure rates.
+- Escalate to the incident response lead if failures include repeated attempts to change role assignments or policy at tenant or management‑group scope, originate from unfamiliar geographies or unapproved IP ranges, spread across multiple subscriptions, or persist more than 15 minutes after containment.
+- Harden by enforcing PIM for privileged roles, enabling Conditional Access for workload identities and administrators (MFA and named locations), implementing secret scanning and rotation for repos and pipelines, exporting Activity Logs to Log Analytics with retention, and alerting on abnormal management‑plane failures per identity.
+"""
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from Azure Activity Logs.
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### Azure Activity Logs Integration Setup
+The Azure Activity Logs integration allows you to collect logs and metrics from Azure with Elastic Agent.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "Azure Activity Logs" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Azure Activity Logs” and select the integration to see more details about it.
+- Click “Add Azure Activity Logs”.
+- Configure the integration.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/reference/integrations/azure/activitylogs).
+"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "1eb74889-18c5-4f78-8010-d8aceb7a9ef4"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+
+[[rule.threat.technique]]
+id = "T1526"
+name = "Cloud Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1526/"
+
+[[rule.threat.technique]]
+id = "T1580"
+name = "Cloud Infrastructure Discovery"
+reference = "https://attack.mitre.org/techniques/T1580/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"

nldcsc_elastic_rules/rules/integrations/azure/ml_azure_rare_event_failures.toml

@@ -0,0 +1,148 @@
+[metadata]
+creation_date = "2025/10/06"
+integration = ["azure"]
+maturity = "production"
+min_stack_comments = "New job added"
+min_stack_version = "9.3.0"
+updated_date = "2025/12/08"
+
+[rule]
+anomaly_threshold = 50
+author = ["Elastic"]
+description = """
+A machine learning job detected an unusual failure in an Azure Activity Logs message. These can be byproducts of attempted or
+successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection.
+"""
+false_positives = [
+    """
+    Rare and unusual failures may indicate an impending service failure state. Rare and unusual user failure activity can
+    also be due to manual troubleshooting or reconfiguration attempts by insufficiently privileged users, bugs in cloud
+    automation scripts or workflows, or changes to IAM privileges.
+    """,
+]
+from = "now-2h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "azure_activitylogs_rare_event_action_on_failure"
+name = "Rare Azure Activity Logs Event Failures"
+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 Rare Azure Activity Logs Event Failures
+
+This rule surfaces statistically rare Azure Activity Logs failures, pointing to control‑plane actions that break from typical patterns and may reflect reconnaissance, privilege changes, or defense evasion. A common attacker sequence is using a newly compromised identity to enumerate subscriptions and resource groups through the management API; repeated access denials during these discovery calls can occur as the adversary maps tenant scope and tests permissions before escalating.
+
+### Possible investigation steps
+
+- Classify the failing operations (discovery vs write/privileged) and tie them to the initiating principal and target scope to gauge intent and blast radius.
+- Correlate with Entra ID sign-in telemetry for the same principal around the event window to assess geo/device novelty, MFA state, Conditional Access results, and identity risk flags.
+- Check whether the identity recently had role assignments, group membership, PIM elevation, or app consent changes, and whether this is first-time access to the affected subscriptions or resource groups.
+- Confirm whether Azure Policy denies, deny assignments, or resource locks explain the failures, and verify whether the principal should legitimately be exempt or granted access.
+- If the actor is a service principal or managed identity, review recent credential changes (keys/secrets/certificates), app role assignment grants, and automation pipeline updates that could explain unexpected calls.
+
+### False positive analysis
+
+- A newly deployed automation or audit workflow attempts wide-scope resource discovery using a service principal or managed identity, encountering expected RBAC or policy denials that are rare for that caller.
+- Recent governance changes such as Azure Policy deny effects, deny assignments, or resource locks cause routine management operations (e.g., writes or deletes) to start failing, creating an unusual failure pattern until baselines adjust.
+
+### Response and remediation
+
+- Immediately contain the initiating identity by disabling user/service principal sign-in, revoking refresh tokens, and applying a temporary Conditional Access block on Azure management endpoints, while placing deny assignments and resource locks on the impacted subscriptions/resource groups.
+- Eradicate potential persistence by removing any newly created role assignments, app consent grants, policy exemptions, or management role changes identified in triage, and rotate keys/secrets/certificates for affected service principals or managed identities.
+- Recover business operations by restoring access only to verified identities through PIM approvals, re-enabling known-good automation accounts/runbooks, and validating that expected management operations succeed without further rare failures on the targeted resources.
+- Escalate to incident response immediately if rare failures are observed across multiple subscriptions or are followed by a successful privileged action (e.g., new Owner or User Access Administrator assignment, app consent grant, or resource lock removal) or originate from an unfamiliar geo/device, triggering tenant-wide containment.
+- Harden going forward by enforcing MFA and Conditional Access (including workload identity policies) for Resource Manager access, restricting service principals to least privilege with certificate-based credentials or workload identity federation, implementing deny assignments/resource locks for crown-jewel resources, and centralizing Activity Logs in SIEM with detections for discovery bursts and denied write attempts.
+"""
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from Azure Activity Logs.
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### Azure Activity Logs Integration Setup
+The Azure Activity Logs integration allows you to collect logs and metrics from Azure with Elastic Agent.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "Azure Activity Logs" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Azure Activity Logs” and select the integration to see more details about it.
+- Click “Add Azure Activity Logs”.
+- Configure the integration.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/reference/integrations/azure/activitylogs).
+"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "c17ffbf9-595a-4c0b-a126-aacedb6dd179"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+
+[[rule.threat.technique]]
+id = "T1526"
+name = "Cloud Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1526/"
+
+[[rule.threat.technique]]
+id = "T1580"
+name = "Cloud Infrastructure Discovery"
+reference = "https://attack.mitre.org/techniques/T1580/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0009"
+name = "Collection"
+reference = "https://attack.mitre.org/tactics/TA0009/"
+

nldcsc_elastic_rules/rules/integrations/azure/ml_azure_rare_method_by_city.toml

@@ -0,0 +1,109 @@
+[metadata]
+creation_date = "2025/10/06"
+integration = ["azure"]
+maturity = "production"
+min_stack_comments = "New job added"
+min_stack_version = "9.3.0"
+updated_date = "2025/12/08"
+
+[rule]
+anomaly_threshold = 50
+author = ["Elastic"]
+description = """
+A machine learning job detected Azure Activity Logs activity that, while not inherently suspicious or abnormal, is sourcing from
+a geolocation (city) that is unusual for the event action. This can be the result of compromised credentials or keys being
+used by a threat actor in a different geography than the authorized user(s).
+"""
+false_positives = [
+    """
+    New or unusual event and user geolocation activity can be due to manual troubleshooting or reconfiguration;
+    changes in cloud automation scripts or workflows; adoption of new services; expansion into new regions; increased
+    adoption of work from home policies; or users who travel frequently.
+    """,
+]
+from = "now-2h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "azure_activitylogs_rare_event_action_for_a_city"
+name = "Unusual City for an Azure Activity Logs Event"
+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 Unusual City for an Azure Activity Logs Event
+
+This rule highlights Azure Activity Logs activity executed from a city atypical for the action, indicating use of valid accounts from a different geography. A common pattern is a threat actor using stolen user or service principal credentials to add privileged role assignments and rapidly spin up compute to stage data exfiltration or mining from overseas. Location–action mismatch surfaces stealthy account abuse before persistence and broader impact.
+
+### Possible investigation steps
+
+- Identify the principal behind the operation and validate legitimate presence in the region by contacting the user/owner and reviewing travel or business justification.
+- Enrich the source IP with ASN, hosting/cloud provider, VPN/Tor indicators, reverse DNS, and threat intel to determine whether it originates from anonymizing or compute infrastructure.
+- Correlate Entra ID sign-in logs for the principal around the timestamp to check impossible travel, MFA usage or bypass, device compliance state, and atypical user-agent strings.
+- Review adjacent Azure Resource Manager activity by the same principal for privileged changes such as role assignments, policy updates, access key or secret actions, and rapid compute/network provisioning.
+- Determine whether the actor is a user or service principal, and if a service principal, inspect recent secret/certificate changes, unexpected consent or role grants, and potential credential exposure in CI/CD or repositories.
+
+### False positive analysis
+
+- A legitimate admin traveling or connecting via a VPN or newly configured egress/NAT gateway can geolocate to an unexpected city while performing routine Azure Activity Logs actions.
+- Service principal or managed identity automation executing from a different Azure region due to multi-region deployment or failover can egress from a city unusual for the action yet still be authorized.
+
+### Response and remediation
+
+- Immediately revoke active sessions and refresh tokens for the implicated user or service principal, disable the account or application, and block the observed source IP/CIDR at Azure Firewall and NSGs to contain activity.
+- Reset the user's password and force MFA re-registration, or for a service principal rotate all client secrets/certificates and remove any recent admin consent grants to eradicate credential reuse.
+- Revert changes executed from the unusual city by removing newly added role assignments, deleting unexpected VMs/VNets or policy updates, and rotating Storage account keys and Key Vault secrets if they were accessed.
+- After containment, verify business justification (travel or new egress) and restore any required resources from ARM/Bicep templates or backups, then re-enable access behind Conditional Access with known egress IPs only.
+- Escalate to Incident Response if the actor performs privileged role grants, Key Vault secret retrieval, Storage key listing, or rapid compute provisioning within the same session, or if sign-in shows impossible travel or missing MFA.
+- Harden by enforcing PIM for Owner/Contributor/User Access Administrator roles, configuring Conditional Access with country allowlists and named egress IP ranges, restricting service principals to certificate-only auth and Private Link on Key Vault/Storage, and enabling continuous geolocation anomaly alerts in Microsoft Sentinel.
+"""
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from Azure Activity Logs.
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### Azure Activity Logs Integration Setup
+The Azure Activity Logs integration allows you to collect logs and metrics from Azure with Elastic Agent.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "Azure Activity Logs" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Azure Activity Logs” and select the integration to see more details about it.
+- Click “Add Azure Activity Logs”.
+- Configure the integration.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/reference/integrations/azure/activitylogs).
+"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "ce08cdb8-e6cb-46bb-a7cc-16d17547323f"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[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/"

nldcsc_elastic_rules/rules/integrations/azure/ml_azure_rare_method_by_country.toml

@@ -0,0 +1,108 @@
+[metadata]
+creation_date = "2025/10/06"
+integration = ["azure"]
+maturity = "production"
+min_stack_comments = "New job added"
+min_stack_version = "9.3.0"
+updated_date = "2025/12/08"
+
+[rule]
+anomaly_threshold = 50
+author = ["Elastic"]
+description = """
+A machine learning job detected Azure Activity Logs activity that, while not inherently suspicious or abnormal, is sourcing from
+a geolocation (country) that is unusual for the event action. This can be the result of compromised credentials or keys being
+used by a threat actor in a different geography than the authorized user(s).
+"""
+false_positives = [
+    """
+    New or unusual event and user geolocation activity can be due to manual troubleshooting or reconfiguration;
+    changes in cloud automation scripts or workflows; adoption of new services; expansion into new regions; increased
+    adoption of work from home policies; or users who travel frequently.
+    """,
+]
+from = "now-2h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "azure_activitylogs_rare_event_action_for_a_country"
+name = "Unusual Country for an Azure Activity Logs Event"
+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 Unusual Country for an Azure Activity Logs Event
+
+This alert flags management operations originating from a country not normally associated with that activity in your environment, signaling credential or key misuse from remote infrastructure. A common pattern is an attacker authenticating from a new region, then automating creation of a service principal, granting it elevated role assignments, and modifying access policies or spinning up compute to persist, escalate privileges, and stage data exfiltration.
+
+### Possible investigation steps
+
+- Enrich the source IP with ASN, hosting provider, and threat intel, distinguishing corporate VPN exit nodes from cloud-hosting or anonymizer infrastructure.
+- Correlate the actor (user, service principal, or managed identity) with Microsoft Entra ID sign-in logs to confirm authentication method, MFA and Conditional Access outcomes, application context, and device compliance.
+- Build a 24–48 hour timeline of the actor’s management operations to spot follow-on actions indicative of persistence or escalation such as app/service principal creation, role assignment changes, Key Vault policy edits, SAS or key issuance, and VM/automation deployment.
+- Validate business legitimacy by checking travel records, change tickets, and approved maintenance windows, and if interactive access, contact the user to verify intent and location.
+- If compromise is suspected, revoke sessions and refresh tokens, rotate secrets and credentials, remove newly added privileges, and enable stricter geo or Conditional Access controls while monitoring for reattempts from the same country.
+
+### False positive analysis
+
+- A legitimate user traveling or working remotely connects via mobile, hotel, or corporate VPN egress whose public IP geolocates to a country outside the baseline, triggering the unusual country alert.
+- Routine automation or a service principal executes from Azure compute in a different region due to scaling or failover, making management operations appear to originate from IP ranges mapped to another country.
+
+### Response and remediation
+
+- Immediately disable the involved user or service principal, revoke active sessions and refresh tokens, and block the public IP/CIDR at Azure Firewall or NSGs while applying Conditional Access to deny management actions from that country.
+- Remove any newly added role assignments or RBAC changes linked to the actor, delete unauthorized service principals or managed identities, invalidate issued SAS tokens or storage account keys, and rotate affected secrets, app passwords, and credentials.
+- Restore access only after user/business validation, reapply baseline Key Vault access policies and RBAC from infrastructure-as-code, and roll forward patched images or automation to replace any VMs or runbooks created during the incident.
+- Escalate to Security Incident Response if a service principal was created and granted Owner/Contributor or Key Vault Admin, if access policies were modified, if compute/automation was deployed from the unusual country, or if interactive management access succeeded without MFA.
+- Harden by enforcing country-aware Conditional Access for management apps, requiring phishing-resistant MFA for privileged actions, enabling PIM with approval and just-in-time for role changes, restricting SAS with IP/time scopes, and disabling legacy authentication.
+"""
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from Azure Activity Logs.
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### Azure Activity Logs Integration Setup
+The Azure Activity Logs integration allows you to collect logs and metrics from Azure with Elastic Agent.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "Azure Activity Logs" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Azure Activity Logs” and select the integration to see more details about it.
+- Click “Add Azure Activity Logs”.
+- Configure the integration.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/reference/integrations/azure/activitylogs).
+"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "76de17b9-af25-49a0-9378-02888b6bb3a2"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[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/"

nldcsc_elastic_rules/rules/integrations/azure/ml_azure_rare_method_by_user.toml

@@ -0,0 +1,147 @@
+[metadata]
+creation_date = "2025/10/06"
+integration = ["azure"]
+maturity = "production"
+min_stack_comments = "New job added"
+min_stack_version = "9.3.0"
+updated_date = "2025/12/08"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job detected Azure Activity Logs activity that, while not inherently suspicious or abnormal, is sourcing from
+user context that does not normally use the event action. This can be the result of compromised credentials or keys as
+someone uses a valid account to persist, move laterally, or exfiltrate data.
+"""
+false_positives = [
+    """
+    New or unusual user event activity can be due to manual troubleshooting or reconfiguration; changes in cloud
+    automation scripts or workflows; adoption of new services; or changes in the way services are used.
+    """,
+]
+from = "now-2h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "azure_activitylogs_rare_event_action_for_a_username"
+name = "Unusual Azure Activity Logs Event for a User"
+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 Unusual Azure Activity Logs Event for a User
+
+This rule flags an Azure Activity Logs event when a user performs an action they don’t normally execute, highlighting potential misuse of valid credentials. It matters because attackers often blend in by operating under legitimate identities to persist, escalate, move laterally, or exfiltrate without tripping simple allowlists. A common pattern is a compromised account creating a new role assignment to grant itself elevated rights, then using that access to enumerate resources and pull data from storage.
+
+### Possible investigation steps
+
+- Reconstruct the timeline by pivoting on the user and ±60 minutes to collect all related Azure Activity Log entries (including those sharing the same correlation ID) and map any subsequent privilege changes, resource modifications, or data access. 
+- Validate identity context by reviewing Entra ID sign-in logs for IP/ASN, geolocation, device compliance, MFA outcome, authentication protocol, and client app to spot first-time usage or impossible travel. 
+- Determine whether the caller is a human account, service principal, or managed identity and confirm legitimate need by checking current and recently changed role assignments and group memberships within the affected scope. 
+- Correlate the activity with approved change records and CI/CD runs (e.g., Azure DevOps, GitHub Actions, Terraform) by matching service principal/user agent and verify the pipeline or requestor was authorized and correctly scoped.
+
+### False positive analysis
+
+- The user temporarily covered an admin role and performed uncommon RBAC changes or resource provider registrations that are legitimate but deviate from their historical baseline.
+- A scheduled maintenance or setup task ran under the user’s credentials and invoked management APIs they rarely call, generating Azure Activity Logs that appear unusual for this identity.
+
+### Response and remediation
+
+- Immediately revoke the user’s refresh tokens and active sessions, force a password reset, and apply a temporary Conditional Access policy to block the source IPs and device observed during the unusual operation.
+- Remove any RBAC role assignments or resource policy changes created by this identity during the event window (including Owner/Contributor grants on subscriptions or resource groups) and require approvals through Privileged Identity Management before restoring access.
+- If a service principal or managed identity executed the action, rotate its client secret/certificate, invalidate issued SAS tokens and storage account keys, and delete any unauthorized app registrations or automation accounts created.
+- Restore affected configurations to baseline by reapplying IaC templates and verifying Key Vault access policies, storage account firewalls, and NSG rules match approved standards before re-enabling routine operations.
+- Escalate to incident response and notify cloud security leadership if the unusual action involved new role assignments granting elevated rights, access to Key Vault secrets, listing storage account keys, disabling logs, or activity across multiple subscriptions.
+- Implement hardening by enforcing MFA with phishing-resistant methods, enabling risk-based Conditional Access, requiring just-in-time elevation via PIM, restricting management-plane access to approved network locations, and adding alerts for role assignment writes, secret reads, and key listings.
+"""
+setup = """## Setup
+
+This rule requires the installation of associated Machine Learning jobs, as well as data coming in from Azure Activity Logs.
+
+### Anomaly Detection Setup
+
+Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).
+
+### Azure Activity Logs Integration Setup
+The Azure Activity Logs integration allows you to collect logs and metrics from Azure with Elastic Agent.
+
+#### The following steps should be executed in order to add the Elastic Agent System integration "Azure Activity Logs" to your system:
+- Go to the Kibana home page and click “Add integrations”.
+- In the query bar, search for “Azure Activity Logs” and select the integration to see more details about it.
+- Click “Add Azure Activity Logs”.
+- Configure the integration.
+- Click “Save and Continue”.
+- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/reference/integrations/azure/activitylogs).
+"""
+references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
+risk_score = 21
+rule_id = "81892f44-4946-4b27-95d3-1d8929b114a7"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[[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]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+
+[[rule.threat.technique]]
+id = "T1021"
+name = "Remote Services"
+reference = "https://attack.mitre.org/techniques/T1021/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1021.007"
+name = "Cloud Services"
+reference = "https://attack.mitre.org/techniques/T1021/007/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+
+[[rule.threat.technique]]
+id = "T1041"
+name = "Exfiltration Over C2 Channel"
+reference = "https://attack.mitre.org/techniques/T1041/"
+