Elastic rules: 32

[metadata]
creation_date = "2023/01/12"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/30"

[rule]
author = ["Elastic"]
description = """
Detects attempts to install or use Kali Linux via Windows Subsystem for Linux. Adversaries may enable and use WSL for
Linux to avoid detection.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Attempt to Install or Run Kali Linux via WSL"
references = [
    "https://learn.microsoft.com/en-us/windows/wsl/basic-commands",
    "https://learn.microsoft.com/en-us/windows/wsl/wsl-config",
]
risk_score = 73
rule_id = "dd34b062-b9e3-4a6b-8c0c-6c8ca6dd450e"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
(
  (process.name : "wsl.exe" and process.args : ("-d", "--distribution", "-i", "--install") and process.args : "kali*") or
  process.executable : (
    "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
    "?:\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
    "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe",

    /* Crowdstrike specific exclusion as it uses NT Object paths */
    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\packages\\kalilinux*",
    "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe",
    "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe"
  )
)
'''

note = """## Triage and analysis

### Investigating Attempt to Install or Run Kali Linux via WSL

#### Possible investigation steps

- What Kali/WSL behavior path did the alert prove?
  - Focus: alert-local `process.name`, `process.executable`, and `process.args`, separating "wsl.exe" Kali install or distro arguments from direct Kali package-path execution.
  - Hint: do not require install flags before escalating; an installed Kali distro may appear only as direct package-path launcher execution.
  - Implication: escalate when "wsl.exe" selects or installs Kali with "-d", "--distribution", "-i", or "--install", or when `process.executable` runs from KaliLinux package or WindowsApps paths without a confirmed endpoint exception; lower suspicion only when exact user, host, parent, and command path match the same previously confirmed Kali/WSL workflow.
- Is the launcher identity and parent chain credible, or does it suggest masquerading or hands-on abuse?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.command_line`.
  - Implication: escalate when unsigned, renamed, running from a user-writable non-package path, or launched by Office, browser, script, or unexpected remote-admin tooling; lower suspicion when signed Microsoft or Store WSL identity and parent workflow both fit recognized Kali/WSL use. Identity alone does not clear the behavior.
- Which account and Windows session started Kali or "wsl.exe", and does that fit the endpoint cohort?
  - Focus: `user.id`, `user.name`, `host.id`, and `process.Ext.session_info.logon_type`.
  - Implication: escalate when a non-admin user, service account, or remote/service logon starts Kali on a workstation or server cohort that does not normally run WSL; lower suspicion when account, logon type, and endpoint cohort align with a recognized developer, lab, training, or image-build pattern.
- Did process telemetry show WSL lifecycle or configuration intent around the alert?
  - Focus: surrounding process starts on `host.id`, using `process.Ext.ancestry`, `process.command_line`, and `process.parent.command_line`.
  - Hint: prefer `host.id` plus `process.entity_id`; if unavailable, use `host.id`, `process.pid`, and a tight alert-time window because PID reuse can mislead process recovery. $investigate_2 $investigate_4
  - Implication: escalate when `process.command_line` shows WSL install, shutdown, terminate, configuration editing, or stop/relaunch in the same lineage; lower suspicion when surrounding starts show only one previously confirmed distro launch and no lifecycle or configuration intent.
- Did Kali/WSL lead to Windows-visible follow-on execution?
  - Focus: child or descendant starts tied by `process.parent.entity_id` or `process.Ext.ancestry` to the alert process, reviewing `process.executable` and `process.command_line`.
  - Hint: direct child starts are high-confidence pivots; manually expand ancestry when WSL launches through intermediate hosts. $investigate_3
  - Implication: escalate for shells, archivers, credential tools, scanners, tunneling clients, Windows interop launches, or repeated distro starts; lower suspicion when visible follow-on activity stays limited to recognized setup or status commands.
- If local evidence remains suspicious or unresolved, is the same user or host repeating Kali/WSL activity elsewhere?
  - Focus: related alerts and recent process starts scoped by `user.id` or `host.id`, compared with the suspicious `process.executable` and `process.parent.command_line` pattern.
  - Hint: review user or host alerts only after local Kali/WSL evidence stays suspicious or unresolved. $investigate_0 $investigate_1
  - Implication: expand scope when the same user, host, parent chain, or Kali/WSL argument pattern appears on other endpoints or repeats outside the recognized workflow; keep scope local when exact activity stays confined to one recognized endpoint and bounded window, but do not close a suspicious local alert from recurrence alone.
- Escalate for unsupported user/host, suspicious launcher, masqueraded binary, lifecycle/configuration activity, offensive follow-on process, or spread; close only when process evidence binds to one exact recognized workflow with no contradictions; preserve evidence and escalate when mixed or incomplete.

### False positive analysis

- Developer, security-lab, training, red-team, provisioning, or image-build systems can legitimately run or install Kali under WSL. First confirm process telemetry ties `user.id` or `host.id` cohort, `process.executable`, `process.args` or package path, `process.parent.command_line`, and signer or hash identity to the same recognized workflow, with no unexpected WSL stop/relaunch, tooling, or follow-on activity. Use rosters, training, build records, owner confirmation, or inventory only as corroboration after process evidence matches; if they conflict or telemetry is incomplete, do not close as benign.
- If workflow context is missing, keep the alert unresolved unless process telemetry proves the exact same bounded user/host, parent, binary identity, and Kali argument or package-path pattern with no contradictory lifecycle or follow-on evidence.
- Before creating an exception, require recurrence for the minimum confirmed pattern: `user.id` or `host.id` cohort, `process.executable`, `process.code_signature.subject_name` or `process.hash.sha256`, `process.parent.command_line`, and the Kali-specific `process.args` or package-path `process.executable`. Avoid exceptions on `process.name`, the substring "kali", or "kali.exe" alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and document the exact workflow evidence: user and host cohort, launcher path, signer or hash identity, parent command line, and Kali argument or package-path pattern. Create an exception only after the same bounded pattern recurs without contradictory follow-on behavior.
- If suspicious but unconfirmed, export the alert and surrounding process timeline, preserve process instance IDs, command lines, binary identity, user/host/session anchors, and any WSL configuration or package paths visible in process telemetry before containment. Apply reversible containment first, such as terminating the active Kali or "wsl.exe" process, disabling the initiating account's WSL access, or running "wsl --shutdown" when operationally safe. Escalate to host isolation only if the activity spreads, reconfigures WSL, or launches offensive tooling.
- If confirmed malicious, isolate the endpoint when the identity, lineage, lifecycle, or follow-on process evidence shows active abuse. Before cleanup, record the Kali/WSL process identity, parent chain, affected `user.id` and `host.id`, package paths, and WSL configuration paths seen in command lines. Then stop active WSL instances, remove the unauthorized Kali distribution and WSL configuration changes, reset credentials exposed to the Kali environment, and scope other endpoints for the same user, launcher identity, or package-path pattern.
- Post-incident hardening should decide whether WSL is permitted for the affected endpoint cohort, restrict who can install or run WSL distributions, and retain process telemetry for Kali package paths, ".wslconfig", "wsl.conf", and "wsl.exe" lifecycle commands.
"""

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 Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "host.id",
    "user.name",
    "user.id",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.args",
    "process.pe.original_file_name",
    "process.code_signature.trusted",
    "process.code_signature.subject_name",
    "process.Ext.session_info.logon_type",
    "process.parent.entity_id",
    "process.parent.command_line",
]

[transform]

[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Same-parent process starts on this host"
description = ""
providers = [
  [
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Child process starts from the Kali or WSL process"
description = ""
providers = [
  [
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "WSL lifecycle commands on this host"
description = ""
providers = [
  [
    { excluded = false, field = "process.name", queryType = "phrase", value = "wsl.exe", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

[[rule.threat.technique]]
id = "T1202"
name = "Indirect Command Execution"
reference = "https://attack.mitre.org/techniques/T1202/"

[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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

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

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

[metadata]
creation_date = "2026/06/19"
integration = ["aws"]
maturity = "production"
updated_date = "2026/06/19"

[rule]
author = ["Elastic"]
description = """
Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or
DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once,
read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the
lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the
backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations.
"""
false_positives = [
    """
    Platform or infrastructure-as-code teams may delete empty or deprecated vaults during decommissioning, or adjust
    Vault Lock during a planned governance change (note that compliance-mode locks cannot be removed). Verify the
    principal in "aws.cloudtrail.user_identity.arn" and confirm the change aligns with an approved request. Known
    administration roles can be excluded after validation.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Backup Vault Deleted or Vault Lock Removed"
note = """## Triage and analysis

### Investigating AWS Backup Vault Deleted or Vault Lock Removed

A backup vault is the container for AWS Backup recovery points, and Vault Lock applies immutability so recovery points cannot be deleted or shortened before retention expires. "DeleteBackupVaultLockConfiguration" removes that immutability (for governance-mode locks), and "DeleteBackupVault" deletes the vault itself. Adversaries remove the lock to enable subsequent deletion of otherwise-immutable recovery points, or delete the vault to destroy backups outright. These are high-impact, rare operations and should be deliberate and tightly controlled.

### Possible investigation steps

- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip", "source.as.organization.name", and "user_agent.original" for an unexpected origin.
- Determine the affected vault from "aws.cloudtrail.request_parameters" and whether it held recovery points.
- For lock removal, check whether DeleteRecoveryPoint or DeleteBackupVault followed shortly after, indicating a staged anti-recovery sequence.
- Correlate with other destructive or evasion activity by the same principal (KMS key deletion, resource deletions, logging changes).

### False positive analysis

- Decommissioning of empty vaults or planned governance changes may match. Confirm the change is expected and exclude known administration roles on "aws.cloudtrail.user_identity.arn" after validation.

### Response and remediation

- If unauthorized, treat as a likely precursor to backup destruction: preserve remaining recovery points, re-apply Vault Lock (in compliance mode where appropriate), and engage incident response.
- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "backup:DeleteBackupVault" and "backup:DeleteBackupVaultLockConfiguration" to break-glass roles via IAM and SCPs.

### Additional information

- [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)
- [DeleteBackupVault API](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html)
- [DeleteBackupVaultLockConfiguration API](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html)
"""
references = [
    "https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html",
    "https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html",
    "https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html",
]
risk_score = 73
rule_id = "4ddac6c1-e4be-4e2b-95b5-0654cb8d423c"
setup = """This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail."""
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Backup",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "backup.amazonaws.com"
    and event.action: ("DeleteBackupVault" or "DeleteBackupVaultLockConfiguration")
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1490"
name = "Inhibit System Recovery"
reference = "https://attack.mitre.org/techniques/T1490/"


[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.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",
    "source.as.number",
    "source.as.organization.name",
    "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 = "2021/09/22"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external
identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate
to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust
manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized
modifications may allow persistent or covert access even after credentials are revoked. Monitoring  "UpdateSAMLProvider"
API activity is critical to detect potential compromise of federated trust relationships.
"""
false_positives = [
    """
    SAML Provider could be updated by a system administrator. Verify whether the user identity, user agent, and/or
    hostname should be making changes in your environment. SAML Provider updates by unfamiliar users should be
    investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM SAML Provider Updated"
note = """## Triage and analysis

### Investigating AWS IAM SAML Provider Updated

AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), 
allowing users from trusted domains to access AWS resources without separate credentials. 
Updating a SAML provider can modify the trust relationship — including the signing certificate or metadata document — 
and, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP.

This rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO), 
as normal SSO operations are filtered out. These changes can be significant because a single unauthorized update 
can affect all federated authentication in the account.

### Possible investigation steps

- **Validate the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update.
  - Confirm if the actor is part of an authorized identity management or platform engineering group.
  - Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins.

- **Assess the scope of the modification**
  - Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes.
  - Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs, 
    certificates, or assertion endpoints.
  - Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one.

- **Correlate related IAM and authentication events**
  - Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities.
  - Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update — this could indicate 
    immediate exploitation of the new configuration.
  - Check for concurrent changes to IAM roles associated with SAML federated access.

- **Confirm authorization**
  - Coordinate with your identity management team to confirm whether the SAML provider update aligns with 
    planned IdP maintenance or certificate rotation.

### False positive analysis

- **Planned SSO certificate rotation**
  - Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins. 
    Validate that the update timing aligns with planned identity provider operations.
- **Automated infrastructure processes**
  - CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment. 
    Verify whether this activity matches known automation patterns.
- **Third-party IdP integrations**
  - Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign.

### Response and remediation

- **Immediate review and containment**
  - Retrieve the current SAML provider configuration using the AWS CLI (`aws iam get-saml-provider`) 
    and compare it with the previous known-good state.
  - If unauthorized changes are confirmed, restore the previous configuration or delete the compromised provider.
  - Temporarily disable federated login access for affected roles or accounts until validation is complete.

- **Investigation and scoping**
  - Review CloudTrail logs for related IAM configuration changes, including `CreateRole`, `AttachRolePolicy`, or 
    `UpdateAssumeRolePolicy` events that may expand federated trust scope.
  - Identify any `AssumeRoleWithSAML` or `GetFederationToken` events following the update, indicating possible exploitation.
  - Cross-check logs from your external IdP to verify if unauthorized assertions or logins were attempted post-update.

- **Recovery and hardening**
  - Limit permissions to modify SAML providers (`iam:UpdateSAMLProvider`) to a dedicated identity management role.
  - Enforce change control documentation and peer review for all federation configuration changes.
  - Enable AWS Config to monitor and record SAML provider resource configuration history.

### 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)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).

"""
references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html"]
risk_score = 47
rule_id = "979729e7-0c52-4c4c-b71e-88103304a79f"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: "UpdateSAMLProvider"
    and event.outcome: "success"
    and not (source.address: "sso.amazonaws.com" and user_agent.original: "sso.amazonaws.com")
'''


[[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.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[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.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/06/18"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
description = """
Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and
aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy
attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response.
Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected
principals or outside change windows should be reviewed.
"""
false_positives = [
    """
    Lambda functions are routinely deleted during application decommissioning, environment teardown, and
    infrastructure-as-code apply/destroy cycles. Verify whether the principal in `aws.cloudtrail.user_identity.arn` and
    the deleted function are expected for the workload, and whether the change aligns with an approved maintenance or
    deployment window. Known deployment roles and automation can be excluded after validation.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
interval = "5m"
language = "kuery"
license = "Elastic License v2"
name = "AWS Lambda Function Deletion"
note = """## Triage and analysis

### Investigating AWS Lambda Function Deletion

Deleting an AWS Lambda function removes its code, configuration, published versions, and aliases. This can be a destructive action that disrupts serverless workloads and automation, or a cleanup step an adversary uses to remove a backdoor function and erase evidence after their objective is met.

This rule detects successful `DeleteFunction` calls. Investigate whether the principal and the deleted function are expected, and whether the deletion correlates with other suspicious activity.

#### Possible investigation steps

- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the deletion was performed (console, CLI, SDK, automation).
- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and environment (prod, staging, dev).
- Determine whether the deletion aligns with an approved change, decommissioning, or infrastructure-as-code destroy operation by comparing `@timestamp` against deployment and change-management records.
- Correlate with recent activity by the same principal or access key, such as `CreateFunction`, `UpdateFunctionCode`, `AddPermission`, `CreateEventSourceMapping`, log-group deletions, or other destructive or evasive actions.
- Verify whether multiple functions were deleted in a short window, which may indicate broad disruption rather than a single planned change.

### False positive analysis

- Function deletions are common during decommissioning and infrastructure-as-code apply/destroy cycles. Deletions by approved deployment roles, CI/CD pipelines, or platform automation are expected. Tune on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation.

### Response and remediation

- If the deletion is unauthorized, restore the function from source control or an infrastructure-as-code definition and confirm its code, configuration, and execution role match a known-good state.
- Review CloudTrail for related destructive or evasive actions by the same actor and assess operational impact.
- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:DeleteFunction` to a small set of trusted roles.

### Additional information

- [DeleteFunction API](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)
"""
references = [
    "https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html",
    "https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html",
]
risk_score = 21
rule_id = "bb3ac0e3-2c9c-4069-a26d-75ca6a6e547b"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Lambda",
    "Tactic: Impact",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "lambda.amazonaws.com"
    and event.action: (DeleteFunction or DeleteFunction20*)
    and event.outcome: "success"
    and not user_agent.original: (*Terraform* or *Pulumi*)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1485"
name = "Data Destruction"
reference = "https://attack.mitre.org/techniques/T1485/"

[[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.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",
    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. 
This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors.
"""
false_positives = [
  """
  External account IDs or broken automation may trigger this rule. For AccessDenied (HTTP 403 Forbidden), S3 doesn't charge the bucket owner when the request is initiated outside of the bucket owner's individual AWS account or the bucket owner's AWS organization.
  """]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS S3 Bucket Enumeration or Brute Force"
note = """
## Triage and analysis

### Investigating AWS S3 Bucket Enumeration or Brute Force

This rule detects when many failed S3 operations (HTTP 403 AccessDenied) hit a single bucket from a single source address in a short window. This can indicate bucket name enumeration, object/key guessing, or brute-force style traffic intended to drive cost or probe for misconfigurations. 403 requests from outside the bucket owner’s account/organization are not billed, but 4XX from inside the owner’s account/org can still incur charges. Prioritize confirming who is making the calls and where they originate.

#### Possible investigation steps

- **Investigate in Timeline.** Investigate the alert in timeline (Take action -> Investigate in timeline) to retrieve and review all of the raw CloudTrail events that contributed to the threshold alert. Threshold alerts only display the grouped fields; Timeline provides a way to see individual event details such as request parameters, full error messages, and additional user context.  

- **Confirm entity & target.** Note the rule’s threshold and window. Identify the target bucket (`tls.client.server_name`) and the source (`source.address`). Verify the caller identity details via any available `aws.cloudtrail.user_identity` fields.  

- **Actor & session context.** In CloudTrail events, pivot 15–30 minutes around the spike for the same `source.address` or principal. Determine if the source is:
  - **External** to your account/organization (recon/cost DDoS risk is lower for you due to 2024 billing change).  
  - **Internal** (same account/org)—higher cost risk and possible misuse of internal automation.  

- **Bucket posture snapshot.** Record S3 Block Public Access, Bucket Policy, ACLs, and whether Versioning/Object Lock are enabled. Capture any recent `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, or lifecycle changes.  

- **Blast radius.** Check for similar spikes to other buckets/regions, or parallel spikes from the same source. Review any GuardDuty S3 findings and AWS Config drift related to the bucket or principal.  

- **Business context.** Contact the bucket/app owner. Validate whether a migration, scanner, or broken job could legitimately cause bursts.  

### False positive analysis

- **Expected jobs / broken automation.** Data movers, posture scanners, or failed credentials can generate 403 storms. Validate with `userAgent`, ARNs, change windows, and environment (dev/stage vs prod).  
- **External probing.** Internet-origin enumeration often looks like uniform 403s from transient or cloud-provider IPs and typically has no business impact and no billing if outside your account/org. Tune thresholds or allowlist known scanners if appropriate.  

### Response and remediation

**Immediate, low-risk actions**
- **Preserve evidence.** Export CloudTrail records (±30 minutes) for the bucket and source address into an evidence bucket with restricted access.  
- **Notify owners.** Inform the bucket/application owner and security lead; confirm any maintenance windows.  

**Containment options**
- **External-origin spikes:** Verify Block Public Access is enforced and bucket policies are locked down. Optionally apply a temporary deny-all bucket policy allowing only IR/admin roles while scoping.  
- **Internal-origin spikes:** Identify the principal. Rotate access keys for IAM users, or restrict involved roles (temporary deny/SCP, remove risky policies). Pause broken jobs/pipelines until validated.  

**Scope & hunting**
- Review Timeline and CloudTrail for related events: `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, lifecycle changes, unusual `PutObject`/`DeleteObject` volumes, or cross-account access.  
- Check GuardDuty S3 and Config drift findings for signs of tampering or lateral movement.  

**Recovery & hardening**
- If data impact suspected: with Versioning, restore known-good versions; otherwise, recover from backups/replicas.  
- Enable Versioning on critical buckets going forward; evaluate Object Lock legal hold if enabled.  
- Ensure Block Public Access, least-privilege IAM policies, CloudTrail data events for S3, and GuardDuty protections are consistently enforced.  

### Additional information

- [AWS S3 billing for error responses](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorCodeBilling.html): see latest AWS docs on which error codes are billed.  
- [AWS announcement (Aug 2024)](https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/): 403s from outside the account/org are not billed.  
- [AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/): NIST-aligned template for evidence, containment, eradication, recovery, post-incident. 
- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/): Practical response steps for account and bucket-level abuse.  
"""
references = [
    "https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1",
    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorCodeBilling.html",
]
risk_score = 21
rule_id = "5f0234fd-7f21-42af-8391-511d5fd11d5c"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS S3",
    "Resources: Investigation Guide",
    "Use Case: Log Auditing",
    "Tactic: Impact",
    "Tactic: Discovery",
    "Tactic: Collection",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
  data_stream.dataset: "aws.cloudtrail" and 
  event.provider : "s3.amazonaws.com" and 
  aws.cloudtrail.error_code : "AccessDenied" and 
  tls.client.server_name : * 
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "source.address",
    "aws.cloudtrail.user_identity.type",
    "tls.client.server_name"
]

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

[[rule.threat.technique]]
id = "T1657"
name = "Financial Theft"
reference = "https://attack.mitre.org/techniques/T1657/"

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

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

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

[[rule.threat.technique]]
id = "T1619"
name = "Cloud Storage Object Discovery"
reference = "https://attack.mitre.org/techniques/T1619/"

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

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

[[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.threshold]
field = ["tls.client.server_name", "source.address", "aws.cloudtrail.user_identity.type"]
value = 1
[[rule.threshold.cardinality]]
field = "event.id"
value = 40

[rule]
description = """
Identifies attempts to perform memory changes in the address space of a remote process and where the call stack is
truncated. This behavior is consistent with remote code injection attacks.
"""
id = "002d9a6d-c09e-4d3f-a1c1-05b92dbdbb67"
license = "Elastic License v2"
name = "Cross Process API Activity with Truncated Stack"
os_list = ["windows"]
version = "1.0.5"

query = '''
api where process.Ext.api.behaviors == "cross-process" and process.Ext.api.behaviors == "truncated_stack" and
 process.Ext.api.name in ("WriteProcessMemory", "VirtualAllocEx", "VirtualProtectEx") and process.Ext.api.parameters.size >= 10000 and
 process.executable != null and Target.process.executable != null and
 not (process.executable : "C:\\Windows\\System32\\lsass.exe" and process.parent.executable : "C:\\Windows\\System32\\wininit.exe") and
 not process.executable : ("C:\\Program Files\\McAfee\\Endpoint Security\\Threat Prevention\\mfetp.exe",
                           "C:\\Program Files (x86)\\CheckPoint\\Endpoint Security\\EFR\\EFRService.exe",
                           "C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe",
                           "C:\\Program Files (x86)\\360\\Total Security\\safemon\\QHActiveDefense.exe",
                           "C:\\Program Files\\Palo Alto Networks\\DEM\\bin\\mtr.exe",
                           "C:\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\AcroRd32.exe",
                           "C:\\Program Files (x86)\\Globus Connect Personal\\bin\\ext\\relaytool.exe",
                           "C:\\Program Files (x86)\\Adobe\\Acrobat *\\Acrobat\\AcroRd32.exe",
                           "C:\\Program Files\\Git\\usr\\bin\\bash.exe",
                           "C:\\Program Files\\Git\\usr\\bin\\sh.exe",
                           "C:\\Program Files\\Git\\usr\\bin\\mintty.exe",
                           "C:\\Program Files\\ESET\\ESET Security\\ekrn.exe",
                           "C:\\Program Files (x86)\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe",
                           "C:\\Program Files (x86)\\Globus Connect Personal\\bin\\ext\\relaytool.exe") and
 not (process.name : "bash.exe" and Target.process.name : "bash.exe" and process.Ext.api.metadata.target_address_name like ("Data", "cyg*.dll")) and 
 not (process.name : "perl.exe" and Target.process.name : "perl.exe" and process.Ext.api.metadata.target_address_name like ("Data", "cyg*.dll", "posix.dll*", "msxml3.dll")) and 
 not (process.name : "ssh.exe" and Target.process.name : "ssh.exe" and process.Ext.api.metadata.target_address_name like ("Data", "msys-*.dll", "cyg*.dll")) and 
 not (process.name : "sh.exe" and Target.process.name : "sh.exe" and process.Ext.api.metadata.target_address_name like ("Data", "cyg*.dll")) and 
 not (process.Ext.api.name == "WriteProcessMemory" and process.executable : "C:\\GEservice\\cygwin\\bin\\perl.exe" and 
      Target.process.executable : "C:\\GEservice\\cygwin\\bin\\perl.exe" and process.Ext.token.integrity_level_name == "system") and
 not (process.Ext.api.summary == "WriteProcessMemory( ssh.exe, Data, 0x3c80 )" and process.name == "relaytool.exe")
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"


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

[internal]
min_endpoint_version = "8.14.2"

[rule]
description = """
This rule detects DNS queries to IP lookup services via living-off-the-land executables or executables in
world/user-writable directories. Malware authors may use these services to determine the external IP address of the
target system.
"""
id = "8c369444-97f3-4624-a772-d1091e14a809"
license = "Elastic License v2"
name = "DNS Request to IP Lookup Service from Suspicious Working Directory"
os_list = ["linux"]
version = "1.0.5"

query = '''
sequence by process.entity_id with maxspan=10s
  [process where event.type == "start" and event.action == "exec" and (
    (
      (
        process.name in ("curl", "wget", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox", "timeout", "env") or
        process.name like (".*", "python*", "perl*", "php*", "ruby*", "lua*", "node", "deno")
      ) and
      process.working_directory like (
        "/tmp*", "/var/tmp*", "/dev/shm*", "/run*", "/var/run*", "/boot*", "/sys*", "/lost+found*",
        "/proc*", "/var/mail*"
      )
    ) or
    process.executable like (
      "./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/boot/*", "/sys/*",
      "/lost+found/*", "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*"
    ) 
  ) and
  not (
    process.executable like (
      "/root/.cache/ms-playwright/*/chrome-linux64/chrome", "/root/.cache/ms-playwright/*/chrome-headless-shell-linux64/chrome-headless-shell",
      "/home/*/.local/share/Steam/*/wine64-preloader", "/home/*/Downloads/firefox-*/firefox/firefox-bin",
      "/home/*/.local/share/uv/python/*/bin/python*", "/home/*/.local/bin/uv", "/home/*/.cache/rod/browser/chromium-*/chrome",
      "/home/*/bin/firefox/firefox-bin", "/home/*/.cache/ms-playwright/chromium-*/chrome-linux64/chrome",
      "/opt/plesk/php/*/bin/php"
    ) or
    process.parent.executable like ("/usr/bin/runc", "/home/*/.vscode-server/cli/servers/Stable-*/server/node", "/usr/local/go/bin/go") or
    (process.parent.name == "timeout" and process.name == "php") or
    process.parent.args == "/var/scripts/setup_secure_permissions_nextcloud.sh" or
    process.args like "/home/*/.ansible/tmp/ansible-tmp-*/AnsiballZ_get_url.py"
  )]
  [dns where event.action == "lookup_result" and dns.question.name like~ (
    "*.geojs.io", "*api.2ip.ua", "*api.db-ip.com", "*api.ip.sb", "*api.ipify.org", "*api.myip.com",
    "*api.npoint.io", "*api64.ipify.org", "*bot.whatismyipaddress.com", "*checkip.amazonaws.com",
    "*checkip.dyndns.org", "*curlmyip.com", "*eth0.me", "*freegeoip.app", "*freegeoip.net",
    "*freeipapi.com", "*geoiptool.com", "*geolocation-db.com", "*httpbin.org",
    "*icanhazip.com", "*ident.me", "*ifcfg.me", "*ifconfig.me", "*inet-ip.info", "*ip-api.com",
    "*ip.appspot.com", "*ip.tyk.nu", "*ip4.seeip.org", "*ipecho.net", "*ipinfo.io", "*iplogger.*",
    "*ipof.in", "*ipwho.is", "*ipwhois.app", "*ipv4.icanhazip.com", "*ipv6.icanhazip.com",
    "*myip.dnsomatic.com", "*myip.ipip.net", "*myip.opendns.com", "*portmap.io", "*wgetip.com",
    "*whatismyip.akamai.com", "*wtfismyip.com"
  )]
'''

min_endpoint_version = "9.3.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 = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"
[[threat.technique.subtechnique]]
id = "T1071.004"
name = "DNS"
reference = "https://attack.mitre.org/techniques/T1071/004/"


[[threat.technique]]
id = "T1102"
name = "Web Service"
reference = "https://attack.mitre.org/techniques/T1102/"


[threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[internal]
min_endpoint_version = "9.3.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies native Windows host and network enumeration commands spawned by the Windows Management Instrumentation
Provider Service (WMIPrvSE).
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Enumeration Command Spawned via WMIPrvSE"
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 Enumeration Command Spawned via WMIPrvSE

Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute enumeration commands stealthily, leveraging the WMI Provider Service (WMIPrvSE) to gather system and network information. The detection rule identifies suspicious command executions initiated by WMIPrvSE, focusing on common enumeration tools while excluding benign use cases, thus highlighting potential malicious activity.

### Possible investigation steps

- Review the process command line details to understand the specific enumeration command executed and its arguments, focusing on the process.command_line field.
- Investigate the parent process to confirm it is indeed WMIPrvSE by examining the process.parent.name field, ensuring the execution context aligns with potential misuse of WMI.
- Check the user context under which the process was executed to determine if it aligns with expected administrative activity or if it suggests unauthorized access.
- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities, such as lateral movement or privilege escalation attempts.
- Assess the network activity from the host around the time of the alert to identify any unusual outbound connections or data exfiltration attempts.
- Verify if the process execution is part of a known and legitimate administrative task or script by consulting with system administrators or reviewing change management records.

### False positive analysis

- Routine administrative tasks using WMI may trigger the rule, such as network configuration checks or system diagnostics. To manage this, identify and exclude specific command patterns or arguments that are part of regular maintenance.
- Security tools like Tenable may use WMI for legitimate scans, which can be mistaken for malicious activity. Exclude processes with arguments related to known security tools, such as "tenable_mw_scan".
- Automated scripts or scheduled tasks that perform system enumeration for inventory or monitoring purposes can cause false positives. Review and whitelist these scripts by excluding their specific command lines or parent processes.
- Certain enterprise applications may use WMI for legitimate operations, such as querying system information. Identify these applications and create exceptions based on their process names or command line arguments.
- Regular use of network utilities by IT staff for troubleshooting can be flagged. Implement exclusions for known IT user accounts or specific command line patterns used during these activities.

### Response and remediation

- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified as being spawned by WMIPrvSE, especially those matching the enumeration tools listed in the detection query.
- Conduct a thorough review of recent WMI activity on the affected system to identify any additional unauthorized or suspicious commands executed.
- Reset credentials for any accounts that may have been compromised or used in the suspicious activity to prevent further unauthorized access.
- Restore the system from a known good backup if any malicious activity is confirmed and cannot be remediated through other means.
- Implement additional monitoring on the affected system and network to detect any recurrence of similar suspicious activities.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems."""
risk_score = 21
rule_id = "770e0c4d-b998-41e5-a62e-c7901fd7f470"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and process.command_line != null and
  process.name:
  (
    "arp.exe", "dsquery.exe", "dsget.exe", "gpresult.exe", "hostname.exe", "ipconfig.exe", "nbtstat.exe",
    "net.exe", "net1.exe", "netsh.exe", "netstat.exe", "nltest.exe", "ping.exe", "qprocess.exe", "quser.exe",
    "qwinsta.exe", "reg.exe", "sc.exe", "systeminfo.exe", "tasklist.exe", "tracert.exe", "whoami.exe"
  ) and
  process.parent.name:"wmiprvse.exe" and
  not (
    process.name : "sc.exe" and process.args : "RemoteRegistry" and process.args : "start=" and
    process.args : ("demand", "disabled")
  ) and
  not process.args : "tenable_mw_scan"
'''

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 Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""


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

[[rule.threat.technique]]
id = "T1047"
name = "Windows Management Instrumentation"
reference = "https://attack.mitre.org/techniques/T1047/"

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

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

[[rule.threat.technique]]
id = "T1007"
name = "System Service Discovery"
reference = "https://attack.mitre.org/techniques/T1007/"

[[rule.threat.technique]]
id = "T1012"
name = "Query Registry"
reference = "https://attack.mitre.org/techniques/T1012/"

[[rule.threat.technique]]
id = "T1016"
name = "System Network Configuration Discovery"
reference = "https://attack.mitre.org/techniques/T1016/"

[[rule.threat.technique.subtechnique]]
id = "T1016.001"
name = "Internet Connection Discovery"
reference = "https://attack.mitre.org/techniques/T1016/001/"

[[rule.threat.technique]]
id = "T1018"
name = "Remote System Discovery"
reference = "https://attack.mitre.org/techniques/T1018/"

[[rule.threat.technique]]
id = "T1033"
name = "System Owner/User Discovery"
reference = "https://attack.mitre.org/techniques/T1033/"

[[rule.threat.technique]]
id = "T1049"
name = "System Network Connections Discovery"
reference = "https://attack.mitre.org/techniques/T1049/"

[[rule.threat.technique]]
id = "T1057"
name = "Process Discovery"
reference = "https://attack.mitre.org/techniques/T1057/"

[[rule.threat.technique]]
id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"

[[rule.threat.technique]]
id = "T1087"
name = "Account Discovery"
reference = "https://attack.mitre.org/techniques/T1087/"

[[rule.threat.technique]]
id = "T1518"
name = "Software Discovery"
reference = "https://attack.mitre.org/techniques/T1518/"

[[rule.threat.technique]]
id = "T1615"
name = "Group Policy Discovery"
reference = "https://attack.mitre.org/techniques/T1615/"

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

[metadata]
creation_date = "2023/05/12"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/07/29"

[rule]
author = ["Elastic"]
description = """
This rule detects 'exec' events launched against a container using the 'exec' command. Using the 'exec'
command in a pod allows a user to establish a temporary shell session and execute any process/command inside the
container. This rule specifically targets higher-risk commands that allow real-time interaction with a
container's shell. A malicious actor could use this level of access to further compromise the container environment or
attempt a container breakout.
"""
false_positives = [
    """
    An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from
    Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands
    inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ...
    ${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec
    cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell
    connected to the terminal: kubectl exec -i -t cassandra -- sh
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Exec Into Container Detected via Defend for Containers"
note = """## Setup

## 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 Exec Into Container Detected via Defend for Containers

In containerized environments, the 'exec' command is used to run processes inside a running container, often for debugging or administrative tasks. Adversaries may exploit this to gain shell access, potentially leading to further compromise or container escape. The detection rule identifies such activities by monitoring for 'exec' sessions, focusing on initial processes within containers, and flagging high-risk interactions.

### Possible investigation steps

- Review the container.id to identify which specific container the interactive exec command was executed against and gather information about its purpose and criticality.
- Examine the process.entry_leader.entry_meta.type to confirm that the process was indeed initiated within a container environment, ensuring the context of the alert is accurate.
- Investigate the process.entry_leader.same_as_process field to verify that the process in question is the initial process run in the container, which may indicate a new or unexpected session.
- Check for any recent changes or deployments in the container environment that might explain the interactive session, such as updates or debugging activities.
- Correlate the event with user activity logs to identify the user or service account responsible for initiating the exec command and assess their access permissions and recent actions.
- Investigate any subsequent actions or commands executed within the container following the interactive session to identify potential malicious activities or attempts at container breakout.

### False positive analysis

- Routine administrative tasks may trigger the rule when system administrators use 'kubectl exec' for legitimate maintenance or debugging. To manage this, create exceptions for known administrator accounts or specific maintenance windows.
- Automated scripts or monitoring tools that use 'exec' for health checks or logging purposes can also cause false positives. Identify these scripts and exclude their associated processes or user accounts from triggering the rule.
- Development and testing activities often involve frequent use of 'exec' commands for container interaction. Consider excluding specific development environments or user roles from the rule to reduce noise.
- Continuous integration/continuous deployment (CI/CD) pipelines might use 'exec' to deploy or test applications within containers. Exclude these pipeline processes or service accounts to prevent false alerts.
- If certain containers are known to require frequent interactive access for legitimate reasons, consider tagging these containers and configuring the rule to ignore interactions with them.

### Response and remediation

- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the environment. This can be done by pausing or stopping the container.
- Review and terminate any unauthorized or suspicious interactive sessions identified by the alert to cut off the adversary's access.
- Conduct a thorough analysis of the container's filesystem and running processes to identify any malicious scripts or binaries that may have been introduced during the interactive session.
- Revert the container to a known good state by redeploying it from a trusted image, ensuring that any potential backdoors or malicious modifications are removed.
- Implement network segmentation and access controls to limit the ability of users to execute 'exec' commands on containers, especially for high-risk or production environments.
- Escalate the incident to the security operations team for further investigation and to determine if additional containers or systems have been compromised.
- Enhance monitoring and alerting for similar activities by ensuring that all interactive 'exec' commands are logged and reviewed, and consider implementing stricter access controls for container management tools like kubectl."""
references = [
    "https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/",
    "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/",
]
risk_score = 21
rule_id = "420e5bb4-93bf-40a3-8f4a-4cc1af90eca1"
severity = "low"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
process.entry_leader.entry_meta.type == "container" and

/* process is the initial process run in a container */
process.entry_leader.same_as_process == true and
container.id like "*"
'''

[[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.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[[rule.threat.technique]]
id = "T1609"
name = "Container Administration Command"
reference = "https://attack.mitre.org/techniques/T1609/"

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

[metadata]
bypass_bbr_timing = true
creation_date = "2023/10/11"
integration = ["github"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Detects a new IP address used for a GitHub PAT not previously seen in the last 14 days.\n"
from = "now-9m"
index = ["logs-github.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Occurrence of IP Address For GitHub Personal Access Token (PAT)"
risk_score = 21
rule_id = "fc909baa-fb34-4c46-9691-be276ef4234c"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Initial Access",
    "Rule Type: BBR",
    "Data Source: Github",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.dataset:"github.audit" and event.category:"configuration" and
github.actor_ip:* and github.hashed_token:* and
github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token")
'''


[[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.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.new_terms]
field = "new_terms_fields"
value = ["github.hashed_token", "github.actor_ip"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2023/08/29"
integration = ["github"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule detects setting modifications for protected branches of a GitHub repository. Branch protection rules can be
used to enforce certain workflows or requirements before a contributor can push changes to a branch in your repository.
Changes to these protected branch settings should be investigated and verified as legitimate activity. Unauthorized
changes could be used to lower your organization's security posture and leave you exposed for future attacks.
"""
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "GitHub Protected Branch Settings Changed"
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 GitHub Protected Branch Settings Changed

GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation.

### Possible investigation steps

- Review the GitHub audit logs to identify the specific changes made to the protected branch settings, focusing on entries where event.dataset is "github.audit" and github.category is "protected_branch".
- Determine the user account responsible for the changes by examining the audit log details, and verify if the account has a legitimate reason to modify branch protection settings.
- Check the timing of the changes to see if they coincide with any other suspicious activities or known incidents within the organization.
- Investigate the context of the change by reviewing recent pull requests or commits to the affected branch to assess if the changes align with ongoing development activities.
- Communicate with the repository owner or relevant team members to confirm if the changes were authorized and necessary for current project requirements.
- Evaluate the impact of the changes on the repository's security posture and consider reverting the changes if they were unauthorized or pose a security risk.

### False positive analysis

- Routine updates by trusted team members may trigger alerts. To manage this, create exceptions for specific users or teams who regularly update branch protection settings as part of their role.
- Automated tools or scripts that modify branch settings for legitimate reasons can cause false positives. Identify these tools and whitelist their activities in the monitoring system.
- Scheduled maintenance or policy updates might lead to expected changes in branch protection settings. Document these events and adjust the detection rule to ignore changes during these periods.
- Changes made by administrators during onboarding or offboarding processes can be mistaken for unauthorized activity. Ensure these processes are well-documented and communicated to the security team to prevent unnecessary alerts.

### Response and remediation

- Immediately revert any unauthorized changes to the protected branch settings to restore the original security posture.
- Conduct a review of recent commits and merges to the affected branch to identify any unauthorized code changes that may have occurred during the period of altered settings.
- Temporarily restrict access to the repository for users who made unauthorized changes until a full investigation is completed.
- Notify the security team and relevant stakeholders about the incident for further analysis and to determine if additional security measures are needed.
- Implement additional monitoring on the affected repository to detect any further unauthorized changes or suspicious activities.
- Review and update access controls and permissions for the repository to ensure that only authorized personnel can modify branch protection settings.
- Document the incident, including the timeline of events and actions taken, to improve future response efforts and update incident response plans."""
risk_score = 47
rule_id = "07639887-da3a-4fbf-9532-8ce748ff8c50"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
configuration where data_stream.dataset == "github.audit"
  and github.category == "protected_branch" and event.type == "change"
'''


[[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]
description = """
Identifies the transfer of a library via SMB followed by loading it into commonly DLL proxy execution binaries such as
rundll32, regsvr32 and shared services via svchost.exe. This may indicate an attempt to remotely execute malicious code.
"""
id = "fdf66d17-0e2e-4667-a145-620bc1204c69"
license = "Elastic License v2"
name = "ImageLoad of a File dropped via SMB"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion",
]
version = "1.0.36"

query = '''
sequence with maxspan=5m
  [ file where event.action != "deletion" and
   /* library dropped via SMB */
   process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and
   (file.extension : ("dll", "cpl", "ocx") or (file.Ext.header_bytes : "4d5a*" and not file.extension : "exe")) ] by file.path
  [ library where dll.hash.sha256 != null and not dll.code_signature.trusted == true and
    (process.name : ("rundll32.exe", "svchost.exe", "lsass.exe") or
     process.executable :
              ("?:\\WINDOWS\\system32\\PerceptionSimulation\\PerceptionSimulationService.exe",
               "?:\\Program Files*\\Windows NT\\Accessories\\wordpad.exe")) and

    /* unsigned with diverse file hashes */
    not (dll.path : "?:\\Windows\\VeeamVssSupport\\VeeamVssHook.dll" and process.executable : "?:\\Windows\\System32\\svchost.exe") and
    not dll.hash.sha256 :
             ("ca329f3db5479be602c2d456f0dafc023c5e744b1454a4215b45761371ffd857",
              "880fe8b7e7e0276ca9f010a30aad003accc1b3f12e0ac50e2f12b3774b8c2aac",
              "a28d2f62629b6926211a2f8245ce2d0ab47d64f6680e6494720e04a13ab6ee1e", 
              "ad46d50fdd0764ee0626beb9720d9b1a00266404189dd99cf18eaf1545d7b43b", 
              "f9ff91b05b5e705464d364226ba5e40b9256f4720f3f9281247c7ce19f311f12",
              "fab84acf7d285984bb61fa655c24973de89b2234b7ba002954ba315fb2b9c90c",
              "b628784e41989e5ba2f96beec98c42fc32d15fc2de03187f6c50cc6705b57166",
              "2d64b8e67e97ccd363d26a5ee3acbb9fe949d2f7f22ae6dc134645972c3f43d9",
              "5e40b53733105e98ad2914bfb2f0dda52e3b9b3c87d82bf4ff092f1bed25cd13",
              "6d859a89e80f290249b9b1a7aaea3929d999f1f15b99089f88d5e5120e23a6d8",
              "2c611395ad89e8653533e6c1b8815720f7fb4c043197e52c93d983b3e3726226",
              "ce77f9afb4942b85a0bfa1ccb41c0b599f0275e56c6ed2e9699dada6b08989d3",
              "3fbe9db285c0248d5d50e832a1c2312e3eb3490607a09cbf9962aa64b8edc3e7",
              "8ed521e3a1e15a85e8043aafef7b69873de69c388bbcbf12f42777134af32751") and
    not dll.pe.imphash : "c7606b6181f4b33c77e536a70d7b354c"
    ] by dll.path
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[threat.technique.subtechnique]]
id = "T1218.010"
name = "Regsvr32"
reference = "https://attack.mitre.org/techniques/T1218/010/"

[[threat.technique.subtechnique]]
id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"



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



[threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

[internal]
min_endpoint_version = "7.16.0"

[metadata]
creation_date = "2023/09/14"
integration = ["dga", "endpoint", "network_traffic"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
A supervised machine learning model has identified a DNS question name with a high probability of sourcing from a Domain
Generation Algorithm (DGA), which could indicate command and control network activity.
"""
from = "now-10m"
index = ["logs-endpoint.events.*", "logs-network_traffic.*"]
language = "kuery"
license = "Elastic License v2"
name = "Machine Learning Detected a DNS Request With a High DGA Probability Score"
references = [
    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
    "https://docs.elastic.co/en/integrations/dga",
    "https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration",
]
risk_score = 21
rule_id = "da7f5803-1cd4-42fd-a890-0173ae80ac69"
setup = """## Setup

The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.

### DGA Detection Setup
The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.

#### Prerequisite Requirements:
- Fleet is required for DGA Detection.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
- DNS events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint), [Network Packet Capture](https://docs.elastic.co/integrations/network_traffic) integration, or [Packetbeat](https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html).
- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
- To add the Network Packet Capture integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
- To set up and run Packetbeat, follow [this](https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html) guide.

#### The following steps should be executed to install assets associated with the DGA Detection integration:
- Go to the Kibana homepage. Under Management, click Integrations.
- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it.
- Follow the instructions under the **Installation** section.
- For this rule to work, complete the instructions through **Configure the ingest pipeline**.
"""
severity = "low"
tags = [
    "Domain: Network",
    "Domain: Endpoint",
    "Data Source: Elastic Defend",
    "Use Case: Domain Generation Algorithm Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
ml_is_dga.malicious_probability > 0.98
'''
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 Machine Learning Detected a DNS Request With a High DGA Probability Score

Machine learning models analyze DNS requests to identify patterns indicative of Domain Generation Algorithms (DGAs), often used by attackers to establish command and control channels. These algorithms generate numerous domain names, making detection challenging. The detection rule leverages a model to flag DNS queries with high DGA probability, aiding in identifying potential malicious activity.

### Possible investigation steps

- Review the DNS query logs to identify the specific domain name associated with the high DGA probability score and gather additional context about the request, such as the timestamp and the source IP address.
- Cross-reference the identified domain name with threat intelligence databases to determine if it is a known malicious domain or associated with any known threat actors or campaigns.
- Investigate the source IP address to determine if it belongs to a legitimate user or system within the network, and check for any unusual or suspicious activity associated with this IP address.
- Analyze network traffic logs to identify any additional communication attempts to the flagged domain or other suspicious domains, which may indicate further command and control activity.
- Check endpoint security logs for any signs of compromise or suspicious behavior on the device that initiated the DNS request, such as unexpected processes or connections.
- Consider isolating the affected system from the network if there is strong evidence of compromise, to prevent further potential malicious activity while conducting a deeper forensic analysis.

### False positive analysis

- Legitimate software updates or services may use domain generation techniques for load balancing or redundancy, leading to false positives. Users can create exceptions for known update services or trusted software to reduce these alerts.
- Content delivery networks (CDNs) often use dynamically generated domains to optimize content delivery, which might be flagged. Identifying and whitelisting these CDN domains can help minimize unnecessary alerts.
- Some security tools and applications use DGA-like patterns for legitimate purposes, such as generating unique identifiers. Users should verify the source and purpose of these requests and consider excluding them if they are confirmed to be non-threatening.
- Internal testing environments or development tools might generate domains that resemble DGA activity. Users can exclude these environments from monitoring or adjust the rule to ignore specific internal IP ranges or domain patterns.

### Response and remediation

- Isolate the affected system from the network to prevent further potential command and control communication.
- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software.
- Review and block the identified suspicious domain names at the network perimeter to prevent any further communication attempts.
- Analyze network traffic logs to identify any other systems that may have communicated with the flagged domains and apply similar containment measures.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign.
- Implement additional monitoring on the affected system and network segment to detect any signs of persistence or further malicious activity.
- Update and reinforce endpoint protection measures, ensuring all systems have the latest security patches and configurations to prevent similar threats in the future."""


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

[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

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

[[rule.threat.technique]]
id = "T1568"
name = "Dynamic Resolution"
reference = "https://attack.mitre.org/techniques/T1568/"

[[rule.threat.technique.subtechnique]]
id = "T1568.002"
name = "Domain Generation Algorithms"
reference = "https://attack.mitre.org/techniques/T1568/002/"

[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[metadata]
creation_date = "2025/05/06"
integration = ["azure"]
maturity = "production"
updated_date = "2026/07/02"

[rule]
author = ["Elastic"]
description = """
Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user
principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT)
to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as
/me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal
object ID. This is a New Terms rule that only signals if the application ID, user principal object ID, and source ASN have not been
seen doing this activity historically.
"""
from = "now-9m"
index = ["logs-azure.graphactivitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Microsoft Graph Email Access by Unusual User and Client"
note = """## Triage and analysis

### Investigating Microsoft Graph Email Access by Unusual User and Client

This rule detects instances where a previously unseen or rare Microsoft Graph application client ID accesses email-related API paths, such as `/v1.0/me/messages`, `/v1.0/me/mailFolders/inbox/messages`, or `/v1.0/users/{id}/messages`. The access is performed with a delegated user token issued to a first-party public client (public client authentication, no client secret), which is the token shape produced by phished OAuth refresh tokens or Primary Refresh Tokens (PRTs). This activity may indicate unauthorized use of a newly consented or compromised application to read or exfiltrate mail content. This is a New Terms rule that only signals if the application ID (`azure.graphactivitylogs.properties.app_id`), user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`), and source ASN (`azure.graphactivitylogs.properties.source_asn`) have not been seen doing this activity historically.

### Possible Investigation Steps:

- `azure.graphactivitylogs.properties.app_id`: Investigate the application ID involved. Is it known and sanctioned in your tenant? Pivot to Azure Portal → Enterprise Applications → Search by App ID to determine app details, publisher, and consent status.
- `azure.graphactivitylogs.properties.scopes`: When present, review the delegated scopes on the token. Email-related scopes such as `Mail.ReadWrite` and `Mail.Send` are especially sensitive and confirm the token can interact with mail content.
- `url.path`: Determine exactly which mail-related APIs were accessed (e.g., reading inbox, sending messages, enumerating folders).
- `user.id`: Identify the user whose credentials were used. Determine if the user recently consented to a new app, clicked a phishing link, or reported suspicious activity.
- `user_agent.original`: Check for suspicious automation tools (e.g., `python-requests`, `curl`, non-browser agents), which may suggest scripted access.
- `source.ip` and `client.geo`: Investigate the source IP and geography. Look for unusual access from unexpected countries, VPS providers, or anonymizing services.
- `http.request.method`: Determine intent based on HTTP method — `GET` (reading), `POST` (sending), `PATCH`/`DELETE` (modifying/removing messages).
- `token_issued_at` and `@timestamp`: Determine how long the token has been active and whether access is ongoing or recent.
- `azure.graphactivitylogs.properties.c_sid`: Use the session correlation ID to identify other related activity in the same session. This may help identify if the app is accessing multiple users' mailboxes or if the same user is accessing multiple apps.
- Correlate with Microsoft Entra ID (`azure.auditlogs` and `azure.signinlogs`) to determine whether:
  - The app was recently granted admin or user consent
  - Risky sign-ins occurred just prior to or after mail access
  - The same IP or app ID appears across multiple users

### False Positive Analysis

- New legitimate apps may appear after a user consents via OAuth. Developers, third-party tools, or IT-supplied utilities may access mail APIs if users consent.
- Users leveraging Microsoft development environments (e.g., Visual Studio Code) may trigger this behavior with delegated `.default` permissions.
- Admin-approved apps deployed via conditional access may trigger similar access logs if not previously seen in detection baselines.

### Response and Remediation

- If access is unauthorized or unexpected:
  - Revoke the app's consent in Azure AD via the Enterprise Applications blade.
  - Revoke user refresh tokens via Microsoft Entra or PowerShell.
  - Investigate the user's session and alert them to possible phishing or OAuth consent abuse.
- Review and restrict risky OAuth permissions in Conditional Access and App Governance policies.
- Add known, trusted app IDs to a detection allowlist to reduce noise in the future.
- Continue monitoring the app ID for additional usage across the tenant or from suspicious IPs.
"""
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",
]
risk_score = 47
rule_id = "e882e934-2aaa-11f0-8272-f661ea17fbcc"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Email",
    "Data Source: Azure",
    "Data Source: Microsoft Graph",
    "Data Source: Microsoft Graph Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:azure.graphactivitylogs and
    azure.graphactivitylogs.result_signature:200 and
    azure.graphactivitylogs.properties.c_idtyp:user and
    azure.graphactivitylogs.properties.client_auth_method:0 and
    http.request.method:(DELETE or GET or PATCH or POST or PUT) and
    url.path:((/beta/me/* or /beta/users/* or /v1.0/me/* or /v1.0/users/*) and (*inbox* or *mail* or *messages*) and not *mailboxSettings*) and
    azure.graphactivitylogs.properties.app_id:* and
    azure.graphactivitylogs.properties.user_principal_object_id:* and
    source.as.number:*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1114"
name = "Email Collection"
reference = "https://attack.mitre.org/techniques/T1114/"
[[rule.threat.technique.subtechnique]]
id = "T1114.002"
name = "Remote Email Collection"
reference = "https://attack.mitre.org/techniques/T1114/002/"



[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"
[[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.new_terms]
field = "new_terms_fields"
value = [
    "azure.graphactivitylogs.properties.app_id",
    "azure.graphactivitylogs.properties.user_principal_object_id",
    "source.as.number",
]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"