Elastic rules: 2y

[metadata]
creation_date = "2020/11/06"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects attempts to deactivate an Okta network zone. Okta network zones can be configured to limit or restrict access to
a network based on IP addresses or geolocations. An adversary may attempt to modify, delete, or deactivate an Okta
network zone in order to remove or weaken an organization's security controls.
"""
false_positives = [
    """
    Consider adding exceptions to this rule to filter false positives if your organization's Okta network zones are
    regularly modified.
    """,
]
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Attempt to Deactivate an Okta Network Zone"
note = """## Triage and analysis

### Investigating Attempt to Deactivate an Okta Network Zone

The Okta network zones can be configured to restrict or limit access to a network based on IP addresses or geolocations. Deactivating a network zone in Okta may remove or weaken the security controls of an organization, which might be an indicator of an adversary's attempt to evade defenses.

#### Possible investigation steps

- Identify the actor related to the alert by reviewing the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields.
- Examine the `event.action` field to confirm the deactivation of a network zone.
- Check the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` to identify the network zone that was deactivated.
- Investigate the `event.time` field to understand when the event happened.
- Review the actor's activities before and after the event to understand the context of this event.

### False positive analysis

- Check the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. If these match the actor's normal behavior, it might be a false positive.
- Check if the actor is a known administrator or part of the IT team who might have a legitimate reason to deactivate a network zone.
- Verify the actor's actions with any known planned changes or maintenance activities.

### Response and remediation

- If unauthorized access or actions are confirmed, immediately lock the affected actor account and require a password change.
- Re-enable the deactivated network zone if it was deactivated without authorization.
- Review and update the privileges of the actor who initiated the deactivation.
- Check the security policies and procedures to identify any gaps and update them as necessary.
- Implement additional monitoring and logging of Okta events to improve visibility of user actions.
- Communicate and train the employees about the importance of following proper procedures for modifying network zone settings.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://help.okta.com/en/prod/Content/Topics/Security/network/network-zones.htm",
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 47
rule_id = "8a5c1e5f-ad63-481e-b53a-ef959230f7f1"
severity = "medium"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Use Case: Network Security Monitoring",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:zone.deactivate
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

[[rule.threat.technique.subtechnique]]
id = "T1484.002"
name = "Trust Modification"
reference = "https://attack.mitre.org/techniques/T1484/002/"

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[[rule.threat.technique.subtechnique]]
id = "T1562.007"
name = "Disable or Modify Cloud Firewall"
reference = "https://attack.mitre.org/techniques/T1562/007/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2026/04/06"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/20"
min_stack_comments = "Changing min stack to 9.3.0, the latest minimum supported version for 9.X releases."
min_stack_version = "9.3.0"

[rule]
author = ["Elastic"]
description = """
Correlates open detection alerts that share the same long-term IAM access key ID ( prefix AKIA). It fires when the rule
AWS Long-Term Access Key First Seen from Source IP (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) has triggered for
that key and at least one other open alert for the same key is medium, high, or critical severity. This higher-order
rule helps prioritize long-term key novelty when it co-occurs with elevated detections that may indicate post-compromise
activity.
"""
false_positives = [
    """
    The same automation identity may legitimately trigger a first-seen-IP alert and unrelated medium-or-higher findings
    in the same window (for example, a noisy compliance rule). Review sibling `kibana.alert.rule.name` values, rule
    tags, and CloudTrail context for the access key before escalating.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts"
note = """## Triage and analysis

### Investigating AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts

This is a [higher-order](https://www.elastic.co/guide/en/security/current/rules-ui-create.html) rule. It evaluates **open** signals in `.alerts-security.*` grouped by
`aws.cloudtrail.user_identity.access_key_id`. A match requires:

1. At least one alert from **AWS Long-Term Access Key First Seen from Source IP** (`kibana.alert.rule.rule_id` **9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f**).
2. At least one **different** alert on the **same access key** with **medium or higher** severity, implemented as
   `kibana.alert.risk_score >= 47` or `kibana.alert.severity` in `medium`, `high`, or `critical`.

### Possible investigation steps

- **`Esql.alert_count_long_term_key_new_ip_rule`**: Confirm the first-seen-IP rule contributed to the correlation.
- **`Esql.alert_count_other_elevated`**: Count of sibling alerts meeting the elevated threshold (excluding the long-term-key new-IP rule).
- **`Esql.kibana_alert_rule_name_values`** / **`Esql.kibana_alert_rule_id_values`**: Identify which rules fired; map tactics and whether activity looks like post-compromise follow-through.
- **`aws.cloudtrail.user_identity.access_key_id`**: Pivot in CloudTrail and IAM (last used, attached policies, user or root context).
- **`Esql.aws_cloudtrail_user_identity_arn_values`**, **`Esql.source_ip_values`**: Reconstruct session context across alerts.

### False positive analysis

- Overlapping scheduled jobs, penetration tests, or purple-team runs that reuse the same IAM access key across many detectors.
- Custom rules calibrated with **medium** severity but **low** risk scores still qualify via `kibana.alert.severity`.

### Response and remediation

- Treat as elevated priority versus the standalone first-seen-IP rule: rotate or disable the access key if abuse is suspected,
  scope CloudTrail for the key, and review open sibling alerts to closure.

### Additional information

- Default risk score to severity mapping in Elastic Security is commonly **21** low, **47** medium, **73** high, **99** critical; confirm in your deployment if customized.

"""
references = [
    "https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise",
]
risk_score = 73
rule_id = "98cfaa44-83f0-4aba-90c4-363fb9d51a75"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS IAM",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
    "Rule Type: Higher-Order Rule",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from .alerts-security.* METADATA _id, _version, _index

// Sibling rule: AWS Long-Term Access Key First Seen from Source IP
// rule_id = 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f

| where kibana.alert.workflow_status == "open"
    and event.kind == "signal"
    and source.ip is not null
    and kibana.alert.rule.name is not null
    and not kibana.alert.rule.type in ("threat_match", "machine_learning")
    and not kibana.alert.rule.name like "Deprecated - *"
    and not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
    and (
        kibana.alert.rule.rule_id == "9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f"
        or kibana.alert.risk_score >= 47
        or kibana.alert.severity in ("medium", "high", "critical")
    )

| eval Esql.is_long_term_key_new_ip_rule = kibana.alert.rule.rule_id == "9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f"
| eval Esql.is_other_elevated_rule = kibana.alert.rule.rule_id != "9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f"
    and (
        kibana.alert.risk_score >= 47
        or kibana.alert.severity in ("medium", "high", "critical")
    )

| stats
    Esql.alert_count_long_term_key_new_ip_rule = SUM(CASE(Esql.is_long_term_key_new_ip_rule, 1, 0)),
    Esql.alert_count_other_elevated_rule = SUM(CASE(Esql.is_other_elevated_rule, 1, 0)),
    Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
    Esql.kibana_alert_rule_id_values = VALUES(kibana.alert.rule.rule_id),
    Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score),
    Esql.kibana_alert_severity_values = VALUES(kibana.alert.severity),
    Esql.user_entity_id_values = VALUES(user.entity.id),
    Esql.timestamp_min = MIN(@timestamp),
    Esql.timestamp_max = MAX(@timestamp)
  by source.ip

| where Esql.alert_count_long_term_key_new_ip_rule > 0
    and Esql.alert_count_other_elevated_rule > 0

| keep
    source.ip,
    Esql.alert_count_long_term_key_new_ip_rule,
    Esql.alert_count_other_elevated_rule,
    Esql.kibana_alert_rule_name_values,
    Esql.kibana_alert_rule_id_values,
    Esql.kibana_alert_risk_score_values,
    Esql.kibana_alert_severity_values,
    Esql.user_entity_id_values,
    Esql.timestamp_min,
    Esql.timestamp_max
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[[rule.threat]]
framework = "MITRE ATT&CK"
[[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 = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[rule.investigation_fields]
field_names = [
    "source.ip",
    "Esql.user_entity_id_values",
    "Esql.alert_count_long_term_key_new_ip_rule",
    "Esql.alert_count_other_elevated_rule",
    "Esql.kibana_alert_rule_name_values",
    "Esql.kibana_alert_rule_id_values",
    "Esql.kibana_alert_risk_score_values",
    "Esql.kibana_alert_severity_values",
    "Esql.timestamp_min",
    "Esql.timestamp_max",
]

[metadata]
creation_date = "2024/04/30"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
description = """
Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the
AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may
abuse this configuration to establish persistence, create a covert execution path, or operate a function as an
unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered
high-risk when performed unexpectedly.
"""
event_category_override = "event.type"
false_positives = [
    """
    Some organizations may legitimately expose Lambda functions for cross-account or anonymous invocation (e.g., custom
    public APIs, integrations, or legacy architectures). Validate whether the function owner explicitly intended to make
    the function publicly invokable. Routine CI/CD deployments or IaC templates may also temporarily set permissive
    policies; confirm this is expected behavior before treating it as suspicious.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS Lambda Function Policy Updated to Allow Public Invocation"
note = """## Triage and analysis

### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation

AWS Lambda policies control who can invoke a function. When the `Principal` is set to `*`, the function becomes publicly invokable by any AWS account. Adversaries may modify Lambda permissions to create a stealthy execution backdoor or to maintain persistence inside an AWS environment. This activity is uncommon in most production environments and should receive careful scrutiny when detected.

### Possible investigation steps

**Identify the actor**
- Identify the actor who made the change by reviewing `aws.cloudtrail.user_identity.arn` and access key ID. Determine whether this principal typically administers Lambda functions.

**Review request details**
- Review request details in `aws.cloudtrail.request_parameters` to understand the exact permission added:
  - Confirm that the `Principal` is set to `"*"`.
  - Note the `Action` (`lambda:InvokeFunction`) and any `SourceArn` restrictions (sometimes present, often missing in malicious cases).

**Analyze source context**
- Check the source of the request using `source.ip`, geo information, and user agent. Unexpected networks, automation tools, or CLI usage may indicate credential compromise.

**Correlate timing and related events**
- Evaluate timing and sequence by correlating `@timestamp` with other events. Look for surrounding actions such as:
  - Creation or update of Lambda function code.
  - Publishing new Lambda layers.
  - Changes to roles attached to the function.

**Assess function sensitivity and impact**
- Assess the function’s role and data sensitivity. Determine whether public invocation could:
  - Enable unmonitored code execution,
  - Trigger access to internal resources via the function’s IAM role,
  - Be chained with persistence or privilege escalation behavior.

**Validate operational intent**
- Validate the operational context. Confirm with the function owner whether the permission change was intentional, part of a deployment, or unexpected.

### False positive analysis

- Public invocation may be intentional for certain workloads (e.g., webhook handlers, openly accessible compute functions). Compare the event with documentation, IaC templates, or the deployment pipeline.
- Some teams may regularly modify permissions during testing or refactoring; check whether this aligns with existing workflows.
- Evaluate whether the function already had permissive invocation policies and whether the update is part of expected configuration drift.

### Response and remediation

- Remove unauthorized public invocation permissions immediately by reverting the Lambda function policy to the approved baseline.
- Investigate for follow-on activity: execution of the function, updates to code, modifications to IAM roles, or API calls issued using the function's role.
- Rotate or disable credentials associated with the identity that issued the `AddPermission` call if compromise is suspected.
- Enable or refine monitoring for Lambda policy updates, layer additions, and code changes to detect future unauthorized modifications.
- Conduct a security review of the Lambda function and any downstream resources it can access to ensure no misuse has occurred.
- Work with the application team to enforce least-privilege invocation policies and deploy guardrails (e.g., SCPs, IAM Conditions, or automated compliance checks) preventing public invocation unless explicitly authorized.

### Additional information
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
"""
references = [
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence",
    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/",
    "https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html",
]
risk_score = 73
rule_id = "151d8f72-0747-11ef-a0c2-f661ea17fbcc"
severity = "high"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Lambda",
    "Tactic: Persistence",
    "Rule Type: Event Correlation (EQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
info where data_stream.dataset == "aws.cloudtrail" 
    and event.provider == "lambda.amazonaws.com" 
    and event.outcome == "success" 
    and event.action : "AddPermission*" 
    and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") 
    and stringContains(aws.cloudtrail.request_parameters, "principal=\\*")
    and not user_agent.original like~ ("*Terraform*", "*Pulumi*")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1578"
name = "Modify Cloud Compute Infrastructure"
reference = "https://attack.mitre.org/techniques/T1578/"

[[rule.threat.technique.subtechnique]]
id = "T1578.005"
name = "Modify Cloud Compute Configurations"
reference = "https://attack.mitre.org/techniques/T1578/005/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

[metadata]
creation_date = "2026/07/09"
integration = ["azure"]
maturity = "production"
updated_date = "2026/07/09"

[rule]
author = ["Elastic"]
description = """
Detects an identity injecting an ephemeral (debug) container into a running AKS (Azure Kubernetes Service) pod via the
pods/ephemeralcontainers subresource, excluding known AKS control-plane and platform identities. Ephemeral containers
share the target pod's namespaces and give stealthy interactive access to its processes and mounted secrets without
creating a new pod. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster
token used to attach a debug container is not excluded.
"""
false_positives = [
    """
    Operators and support tooling use ephemeral containers (kubectl debug) for legitimate troubleshooting. Baseline
    expected users and exclude verified break-glass or platform identities after review.
    """,
]
from = "now-9m"
index = ["logs-azure.platformlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure AKS Ephemeral Container Added to Pod"
note = """## Triage and analysis

### Investigating Azure AKS Ephemeral Container Added to Pod

AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. An ephemeral container is
attached to a running pod (via `kubectl debug`) and shares that pod's process and network namespaces. Adversaries use it
as a stealthier alternative to `exec` to read mounted secrets and interact with the workload.

### Possible investigation steps

- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in
  `azure.platformlogs.properties.log.user.groups`) and whether it should debug pods. A username of `masterclient` with
  the `system:masters` group is the AKS local cluster-admin certificate (`az aks get-credentials --admin`); on clusters
  with local accounts disabled it should not appear at all, so its presence is itself notable. Entra-integrated admins
  appear as their UPN/objectId instead.
- Inspect the injected container in the `azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.*`
  fields: the `image`, `command`, and `targetContainerName` show what was run and against which container, and
  `securityContext.capabilities.add` (e.g. `SYS_PTRACE`, `SYS_ADMIN`) or a privileged context indicates offensive
  debugging.
- Review `azure.platformlogs.properties.log.userAgent` to distinguish an interactive `kubectl debug` from automation or
  custom tooling, and `azure.platformlogs.properties.log.responseStatus.code` to tell a successful injection (200) from
  a denied attempt (403) by an identity lacking RBAC.
- Identify the target pod in `azure.platformlogs.properties.log.objectRef.name` /
  `azure.platformlogs.properties.log.objectRef.namespace`.
- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for related exec sessions, secret
  reads, or RBAC changes.

### False positive analysis

- Operators and support tooling use ephemeral containers for legitimate troubleshooting; baseline expected users and
  exclude verified break-glass or platform identities.

### Response and remediation

- If unauthorized, remove the ephemeral container (delete or replace the pod), revoke the acting identity's tokens, and
  review the RBAC that permitted the injection.
- Inspect the target pod for accessed secrets or tampering and rotate any exposed credentials.
- Collect kube-audit and identity artifacts per incident response procedures.
"""
references = [
    "https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container",
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
    "https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/",
]
risk_score = 47
rule_id = "d4209683-ee18-439f-b816-1bbe6ee6bbc8"
setup = """The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs`
data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft
recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Mutating
ephemeral-container writes are recorded in both categories with the same `auditID`, so clusters that enable both
categories may generate two alerts per injection.
"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: Azure",
    "Data Source: Azure Platform Logs",
    "Data Source: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.platformlogs and
  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
  azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and
  azure.platformlogs.properties.log.stage:"ResponseComplete" and
  azure.platformlogs.properties.log.objectRef.resource:"pods" and
  azure.platformlogs.properties.log.objectRef.subresource:"ephemeralcontainers" and
  azure.platformlogs.properties.log.verb:("update" or "patch") and
  not azure.platformlogs.properties.log.user.username:(
    system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or
    system\:serviceaccount\:kube-system\:*
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1610"
name = "Deploy Container"
reference = "https://attack.mitre.org/techniques/T1610/"


[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "azure.platformlogs.category",
    "azure.platformlogs.properties.log.verb",
    "azure.platformlogs.properties.log.user.username",
    "azure.platformlogs.properties.log.user.groups",
    "azure.platformlogs.properties.log.userAgent",
    "azure.platformlogs.properties.log.sourceIPs",
    "azure.platformlogs.properties.log.objectRef.namespace",
    "azure.platformlogs.properties.log.objectRef.name",
    "azure.platformlogs.properties.log.objectRef.subresource",
    "azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.name",
    "azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.image",
    "azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.command",
    "azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.targetContainerName",
    "azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.securityContext.capabilities.add",
    "azure.platformlogs.properties.log.responseStatus.code",
]

[metadata]
creation_date = "2020/12/03"
integration = ["endpoint", "windows", "system"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
This rule identifies a high number (10) of process terminations (stop, delete, or suspend) from the same host within a
short time period.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-endpoint.events.process-*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "kuery"
license = "Elastic License v2"
name = "High Number of Process and/or Service Terminations"
note = """## Triage and analysis

### Investigating High Number of Process and/or Service Terminations

Attackers can stop services and kill processes for a variety of purposes. For example, they can stop services associated with business applications and databases to release the lock on files used by these applications so they may be encrypted, or stop security and backup solutions, etc.

This rule identifies a high number (10) of service and/or process terminations (stop, delete, or suspend) from the same host within a short time period.

#### Possible investigation steps

- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Check if any files on the host machine have been encrypted.

### False positive analysis

- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Reimage the host operating system or restore it to the operational state.
- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through 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).
"""

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

references = ["https://www.elastic.co/security-labs/luna-ransomware-attack-pattern"]
risk_score = 47
rule_id = "035889c4-2686-4583-a7df-67f89c292f2c"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
event.category:process and host.os.type:windows and event.type:start and process.name:(net.exe or sc.exe or taskkill.exe) and
 process.args:(stop or pause or delete or "/PID" or "/IM" or "/T" or "/F" or "/t" or "/f" or "/im" or "/pid") and
 not process.parent.name:(osquerybeat.exe or agentbeat.exe)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1489"
name = "Service Stop"
reference = "https://attack.mitre.org/techniques/T1489/"

[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.threshold]
field = ["host.id"]
value = 10

[metadata]
creation_date = "2025/05/01"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies sign-ins on behalf of a principal user to the Microsoft Graph or legacy Azure AD API from multiple IPs using
first-party Microsoft applications from the FOCI (Family of Client IDs) group. Developer tools like Azure CLI, VSCode,
and Azure PowerShell accessing these resources from multiple IPs are flagged, along with any FOCI application accessing
the deprecated Windows Azure Active Directory from multiple IPs. This behavior may indicate an adversary using a phished
OAuth authorization code or refresh token, as seen in attacks like ConsentFix where attackers steal localhost OAuth
codes and replay them from attacker infrastructure.
"""
from = "now-60m"
interval = "59m"
language = "esql"
license = "Elastic License v2"
name = "M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs"
note = """## Triage and analysis

### Investigating M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs

This rule detects when the same user authenticates to Microsoft Graph or legacy Azure AD using FOCI applications from multiple IP addresses within a 30-minute window. This pattern is a strong indicator of OAuth code/token theft attacks like ConsentFix, where the victim completes the OAuth authorize flow on their device (first IP), and the attacker exchanges the stolen authorization code for tokens from their infrastructure (second IP).

The rule aggregates events by user, application, and resource, requiring both `OAuth2:Authorize` and `OAuth2:Token` requests from at least 2 different IPs to fire - this indicates the code was generated on one IP and exchanged on another.

### Possible investigation steps

- Review `o365.audit.UserId` to identify the affected user and determine if they are a high-value target.
- Analyze `Esql.source_ip_values` to see all unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers (AWS, Azure, GCP), or anonymizing infrastructure (Tor, VPNs).
- Use `Esql.time_window_date_trunc` to pivot into raw events and reconstruct the full sequence of resource access events with exact timestamps.
- Check `Esql.source_as_organization_name_values` for unfamiliar ASN organizations that may indicate attacker infrastructure.
- Review `Esql.o365_audit_ApplicationId_values` to confirm which first-party application was used.
- Pivot to `azure.auditlogs` to check for device join or registration events around the same timeframe, which may indicate persistence attempts.
- Correlate with `azure.identityprotection` to identify related risk detections such as anonymized IP access or token replay.
- Search for additional sign-ins from the IPs involved across other users to determine if this is part of a broader campaign.

### False positive analysis

- Developers or IT administrators working across environments (office, home, cloud VMs) may produce similar behavior.
- Users on VPN who switch servers or traveling between networks may show multiple IPs.
- Mobile users moving between cellular and WiFi networks during the time window.
- Consider correlating with device compliance status to distinguish managed vs. unmanaged access.

### Response and remediation

- If confirmed unauthorized, immediately revoke all refresh tokens for the affected user via Entra ID.
- Remove any devices registered during this session by checking `azure.auditlogs` for `Add device` events.
- Notify the user and determine whether they may have shared an OAuth code via phishing.
- Block the attacker IPs at the perimeter and add to threat intel feeds.
- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices and approved locations.
- Monitor for follow-on activity like lateral movement, privilege escalation, or data exfiltration via Graph API.
"""
references = [
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
    "https://github.com/dirkjanm/ROADtools",
    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
    "https://pushsecurity.com/blog/consentfix",
    "https://github.com/secureworks/family-of-client-ids-research",
]
risk_score = 73
rule_id = "36188365-f88f-4f70-8c1d-0b9554186b9c"
setup = """## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Email",
    "Domain: Identity",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Tactic: Defense Evasion",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-o365.audit-*
| where
    data_stream.dataset == "o365.audit" and
    event.action == "UserLoggedIn" and
    source.ip is not null and
    o365.audit.UserId is not null and
    o365.audit.ApplicationId is not null and
    o365.audit.UserType in ("0", "2", "3", "10") and
    (
        /* Developer tools accessing Graph OR Legacy AAD */
        (
            o365.audit.ApplicationId in (
                "aebc6443-996d-45c2-90f0-388ff96faa56",
                "29d9ed98-a469-4536-ade2-f981bc1d605e",
                "04b07795-8ddb-461a-bbee-02f9e1bf7b46",
                "1950a258-227b-4e31-a9cf-717495945fc2"
            ) and
            o365.audit.ObjectId in (
                "00000003-0000-0000-c000-000000000000",
                "00000002-0000-0000-c000-000000000000"
            )
        ) or
        /* Any FOCI app accessing Legacy AAD only */
        (
            o365.audit.ApplicationId in (
                "00b41c95-dab0-4487-9791-b9d2c32c80f2",
                "1fec8e78-bce4-4aaf-ab1b-5451cc387264",
                "26a7ee05-5602-4d76-a7ba-eae8b7b67941",
                "27922004-5251-4030-b22d-91ecd9a37ea4",
                "4813382a-8fa7-425e-ab75-3b753aab3abb",
                "ab9b8c07-8f02-4f72-87fa-80105867a763",
                "d3590ed6-52b3-4102-aeff-aad2292ab01c",
                "872cd9fa-d31f-45e0-9eab-6e460a02d1f1",
                "af124e86-4e96-495a-b70a-90f90ab96707",
                "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8",
                "844cca35-0656-46ce-b636-13f48b0eecbd",
                "87749df4-7ccf-48f8-aa87-704bad0e0e16",
                "cf36b471-5b44-428c-9ce7-313bf84528de",
                "0ec893e0-5785-4de6-99da-4ed124e5296c",
                "22098786-6e16-43cc-a27d-191a01a1e3b5",
                "4e291c71-d680-4d0e-9640-0a3358e31177",
                "57336123-6e14-4acc-8dcf-287b6088aa28",
                "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0",
                "66375f6b-983f-4c2c-9701-d680650f588f",
                "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223",
                "a40d7d7d-59aa-447e-a655-679a4107e548",
                "a569458c-7f2b-45cb-bab9-b7dee514d112",
                "b26aadf8-566f-4478-926f-589f601d9c74",
                "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12",
                "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0",
                "e9c51622-460d-4d3d-952d-966a5b1da34c",
                "eb539595-3fe1-474e-9c1d-feb3625d1be5",
                "ecd6b820-32c2-49b6-98a6-444530e5a77a",
                "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d",
                "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34",
                "be1918be-3fe3-4be9-b32b-b542fc27f02e",
                "cab96880-db5b-4e15-90a7-f3f1d62ffe39",
                "d7b530a4-7680-4c23-a8bf-c52c121d2e87",
                "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3",
                "e9b154d0-7658-433b-bb25-6b8e0a8a7c59"
            ) and
            o365.audit.ObjectId == "00000002-0000-0000-c000-000000000000"
        )
    )
| eval
    Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp),
    Esql.oauth_authorize_user_id_case = case(
        o365.audit.ExtendedProperties.RequestType == "OAuth2:Authorize" and o365.audit.ExtendedProperties.ResultStatusDetail == "Redirect",
        o365.audit.UserId,
        null
    ),
    Esql.oauth_token_user_id_case = case(
        o365.audit.ExtendedProperties.RequestType == "OAuth2:Token",
        o365.audit.UserId,
        null
    )
| stats
    Esql.source_ip_count_distinct = count_distinct(source.ip),
    Esql.source_ip_values = values(source.ip),
    Esql.o365_audit_ApplicationId_values = values(o365.audit.ApplicationId),
    Esql.source_as_organization_name_values = values(source.`as`.organization.name),
    Esql.oauth_token_count_distinct = count_distinct(Esql.oauth_token_user_id_case),
    Esql.oauth_authorize_count_distinct = count_distinct(Esql.oauth_authorize_user_id_case)
  by
    o365.audit.UserId,
    Esql.time_window_date_trunc,
    o365.audit.ApplicationId,
    o365.audit.ObjectId
| keep
    Esql.time_window_date_trunc,
    Esql.source_ip_values,
    Esql.source_ip_count_distinct,
    Esql.o365_audit_ApplicationId_values,
    Esql.source_as_organization_name_values,
    Esql.oauth_token_count_distinct,
    Esql.oauth_authorize_count_distinct
| where
    Esql.source_ip_count_distinct >= 2 and
    Esql.oauth_token_count_distinct > 0 and
    Esql.oauth_authorize_count_distinct > 0
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[[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/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[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.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"

[[rule.threat.technique.subtechnique]]
id = "T1566.002"
name = "Spearphishing Link"
reference = "https://attack.mitre.org/techniques/T1566/002/"

[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[metadata]
creation_date = "2020/11/30"
integration = ["o365"]
maturity = "production"
updated_date = "2026/09/10"

[rule]
author = ["Elastic", "Willem D'Haese", "Austin Songer"]
description = """
Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that
match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force
authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.
"""
false_positives = [
    """
    Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false
    positives.
    """,
]
from = "now-60m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "M365 Identity User Brute Force Attempted"
note = """## Triage and Analysis

### Investigating M365 Identity User Brute Force Attempted

Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.

### Possible investigation steps

- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins).
- Check `login_errors`: A consistent error such as `"InvalidUserNameOrPassword"` confirms a spray-style attack using one or a few passwords.
- Examine `ip_list` and `source_orgs`: Determine if the traffic originates from a known corporate VPN, datacenter, or suspicious ASN like hosting providers or anonymizers.
- Review `countries` and `unique_country_count`: Geographic anomalies (e.g., login attempts from unexpected regions) may indicate malicious automation.
- Validate `total_attempts` vs `duration_seconds`: A high frequency of login attempts over a short period may suggest automation rather than manual logins.
- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded.
- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA.

### False positive analysis

- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster.
- Penetration testing or red team simulations may resemble spray activity.
- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns.

### Response and remediation

- Initiate an internal incident ticket and inform the affected identity/IT team.
- Temporarily disable impacted user accounts if compromise is suspected.
- Investigate whether any login attempts succeeded after the spray window.
- Block the offending IPs or ASN temporarily via firewall or conditional access policies.
- Rotate passwords for all targeted accounts and audit for password reuse.
- Enforce or verify MFA is enabled for all user accounts.
- Consider deploying account lockout or progressive delay mechanisms if not already enabled.
"""
references = [
    "https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray",
    "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties",
    "https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/",
    "https://github.com/0xZDH/Omnispray",
    "https://github.com/0xZDH/o365spray",
]
risk_score = 47
rule_id = "26f68dba-ce29-497b-8e13-b4fde1db5a2d"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-o365.audit-*
| mv_expand event.category
| eval
    Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp),
    Esql_priv.o365_audit_UserId_lower = to_lower(o365.audit.UserId),
    Esql.o365_audit_LogonError = o365.audit.LogonError,
    Esql.o365_audit_ExtendedProperties_RequestType_lower = to_lower(o365.audit.ExtendedProperties.RequestType)
| where
    data_stream.dataset == "o365.audit" and
    event.category == "authentication" and
    event.provider in ("AzureActiveDirectory", "Exchange") and
    event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and
    Esql.o365_audit_ExtendedProperties_RequestType_lower rlike "(oauth.*|.*login.*)" and
    Esql.o365_audit_LogonError != "IdsLocked" and
    Esql.o365_audit_LogonError not in (
        "EntitlementGrantsNotFound",
        "UserStrongAuthEnrollmentRequired",
        "UserStrongAuthClientAuthNRequired",
        "InvalidReplyTo",
        "SsoArtifactExpiredDueToConditionalAccess",
        "PasswordResetRegistrationRequiredInterrupt",
        "SsoUserAccountNotFoundInResourceTenant",
        "UserStrongAuthExpired",
        "CmsiInterrupt"
    ) and
    Esql_priv.o365_audit_UserId_lower != "not available" and
    o365.audit.Target.Type in ("0", "2", "6", "10")
| stats
    Esql.o365_audit_UserId_lower_count_distinct = count_distinct(Esql_priv.o365_audit_UserId_lower),
    Esql_priv.o365_audit_UserId_lower_values = values(Esql_priv.o365_audit_UserId_lower),
    Esql.o365_audit_LogonError_values = values(Esql.o365_audit_LogonError),
    Esql.o365_audit_LogonError_count_distinct = count_distinct(Esql.o365_audit_LogonError),
    Esql.o365_audit_ExtendedProperties_RequestType_values = values(Esql.o365_audit_ExtendedProperties_RequestType_lower),
    Esql.source_ip_values = values(source.ip),
    Esql.source_ip_count_distinct = count_distinct(source.ip),
    Esql.source_as_organization_name_values = values(source.`as`.organization.name),
    Esql.source_geo_country_name_values = values(source.geo.country_name),
    Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name),
    Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),
    Esql.timestamp_first_seen = min(@timestamp),
    Esql.timestamp_last_seen = max(@timestamp),
    Esql.event_count = count(*)
  by Esql.time_window_date_trunc
| eval
    Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen),
    Esql.brute_force_type = case(
        Esql.o365_audit_UserId_lower_count_distinct >= 15 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_duration_seconds <= 1800, "password_spraying",
        Esql.o365_audit_UserId_lower_count_distinct >= 8 and Esql.event_count >= 15 and Esql.o365_audit_LogonError_count_distinct <= 3 and Esql.source_ip_count_distinct <= 5 and Esql.event_duration_seconds <= 600, "credential_stuffing",
        Esql.o365_audit_UserId_lower_count_distinct == 1 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 20 and Esql.event_duration_seconds <= 300, "password_guessing",
        "other"
    )
| keep
    Esql.time_window_date_trunc,
    Esql.o365_audit_UserId_lower_count_distinct,
    Esql_priv.o365_audit_UserId_lower_values,
    Esql.o365_audit_LogonError_values,
    Esql.o365_audit_LogonError_count_distinct,
    Esql.o365_audit_ExtendedProperties_RequestType_values,
    Esql.source_ip_values,
    Esql.source_ip_count_distinct,
    Esql.source_as_organization_name_values,
    Esql.source_geo_country_name_values,
    Esql.source_geo_country_name_count_distinct,
    Esql.source_as_organization_name_count_distinct,
    Esql.timestamp_first_seen,
    Esql.timestamp_last_seen,
    Esql.event_duration_seconds,
    Esql.event_count,
    Esql.brute_force_type
| where Esql.brute_force_type != "other"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[[rule.threat.technique.subtechnique]]
id = "T1110.001"
name = "Password Guessing"
reference = "https://attack.mitre.org/techniques/T1110/001/"

[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"

[[rule.threat.technique.subtechnique]]
id = "T1110.004"
name = "Credential Stuffing"
reference = "https://attack.mitre.org/techniques/T1110/004/"



[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[metadata]
creation_date = "2026/02/24"
integration = ["o365"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies file downloads or access from OneDrive or SharePoint using PowerShell-based user agents. Adversaries may use
native PowerShell cmdlets like Invoke-WebRequest or Invoke-RestMethod with Microsoft Graph API to exfiltrate data after
compromising OAuth tokens via device code phishing or other credential theft techniques. This rule detects both direct
PowerShell access and PnP PowerShell module usage for file operations. FileAccessed events are included to detect
adversaries reading file content via API and saving locally, bypassing traditional download methods. Normal users access
SharePoint/OneDrive via browsers or sync clients, making PowerShell-based file access inherently suspicious.
"""
false_positives = [
    "Legitimate automation scripts using PowerShell to interact with SharePoint or OneDrive for business purposes.",
    "IT administrators using PnP PowerShell for site management, migration, or backup operations.",
]
from = "now-9m"
index = ["filebeat-*", "logs-o365.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 SharePoint/OneDrive File Access via PowerShell"
note = """## Triage and Analysis

### Investigating M365 SharePoint/OneDrive File Access via PowerShell

This rule detects file downloads and access from OneDrive or SharePoint using PowerShell-based user agents. Threat actors commonly use device code phishing to obtain OAuth tokens, then use native PowerShell or PnP PowerShell modules to enumerate and exfiltrate files from SharePoint and OneDrive. FileAccessed events are included because adversaries may read file content via the Graph API `/content` endpoint and save locally, bypassing traditional download events.

#### Possible Investigation Steps

- Identify the user whose token was used and determine if they typically use PowerShell for file operations.
- Review the OAuth application/client ID used to authenticate. Look for public client IDs that may indicate device code phishing.
- Check the source IP address and compare with the user's typical access locations.
- Identify which SharePoint site or OneDrive was accessed.
- Correlate with Azure AD sign-in logs to determine if device code authentication was used.
- Look for rapid sequential file downloads from the same session, which may indicate bulk data exfiltration.
- Check for search activity from the same user/session that may indicate reconnaissance before download.

### False Positive Analysis

- IT administrators legitimately using PnP PowerShell for site management, migration, or backup operations.
- Automated scripts using PowerShell for legitimate data processing or synchronization tasks.
- Consider creating exceptions for known automation service accounts.

### Response and Remediation

- If unauthorized activity is confirmed, immediately revoke the OAuth token and terminate active sessions for the affected user.
- Reset the user's credentials and require reauthentication with MFA.
- Review all files accessed during the session to assess data exposure.
- Implement conditional access policies to restrict device code authentication flow.
- Consider blocking public client IDs that are not needed for business operations.
- Review and audit OAuth application permissions in your tenant.
"""
references = [
    "https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/",
    "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft",
    "https://pnp.github.io/powershell/",
]
risk_score = 73
rule_id = "491651da-125b-11f1-af7d-f661ea17fbce"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Threat Detection",
    "Tactic: Collection",
    "Tactic: Exfiltration",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "o365.audit" and
    event.provider: ("SharePoint" or "OneDrive") and
    event.action: ("FileDownloaded" or "FileAccessed") and
    event.outcome: "success" and
    user_agent.original: (*PowerShell* or *PnPPS* or *PnPCoreSDK* or *SharePointPnP*)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1213"
name = "Data from Information Repositories"
reference = "https://attack.mitre.org/techniques/T1213/"

[[rule.threat.technique.subtechnique]]
id = "T1213.002"
name = "Sharepoint"
reference = "https://attack.mitre.org/techniques/T1213/002/"

[[rule.threat.technique]]
id = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[rule.threat.tactic]
id = "TA0010"
name = "Exfiltration"
reference = "https://attack.mitre.org/tactics/TA0010/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.id",
    "user_agent.original",
    "event.action",
    "event.provider",
    "source.ip",
    "source.geo.country_name",
    "o365.audit.ApplicationId",
    "o365.audit.SiteUrl",
    "file.name",
    "file.directory",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["user.id", "user_agent.original"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[rule]
description = """
Detects Node.js executing a JavaScript file followed by immediate deletion of that script. This anti-forensics pattern
is used to execute malicious logic and then destroy the evidence, making post-incident inspection difficult. The tight
timing window between execution and deletion distinguishes this from normal cleanup or build processes.
"""
id = "1059825f-8f64-4b69-a398-2a54003d1946"
license = "Elastic License v2"
name = "Node Script Execution and Immediate Deletion"
os_list = ["linux", "windows"]
reference = ["https://www.elastic.co/security-labs/axios-supply-chain-compromise-detections"]
version = "1.0.2"

query = '''
sequence by process.entity_id with maxspan=10s
  [process where event.type == "start" and event.action in ("exec", "start") and
    process.name in ("node", "node.exe") and process.args_count <= 2 and
    process.args like~ (
      "/tmp/*.js", "/private/tmp/*.js",
      "/var/tmp/*.js", "/private/var/tmp/*.js",
      "/Users/Shared/*.js",
      "/var/folders/*/T/*.js", "/private/var/folders/*/T/*.js",
      "/Users/*/Library/Caches/*.js",
      "/dev/shm/*.js",
      "?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Temp\\\\*.js",
      "?:\\\\Windows\\\\Temp\\\\*.js",
      "?:\\\\ProgramData\\\\Temp\\\\*.js"
    )] as event0
  [file where event.action == "deletion" and file.extension : "js" and
   stringcontains~(event0.process.command_line, file.name) and
   not (
     process.executable like "/actions-runner/externals/node24/bin/node" and
     file.path like (
       "/tmp/github-runner-*/index.js",
       "/root/setup-pnpm/node_modules/.pnpm/pnpm@*/node_modules/pnpm/dist/node_modules/env-paths/index.js"
     )
   )]
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 1

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 1

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"
[[threat.technique.subtechnique]]
id = "T1070.004"
name = "File Deletion"
reference = "https://attack.mitre.org/techniques/T1070/004/"



[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[internal]
min_endpoint_version = "8.16.0"

[metadata]
creation_date = "2021/03/22"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies NullSessionPipe registry modifications that specify which pipes can be accessed anonymously. This could be
indicative of adversary lateral movement preparation by making the added pipe available to everyone.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.registry-*",
    "endgame-*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "NullSessionPipe Registry Modification"
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 NullSessionPipe Registry Modification

The NullSessionPipe registry setting in Windows defines which named pipes can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. The detection rule monitors changes to this registry path, flagging modifications that introduce new accessible pipes, which could indicate malicious intent.

### Possible investigation steps

- Review the registry event details to confirm the specific named pipes added or modified in the NullSessionPipes registry path. Focus on the registry.data.strings field to identify any new or suspicious entries.
- Correlate the timestamp of the registry change event with other security events or logs from the same host to identify any concurrent suspicious activities, such as unusual network connections or process executions.
- Investigate the user account or process responsible for the registry modification by examining the event data for user context or process identifiers. This can help determine if the change was made by an unauthorized user or malicious process.
- Check for any recent alerts or logs related to lateral movement or unauthorized access attempts on the network, focusing on the host where the registry change was detected.
- Assess the risk and impact of the modified named pipes by determining if they are commonly used in legitimate operations or if they are known to be exploited by malware or threat actors.

### False positive analysis

- Legitimate administrative tools or scripts may modify the NullSessionPipe registry setting as part of routine network management. Review the source of the change and verify if it aligns with known administrative activities.
- Some network services or applications might require anonymous access to specific pipes for functionality. Identify these services and document them to differentiate between expected and unexpected modifications.
- Scheduled tasks or automated deployment scripts could alter the registry setting during updates or installations. Ensure these tasks are documented and verify their legitimacy.
- Security software or network monitoring tools might adjust the NullSessionPipe settings for scanning purposes. Confirm with your security team if such tools are in use and adjust the detection rule to exclude these known activities.
- Regularly review and update the list of known exceptions in your detection system to prevent alert fatigue and ensure focus on genuine threats.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
- Review the registry changes to identify any unauthorized pipes added to the NullSessionPipes registry key and remove them to restore secure configurations.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software that may have been introduced.
- Analyze network logs and system event logs to identify any unauthorized access attempts or successful connections made through the modified pipes, and block any suspicious IP addresses or accounts.
- Reset credentials for any accounts that may have been compromised or used in conjunction with the unauthorized access to ensure they cannot be reused by adversaries.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected.
- Implement enhanced monitoring and alerting for changes to the NullSessionPipes registry key and similar registry paths to detect and respond to future unauthorized modifications promptly."""
references = [
    "https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/",
    "https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares",
]
risk_score = 47
rule_id = "ddab1f5f-7089-44f5-9fda-de5b11322e77"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type == "change" and
  registry.value : "NullSessionPipes" and
  length(registry.data.strings) > 0 and
  not registry.data.strings : "(empty)"
'''

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
"""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"
[[rule.threat.technique.subtechnique]]
id = "T1021.002"
name = "SMB/Windows Admin Shares"
reference = "https://attack.mitre.org/techniques/T1021/002/"



[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"


[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2024/12/16"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects the creation of Pluggable Authentication Module (PAM) shared object files in unusual directories.
Attackers may compile PAM shared object files in temporary directories, to move them to system directories later,
potentially allowing them to maintain persistence on a compromised system, or harvest account credentials.
"""
false_positives = [
    "Trusted system module updates or allowed Pluggable Authentication Module (PAM) daemon configuration changes.",
]
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
language = "eql"
license = "Elastic License v2"
name = "Pluggable Authentication Module (PAM) Creation in Unusual Directory"
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 Pluggable Authentication Module (PAM) Creation in Unusual Directory

Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats.

### Possible investigation steps

- Review the file creation event details, focusing on the file path and name to determine the exact location and nature of the PAM shared object file created.
- Investigate the process that created the file by examining the process name and its parent process to understand the context and legitimacy of the file creation.
- Check the user account associated with the process that created the file to assess if it has the necessary permissions and if the activity aligns with typical user behavior.
- Analyze recent system logs and command history for any suspicious activities or commands that might indicate an attempt to compile or move PAM modules.
- Correlate the event with other security alerts or anomalies on the system to identify potential patterns or coordinated actions that could indicate a broader compromise.
- If possible, retrieve and analyze the contents of the PAM shared object file to identify any malicious code or indicators of compromise.

### False positive analysis

- Development and testing environments may compile PAM modules in temporary directories. To manage this, exclude paths commonly used for development, such as "/tmp/dev/*" or "/var/tmp/test/*".
- Containerized applications might create PAM modules in non-standard directories. Exclude processes like "dockerd" and "containerd" to prevent false positives from container operations.
- Package managers or system update tools may temporarily store PAM modules in unusual directories during updates. Exclude paths like "/var/cache/pacman/pkg/*" or "/var/lib/dpkg/tmp.ci/*" to avoid alerts during legitimate system updates.
- Custom scripts or automation tools might generate PAM modules in user-specific directories. Identify and exclude these specific scripts or paths if they are known to be safe and necessary for operations.
- Temporary backup or recovery operations might involve copying PAM modules to non-standard locations. Exclude paths used for backups, such as "/backup/*" or "/recovery/*", if these operations are verified as secure.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Conduct a thorough review of the unusual directory where the PAM file was created to identify any other suspicious files or activities, and remove any malicious files found.
- Analyze the process that created the PAM file to determine if it was initiated by a legitimate user or process, and terminate any malicious processes.
- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges or access to sensitive systems.
- Restore the affected system from a known good backup to ensure that no malicious modifications persist.
- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create PAM files in unusual directories.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
references = [
    "https://github.com/zephrax/linux-pam-backdoor",
    "https://github.com/eurialo/pambd",
    "http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html",
    "https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html",
]
risk_score = 21
rule_id = "5c832156-5785-4c9c-a2e7-0d80d2ba3daa"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "creation" and file.name like "pam_*.so" and not file.path like (
  "/lib/security/*",
  "/lib64/security/*",
  "/lib/x86_64-linux-gnu/security/*",
  "/usr/lib/security/*",
  "/usr/lib64/security/*",
  "/usr/lib/x86_64-linux-gnu/security/*"
) and not (
  process.name in ("dockerd", "containerd", "steam", "buildkitd", "unsquashfs", "pacman", "executor") or
  file.path like (
    "/build/rootImage/nix/store/*", "/home/*/.local/share/containers/*", "/nix/store/*", "/var/lib/containerd/*",
    "/var/snap/*", "/usr/share/nix/nix/store/*", "/tmp/cura/squashfs-root/*", "/home/*/docker/*", "/tmp/containerd*",
    "/var/lib/rancher/*/agent/containerd/*", "/var/lib/lxc/*", "/var/lib/containers/storage/*", "/var/lib/checkpoint*",
    "/var/lib/docker/overlay2/*", "/srv/docker/*", "/podman/storage/*", "/opt/jail/driver-jail*", "/build/tmp/work/iot*",
    "/tmp/containers-root/*", "/cce-14/*", "/cce-usr/*", "/var/tmp/portage/*", "/media/*", "/data/var/lib/docker/overlay2/*",
    "/home/*/.cache/bazel/*", "/home/*/.cache/umu/*/SteamLinuxRuntime*"
  )
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[[rule.threat.technique.subtechnique]]
id = "T1556.003"
name = "Pluggable Authentication Modules"
reference = "https://attack.mitre.org/techniques/T1556/003/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[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.003"
name = "Pluggable Authentication Modules"
reference = "https://attack.mitre.org/techniques/T1556/003/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[metadata]
creation_date = "2026/02/25"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies a user account (often a service account) that normally logs in with high volume using one logon type
suddenly showing successful logons using a different logon type with low count. This pattern may indicate account
takeover or use of stolen credentials from a new context (e.g. interactive or network logon where only batch/service
was expected).
"""
from = "now-15m"
interval = "14m"
language = "esql"
license = "Elastic License v2"
name = "Potential Account Takeover - Mixed Logon Types"
note = """## Triage and analysis

### Investigating Potential Account Takeover - Mixed Logon Types

A high-volume account (e.g. service account tied to a specific logon type such as Batch or Network) that also shows successful logons with a different logon type and low count may indicate credential compromise and use from a new context (account takeover or misuse).

### Possible investigation steps

- Confirm with the account owner or service owner whether the additional logon type is expected (e.g. new automation, RDP for maintenance).
- Review which logon types appear in Esql.logon_type_values and which has the low count (likely the anomalous one).
- Correlate with other alerts for the same user (e.g. logon from new source IP, password changes, MFA changes).
- Check whether the account is a known service account; if so, verify if any new scripts or systems were authorized to use it.

### False positive analysis

- Legitimate expansion of use (e.g. service account also used for occasional interactive logon for troubleshooting) can trigger this. Tune thresholds (e.g. max_logon >= 1000, min_logon <= 10) or add exclusions for known service accounts with documented multi-context use.
- New scheduled tasks or automation that use a different logon type may cause a short-lived spike in the "other" logon type; review over a longer window if needed.

### Response and remediation

- If takeover or misuse is confirmed: force password reset, revoke sessions, rotate service account credentials, and restrict logon type or source where possible.
- Investigate how credentials may have been compromised and address the vector.
"""

setup = """## Setup

Audit Logon must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-logon
"""

references = ["https://attack.mitre.org/techniques/T1078/"]
risk_score = 47
rule_id = "b2c3d4e5-f6a7-5b6c-9d0e-1f2a3b4c5d6e"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index
| WHERE event.category == "authentication" and event.action == "logged-in" and winlog.event_id == "4624" and
        event.outcome == "success" and not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and
        to_lower(user.name) != "administrator"
| STATS logon_count = COUNT(*), host_names = VALUES(host.name) by user.name, user.id, winlog.logon.type
| STATS
    Esql.max_logon = MAX(logon_count),
    Esql.min_logon = MIN(logon_count),
    Esql.unique_host_count = COUNT_DISTINCT(host_names),
    Esql.host_name_values = VALUES(host_names),
    Esql.logon_type_values = VALUES(winlog.logon.type),
    Esql.count_distinct_logon_types = COUNT_DISTINCT(winlog.logon.type) by user.name, user.id

// high count of logons is often associated with service account tied to a specific service, if observed in use with a different logon type it's suspicious
| WHERE Esql.count_distinct_logon_types >= 2 and Esql.max_logon >= 1000 and (Esql.min_logon >= 1 and Esql.min_logon <= 10) and Esql.unique_host_count >= 2
| EVAL winlog.logon.type = MV_FIRST(Esql.logon_type_values), host.name = MV_FIRST(Esql.host_name_values)
| KEEP user.name, user.id, host.name, winlog.logon.type, Esql.*
'''

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"


[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"