Elastic rules: 3a

[metadata]
creation_date = "2025/12/15"
maturity = "production"
updated_date = "2026/02/16"

[rule]
author = ["Elastic"]
description = """
This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and
involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses
are more likely to be related to a compromise.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Alerts From Multiple Integrations by Source Address"
risk_score = 73
rule_id = "7d02c440-52a8-4854-ad3f-71af7fbb4fc6"
severity = "high"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from .alerts-security.*

// any alerts excluding low severity and the noisy ones
| where kibana.alert.rule.name is not null and source.ip is not null and kibana.alert.risk_score > 21 and
        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)

// group alerts by source.ip and extract values of interest for alert triage
| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
        Esql.event_module_values = VALUES(event.module),
        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.message_values = VALUES(message),
        Esql.event_category_values = VALUES(event.category),
        Esql.event_action_values = VALUES(event.action),
        Esql.destination_ip_values = VALUES(destination.ip),
        Esql.host_id_values = VALUES(host.id),
        Esql.agent_id_values = VALUES(agent.id),
        Esql.user_name_values = VALUES(user.name),
        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by source.ip

// filter for alerts from same source.ip reported by different integrations with unique categories and with different severity levels
| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
| keep source.ip, Esql.*
'''
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 Alerts From Multiple Integrations by Source Address

The detection rule uses alert data to determine when multiple alerts from different integrations involving the same source.ip are triggered.

### Possible investigation steps

- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.

### False positive analysis

- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.

### Response and remediation

- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""

[metadata]
bypass_bbr_timing = true
creation_date = "2023/09/25"
integration = ["endpoint"]
maturity = "production"
updated_date = "2024/05/21"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the creation of an archive file with an unusual extension. Attackers may attempt to evade detection by
masquerading files using the file extension values used by image, audio, or document file types.
"""
from = "now-9m"
index = ["logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "Archive File with Unusual Extension"
risk_score = 21
rule_id = "cffbaf47-9391-4e09-a83c-1f27d7474826"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.action != "deletion" and

  /* common archive file headers - Rar, 7z, GZIP, MSCF, XZ, ZIP */
  file.Ext.header_bytes : ("52617221*", "377ABCAF271C*", "1F8B*", "4d534346*", "FD377A585A00*", "504B0304*", "504B0708*") and

  (
    /* common image file extensions */
    file.extension : ("jpg", "jpeg", "emf", "tiff", "gif", "png", "bmp", "ico", "fpx", "eps", "inf") or

    /* common audio and video file extensions */
    file.extension : ("mp3", "wav", "avi", "mpeg", "flv", "wma", "wmv", "mov", "mp4", "3gp") or

    /* common document file extensions */
    (file.extension : ("doc", "docx", "rtf", "ppt", "pptx", "xls", "xlsx") and

    /* exclude ZIP file header values for OPENXML documents */
    not file.Ext.header_bytes : ("504B0304*", "504B0708*"))
  ) and

  not (process.executable : "?:\\Windows\\System32\\inetsrv\\w3wp.exe" and file.path : "?:\\inetpub\\temp\\IIS Temporary Compressed Files\\*")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[rule.threat.technique.subtechnique]]
id = "T1036.008"
name = "Masquerade File Type"
reference = "https://attack.mitre.org/techniques/T1036/008/"



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

[metadata]
bypass_bbr_timing = true
creation_date = "2024/08/26"
integration = ["aws"]
maturity = "production"
updated_date = "2025/12/04"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies when a single AWS resource is making `DescribeInstances` API calls in more than 10 regions within a 30-second
window. This could indicate a potential threat actor attempting to discover the AWS infrastructure across multiple
regions using compromised credentials or a compromised instance. Adversaries may use this information to identify
potential targets for further exploitation or to gain a better understanding of the target's infrastructure.
"""
false_positives = [
    """
    Legitimate use of the `DescribeInstances` API call by an AWS resource that requires information about instances in
    multiple regions.
    """,
    "Scheduled tasks or scripts that require information about instances in multiple regions.",
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "AWS EC2 Multi-Region DescribeInstances API Calls"
note = """## Triage and analysis

### Investigating AWS EC2 Multi-Region DescribeInstances API Calls

This rule flags when the `DescribeInstances` API is executed across multiple AWS regions within a short timeframe. While benign in some cases (e.g., asset inventory, legitimate multi-region management), this pattern can indicate a reconnaissance phase in which an adversary enumerates EC2 instances in all regions to identify potential targets across the environment.

Because the signal can generate significant noise in dynamic or large AWS environments, this rule should be treated as a Building Block Rule (BBR), not a stand-alone alert requiring immediate incident response. Instead, it is best used for hunting, enrichment, correlation, and escalation when combined with other signals.

### How to use this rule (hunting & correlation guide)

This rule is most effective when paired with other detection rules or data sources. Use it to answer questions such as:

- Did a newly created or unknown principal call `DescribeInstances` across many regions? Pair this with a new terms or first-time principal rule (e.g., `GetCallerIdentity`, `AssumeRole`, or `aws.cloudtrail.user_identity.session_context.session_issuer.arn`).  
- Was the same principal also observed making other discovery or enumeration calls (e.g., `DescribeSnapshots`, `DescribeVolumes`, `DescribeImages`, `DescribeSecurityGroups`) in a short timeframe?  
- Did the multi-region calls precede or coincide with higher-risk actions such as:  
  - Snapshot creation or shared snapshot modifications (`CreateSnapshot`, `ModifySnapshotAttribute`)  
  - AMI export/copy operations (`ExportImage`, `CopyImage`)  
  - Access key creation, role assumption, or IAM permission changes  
  - Unexpected S3 bucket or data transfer activity (e.g., large data egress, new S3 bucket writes)  
- Did the activity span regions normally unused or outside the organization's typical operational footprint?

#### Possible investigation steps:

- **Review the principal and session trace**:  
  - Identify `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`, and determine whether the principal is known, recently onboarded, or unusual (e.g., a service role used in rare cases).  
  - Examine `user_agent.original` and `source.ip` for anomalies (e.g., new CLI/SDK versions, IAM roles from unexpected hosts, geolocation outside expected range).

- **Evaluate region distribution and timing**:  
  - Inspect the regions contacted by `DescribeInstances` within the alert window. Are some regions rarely used in your org?  
  - Look at the timeline: did the calls occur in rapid succession or spread out? A burst suggests automated reconnaissance rather than manual usage.

- **Correlate with other detection signals & data access patterns**:  
  - Query for other CloudTrail events by the same principal in the ±30 minutes window: enumeration APIs (`Describe*`), snapshot/AMI events, `CopySnapshot`, `ExportImage`, `StartInstances`, etc.  
  - Cross-validate with SIEM or data egress logs: did large volumes of data leave the environment after the enumeration?  
  - Review IAM activity for privilege elevation, new access keys, or role chaining that could support the enumeration action.

- **Assess intent and operational context**:  
  - Determine whether the enumeration aligns with known asset-inventory or management tasks (Recurring scans, DevOps automation, IT health checks).  
  - If this principal is known for asset management, verify the timing, region list, and audit logs for existing tickets/change-records.  
  - If the activity is unexpected, low legitimacy, or tied to other suspicious events, escalate.

### False positive analysis:

Because many organizations have legitimate multi-region cloud operations, this rule may generate false positives. Common benign scenarios include:

- DevOps or cloud-ops automation that inventories EC2 instances across all regions (for cost, compliance, or multi-region deployment verification).  
- Large-scale migrations or disaster-recovery tests that touch many regions in a short time.  
- Security or audit team enumeration of the environment (e.g., internal red-team, internal asset scanning).  
- Cross-account management tools in AWS Organizations that routinely query multiple regions.

To manage these, consider:  
- Whitelisting known automation roles/principals (with caution).  
- Tagging and excluding known “inventory scan” sessions (based on user agent, IP range, timing).  
- Using this rule only as a correlation trigger and not as a direct alert.

### Response and escalation:

Because this rule is a BBR, its detection alone does not usually warrant full incident response. Instead:

- **Document the finding** in your hunt log, noting principal, regions, timestamp, and correlation flags (other events).  
- If correlation reveals additional suspicious activity (e.g., snapshot share, data export, IAM privilege change) escalate to full incident response.  
- If the enumeration is determined benign (e.g., approved internal scan), add context (ticket number, owner, justification) and suppress/annotate this principal in future hunts for a defined interval.  
- Update your detection playbooks to reflect this rule’s role as a recon-indicator, and train analysts to use it as a pivot point.

### Additional information

For further information on AWS `DescribeInstances` permissions and best practices, refer to the [AWS DescribeInstances API documentation](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html).
"""
references = [
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html",
]
risk_score = 21
rule_id = "393ef120-63d1-11ef-8e38-f661ea17fbce"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: AWS EC2",
    "Resources: Investigation Guide",
    "Rule Type: BBR",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws.cloudtrail-* metadata _id, _version, _index

// filter for DescribeInstances API calls
| where event.dataset == "aws.cloudtrail"
  and event.provider == "ec2.amazonaws.com"
  and event.action == "DescribeInstances"

// truncate the timestamp to a 30-second window
| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp)

// keep only the relevant raw fields
| keep 
    Esql.time_window_date_trunc, 
    aws.cloudtrail.user_identity.arn, 
    cloud.region, 
    cloud.account.id,
    aws.cloudtrail.user_identity.access_key_id,
    aws.cloudtrail.user_identity.type,
    user_agent.original,
    source.as.organization.name,
    source.ip,
    @timestamp,
    data_stream.namespace    

// count the number of unique regions and total API calls within the 30-second window
| stats
    Esql.cloud_region_count_distinct = count_distinct(cloud.region),
    Esql.event_count = count(*),
    Esql.event_timestamp_values = VALUES(@timestamp),
    Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type),
    Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id),
    Esql.source_ip_values = VALUES(source.ip),
    Esql.user_agent_original_values = VALUES(user_agent.original),
    Esql.source_as_organization_name_values = VALUES(source.as.organization.name),
    Esql.cloud_account_id_values = VALUES(cloud.account.id),
    Esql.cloud_region_values = VALUES(cloud.region),
    Esql.data_stream_namespace_values = VALUES(data_stream.namespace)
  by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn

// filter for resources making DescribeInstances API calls in more than 10 regions within the 30-second window
| where Esql.cloud_region_count_distinct >= 10 and Esql.event_count >= 10
'''


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


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

[rule.investigation_fields]
field_names = [
    "Esql.cloud_region_count_distinct",
    "Esql.event_count",
    "Esql.event_timestamp_values",
    "aws.cloudtrail.user_identity.arn",
    "Esql.aws_cloudtrail_user_identity_type_values",
    "Esql.aws_cloudtrail_user_identity_access_key_id_values",
    "Esql.source_ip_values",
    "Esql.user_agent_original_values",
    "Esql.source_as_organization_name_values",
    "Esql.cloud_account_id_values",
    "Esql.cloud_region_values",
    "Esql.data_stream_namespace_values"
]

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

[rule]
author = ["Austin Songer", "Elastic"]
description = """
Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to
valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate
sensitive data from a duplicated environment. This rule detects successful restoration operations using
"RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or
post-compromise defense evasion.
"""
false_positives = [
    """
    Restoring an RDS DB instance may be performed legitimately during troubleshooting, development refresh processes,
    migrations, or disaster-recovery drills. Validate the user identity, source IP, automation context, and whether the
    restoration aligns with a known maintenance or testing workflow before treating the event as suspicious. Expected
    behavior can be exempted through rule exceptions.
    """,
]
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS RDS DB Instance Restored"
note = """## Triage and analysis

### Investigating AWS RDS DB Instance Restored

Restoring an RDS DB instance from a snapshot or from S3 is a powerful operation that recreates a full database environment. While legitimate for recovery, migrations, or cloning, adversaries may use restore actions to access historical data, duplicate sensitive environments, evade guardrails, or prepare for data exfiltration. 

This rule detects successful invocation of `RestoreDBInstanceFromDBSnapshot` and `RestoreDBInstanceFromS3`, both of which may indicate attempts to rehydrate old datasets, bypass deletion protection, or establish a shadow environment for further malicious actions.

#### Possible investigation steps

- **Identify the actor and execution context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`.
  - Check `user.name`, `source.ip`, and `user_agent.original` to determine how the restore was executed (console, CLI, automation, SDK).

- **Understand what was restored and why**
  - Inspect `aws.cloudtrail.request_parameters` to identify:
    - Snapshot identifier or S3 location used as the restore source.
    - The new DB instance identifier and configuration parameters.
  - Determine:
    - Whether the snapshot/backup used for the restore contains sensitive or high-value data.
    - Whether this restore created a publicly accessible instance, changed security groups, or used unusual storage/instance classes.

- **Reconstruct the activity flow**
  - Use `@timestamp` to correlate the restore event with:
    - Snapshot creation, copy, or export events.
    - IAM policy changes or privilege escalations.
    - Deletion or modification of the original database.
    - Other RDS lifecycle actions such as `ModifyDBInstance`, `DeleteDBInstance`, or backup configuration changes.
  - Look for signs of attacker staging:
    - Prior enumeration activity (`DescribeDBSnapshots`, `DescribeDBInstances`).
    - Recent logins from unusual IPs or federated sessions without MFA.

- **Correlate with broader behavior**
  - Pivot in CloudTrail on:
    - The same snapshot identifier.
    - The same actor or access key ID.
    - The newly created DB instance identifier.
  - Examine:
    - Whether the restored DB was modified immediately after (e.g., security groups opened, deletion protection disabled).
    - Whether there were large-volume read operations or export actions following the restore.
    - Whether the restore is part of a pattern of parallel suspicious activity (snapshot copying, S3 backups, cross-account actions).

- **Validate intent with owners**
  - Confirm with the application/database/platform teams:
    - Whether the restore was requested or part of an authorized operational workflow.
    - Whether this restore corresponds to migration, testing, DR drill, or another planned activity.
    - Whether the restored environment should exist (and for how long).

### False positive analysis

- **Legitimate maintenance and DR workflows**
  - Many teams restore databases for patch testing, DR validation, schema testing, or migration.
- **Automated restore workflows**
  - CI/CD pipelines or internal automation may restore DBs to generate staging or dev environments.
- **Third-party tooling**
  - Backup/DR solutions, migration tools, or observability platforms may restore DB instances for operational reasons. Tune based on `user_agent.original` or known service roles.

### Response and remediation

- **Contain the restored environment**
  - If unauthorized:
    - Apply restrictive security groups to block access.
    - Disable public accessibility if enabled.
    - Evaluate whether deletion protection or backup retention is misconfigured.

- **Assess data exposure and intent**
  - Work with data owners to evaluate:
    - The sensitivity of the restored environment.
    - Whether any reads, dumps, or exports occurred post-restore.
    - Whether the restore enabled the attacker to access older or deleted data.

- **Investigate scope and related activity**
  - Review CloudTrail for:
    - Additional restores, exports, or copies.
    - IAM changes allowing expanded privileges.
    - Unusual authentication events or federated sessions without MFA.
    - Related destructive actions (snapshot deletion, backup disabled, instance deletion).

- **Hardening and preventive controls**
  - Enforce least privilege for `rds:RestoreDBInstanceFromDBSnapshot` and `rds:RestoreDBInstanceFromS3`.
  - Use IAM conditions to restrict restore actions by network, principal, or region.
  - Add AWS Config and Security Hub controls for monitoring:
    - Unapproved restores.
    - Public or misconfigured restored instances.
  - Consider SCPs that prevent RDS restores in production accounts except through controlled roles.

- **Post-incident improvements**
  - Rotate credentials for affected IAM users/roles.
  - Update change management processes to ensure restore actions are tracked and approved.
  - Adjust rule exceptions sparingly and ensure high-risk restores continue to generate alerts.

### Additional information

- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html",
    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html",
    "https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/rds__explore_snapshots/main.py",
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-createdbsnapshot-rds-restoredbinstancefromdbsnapshot-rds-modifydbinstance",
]
risk_score = 47
rule_id = "bf1073bf-ce26-4607-b405-ba1ed8e9e204"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS RDS",
    "Use Case: Asset Visibility",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "rds.amazonaws.com"
    and event.action: ("RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3")
    and event.outcome: "success"
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1578.002"
name = "Create Cloud Instance"
reference = "https://attack.mitre.org/techniques/T1578/002/"

[[rule.threat.technique.subtechnique]]
id = "T1578.004"
name = "Revert Cloud Instance"
reference = "https://attack.mitre.org/techniques/T1578/004/"

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

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

[[rule.threat.technique]]
id = "T1074"
name = "Data Staged"
reference = "https://attack.mitre.org/techniques/T1074/"

[[rule.threat.technique.subtechnique]]
id = "T1074.002"
name = "Remote Data Staging"
reference = "https://attack.mitre.org/techniques/T1074/002/"

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

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

[rule]
author = ["Elastic"]
description = """
Identifies AWS CloudTrail events where an unauthenticated source is attempting to access an S3 bucket. This activity may
indicate a misconfigured S3 bucket policy that allows public access to the bucket, potentially exposing sensitive data
to unauthorized users. Adversaries can specify --no-sign-request in the AWS CLI to retrieve objects from an S3 bucket
without authentication. This is a New Terms rule, which means it will trigger for each unique combination of the source.address and targeted bucket name that has not been seen making this API request.
"""
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS S3 Unauthenticated Bucket Access by Rare Source"
note = """## Triage and analysis

### Investigating AWS S3 Unauthenticated Bucket Access by Rare Source

This rule detects requests to an AWS S3 bucket by an unauthenticated source, which could indicate a misconfigured bucket policy allowing public access. Adversaries can exploit this misconfiguration by using tools or AWS CLI options like `--no-sign-request` to access bucket contents.

The rule triggers when an unauthenticated IP address retrieves an object, and that IP has not been seen in the last 7 days.

### Possible Investigation Steps

**Identify the Source of the Request**:
    - Review the `source.address` field to determine the IP address of the request source.
    - Check `source.geo` fields for geographic details of the originating IP address.
    - Analyze the `user_agent.original` field to identify the client or tool used (e.g., `Python Requests`, `aws-cli`, browser).

**Review the Accessed Bucket and Object**:
    - Analyze the `aws.cloudtrail.resources.arn` field to identify the S3 bucket and object being accessed.
    - Inspect `aws.cloudtrail.request_parameters` for bucket name and object key to determine which file was retrieved.
    - Review the `even.action` field to identify which API call was made (e.g., `GetObject`, `ListObjects`, `PutObject`, `ListBucket`).

**Validate the Source IP and Context**:
    - Determine if the IP address (`source.address`) has any prior activity in your environment.
    - Correlate the IP with threat intelligence or blocklist databases to check for malicious indicators.
    - Review CloudTrail logs for other activities originating from the same IP.

**Analyze the S3 Bucket Configuration**:
    - Review the S3 bucket's Access Control List (ACL) and bucket policy to check for misconfigurations allowing public or unauthenticated access.
    - Look for overly permissive settings, such as `Principal: *` or `Effect: Allow` rules that expose the bucket.

**Investigate Additional Activity**:
    - Check if there are subsequent actions, such as:
        - **Additional `GetObject` API calls**: Indicating further data exfiltration.
        - **ListObjects requests**: Attempting to enumerate the bucket's contents.
    - Correlate events within the same timeframe to identify related suspicious activity.

**Assess the Data Exposed**:
    - Identify the retrieved object(s) and analyze their content to assess potential data exposure.
    - Determine if the file contains sensitive information, such as credentials, intellectual property, or PII.

### False Positive Analysis

- **Public Buckets by Design**: Some S3 buckets may intentionally allow public access. Verify with the bucket owner if the access was expected.
- **Automated Tools**: Security scanners or legitimate services may generate `GetObject` events to validate bucket configurations.

### Response and Remediation

**Immediate Action**:
    - Restrict or remove public access to the affected S3 bucket.
    - Update the bucket policy to ensure access is restricted to trusted principals.
    - Enable **S3 Block Public Access** settings to prevent unintended public access.

**Monitoring and Detection**:
    - Enable detailed logging and monitoring for all S3 bucket activities.
    - Configure real-time alerts for unauthenticated `GetObject` or `ListObjects` events on sensitive S3 buckets.

**Security Audits**:
    - Regularly audit S3 bucket policies and ACLs to ensure they adhere to AWS security best practices.
    - Use AWS tools like **Trusted Advisor** or **Access Analyzer** to identify and address misconfigurations.

**Investigate for Data Exfiltration**:
    - Analyze historical CloudTrail logs to determine if other sensitive files were accessed or exfiltrated.
    - Assess the scope of the exposure and initiate further response if sensitive data was compromised.

### Additional Resources

- [AWS Documentation: S3 Bucket Policy Best Practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html)
- [AWS S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)
"""
references = [
    "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/",
]
risk_score = 47
rule_id = "59bf26c2-bcbe-11ef-a215-f661ea17fbce"
setup = "S3 data events must be enabled in CloudTrail to capture the GetObject, PutObject, ListObjects, and DeleteObject actions. Ensure that the AWS CloudTrail service is configured to log data events for the S3 bucket you'd like to monitor."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon S3",
    "Use Case: Asset Visibility",
    "Resources: Investigation Guide",
    "Tactic: Collection",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "s3.amazonaws.com"
    and event.action: (
        "GetObject" or
        "PutObject" or
        "ListObjects" or
        "DeleteObject" or
        "ListBucket")
    and event.outcome: "success"
    and aws.cloudtrail.user_identity.type: ("AWSAccount" or "Unknown")
    and cloud.account.id: "anonymous"
'''


[[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 = "T1619"
name = "Cloud Storage Object Discovery"
reference = "https://attack.mitre.org/techniques/T1619/"

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1565.001"
name = "Stored Data Manipulation"
reference = "https://attack.mitre.org/techniques/T1565/001/"

[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user_agent.original",
    "source.ip",
    "tls.client.server_name",
    "aws.cloudtrail.resources.arn",    
    "aws.cloudtrail.resources.type", 
    "aws.cloudtrail.resources.account_id", 
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["source.address", "tls.client.server_name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2026/05/20"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/05/20"

[rule]
author = ["Elastic"]
description = """
Identifies process start events whose parent matches Azure Virtual Machine Run Command execution patterns on Windows
or Linux. On Windows, Run Command often launches PowerShell with `-ExecutionPolicy Unrestricted` and a `script?.ps1`
file; on Linux, the Azure Linux Agent (waagent) runs downloaded script.sh under "/var/lib/waagent/run-command/".
Child process telemetry exposes the on-guest payload that cloud activity logs do not fully describe.
"""
false_positives = [
    """
    Legitimate configuration management, extension deployment, or automation that uses Azure Run Command with the same
    PowerShell or shell script paths may match. Baseline approved VM names, script naming, and deployment windows
    before tuning.
    """,
]
from = "now-9m"
index = [
    "logs-endpoint.events.process*",
    "logs-windows.sysmon_operational-*"
]
language = "eql"
license = "Elastic License v2"
name = "Azure Run Command Script Child Process"
note = """## Triage and analysis

### Investigating Azure Run Command Script Child Process

Azure VM Run Command executes scripts on guests without interactive RDP or SSH. On Windows, a parent PowerShell
process with `-ExecutionPolicy Unrestricted -File script?.ps1` often precedes child utilities; on Linux, `waagent`
invokes `/var/lib/waagent/run-command/download/*/script.sh` via `bash`, `sh`, or `dash`.

Correlate with `logs-azure.activitylogs-*` for `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` when available.

### Possible investigation steps

- Review `process.command_line`, `process.name`, and `process.parent.command_line` or `process.parent.args`.
- Confirm whether the host is an Azure VM and whether Run Command was expected for that asset.
- Pivot on `host.name` or `host.id` for other suspicious process or network activity in the same window.

### False positive analysis

- Extension handlers, guest configuration, and patch orchestration may use the same parent patterns.
- Exclude known automation hosts or script paths after validating with platform teams.

### Response and remediation

- If unauthorized, review Azure RBAC on the VM and subscription, revoke compromised credentials, and isolate the guest.
- Collect endpoint artifacts and Azure activity logs for incident reporting.
"""
references = [
    "https://docs.microsoft.com/en-us/azure/virtual-machines/run-command",
    "https://hackingthe.cloud/azure/run-command-abuse/"
    ]
risk_score = 47
rule_id = "cb9554e8-9f31-41a8-b4f5-d82144e6dc33"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Endpoint",
    "OS: Linux",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Azure",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type in ("start", "process_started") and
  (
    (process.parent.name == "powershell.exe" and
      process.parent.command_line like "powershell  -ExecutionPolicy Unrestricted -File script?.ps1") or
    (process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and
      process.parent.args like "/var/lib/waagent/run-command/download/*/script.sh")
  )
'''


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

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

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

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

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

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

[metadata]
bypass_bbr_timing = true
creation_date = "2023/07/12"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/02/19"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the use of built-in tools attackers can use to check for Internet connectivity on compromised systems. These
results may be used to determine communication capabilities with C2 servers, or to identify routes, redirectors, and
proxy servers.
"""
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "kuery"
license = "Elastic License v2"
name = "Discovery of Internet Capabilities via Built-in Tools"
risk_score = 21
rule_id = "7f89afef-9fc5-4e7b-bf16-75ffdf27f8db"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Rule Type: BBR",
    "Data Source: Elastic Defend",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:windows and event.category:process and event.type:start and 
process.name.caseless:("ping.exe" or "tracert.exe" or "pathping.exe") and
not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1" or 192.168.*) and
process.command_line:*.*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1016"
name = "System Network Configuration Discovery"
reference = "https://attack.mitre.org/techniques/T1016/"
[[rule.threat.technique.subtechnique]]
id = "T1016.001"
name = "Internet Connection Discovery"
reference = "https://attack.mitre.org/techniques/T1016/001/"



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

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

[rule]
description = """
Detects suspicious network events executed by the Yum package manager, potentially indicating persistence through a Yum
backdoor. In Linux, Yum (Yellowdog Updater, Modified) is a command-line utility used for handling packages on
Fedora-based systems, providing functions for installing, updating, upgrading, and removing software along with managing
package repositories. Attackers can backdoor Yum to gain persistence by injecting malicious code into plugins that Yum
runs, thereby ensuring continued unauthorized access or control each time Yum is used for package management. For this
persistence mechanism to work, plugins need to be enabled in the `/etc/dnf/dnf.conf` and plugin.conf files.
"""
id = "74afd5bc-7d44-4a11-9383-a5e30c3ec8ae"
license = "Elastic License v2"
name = "Egress Connection by a YUM Package Manager Descendant"
os_list = ["linux"]
reference = [
    "https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
version = "1.0.8"

query = '''
sequence by process.entity_id with maxspan=5s
  [process where event.type == "start" and event.action == "exec" and (
   process.name : (
     "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*",
     "perl", "ruby", "lua*", "openssl", "nc", "ncat", "netcat", "netcat.openbsd",
     "netcat.traditional", "nc.openbsd", "nc.traditional", "telnet", "awk"
   ) or
   process.executable : (
     "./*", "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*", "/run/*", "/srv/*",
     "/tmp/*", "/var/tmp/*", "/var/log/*"
     )
   ) and descendant of [process where event.action == "exec" and process.name == "yum"] and not (
     process.executable : "/run/user/*/newroot/*" or
     process.args : "/usr/local/cpanel/*"
   )
  ]
  [network where event.action == "connection_attempted" and event.type == "start" and not (
     destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
       "FF00::/8", "172.31.0.0/16"
       ) or
     process.name in ("yumBackend.py", "urlgrabber-ext-down") or
     process.executable in ("/usr/share/logstash/jdk/bin/java", "/opt/java/openjdk/bin/java", "/usr/local/cpanel/scripts/rebuildhttpdconf")
     )
  ]
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"


[threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[threat]]
framework = "MITRE ATT&CK"

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

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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
bypass_bbr_timing = true
creation_date = "2026/08/20"
integration = ["netflow", "goflow2"]
maturity = "production"
updated_date = "2026/08/20"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies a NetFlow, IPFIX, or sFlow exporter IP that has not previously sent decoded flow records in the same data
stream namespace during the prior 2 hours. This low-risk building-block signal records exporter novelty for correlation
with later detection alerts in which the same address is the source of suspicious activity.
"""
false_positives = [
    """
    Newly deployed routers, switches, firewalls, packet brokers, collector migrations, disaster-recovery activation,
    exporter address changes, and integration re-onboarding can trigger this rule.
    """,
]
from = "now-125m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "First Seen Network Flow Exporter"
note = """## Triage and analysis

### Investigating First Seen Network Flow Exporter

This building-block rule detects a newly observed exporter identity from decoded NetFlow, IPFIX, or sFlow records. In
these datasets, `observer.ip` identifies the exporter or sampler. The `source.ip` and `destination.ip` fields identify
endpoints in the exported flow and must not be treated as the exporter transport connection.

This signal establishes novelty only. It does not prove that the exporter is unauthorized or that the exporter itself
performed the activity represented by the flow records. The signal is intended for correlation with later detection
alerts whose `source.ip` equals this alert's `observer.ip`.

### Possible investigation steps

- Identify the device assigned to `observer.ip` and verify its owner, model, location, and change record.
- Confirm the expected collector, data stream namespace, export protocol, observation domain, and template behavior.
- Compare `netflow.exporter.source_id`, `netflow.exporter.version`, sequence values, interfaces, sampling rate, and flow
  volume with established exporters.
- Check for template churn, malformed records, implausible addresses or byte counts, and conflicting telemetry from
  independent sensors.

### False positive analysis

- Validate recent network-device onboarding, collector migrations, disaster-recovery activation, NAT changes, and
  integration re-onboarding.

### Response and remediation

- If unauthorized, block the exporter at the collector boundary and preserve the received records for investigation.
- Review collector authentication, network ACLs, and exporter configuration to prevent further telemetry injection.
"""
references = [
    "https://www.elastic.co/docs/reference/integrations/netflow",
    "https://www.elastic.co/docs/reference/integrations/goflow2",
    "https://datatracker.ietf.org/doc/html/rfc7011",
    "https://sflow.org/sflow_version_5.txt",
]
risk_score = 21
rule_id = "dfe3f626-4224-417e-aff1-8ef9a72c3191"
setup = """## Setup

This rule requires at least one decoded flow-export data source:

- Elastic NetFlow integration (`netflow.log`) for NetFlow or IPFIX records.
- Elastic GoFlow2 integration (`goflow2.sflow`) for sFlow records processed by GoFlow2.

Verify that `observer.ip` contains the exporter or sampler address. Do not broaden this rule to generic firewall or
`network_traffic.flow` events: in those records, `source.ip` and `destination.ip` describe the observed traffic and do
not reliably identify the device exporting telemetry.
"""
severity = "low"
tags = [
    "Domain: Network",
    "Use Case: Network Security Monitoring",
    "Use Case: Threat Detection",
    "Rule Type: BBR",
    "Data Source: NetFlow",
    "Data Source: GoFlow2",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-netflow.log-*, logs-goflow2.sflow-*
| WHERE observer.ip IS NOT NULL AND data_stream.namespace IS NOT NULL
| STATS
    Esql.event_count = COUNT(*),
    Esql.first_time_seen = MIN(@timestamp),
    Esql.data_stream_dataset_values = VALUES(data_stream.dataset)
  BY data_stream.namespace, observer.ip
| EVAL Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, NOW())
| WHERE Esql.recent <= 6
| KEEP
    data_stream.namespace,
    observer.ip,
    Esql.event_count,
    Esql.first_time_seen,
    Esql.data_stream_dataset_values,
    Esql.recent
'''



[rule.investigation_fields]
field_names = [
    "data_stream.namespace",
    "observer.ip",
    "Esql.data_stream_dataset_values",
    "Esql.event_count",
    "Esql.first_time_seen",
    "Esql.recent",
]

[rule.alert_suppression]
group_by = ["data_stream.namespace", "observer.ip"]
missing_fields_strategy = "doNotSuppress"

[rule.alert_suppression.duration]
unit = "h"
value = 2

[metadata]
creation_date = "2026/07/30"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/07/30"

[rule]
author = ["Elastic"]
description = """
Identifies the first successful or no-reply Memcached store command from a client to a server. Memcached commonly has no
authentication, so an unauthorized writer can overwrite session tokens, poison cached application content, or alter
security-sensitive state. This behavior can enable session hijacking such as the exposure described by CVE-2026-29093.
"""
false_positives = [
    """
    New application servers, autoscaled workloads, cache warmers, deployment jobs, administrative tools, and failover
    systems may legitimately write to Memcached for the first time. Validate the client and server roles, affected keys,
    deployment context, and application behavior before escalating.
    """,
]
from = "now-9m"
index = ["logs-network_traffic.memcached-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Time Seen Memcached Writer"
note = """## Triage and analysis

### Investigating First Time Seen Memcached Writer

Memcached permits store commands without authentication by default. A client with network access can use `set`, `add`, `replace`, `append`, `prepend`, or `cas` to overwrite session objects or inject content consumed by an application. This rule uses a seven-day new-terms history window to surface the first observed client, Memcached server, and store command combination performing a successful operation or issuing a store command with `noreply`.

The rule does not inspect cached values and does not prove that a session was hijacked. It identifies an unusual writer relationship that requires application and asset context.

### Possible investigation steps

- Review `client.ip`, `server.ip`, `server.port`, `network.community_id`, `network_traffic.memcached.request.command`, `network_traffic.memcached.request.keys`, `network_traffic.memcached.response.type`, and `network_traffic.memcached.response.status_code`.
- Determine whether the client is an approved application server, cache warmer, administrative host, deployment job, or newly scaled workload.
- Inspect key names for application-specific session prefixes such as `memc.sess.key`, `PHPSESSID`, or `session`. Do not retrieve or ingest cached values unless incident response requires it and access controls permit it.
- Search earlier Memcached events from the same client for `get`, `gets`, `stats`, `lru_crawler`, or key enumeration activity that could indicate discovery before modification.
- Search subsequent events for `flush_all`, delete bursts, privileged web sessions from new source addresses or user agents, and administrative actions without the normal authentication sequence.
- Review application and identity logs to determine whether the write was followed by session reuse or impersonation.

### False positive analysis

- Autoscaling and deployments can introduce legitimate first-time writers.
- NAT or proxies can combine multiple application instances under one client address or make a known writer appear new.
- Add exceptions for validated client and server pairs rather than excluding store commands globally.

### Response and remediation

- Block unauthorized clients and restrict Memcached listeners to approved application and administration networks.
- Invalidate affected sessions and rotate exposed credentials if session manipulation is suspected.
- Bind Memcached to private interfaces, enforce network-layer access controls, and disable UDP unless explicitly needed.
"""
references = [
    "https://nvd.nist.gov/vuln/detail/CVE-2026-29093",
    "https://attack.mitre.org/techniques/T1565/001/",
    "https://www.elastic.co/docs/reference/integrations/network_traffic",
]
risk_score = 47
rule_id = "63c3c736-72e1-4d41-8022-27b5c4935e93"
setup = """## Setup

This rule requires the Elastic Network Packet Capture integration with the Memcached protocol analyzer enabled and
cleartext visibility into client-to-server transactions. The sensor must observe responses to confirm successful
operations, except when the client explicitly uses `noreply`.

Keep value capture disabled unless it is explicitly required and protected. Cached values can contain live session
tokens, credentials, personal data, and other sensitive application content. Key and command metadata are sufficient
for this rule.
"""
severity = "medium"
tags = [
    "Domain: Network",
    "Use Case: Network Security Monitoring",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Data Source: Network Packet Capture",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:network_traffic.memcached and
client.ip:* and server.ip:* and
network_traffic.memcached.request.command:("set" or "add" or "replace" or "append" or "prepend" or "cas") and
(
  network_traffic.memcached.response.type:("Success" or "success") or
  network_traffic.memcached.response.status_code:0 or
  network_traffic.memcached.request.noreply:true
)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1565"
name = "Data Manipulation"
reference = "https://attack.mitre.org/techniques/T1565/"
[[rule.threat.technique.subtechnique]]
id = "T1565.001"
name = "Stored Data Manipulation"
reference = "https://attack.mitre.org/techniques/T1565/001/"



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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.ip",
    "server.ip",
    "server.port",
    "network.community_id",
    "network_traffic.memcached.protocol_type",
    "network_traffic.memcached.request.command",
    "network_traffic.memcached.request.keys",
    "network_traffic.memcached.request.noreply",
    "network_traffic.memcached.response.type",
    "network_traffic.memcached.response.status_code",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["client.ip", "server.ip", "network_traffic.memcached.request.command"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2020/09/22"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies a modification to a Logging sink in Google Cloud Platform (GCP). Logging compares the log entry to the sinks
in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink's export
destination. An adversary may update a Logging sink to exfiltrate logs to a different export destination.
"""
false_positives = [
    """
    Logging sink modifications may be done by a system or network administrator. Verify whether the user email, resource
    name, and/or hostname should be making changes in your environment. Sink modifications from unfamiliar users or
    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Logging Sink Modification"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating GCP Logging Sink Modification

In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule identifies successful modifications to logging sinks, signaling potential misuse by monitoring specific audit events related to sink updates.

### Possible investigation steps

- Review the event details for the specific `event.action` field value `google.logging.v*.ConfigServiceV*.UpdateSink` to confirm the type of modification made to the logging sink.
- Check the `event.outcome` field to ensure the modification was successful, as indicated by the value `success`.
- Identify the user or service account responsible for the modification by examining the `actor` or `principalEmail` fields in the audit log.
- Investigate the `resource` field to determine which logging sink was modified and assess its intended purpose and usual configuration.
- Analyze the `destination` field in the sink configuration to verify if the new export destination is authorized and aligns with organizational policies.
- Review historical logs for any previous modifications to the same logging sink to identify patterns or repeated unauthorized changes.
- Correlate this event with other security alerts or anomalies in the environment to assess if this modification is part of a broader attack or data exfiltration attempt.

### False positive analysis

- Routine updates to logging sinks by authorized personnel can trigger alerts. To manage this, maintain a list of known and trusted users who regularly perform these updates and create exceptions for their actions.
- Automated processes or scripts that update logging sinks as part of regular maintenance or deployment activities may cause false positives. Identify these processes and exclude their specific actions from triggering alerts.
- Changes to logging sinks during scheduled maintenance windows can be mistaken for unauthorized modifications. Define and exclude these time periods from monitoring to reduce unnecessary alerts.
- Integration with third-party tools that require sink modifications for functionality might generate false positives. Document these integrations and adjust the detection rule to account for their expected behavior.
- Frequent changes in a dynamic environment, such as development or testing environments, can lead to false positives. Consider applying the rule more stringently in production environments while relaxing it in non-production settings.

### Response and remediation

- Immediately review the audit logs to confirm the unauthorized modification of the logging sink and identify the source of the change, including the user account and IP address involved.
- Revert the logging sink configuration to its original state to ensure logs are directed to the intended, secure destination.
- Temporarily disable or restrict access to the user account or service account that made the unauthorized change to prevent further unauthorized actions.
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized modification and initial containment actions taken.
- Conduct a thorough investigation to determine if any data was exfiltrated and assess the potential impact on the organization.
- Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future.
- Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/logging/docs/export#how_sinks_work"]
risk_score = 21
rule_id = "184dfe52-2999-42d9-b9d1-d1ca54495a61"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Log Auditing",
    "Tactic: Exfiltration",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.UpdateSink and event.outcome:success
'''


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

[[rule.threat.technique]]
id = "T1537"
name = "Transfer Data to Cloud Account"
reference = "https://attack.mitre.org/techniques/T1537/"

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

[[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]
description = """
Detects when Curl or NsCurl download and modify a hidden AppleScript file. Threat actors have been seen downloading a
hidden AppleScript file as a second stage payload in order to facilitate additional post exploitation actions on
compromised systems.
"""
id = "a6ed2e19-67e9-4999-b4a7-499b86cf5784"
license = "Elastic License v2"
name = "Hidden AppleScript Download via Curl"
os_list = ["macos"]
reference = ["https://x.com/moonlock_lab/status/1980683916571996312"]
version = "1.0.1"

query = '''
sequence with maxspan=20s
[process where event.type == "start" and event.action == "exec" and process.name in ("curl", "nscurl")] by process.parent.entity_id
[file where event.action == "modification" and file.name : ".*" and file.extension == "scpt" and process.name in ("curl", "nscurl")] by Effective_process.entity_id
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.entity_id"
state = 1

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"



[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"


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

[internal]
min_endpoint_version = "8.16.0"

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

[rule]
author = ["Elastic"]
description = """
This rule detects the use of the mount utility from inside a privileged container. The mount command is used to make a
device or file system accessible to the system, and then to connect its root directory to a specified mount point on the
local file system. When launched inside a privileged container--a container deployed with all the capabilities of the
host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation
and container escapes to the host machine. Any usage of mount inside a running privileged container should be further
investigated.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Mount Execution Detected via Defend for Containers"
note = """## Setup
## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Mount Execution Detected via Defend for Containers

In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security threats for further investigation.

### Possible investigation steps

- Review the alert details to confirm that the process name is "mount" and that the container's security context is marked as privileged.
- Identify the container involved in the alert by examining the container ID or name, and gather information about its purpose and the applications it runs.
- Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function.
- Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity.
- Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed.
- Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation.

### False positive analysis

- Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns.
- Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions.
- Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise.
- Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts.
- Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations.

### Response and remediation

- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network.
- Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary.
- Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files.
- If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts.
- Patch and update the container image and host system to address any vulnerabilities that may have been exploited.
- Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like `mount`.
- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions."""
references = [
    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged",
]
risk_score = 21
rule_id = "41f7da9e-4e9f-4a81-9b58-40d725d83bc0"
severity = "low"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  process.name == "mount" or
  (
    /* account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
    process.args in (
      "mount", "/bin/mount", "/usr/bin/mount", "/usr/local/bin/mount"
    ) and
    /* default exclusion list to not FP on default multi-process commands */
    not process.args in (
      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
    )
  )
) and container.security_context.privileged == true and container.id like "*"
'''

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

[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

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

[metadata]
creation_date = "2026/01/07"
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days
of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this
to prioritize triage and response.
"""
from = "now-7205m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Newly Observed High Severity Detection Alert"
risk_score = 73
rule_id = "1a3d5b36-b995-4ace-9b85-8a0af429ccf6"
severity = "high"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM .alerts-security.*
| where kibana.alert.rule.name is not null and kibana.alert.risk_score >= 73  and
  not kibana.alert.rule.type in ("threat_match", "machine_learning", "new_terms") and
  not kibana.alert.rule.name like "Deprecated - *" and kibana.alert.rule.name != "My First Rule" and
  // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8
  event.dataset != "endpoint.alerts" and
  not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
| STATS Esql.alerts_count = count(*),
        Esql.first_time_seen = MIN(@timestamp),
        Esql.last_time_seen = MAX(@timestamp),
        Esql.process_executable = VALUES(process.executable),
        Esql.process_command_line_values = VALUES(process.command_line),
        Esql.process_parent_executable_values = VALUES(process.parent.executable),
       Esql.file_path_values = VALUES(file.path),
        Esql.dll_path_values = VALUES(dll.path),
        Esql.user_id_values = VALUES(user.id),
        Esql.user_name_values = VALUES(user.name),
        Esql.agent_id_values = VALUES(agent.id),
        Esql.host_id_values = VALUES(host.id),
        Esql.event_module_values = VALUES(event.module),
        Esql.source_ip_values = VALUES(source.ip), 
        Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.agent_id_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name
// fist time seen in the last 5 days - defined in the rule schedule Additional look-back time
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
// first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and Esql.agent_id_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)

// Move single values to their corresponding ECS fields for alerts exclusion
| eval host.id = mv_min(Esql.host_id_values)

| keep host.id, kibana.alert.rule.name, Esql.*
'''
note = """## Triage and analysis

### Investigating Newly Observed High Severity Detection Alert

This rule surfaces newly observed, low-frequency behavior high severity alerts affecting a single agent within the current day.

Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine
whether it represents a true compromise or rare benign activity.

### Investigation Steps

- Identify the affected host, user and review the associated rule name to understand the behavior that triggered the alert.
- Validate the user context under which the activity occurred and assess whether it aligns with normal behavior for that account.
- Refer to the specific rule investiguation guide for further actions.

### False Positive Considerations

- Newly deployed or updated software may introduce behavior not previously observed on the host.
- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.
- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.
- Development or testing environments may produce one-off behaviors that resemble malicious techniques.

### Response and Remediation

- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
- Terminate malicious processes and remove any dropped files or persistence mechanisms.
- Collect forensic artifacts to understand initial access and execution flow.
- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
- If benign, document the finding and consider tuning or exception handling to reduce future noise.
- Continue monitoring the host and environment for recurrence of the behavior or related alerts."""
references = ["https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules"]

[rule]
description = """
Detects suspicious use of sudo's --chroot / -R option consistent with attempts to exploit CVE-2025-32463 (the "sudo
chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to
gain root.
"""
id = "1ec98de0-3c28-4a56-b4ff-becb13cacb6e"
license = "Elastic License v2"
name = "Potential CVE-2025-32463 Sudo Chroot Execution Attempt"
os_list = ["linux"]
reference = [
    "https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot",
    "https://github.com/kh4sh3i/CVE-2025-32463",
]
version = "1.0.3"

query = '''
process where event.type == "start" and event.action == "exec" and
process.name == "sudo" and process.args in ("-R", "--chroot") and
// To enforce the -R and --chroot arguments to be for sudo specifically, while wildcarding potential full sudo paths
process.command_line like ("*sudo -R*", "*sudo --chroot*") and
not process.args == "chown"
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"


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

[internal]
min_endpoint_version = "7.15.0"