Elastic rules: 18

[metadata]
creation_date = "2020/12/27"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies execution of the Apple script interpreter (osascript) without a password prompt and with administrator
privileges.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Apple Scripting Execution with Administrator Privileges"
references = ["https://discussions.apple.com/thread/2266150"]
risk_score = 47
rule_id = "827f8d8f-4117-4ae4-b551-f56d54b9da6b"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a macOS System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "osascript" and
 process.command_line : "osascript*with administrator privileges" and
 ((process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false) or process.Ext.effective_parent.executable like ("/tmp/*", "/private/tmp/*", "/Users/Shared/*"))
'''
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 Apple Scripting Execution with Administrator Privileges

AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries may exploit it to execute scripts with elevated privileges, bypassing password prompts, to gain unauthorized access or escalate privileges. The detection rule identifies such misuse by monitoring the execution of AppleScript with admin rights, excluding benign parent processes like Electron, to flag potential threats.

### Possible investigation steps

- Review the process details to confirm the execution of 'osascript' with administrator privileges, focusing on the command line arguments to understand the script's intent.
- Investigate the parent process of 'osascript' to determine if it is a known and trusted application, ensuring it is not 'Electron' or any other excluded parent processes.
- Check the user account associated with the 'osascript' execution to verify if it is a legitimate account and assess if there are any signs of compromise or unauthorized access.
- Analyze recent system logs and user activity to identify any unusual behavior or patterns that coincide with the time of the alert.
- Correlate this event with other security alerts or incidents to determine if it is part of a broader attack or isolated incident.

### False positive analysis

- Known false positives may arise from legitimate applications that use AppleScript with administrator privileges for valid operations, such as software installers or system management tools.
- Exclude processes with benign parent applications like Electron, as specified in the rule, to reduce false positives from common development environments.
- Consider adding exceptions for other trusted applications that frequently use AppleScript with elevated privileges, ensuring they are verified and necessary for business operations.
- Regularly review and update the list of excluded applications to adapt to changes in software usage and maintain effective threat detection.
- Monitor the frequency and context of alerts to identify patterns that may indicate false positives, adjusting the detection rule as needed to minimize unnecessary alerts.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious osascript processes running with administrator privileges that were not initiated by known, legitimate applications.
- Review system logs and process execution history to identify any unauthorized changes or access that occurred during the incident.
- Revoke any compromised credentials or accounts that may have been used to execute the AppleScript with elevated privileges.
- Restore the system to a known good state from a backup taken before the unauthorized script execution, if necessary.
- Implement application whitelisting to prevent unauthorized scripts from executing with elevated privileges in the future.
- Escalate the incident to the security operations team for further investigation and to assess the need for additional security controls or monitoring enhancements."""


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

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

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.004"
name = "Elevated Execution with Prompt"
reference = "https://attack.mitre.org/techniques/T1548/004/"

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the
DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging
is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An
adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using
the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this
single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique
that should be validated against expected administrative change activity.
"""
false_positives = [
    """
    Cloud or security administrators may legitimately delete or reconfigure Bedrock model invocation logging during
    onboarding, log destination migrations, or compliance changes. Verify whether the user identity, user agent, and
    source IP are expected to make this change. For PutModelInvocationLoggingConfiguration, confirm that the destination
    S3 bucket or CloudWatch log group remains owned and monitored by your organization. Known, planned changes can be
    exempted from this rule.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Model Invocation Logging Disabled or Modified"
note = """## Triage and analysis

### Investigating AWS Bedrock Model Invocation Logging Disabled or Modified

AWS Bedrock model invocation logging captures the prompts and responses processed by foundation models and delivers them
to an S3 bucket or CloudWatch log group. This data feeds the `logs-aws_bedrock.invocation-*` dataset that all data-plane
Bedrock detections depend on. Deleting the configuration stops this telemetry entirely, while overwriting it with `Put`
can silently redirect logs to a destination the defender does not monitor. Either action effectively blinds the
data-plane detection stack, making this a high-priority defense-evasion event.

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`.
  - Determine whether the identity is an approved Bedrock administrator and whether a change request exists.
- **Determine the exact action**
  - For `DeleteModelInvocationLoggingConfiguration`, logging is being turned off entirely — confirm this is intentional.
  - For `PutModelInvocationLoggingConfiguration`, inspect `aws.cloudtrail.flattened.request_parameters` for the new
    `s3Config` bucket name / key prefix and `cloudWatchConfig` log group, and verify they are owned and monitored by your org.
- **Correlate surrounding activity**
  - Pivot on the same identity, `source.ip`, and `cloud.account.id` for prior enumeration
    (`GetModelInvocationLoggingConfiguration`) or follow-on Bedrock data-plane activity (model invocations) that would now
    be unlogged.
  - Check for parallel logging-tampering against CloudTrail, Config, or GuardDuty.

### False positive analysis

- **Planned changes**: Logging migrations or compliance updates may legitimately reconfigure or remove the
  configuration. Validate against change tickets and infrastructure-as-code pipelines.

### Response and remediation

- If unauthorized, restore model invocation logging to the approved destination and verify log delivery resumes into
  `logs-aws_bedrock.invocation-*`.
- Review and secure any attacker-specified S3 bucket or CloudWatch log group, and treat data sent there as exposed.
- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected.
- Restrict `bedrock:DeleteModelInvocationLoggingConfiguration` and `bedrock:PutModelInvocationLoggingConfiguration` to a
  small set of administrative roles and alert on changes.
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteModelInvocationLoggingConfiguration.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutModelInvocationLoggingConfiguration.html",
    "https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html"
]
risk_score = 73
rule_id = "fa830742-fd41-4b12-a287-2c57bdf079ef"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Log Auditing",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Tactic: Defense Evasion",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail" and
    event.provider: "bedrock.amazonaws.com" and
    event.action: ("DeleteModelInvocationLoggingConfiguration" or "PutModelInvocationLoggingConfiguration") and 
    event.outcome: "success"
'''


[[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.008"
name = "Disable or Modify Cloud Logs"
reference = "https://attack.mitre.org/techniques/T1562/008/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication
mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and
what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers
or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl,
Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines.
"""
false_positives = [
    """
    Cluster provisioning, GitOps, or approved platform automation may perform these APIs under IAM principals whose ARNs do
    not match the exclusion patterns. Baseline expected roles and expand exclusions if needed.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EKS Access Entry Modified"
note = """## Triage and analysis

### Investigating AWS EKS Access Entry Modified

Review aws.cloudtrail.user_identity (ARN, type), user.name, source.ip, user_agent.original, cloud.account.id, and
cloud.region. Map event.action to intent: new principal (CreateAccessEntry), policy binding changes (AssociateAccessPolicy,
DisassociateAccessPolicy), metadata updates (UpdateAccessEntry), or removal (DeleteAccessEntry).

### Possible investigation steps

- Inspect aws.cloudtrail.request_parameters and response_elements for cluster name, principal ARN, and policy ARNs.
- Compare against change management and infrastructure-as-code deploy windows.
- Correlate with Kubernetes audit logs for subsequent API activity from identities tied to the affected access entry.
- Pair with the higher-fidelity rule EKS Access Entry Granted Cluster Admin Policy when AssociateAccessPolicy fires.

### Response and remediation

- If unauthorized, revert access entry changes via AWS APIs or console; restrict eks:* permissions and review SCPs.
- Rotate credentials for compromised IAM principals as appropriate.

### Additional information

- [Amazon EKS access entries](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)
"""
references = [
    "https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html",
]
risk_score = 47
rule_id = "90c0ce77-3fb4-484f-a8ad-4648e12b35b1"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"aws.cloudtrail" and event.provider:"eks.amazonaws.com" and
event.action:("CreateAccessEntry" or "AssociateAccessPolicy" or "UpdateAccessEntry" or "DisassociateAccessPolicy" or "DeleteAccessEntry") and
event.outcome:"success" and
not aws.cloudtrail.user_identity.arn:(*AWSServiceRoleForAmazonEKS* or *eksctl* or *terraform* or *AWSCloudFormation*)
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

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

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

[rule]
author = ["Elastic"]
description = """
Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is
used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account
root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios.
Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic
access patterns.
"""
false_positives = [
    """
    Legitimate users may travel, rotate through VPN egress IPs, or run automation from new build hosts, producing a
    first-seen IP for an existing access key. Baseline the principal, confirm with the key owner, and extend the history
    window or add exceptions for known automation networks if needed.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM Long-Term Access Key First Seen from Source IP"
note = """## Triage and analysis

### Investigating AWS IAM Long-Term Access Key First Seen from Source IP

This rule is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) detection on CloudTrail. It fires when a successful API call uses a long-term IAM access key (`AKIA*`) from a `source.ip` that has not appeared with that key in the rule history window.

Long-term keys are high-value targets. Unlike session credentials (`ASIA*`), they do not expire until rotated or deleted. Threat reporting on cloud compromises often highlights abuse of leaked or stolen `AKIA` keys.

### Possible investigation steps

**Confirm the key and principal**
- Identify the IAM user or root context implied by `aws.cloudtrail.user_identity.arn` or `user.name`.
- **`aws.cloudtrail.user_identity.type`**: Distinguish `IAMUser`, `Root`, or other types; root long-term keys warrant extra scrutiny.

**Assess the new source**
- **`source.ip`** and **`source.geo`**: Compare to normal geography, corporate egress, and known cloud provider ranges.
- **`user_agent.original`**: Identify AWS CLI, SDKs, custom tooling, or unusual agents.

**Correlate activity**
- Search CloudTrail for the same access key and IP over the following hours for sensitive APIs (IAM changes, STS, S3 data access, Secrets Manager, role assumption).
- Review IAM last-used metadata for the key in the AWS console or API (`GetAccessKeyLastUsed`).

### False positive analysis

- Travel and VP* for human IAM users.
- New CI runners, ephemeral build agents, or re-IP'd NAT gateways for automation keys.
- Partner or MSP access from new networks if keys are shared (discouraged practice).

### Response and remediation

- If unexpected, deactivate or delete the access key, rotate credentials, and review policies attached to the user.
- Enable or enforce MFA for console users; prefer roles and temporary credentials over long-term keys for workloads.
- Document approved networks or principals and tune history or exceptions accordingly.

### Additional information

- [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf)

"""
references = [
    "https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise",
]
risk_score = 47
rule_id = "9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS IAM",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.outcome: "success"
    and source.ip:*
    and aws.cloudtrail.user_identity.access_key_id: AKIA*
'''


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


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

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "source.geo.city_name",
    "source.geo.country_iso_code",
    "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",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.access_key_id", "source.ip"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

[metadata]
creation_date = "2026/09/09"
integration = ["endpoint", "windows", "m365_defender", "crowdstrike"]
maturity = "production"
updated_date = "2026/09/09"

[rule]
author = ["Elastic"]
description = """
Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File
storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and
cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push
it to attacker-controlled accounts.
"""
false_positives = [
    "IT or DevOps using AzCopy for authorized migrations on a host that has not used it in the history window.",
    "Users launching Azure Storage Explorer (including the installer) for the first time on a host.",
]
from = "now-9m"
index = [
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-windows.sysmon_operational-*",
]
language = "kuery"
license = "Elastic License v2"
name = "AzCopy or Azure Storage Explorer Usage on Unusual Host"
note = """## Triage and analysis

### Investigating AzCopy or Azure Storage Explorer Usage on Unusual Host

AzCopy and Azure Storage Explorer are Microsoft utilities for moving data to and from Azure Storage. Threat actors abuse them as living-off-the-land binaries: they run `azcopy copy` with SAS URLs against `*.blob.core.windows.net` (GetBlob from a victim account, PutBlob to an attacker account, or Blob-to-Blob between them) and launch Storage Explorer to browse or move the same data. CISA's Rhysida advisory is one example of that tradecraft.

This is a new-terms rule: it alerts the first time a `host.id` matches in the history window (7 days). AzCopy `copy`/`sync` whose command line includes an Azure Storage hostname, or Storage Explorer (`StorageExplorer.exe`, `StorageExplorer-windows-x64.exe`, `StorageExplorer-windows-arm64.exe`, `StorageExplorer-windowsx64.exe`), fires once per host. Recurring use on the same host will not re-alert until the history window expires.

### Possible investigation steps

- Confirm which utility fired the alert. For AzCopy, inspect `process.command_line` for `copy` vs `sync`, `--from-to` (`BlobLocal`, `LocalBlob`, `BlobBlob`), and the SAS URL host, container, and `sp`/`se` parameters. For Storage Explorer, note the installer vs application name and silent-install flags such as `/VERYSILENT`.
- Identify source and destination. AzCopy command lines often contain a local path and one or two `https://<account>.blob.core.windows.net/...` URLs. Treat Blob-to-Blob copies as direct tenant-to-attacker movement even when no files touch disk.
- Check `process.executable` and `process.parent.executable`. A copy from a user-writable or staging path, especially spawned by PowerShell or a scripting host, is more suspicious than a packaged install.
- Compare `process.name` with `process.pe.original_file_name` and `process.code_signature.subject_name`. A Microsoft-signed binary from an unusual path is still the Rhysida/Storm-0501 tradecraft; a renamed unsigned copy is additional evasion.
- Pivot to Azure Storage diagnostic logs for the same window: GetBlob, PutBlob, and BlobBlob with user agent `AzCopy*` or `Microsoft Azure Storage Explorer*` and SAS authentication. Correlate with the SIEM rule "Azure Storage Blob Retrieval via AzCopy".
- Review network telemetry from the same `process.entity_id` to `*.blob.core.windows.net` or `*.dfs.core.windows.net` and estimate volume.
- Hunt sibling activity on the host: other Azure LOLBINs, rclone, or bulk archive creation preceding the copy.

### False positive analysis

- Authorized AzCopy migrations and first-time Storage Explorer use on a host will match. This rule alerts only the first time a given `host.id` matches within 7 days; allowlist by host, user, or approved destination if that first alert is expected.
- Do not treat a trusted Microsoft signature as benign by itself; CISA's Rhysida advisory describes the official AzCopy and Storage Explorer binaries.

### Response and remediation

- If exfiltration is confirmed, isolate the host, stop AzCopy and Storage Explorer processes, and preserve the command line (SAS URLs are credentials).
- Revoke the SAS tokens and account keys that appear in the command line; rotate storage account keys and any related Entra ID credentials.
- Identify which blobs were read or written (GetBlob/PutBlob/ListBlobs for the same account and time window) and assess data exposure.
- Remove staged binaries under unusual paths and investigate how they were delivered.
- Hunt for additional AzCopy, Storage Explorer, or rclone activity on other hosts in the same window.

### Related rules

- Azure Storage Blob Retrieval via AzCopy: cloud-side GetBlob with AzCopy user agent and SAS authentication.
- Potential Data Exfiltration via Rclone: similar endpoint abuse of a different cloud-sync utility.
"""
references = [
    "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-319a",
    "https://www.cisa.gov/sites/default/files/2025-04/aa23-319a-stopransomware-rhysida-ransomware_2.pdf",
    "https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10",
    "https://learn.microsoft.com/en-us/azure/storage/storage-explorer/vs-azure-tools-storage-explorer-blobs",
    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
]
risk_score = 47
rule_id = "7265f4fa-4839-4399-924c-a91f1e45d76c"
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)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Platform: Windows",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
    "Tactic: Collection",
    "Tactic: Execution",
    "Rule Type: New Terms",
    "Threat: Rhysida",
    "Use Case: Ransomware",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:windows and event.category:process and event.type:start and
(
  (
    (process.name:"azcopy.exe" or process.pe.original_file_name:"azcopy.exe") and
    process.args:("copy" or "sync") and
    process.command_line:(*blob.core.windows.net* or *dfs.core.windows.net* or *file.core.windows.net* or *blob.storage.azure.net*)
  ) or
  process.name:("StorageExplorer.exe" or "StorageExplorer-windows-x64.exe" or "StorageExplorer-windows-arm64.exe" or "StorageExplorer-windowsx64.exe")
)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1567"
name = "Exfiltration Over Web Service"
reference = "https://attack.mitre.org/techniques/T1567/"
[[rule.threat.technique.subtechnique]]
id = "T1567.002"
name = "Exfiltration to Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1567/002/"



[rule.threat.tactic]
id = "TA0010"
name = "Exfiltration"
reference = "https://attack.mitre.org/tactics/TA0010/"
[[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.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.009"
name = "Cloud API"
reference = "https://attack.mitre.org/techniques/T1059/009/"



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

[rule.new_terms]
field = "new_terms_fields"
value = ["host.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

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

[rule]
author = ["Elastic"]
description = """
Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command
execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling,
and expand access from a foothold container. Node, control-plane, and kube-system service account identities are
excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope.
"""
false_positives = [
    """
    Administrators routinely exec into pods for troubleshooting. Baseline expected users and target pods, then exclude
    known break-glass or operator identities after review.
    """,
]
from = "now-9m"
index = ["logs-azure.platformlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure AKS Attempted User Exec into Pod"
note = """## Triage and analysis

### Investigating Azure AKS Attempted User Exec into Pod

AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule alerts on a
`pods/exec` request by an identity that is not node, control-plane, or kube-system infrastructure. Exec into a pod grants
an interactive shell inside the workload, which adversaries use to read mounted secrets, pivot, and stage tooling.

### Possible investigation steps

- Review the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in
  `azure.platformlogs.properties.log.user.groups`, and the target pod in
  `azure.platformlogs.properties.log.objectRef.name` / `azure.platformlogs.properties.log.objectRef.namespace`.
- Determine whether the target pod holds sensitive data, cluster credentials, or a mounted service account token.
- Inspect the exec request path and command context in `azure.platformlogs.properties.log.requestURI` and the client in
  `azure.platformlogs.properties.log.userAgent` (interactive `kubectl` vs a scripted client).
- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. Pivot on it for related API activity, secret
  reads, or RBAC changes from the same identity.

### False positive analysis

- Approved admin debugging; exclude stable operator or break-glass identities after review.
- CI/CD or platform tooling that execs into workloads may match; exclude verified service accounts and namespaces.

### Response and remediation

- If unauthorized, revoke the identity's tokens and kubeconfig and terminate the exec session.
- Inspect the target pod for tampering, dropped tooling, or accessed secrets, and rotate any credentials it exposed.
- Collect kube-audit and identity artifacts per incident response procedures.
"""
references = [
    "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/",
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
    "https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/",
]
risk_score = 47
rule_id = "8f131efa-0284-465f-a360-da23e5562dd1"
setup = "The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: Azure",
    "Data Source: Azure Platform Logs",
    "Data Source: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "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/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "azure.platformlogs.category",
    "azure.platformlogs.properties.log.verb",
    "azure.platformlogs.properties.log.user.username",
    "azure.platformlogs.properties.log.sourceIPs",
    "azure.platformlogs.properties.log.objectRef.resource",
    "azure.platformlogs.properties.log.objectRef.subresource",
    "azure.platformlogs.properties.log.objectRef.namespace",
    "azure.platformlogs.properties.log.objectRef.name"
]

[rule]
description = """
Identifies failed attempts to access common sensitive files and registries. Adversaries may search local file systems
and remote file shares for files containing insecurely stored credentials.
"""
id = "3163dd96-c677-4f1f-98bf-c8f3c81b197b"
license = "Elastic License v2"
name = "Failed Attempts to Access Sensitive Files"
os_list = ["windows"]
reference = ["https://github.com/GhostPack/Seatbelt", "https://github.com/AlessandroZ/LaZagne"]
version = "1.0.31"

query = '''
any where event.category in ("registry", "file") and
   event.action in ("query", "open") and event.outcome == "failure" and process.pid != 4 and
   process.executable != null and
   (
    (file.path : "?:\\*" and
     file.path :
	     (
		  "?:\\Users\\*\\AppData\\Local\\*\\Remote Desktop Connection Manager\\RDCMan.settings",
		  "?:\\Users\\*\\AppData\\*\\NordVPN\\NordVPN.exe*\\user.config",
		  "?:\\Users\\*\\AppData\\*\\FileZilla\\recentservers.xml",
		  "?:\\Users\\*\\AppData\\*\\FileZilla\\sitemanager.xml") and
	 not process.executable :
	          ("?:\\Program Files\\*",
	           "?:\\Program Files (x86)\\*",
	           "?:\\Windows\\System32\\SearchProtocolHost.exe",
	           "?:\\Windows\\System32\\svchost.exe",
	           "?:\\Windows\\System32\\OpenSSH\\ssh.exe", 
	           "?:\\Windows\\System32\\OpenSSH\\ssh-keygen.exe",
	           "?:\\Windows\\System32\\OpenWith.exe", 
	           "\\Device\\Mup*",
	           "?:\\Windows\\explorer.exe",
	           "?:\\Windows\\eMweb\\certutil.exe") and
	 not (process.code_signature.subject_name :
	          ("Rapid7 LLC", "Mozilla Corporation", "Commvault Systems, Inc.", "Google LLC", "Bitdefender SRL",
	           "McAfee, Inc.", "Serengeti Systems Incorporated", "nordvpn s.a.", "Kaspersky Lab", "JetBrains s.r.o.", 
	           "Illusive Networks LTD", "Ghisler Software GmbH", "Keeper Security Inc.", "Eric R. Zimmerman", 
	           "Galactic Advisors, Inc.", "Johannes Schindelin", "Mobatek", "Shift Technologies Inc.",
	           "Viber Media S.a r.l.", "ONELAUNCH TECHNOLOGIES INC.", "SAP SE") and
         process.code_signature.trusted == true) and
     not (process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe") and
         user.id == "S-1-5-18" and process.code_signature.trusted == true) and
     not (file.name : "RDCMan.settings" and process.name : ("RDCMan.exe", "RDCMan-x86.exe"))
     ) or

	(registry.path :
         ("HKEY_USERS\\S-1-5-21*\\SOFTWARE\\WOW6432Node\\TeamViewer\\ProxyPassword", 
	  "HKEY_USERS\\S-1-5-21*\\Software\\OpenVPN-GUI\\Configs\\*auth-data*") and

	not (process.code_signature.trusted == true and
	     process.code_signature.subject_name :
	        ("Simon Tatham", "Tim Kosse", "David Sparer", "Martin Prikryl", "Open Source Developer, Sven Strickroth",
	         "Astrospark Technologies, LLC", "Solarwinds Worldwide, LLC", "NETSUPPORT LTD.", "Bitdefender SRL",
	         "Ivanti, Inc.", "Fortinet Technologies*", "Ivanti, Inc.")) and
	not process.executable : "?:\\$WINDOWS.~BT\\Sources\\SetupHost.exe")
    )
'''

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

[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1539"
name = "Steal Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1539/"

[[threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"
[[threat.technique.subtechnique]]
id = "T1552.001"
name = "Credentials In Files"
reference = "https://attack.mitre.org/techniques/T1552/001/"


[[threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[threat.technique.subtechnique]]
id = "T1555.003"
name = "Credentials from Web Browsers"
reference = "https://attack.mitre.org/techniques/T1555/003/"



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

[internal]
min_endpoint_version = "8.6.0"

[rule]
description = "Identifies a list of LDAP queries often used to perform Active Directory groups and privileges reconnaissance."
id = "447b004a-ac74-4ba4-8131-44efc25fdd47"
license = "Elastic License v2"
name = "Group and Privileged Accounts Discovery via LDAP"
os_list = ["windows"]
reference = ["https://attack.mitre.org/techniques/T1069/002/"]
version = "1.0.5"

query = '''
api where process.Ext.api.name == "ldap_search" and user.id != "S-1-5-18" and
 not process.executable :
             ("?:\\Program Files\\Azure Advanced Threat Protection Sensor\\*\\Microsoft.Tri.Sensor.exe",
              "?:\\Windows\\System32\\lsass.exe",
              "?:\\Windows\\ADFS\\Microsoft.IdentityServer.ServiceHost.exe",
              "?:\\Windows\\ADWS\\Microsoft.ActiveDirectory.WebServices.exe",
              "\\Device\\Mup\\*\\VMedView.exe") and
 process.Ext.api.parameters.search_filter : (
  "(&(objectClass=group))",
  "(&(objectClass=group)(managedBy=?))",
  "(&(objectClass=group)(managedBy=?)(groupType:1.2.840.113556.1.4.803:=2147483648))",
  "(&(objectCategory=group)(name=Domain Admins))",
  "*(adminCount=1)*"
 ) and
 not (process.code_signature.subject_name in ("Netwrix Corporation", "Kaseya Holdings Inc", "VEPRO AG", "Recast Software Inc.", "Azul Systems, Inc.", "SEMPERIS INC.") and process.code_signature.trusted == true) and
 not (process.executable : "C:\\Windows\\System32\\inetsrv\\w3wp.exe" and process.Ext.api.parameters.search_filter : "(&(objectClass=group))") and
 not process.executable : ("C:\\Program Files\\IIS Express\\iisexpress.exe",
                           "C:\\Windows\\ADWS\\Microsoft.ActiveDirectory.WebServices.exe",
                           "C:\\Program Files (x86)\\ISDecisions\\FileAudit\\FileAuditService.exe",
                           "C:\\Program Files (x86)\\baramundi\\Management Server\\bServer.exe",
                           "C:\\Program Files (x86)\\OpenDNS\\OpenDNS Connector\\v*\\CiscoAuditClient.exe",
                           "C:\\Program Files (x86)\\Cisco\\CiscoADConnector\\v*\\CiscoAuditClient.exe")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"
[[threat.technique.subtechnique]]
id = "T1069.002"
name = "Domain Groups"
reference = "https://attack.mitre.org/techniques/T1069/002/"


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


[[threat.technique]]
id = "T1482"
name = "Domain Trust Discovery"
reference = "https://attack.mitre.org/techniques/T1482/"


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

[internal]
min_endpoint_version = "9.1.0"

[metadata]
creation_date = "2025/06/19"
integration = ["endpoint", "auditd_manager", "crowdstrike", "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/02/05"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
This rule detects the execution of kubectl commands that are commonly used for configuration discovery in Kubernetes
environments. It looks for process events where kubectl is executed with arguments that query configuration information,
such as configmaps. In environments where kubectl is not expected to be used, this could indicate potential reconnaissance
activity by an adversary.
"""
from = "now-119m"
index = [
    "logs-endpoint.events.*",
    "endgame-*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-cloud_defend.process*",
]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Kubectl Configuration Discovery"
risk_score = 21
rule_id = "98ac2919-f8b3-4d2d-b85b-e1c13ac0c68b"
severity = "low"
tags = [
  "Domain: Container",
  "Domain: Endpoint",
  "Domain: Kubernetes",
  "OS: Linux",
  "Use Case: Threat Detection",
  "Tactic: Discovery",
  "Rule Type: BBR",
  "Data Source: Elastic Defend",
  "Data Source: Elastic Endgame",
  "Data Source: Auditd Manager",
  "Data Source: Crowdstrike",
  "Data Source: Elastic Defend for Containers",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and
process.name == "kubectl" and process.args in ("get", "describe") and process.args in ("configmap", "configmaps") and
not ?process.parent.args in (
  "/hooks/schedule_sync_configmap.sh", "/service-fabric/generate-support-bundle.sh", "/hooks/onstartup_sync_configmap.sh"
)
'''

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

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when a malware filter rule has been deleted or disabled in Microsoft 365. An adversary or insider threat may
want to modify a malware filter rule to evade detection.
"""
false_positives = [
    """
    A malware filter rule may be deleted by a system or network administrator. Verify that the configuration change was
    expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Exchange Malware Filter Rule Modified"
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 M365 Exchange Malware Filter Rule Modified

Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to disable or remove these rules to bypass security measures and facilitate attacks. The detection rule monitors audit logs for successful actions that alter these rules, signaling potential defense evasion tactics. This helps security analysts quickly identify and respond to unauthorized modifications.

### Possible investigation steps

- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the rule modification.
- Identify the user account associated with the event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and verify if the action was authorized or expected.
- Check the event.category:web logs for any related activities around the same timeframe to identify potential patterns or additional suspicious actions.
- Investigate the event.outcome:success to ensure that the modification was indeed successful and assess the impact on the organization's security posture.
- Correlate the identified actions with any recent security incidents or alerts to determine if this modification is part of a larger attack or threat campaign.
- Review the user's recent activity and access logs to identify any other unusual or unauthorized actions that may indicate compromised credentials or insider threat behavior.

### False positive analysis

- Routine administrative changes to malware filter rules by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system.
- Scheduled maintenance or updates to Microsoft 365 configurations might involve temporary disabling of certain rules. Document these activities and adjust the monitoring system to recognize these as non-threatening.
- Automated scripts or third-party tools used for system management may perform actions that resemble rule modifications. Ensure these tools are properly documented and their actions are whitelisted if verified as safe.
- Changes made during incident response or troubleshooting can appear as rule modifications. Coordinate with the incident response team to log these activities and exclude them from triggering alerts.

### Response and remediation

- Immediately isolate the affected user accounts and systems to prevent further unauthorized modifications to the malware filter rules.
- Re-enable or recreate the disabled or removed malware filter rules to restore the intended security posture of the Microsoft 365 environment.
- Conduct a thorough review of recent email traffic and logs to identify any potential malicious content that may have bypassed the filters during the period of rule modification.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised.
- Implement enhanced monitoring and alerting for any future attempts to modify malware filter rules, ensuring rapid detection and response.
- Review and update access controls and permissions for administrative actions within Microsoft 365 to limit the ability to modify security configurations to only essential personnel.
- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/powershell/module/exchange/remove-malwarefilterrule?view=exchange-ps",
    "https://docs.microsoft.com/en-us/powershell/module/exchange/disable-malwarefilterrule?view=exchange-ps",
]
risk_score = 47
rule_id = "ca79768e-40e1-4e45-a097-0e5fbc876ac2"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Microsoft 365",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and event.outcome:success
'''


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

[metadata]
creation_date = "2026/08/20"
integration = ["network_traffic", "fortinet_fortigate", "zeek"]
maturity = "production"
updated_date = "2026/08/26"

[rule]
author = ["Elastic"]
description = """
Identifies a client generating many unique, unusually long DNS query names to the same registered domain within a
five-minute window. Malware DNS tunnels and DNS command-and-control commonly encode data in lengthy subdomain portions
under one apex domain.
"""
false_positives = [
    """
    CDN, cloud load-balancer, software-update, and telemetry hostnames can be long and change often. Recursive
    resolvers, forwarders, NAT gateways, and localhost DNS listeners can also combine queries from many endpoints under
    one client address. Validate the apex domain and whether the source is an endpoint before treating the activity as
    tunneling.
    """,
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Potential DNS Tunneling via Long and Unique Subdomains"
note = """## Triage and analysis

### Investigating Potential DNS Tunneling via Long and Unique Subdomains

DNS tunneling encodes data in query labels and often produces many unique, unusually long subdomains under a single apex
domain. This rule aggregates network DNS telemetry for that behavioral pattern without relying on threat intelligence
feeds or machine learning jobs.

Compare overlapping apex domains against the machine learning **DNS Tunneling** rule when that job is enabled.

### Possible investigation steps

- Review `Esql.dns_registered_domain`, `Esql.count_distinct_names`, `Esql.unique_name_ratio`,
  `Esql.max_subdomain_length`, and sample values in `Esql.sample_names`.
- Inspect `Esql.dns_question_type_values`. TXT, NULL, CNAME, or MX bursts increase confidence; A/AAAA-only activity can
  still be tunneling and should not be dismissed on type alone.
- Use `Esql.first_seen`, `Esql.last_seen`, `Esql.dataset_values`, and `Esql.observer_name_values` to establish the event
  span and identify the integrations and sensors that contributed to the alert.
- Confirm whether `Esql.client_ip` is a workstation, server, recursive resolver, forwarder, NAT address, or localhost
  DNS service. Resolver and localhost sources merge many clients and are a common false-positive pattern.
- Review `Esql.destination_ip_values` to identify the resolver or authoritative destination observed by the sensor.
- Pivot on the same client and apex domain in raw DNS events and look for follow-on process, file, or additional C2
  activity.

### False positive analysis

- CDN, cloud load-balancer, certificate, and software-update services often create long hostnames. Confirm the apex
  domain reputation and whether the requesting host role normally uses that provider.
- Security or network appliances performing DNS-based reachability or reputation checks can resemble tunneling. Exclude
  confirmed appliance addresses after validation.
- Do not create a global resolver exception until the originating endpoint is known; a shared `Esql.client_ip` can hide
  a single infected host behind legitimate bulk lookups.

### Response and remediation

- Block the apex domain or forwarding from the affected host at recursive resolvers if malicious activity is confirmed.
- Isolate the source host and inspect for tunneling tools or malware initiating the queries.
- Add temporary blocks for the apex domain while scoping additional hosts querying the same name.
"""
references = [
    "https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/",
]
risk_score = 47
rule_id = "89ed957d-609b-4b00-b8c6-a5cbd187632c"
setup = """## Setup

This rule requires DNS transaction events from one of the following sources:

- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*`
- Fortinet FortiGate DNS logs (`fortinet_fortigate.log`) in `logs-fortinet_fortigate.log-*`
- Elastic Zeek (`zeek.dns`) in `logs-zeek.dns-*`
- Legacy Packetbeat DNS events in `packetbeat-*` with `event.dataset` set to `dns`

Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver,
or if the captured client is a localhost listener such as `127.0.0.1`, `Esql.client_ip` may identify shared DNS
infrastructure instead of the originating endpoint.

DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and other encrypted DNS traffic are not visible to packet capture unless the
sensor receives decrypted DNS telemetry or equivalent resolver logs mapped to ECS.
"""
severity = "medium"
tags = [
    "Domain: Network",
    "Use Case: Threat Detection",
    "Use Case: Network Security Monitoring",
    "Rule Type: ESQL",
    "Tactic: Command and Control",
    "Tactic: Exfiltration",
    "Data Source: Network Packet Capture",
    "Data Source: Fortinet",
    "Data Source: Network Traffic",
    "Data Source: Zeek",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-network_traffic.dns-*, logs-fortinet_fortigate.log-*, logs-zeek.dns-*, packetbeat-*
| where
    (
      data_stream.dataset in ("network_traffic.dns", "fortinet_fortigate.log", "zeek.dns")
      or event.dataset == "dns"
    )
    and dns.question.name is not null
    and dns.question.registered_domain is not null
| eval
    Esql.client_ip = COALESCE(client.ip, source.ip),
    Esql.dataset = COALESCE(data_stream.dataset, event.dataset),
    Esql.dns_question_name = TO_LOWER(dns.question.name),
    Esql.dns_registered_domain = TO_LOWER(dns.question.registered_domain),
    Esql.dns_question_type = TO_LOWER(dns.question.type),
    Esql.subdomain_length = LENGTH(Esql.dns_question_name) - LENGTH(Esql.dns_registered_domain) - 1
| where
    Esql.client_ip is not null
    and Esql.subdomain_length >= 50
    and (Esql.dns_question_type is null or Esql.dns_question_type != "ptr")
    and not ENDS_WITH(Esql.dns_question_name, ".arpa")
| eval Esql.time_window = DATE_TRUNC(5 minutes, @timestamp)
| stats
    Esql.count_queries = COUNT(*),
    Esql.count_distinct_names = COUNT_DISTINCT(Esql.dns_question_name),
    Esql.max_subdomain_length = MAX(Esql.subdomain_length),
    Esql.avg_subdomain_length = AVG(Esql.subdomain_length),
    Esql.dns_question_type_values = MV_SLICE(VALUES(Esql.dns_question_type), 0, 9),
    Esql.destination_ip_values = MV_SLICE(VALUES(destination.ip), 0, 4),
    Esql.sample_names = MV_SLICE(VALUES(Esql.dns_question_name), 0, 4),
    Esql.dataset_values = MV_SLICE(VALUES(Esql.dataset), 0, 9),
    Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 19),
    Esql.first_seen = MIN(@timestamp),
    Esql.last_seen = MAX(@timestamp)
  by Esql.time_window, Esql.client_ip, Esql.dns_registered_domain
| where Esql.count_queries >= 25 and Esql.count_distinct_names >= 15
| eval Esql.unique_name_ratio = TO_DOUBLE(Esql.count_distinct_names) / Esql.count_queries
| keep Esql.*
'''


[[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 = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"


[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1048"
name = "Exfiltration Over Alternative Protocol"
reference = "https://attack.mitre.org/techniques/T1048/"
[[rule.threat.technique.subtechnique]]
id = "T1048.003"
name = "Exfiltration Over Unencrypted Non-C2 Protocol"
reference = "https://attack.mitre.org/techniques/T1048/003/"



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

[rule.investigation_fields]
field_names = [
    "Esql.client_ip",
    "Esql.dns_registered_domain",
    "Esql.time_window",
    "Esql.count_queries",
    "Esql.count_distinct_names",
    "Esql.unique_name_ratio",
    "Esql.max_subdomain_length",
    "Esql.avg_subdomain_length",
    "Esql.dns_question_type_values",
    "Esql.destination_ip_values",
    "Esql.sample_names",
    "Esql.dataset_values",
    "Esql.observer_name_values",
    "Esql.first_seen",
    "Esql.last_seen",
]

[metadata]
creation_date = "2024/09/12"
integration = ["endpoint", "sentinel_one_cloud_funnel", "m365_defender", "windows"]
maturity = "production"
updated_date = "2026/05/03"

[rule]
author = ["Elastic"]
description = """
Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This
may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "endgame-*",
    "logs-endpoint.events.process-*",
    "logs-windows.sysmon_operational-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-m365_defender.event-*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Escalation via Vulnerable MSI Repair"
references = [
    "https://sec-consult.com/blog/detail/msi-installer-repair-to-system-a-detailed-journey/",
    "https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-38014",
]
risk_score = 73
rule_id = "043d80a3-c49e-43ef-9c72-1088f0c7b278"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type == "start" and host.os.type == "windows" and
 user.domain : ("NT AUTHORITY", "AUTORITE NT", "AUTORIDADE NT") and
 process.parent.name : ("chrome.exe", "msedge.exe", "brave.exe", "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe",
                        "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and
 process.parent.command_line : "*go.microsoft.com*"
'''

note = """## Triage and analysis

### Investigating Potential Escalation via Vulnerable MSI Repair
#### Possible investigation steps

- What did the elevated browser parent launch?
  - Why: MSI repair abuse can expose a SYSTEM browser through a help-link redirect; a non-browser child marks the privilege-escalation boundary.
  - Focus: `process.parent.command_line`, `process.name`, `process.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name`.
  - Implication: escalate when a Microsoft Help-tied browser launches a SYSTEM or high-integrity shell, script host, installer, admin utility, file manager, or user-writable binary; lower concern only when the command line shows a browser-internal role, path and signer match the parent browser family, and no non-browser child appears in the alert window.
- Does the lineage fit an MSI repair-to-help-link path?
  - Focus: `process.parent.entity_id`, `process.parent.pid`, surrounding `process.name`, and `process.command_line`.
  - Implication: escalate when ancestry or surrounding starts show MSI repair, installer custom actions, console activity, or an unexpected SYSTEM browser before the child; lower concern when the chain stays inside browser self-maintenance without repair, console, or custom-action ancestry.
  - Hint: recover the parent browser event first. If parentage is incomplete, inspect `process.Ext.ancestry`; if entity IDs are absent, use `host.id`, `process.parent.pid`, and a tight alert window. $investigate_0
- Is the child process identity expected for the host and signer?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.Ext.relative_file_creation_time`.
  - Implication: escalate when the child runs from a user-writable or temporary path, has a mismatched original file name, lacks a trusted signer, or was recently created; lower concern only when signer, path, age, and browser parent context all fit the same recognized component.
- What follow-on process activity came from the same SYSTEM browser or spawned child?
  - Focus: same-host starts from the browser `process.parent.entity_id` or child `process.entity_id`: `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`.
  - Implication: escalate when the browser or child launches shells, scripts, persistence or administration tools, additional installers, or chained SYSTEM processes; keep scope local when activity stops at browser helpers with no privileged child chain.
  - Hint: prefer `host.id` plus parent or child `process.entity_id`; use `host.id`, `process.pid`, and a tight window only when entity IDs are absent.
    - $investigate_1
    - $investigate_2
- Does the user and session context support interactive exploitation?
  - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.authentication_id`, and `process.Ext.session_info.logon_type`.
  - Implication: escalate when a low-privileged or unexpected interactive session is tied to the SYSTEM browser-to-child chain; a pre-existing user browser usually breaks the SYSTEM child path, so a SYSTEM or high-integrity child tied to an interactive session is severity-changing. Lower concern only when process evidence maps to controlled repair validation or browser-helper behavior.
- Does process telemetry show the same SYSTEM-browser-to-tool pattern beyond this process instance?
  - Focus: same `process.parent.command_line` redirect fragment, suspicious `process.name` or `process.executable`, `user.id`, and `host.id` across recent starts.
  - Implication: broaden when recent starts show the same non-browser child pattern across unrelated hosts or users; keep response scoped when telemetry shows only this browser parent, child command line, and no repeated non-browser descendants.
  - Hint: run this pivot only if child intent, lineage, or session context remains suspicious or unresolved. $investigate_3
- Based on the evidence gathered, what disposition is supported?
  - Escalate on SYSTEM or high-integrity browser-to-tool execution, MSI repair lineage, suspicious child identity, interactive session linkage, or repeated scope; close only for same-browser helper behavior with no non-browser descendants or an authorized test whose process facts exactly match scope. Preserve evidence and escalate when child intent, lineage, or session context is mixed or incomplete.

### False positive analysis

- Browser helper, renderer, GPU, updater, or crash subprocesses can trigger after a SYSTEM browser opens a Microsoft Help link. Confirm a browser-internal role, same browser family, installed-browser path and signer, and no shell, installer, file manager, or admin tool from the same parent.
- Authorized MSI repair security validation is benign only when `@timestamp`, `host.id`, `user.id`, the SYSTEM browser parent command line, and child command line match the exact exercise; outside records may corroborate but not replace process facts.
- Build exceptions from the minimum confirmed workflow: browser family and signer, exact redirect parent context, expected child executable or command pattern, `host.id`, and tightly scoped test or managed-repair cohort. Avoid exceptions on `user.domain`, browser name, or redirect URL alone.

### Response and remediation

- If confirmed benign, document the process evidence that proved the browser-helper or validation workflow, reverse any temporary containment, and create only the narrow exception described above if the same workflow recurs.
- If suspicious but unconfirmed, preserve the alert and Timeline/export records for the browser parent, child, ancestor chain, host, and user. Record command lines, `process.entity_id`, `process.parent.entity_id`, `host.id`, `user.id`, and any visible MSI package or vulnerable-application names before containment or process termination.
- Apply reversible containment first when findings remain suspicious: isolate the host if its business role allows, or restrict the affected account/session while preserving endpoint telemetry. Do not terminate the child process until its command line, parentage, and spawned descendants are recorded.
- If confirmed malicious, contain the host and affected account based on the process lineage and session evidence, then terminate the malicious child and descendants after recording their identifiers. Remove only the payloads, repair artifacts, or configuration changes identified during the investigation.
- Patch Windows Installer and the vulnerable application package involved in the repair path, verify that the affected OS has the relevant vendor security update for CVE-2024-38014, and repackage or disable repair flows that let low-privileged users reach elevated custom actions, console windows, or help-link execution.
- Document the final evidence set, repair path, affected hosts, and any missing telemetry that limited certainty so future alerts can distinguish browser helper noise, authorized validation, and repeated exploitation."""

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:

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.name",
    "process.executable",
    "process.command_line",
    "process.code_signature.trusted",
    "process.parent.entity_id",
    "process.parent.name",
    "process.parent.executable",
    "process.parent.command_line",
    "process.Ext.authentication_id",
    "process.Ext.session_info.logon_type",
    "process.Ext.token.integrity_level_name",
]

[transform]

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

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

[[transform.investigate]]
label = "Process starts from the launched child"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
  ]
]
relativeFrom = "now"
relativeTo = "now"

[[transform.investigate]]
label = "Recent process starts with the same child executable"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" },
    { excluded = false, field = "process.executable", queryType = "phrase", value = "{{process.executable}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

[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 = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"

[[rule.threat.technique.subtechnique]]
id = "T1218.007"
name = "Msiexec"
reference = "https://attack.mitre.org/techniques/T1218/007/"

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

[rule]
description = """
Identifies attempts to load a library from a potentially transacted file. This is a technique that exploits
Transactional NTFS to execute arbitrary code in the address space of a separate running process, without committing the
code to disk.
"""
id = "edc23204-fd97-4c0f-8a2a-bb769370a7e3"
license = "Elastic License v2"
name = "Potential Image Load via Transactional NTFS"
os_list = ["windows"]
reference = ["https://www.elastic.co/blog/process-ghosting-a-new-executable-image-tampering-attack"]
version = "1.0.5"

query = '''
sequence with maxspan=1m
[library where event.action == "load" and process.pid != 4 and
  dll.Ext.defense_evasions : "Process Tampering: Image is writable" and
  dll.Ext.defense_evasions : "Process Tampering: Image has been accessed before mapping"] by process.entity_id as event0
[api where
  process.Ext.api.name in ("SetThreadContext", "Wow64SetThreadContext") and
  process.executable != null and process.Ext.api.behaviors == "cross-process" and
  stringcontains~(process.Ext.api.summary, event0.dll.name) and
  process.thread.Ext.call_stack_final_user_module.name != null and
  process.thread.Ext.call_stack_final_user_module.name != "Kernel"] by Target.process.entity_id
'''

min_endpoint_version = "8.12.0"
[[actions]]
action = "kill_process"
field = "Target.process.entity_id"
state = 0
tree = true

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

[[optional_actions]]
action = "rollback"
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.12.0"

[metadata]
creation_date = "2021/04/12"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"]
maturity = "production"
updated_date = "2026/03/24"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve Listening Ports"
query = "SELECT pid, address, port, socket, protocol, path FROM listening_ports"

[[transform.osquery]]
label = "Osquery - Retrieve Open Sockets"
query = "SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"

[[transform.osquery]]
label = "Osquery - Retrieve Information for a Specific User"
query = "SELECT * FROM users WHERE username = {{user.name}}"

[[transform.osquery]]
label = "Osquery - Investigate the Account Authentication Status"
query = "SELECT * FROM logged_in_users WHERE user = {{user.name}}"

[[transform.osquery]]
label = "Osquery - Retrieve Running Processes by User"
query = "SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"

[[transform.osquery]]
label = "Osquery - Retrieve Process Info"
query = "SELECT name, cmdline, parent, path, uid FROM processes"

[rule]
author = ["Elastic"]
description = """
Identifies the execution of the EarthWorm tunneler. Adversaries may tunnel network communications to and from a victim
system within a separate protocol to avoid detection and network filtering, or to enable access to otherwise unreachable
systems.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Protocol Tunneling via EarthWorm"
note = """## Triage and analysis

### Investigating Potential Protocol Tunneling via EarthWorm

Attackers can leverage `earthworm` to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems.

This rule looks for several command line arguments that are consistent with `earthworm` tunneling behavior. 

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.

#### Possible investigation steps

- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior.
  - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration.
    - $osquery_0
    - $osquery_1
- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.
  - $osquery_2
- Investigate whether the user is currently logged in and active.
  - $osquery_3
- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
  - $osquery_4
  - $osquery_5
- Investigate other alerts associated with the user/host during the past 48 hours.
  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
    - Use a private sandboxed malware analysis system to perform analysis.
      - Observe and collect information about the following activities:
        - Attempts to contact external domains and addresses.
          - Check if the domain is newly registered or unexpected.
          - Check the reputation of the domain or IP address.
        - File access, modification, and creation activities.

### Related rules

- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd
- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f
- Potential Linux Tunneling and/or Port Forwarding - 6ee947e9-de7e-4281-a55d-09289bdf947e

### False positive analysis

- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
- If this activity is related to a system administrator or developer who uses port tunneling for benign purposes, consider adding exceptions for specific user accounts or hosts. 
- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
    "http://rootkiter.com/EarthWorm/",
    "https://decoded.avast.io/luigicamastra/apt-group-targeting-governmental-agencies-in-east-asia/",
]
risk_score = 73
rule_id = "9f1c4ca3-44b5-481d-ba42-32dc215a2769"
setup = """## Setup

This rule requires data coming in either from Elastic Defend, or Auditbeat integration.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).

### Auditbeat Setup
Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).

#### Custom Ingest Pipeline
For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the [guide](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "start", "exec_event", "ProcessRollup2", "executed", "exec_event", "process_started") and
process.args : "-s" and process.args : "-d" and process.args : "rssocks"
'''

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

[[rule.threat.technique]]
id = "T1090"
name = "Proxy"
reference = "https://attack.mitre.org/techniques/T1090/"

[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"

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

[metadata]
creation_date = "2024/11/04"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects private key searching activity on Linux systems. Searching for private keys can be an indication of an
attacker attempting to escalate privileges or exfiltrate sensitive information.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-auditd_manager.auditd-*",
]
language = "eql"
license = "Elastic License v2"
name = "Private Key Searching Activity"
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 Private Key Searching Activity

In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key files in sensitive directories, signaling potential malicious intent. This proactive monitoring helps mitigate risks associated with unauthorized key access.

### Possible investigation steps

- Review the process details to confirm the 'find' command was executed with parameters targeting private key files, as indicated by the command line containing patterns like "*id_dsa*", "*id_rsa*", etc., and directories such as "/home/", "/etc/ssh", or "/root/".
- Identify the user account associated with the process to determine if the activity aligns with expected behavior for that user or if it suggests potential compromise.
- Check the process's parent process to understand the context in which the 'find' command was executed, which may provide insights into whether this was part of a legitimate script or an unauthorized action.
- Investigate any recent login activity or changes in user privileges for the account involved to assess if there has been any unauthorized access or privilege escalation.
- Examine system logs and other security alerts around the time of the event to identify any correlated suspicious activities or anomalies that might indicate a broader attack campaign.

### False positive analysis

- System administrators or automated scripts may use the 'find' command to locate private keys for legitimate maintenance tasks. To handle this, create exceptions for known administrative accounts or scripts that regularly perform these actions.
- Backup processes might search for private keys as part of routine data protection activities. Identify and exclude these processes by specifying their unique command-line patterns or process IDs.
- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place. Exclude these activities by recognizing the specific tools or scripts used during audits.
- Developers or DevOps teams may search for private keys during application deployment or configuration. Establish a list of trusted users or processes involved in these operations and exclude them from triggering alerts.
- Automated configuration management tools like Ansible or Puppet might search for keys as part of their operations. Identify these tools and exclude their specific command-line patterns to prevent false positives.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'find' command searching for private keys.
- Conduct a thorough review of access logs and process execution history to identify any unauthorized access or privilege escalation attempts.
- Change all potentially compromised private keys and associated credentials, ensuring new keys are securely generated and stored.
- Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files."""
risk_score = 73
rule_id = "627374ab-7080-4e4d-8316-bef1122444af"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Tactic: Credential Access",
    "Data Source: Auditd Manager",
    "Data Source: Elastic Defend",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and
process.name == "find" and
process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
'''

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

[[rule.threat.technique]]
id = "T1083"
name = "File and Directory Discovery"
reference = "https://attack.mitre.org/techniques/T1083/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1552.001"
name = "Credentials In Files"
reference = "https://attack.mitre.org/techniques/T1552/001/"

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

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