Elastic rules: 1u

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

[rule]
author = ["Elastic"]
description = """
Detects attempts to delete an Okta policy. An adversary may attempt to delete an Okta policy in order to weaken an
organization's security controls. For example, an adversary may attempt to delete an Okta multi-factor authentication
(MFA) policy in order to weaken the authentication requirements for user accounts.
"""
false_positives = [
    """
    Consider adding exceptions to this rule to filter false positives if Okta policies are regularly deleted in your
    organization.
    """,
]
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Attempt to Delete an Okta Policy"
note = """## Triage and analysis

### Investigating Attempt to Delete an Okta Policy

Okta policies are critical to managing user access and enforcing security controls within an organization. The deletion of an Okta policy could drastically weaken an organization's security posture by allowing unrestricted access or facilitating other malicious activities.

This rule detects attempts to delete an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. Adversaries may do this to bypass security barriers and enable further malicious activities.

#### Possible investigation steps:

- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert.
- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor.
- Examine the `okta.outcome.reason` field for additional context around the deletion attempt.
- Check the `okta.outcome.result` field to confirm the policy deletion attempt.
- Check if there are multiple policy deletion attempts from the same actor or IP address (`okta.client.ip`).
- Check for successful logins immediately following the policy deletion attempt.
- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deletion attempt.

### False positive analysis:

- Check if there were issues with the Okta system at the time of the deletion attempt. This could indicate a system error rather than a genuine threat activity.
- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deletion attempt. If these match the actor's normal behavior, it might be a false positive.
- Verify the actor's administrative rights to ensure they are correctly configured.

### Response and remediation:

- If unauthorized policy deletion is confirmed, initiate the incident response process.
- Immediately lock the affected actor account and require a password change.
- Consider resetting MFA tokens for the actor and require re-enrollment.
- Check if the compromised account was used to access or alter any sensitive data or systems.
- If a specific deletion technique was used, ensure your systems are patched or configured to prevent such techniques.
- Assess the criticality of affected services and servers.
- Work with your IT team to minimize the impact on users and maintain business continuity.
- If multiple accounts are affected, consider a broader reset or audit of MFA tokens.
- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

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

query = '''
data_stream.dataset:okta.system and event.action:policy.lifecycle.delete
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"

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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"

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

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

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies when an EC2 Route Table has been created. Route tables can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role.
"""
false_positives = [
    """
    Route Tables may be created by a system or network administrators. Verify whether the user identity, user agent,
    and/or hostname should be making changes in your environment. Route Table creation by unfamiliar users or hosts
    should be investigated. If known behavior is causing false positives, it can be exempted from the rule. Automated
    processes that use Terraform may lead to false positives.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 Route Table Created"
note = """## Triage and analysis

### Investigating AWS EC2 Route Table Created

AWS Route Tables are crucial components in managing network traffic within AWS environments, directing data between subnets and internet gateways. Adversaries may exploit route tables to reroute traffic for data exfiltration or to establish persistence by creating unauthorized routes. The detection rule monitors successful creation events of route tables, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized network configuration changes.

### Possible investigation steps

- Investigate the AWS account and IAM user or role to determine if the action aligns with expected behavior and permissions.
- Examine the newly created route table's configuration to identify any unauthorized or suspicious routes that could indicate potential misuse or data exfiltration attempts.
- Correlate the event with other network security monitoring data to identify any unusual traffic patterns or anomalies that coincide with the route table creation.
- Assess the environment for any recent changes or incidents that might explain the creation of the route table, such as new deployments or infrastructure modifications.

### False positive analysis

- Routine infrastructure updates or deployments may trigger route table creation events. To manage this, establish a baseline of expected behavior during scheduled maintenance windows and exclude these from alerts.
- Automated cloud management tools often create route tables as part of their operations. Identify these tools and create exceptions for their known activities to reduce noise.
- Development and testing environments frequently undergo changes, including the creation of route tables. Consider excluding these environments from alerts or applying a different set of monitoring rules.
- Legitimate changes by authorized personnel can be mistaken for suspicious activity. Implement a process to verify and document authorized changes, allowing for quick exclusion of these events from alerts.
- Multi-account AWS setups might have centralized networking teams that create route tables across accounts. Coordinate with these teams to understand their activities and exclude them from triggering alerts.

### Response and remediation

- If unauthorized, remove permissions for related actions from the user or role. You can use the managed [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) policy. 
- Review the newly created route table and any associated routes to identify unauthorized entries. Remove any routes that are not part of the expected network configuration.
- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to create or modify route tables. Revoke any excessive permissions identified.
- Implement network monitoring to detect unusual traffic patterns that may indicate data exfiltration or other malicious activities.
- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised.
- Review AWS CloudTrail logs for any other suspicious activities around the time of the route table creation to identify potential indicators of compromise.
- Update security policies and procedures to include specific guidelines for monitoring and responding to unauthorized route table modifications, ensuring rapid detection and response in the future.

## Setup

The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.datadoghq.com/security_platform/default_rules/aws-ec2-route-table-modified/",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateRoute.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateRouteTable",
]
risk_score = 21
rule_id = "e12c0318-99b1-44f2-830c-3a38a43207ca"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EC2",
    "Tactic: Persistence",
    "Rule Type: New Terms",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

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

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

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

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

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

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

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

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.new_terms]
field = "new_terms_fields"
value = ["cloud.account.id", "user.name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

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

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment.
"""
false_positives = [
    """
    A security group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Security group creations by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 Security Group Configuration Change"
note = """## Triage and analysis

### Investigating AWS EC2 Security Group Configuration Change

This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment.

#### Possible Investigation Steps

**Identify the Modified Security Group**:
   - **Security Group ID**: Check the `aws.cloudtrail.request_parameters` field to identify the specific security group affected.
   - **Rule Changes**: Review `aws.cloudtrail.response_elements` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications.

**Review User Context**:
   - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account.
   - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account.

**Analyze the Configuration Change**:
   - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts.
   - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open.

**Check User Agent and Source IP**:
   - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual.
   - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access.

**Evaluate for Persistence Indicators**:
   - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access.
   - **Permissions Review**: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary.

**Correlate with Other CloudTrail Events**:
   - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access.
   - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities.

### False Positive Analysis

- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities.
- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments.

### Response and Remediation

- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment.
- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access.
- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity.
- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access.

### Additional Information

For more details on managing AWS Security Groups and best practices, refer to the [AWS EC2 Security Groups Documentation](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html) and AWS security best practices.
"""
references = ["https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html"]
risk_score = 21
rule_id = "29052c19-ff3e-42fd-8363-7be14d7c5469"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EC2",
    "Tactic: Defense Evasion",
    "Tactic: Persistence",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ec2.amazonaws.com"  and event.outcome: "success"
    and (event.action:(
            "AuthorizeSecurityGroupIngress" or
            "AuthorizeSecurityGroupEgress" or
            "CreateSecurityGroup" or
            "ModifySecurityGroupRules" or
            "RevokeSecurityGroupEgress" or
            "RevokeSecurityGroupIngress") or 
            (event.action: "ModifyInstanceAttribute" and aws.cloudtrail.flattened.request_parameters.groupSet.items.groupId:*))
    and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible*)
'''

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


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

[[rule.threat.technique]]
id = "T1133"
name = "External Remote Services"
reference = "https://attack.mitre.org/techniques/T1133/"

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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1133"
name = "External Remote Services"
reference = "https://attack.mitre.org/techniques/T1133/"

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

[metadata]
creation_date = "2022/07/20"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/12/18"

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a hidden shared object (.so) file. Users can mark specific files as hidden simply by putting
a "." as the first character in the file or folder name. Adversaries can use this to their advantage to hide files and
folders on the system for persistence and defense evasion.
"""
from = "now-9m"
index = ["auditbeat-*", "endgame-*", "logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*"]
language = "eql"
license = "Elastic License v2"
max_signals = 33
name = "Creation of Hidden Shared Object File"
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 Creation of Hidden Shared Object File

Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats.

### Possible investigation steps

- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename.
- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious.
- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation.
- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise.
- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities.
- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism.

### False positive analysis

- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows.
- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts.
- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening.
- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts.

### Response and remediation

- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker.
- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery.
- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts.
- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents."""
risk_score = 47
rule_id = "766d3f91-3f12-448c-b65f-20123e9e9e8c"
setup = """## Setup

This rule requires data coming in from one of the following integrations:
- Elastic Defend
- Auditbeat

### 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 = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "creation" and
(file.extension == "so" or file.name like "*.so.*") and file.name : ".*.so" and
not process.name in ("dockerd", "azcopy", "podman", "opencode") and not file.name like "._*"
'''

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

[[rule.threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"

[[rule.threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"

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

[rule]
description = """
This rule detects DNS queries to dynamic DNS services via living-off-the-land executables or executables in
world/user-writable directories. Malware authors may use these requests to communicate with command and control
infrastructure or to exfiltrate data from the target system.
"""
id = "b85d016e-3a28-43bd-8fbf-cbb19b09dc46"
license = "Elastic License v2"
name = "DNS Request to Dynamic DNS via Suspicious Executable"
os_list = ["linux"]
reference = ["https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/"]
version = "1.0.5"

query = '''
sequence by process.entity_id with maxspan=10s
  [process where event.type == "start" and event.action == "exec" and (
    process.name in ("curl", "wget", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox", "timeout", "env") or
    process.name like (".*", "python*", "perl*", "php*", "ruby*", "lua*", "node", "deno") or
    process.executable like (
      "./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/boot/*", "/sys/*",
      "/lost+found/*", "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*"
    )
  ) and
  not (
    (
      process.parent.name in ("bash", "node") and
      (
        process.working_directory in ("/usr/local/meshcentral", "/opt/meshcentral/meshcentral", "/usr/local/mesh_services/meshagent") or
        process.parent.args in ("/usr/local/meshcentral/node_modules/meshcentral", "/home/periodic/dyndns-noip.sh")
      )
    ) or
    (
      process.command_line == "python3 -m app.run_scheduled_update" and
      process.parent.args == "./workflow_unified.sh"
    ) or
    process.executable == "/usr/bin/qbittorrent-nox" or
    process.executable like "/snap/firefox/*/usr/lib/firefox/firefox" or
    (process.executable like "/usr/bin/php*" and process.args == "/var/tools/koalaping/bin/ping.php")
  )]
  [dns where event.action == "lookup_result" and dns.question.name like~ (
    "*.no-ip.com", "*.no-ip.org", "*.no-ip.biz", "*.no-ip.info", "*.noip.com", "*.afraid.org", "*.changeip.com",
    "*.ddns.net", "*.dyndns.org", "*.hopto.org", "*.zapto.org", "*.servehttp.com", "*.sytes.net", "*.myftp.biz",
    "*.myftp.org", "*.ddnsfree.com", "*.duckdns.org", "*.000webhostapp.com", "*.myddns.me", "*.dlinkddns.com",
    "*.chickenkiller.com", "*.thddns.net", "*.linkpc.net", "*.gotdns.ch", "*.dynv6.net", "*.dns.army",
    "*.dns.navy", "*.v6.army", "*.v6.navy", "*.v6.rocks", "*.dyndns-office.com", "*.myvnc.com", "*.is-certified.com",
    "*.instanthq.com", "*.ddnsgeek.com", "*.ygto.com", "*.casacam.com"
  )]
'''

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

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

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"
[[threat.technique.subtechnique]]
id = "T1071.004"
name = "DNS"
reference = "https://attack.mitre.org/techniques/T1071/004/"


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


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

[internal]
min_endpoint_version = "9.3.0"

[rule]
description = """
Identifies the execution of powershell command via a Microsoft signed Visual Basic script Syncappvpublishingserver.vbs.
Adversaries may use this method to bypass application whitelisting.
"""
id = "96a12f63-320b-4738-bca5-5cf80fc89ede"
license = "Elastic License v2"
name = "Execution via SyncAppvPublishingServer"
os_list = ["windows"]
reference = ["https://lolbas-project.github.io/lolbas/Scripts/Syncappvpublishingserver/"]
version = "1.0.16"

query = '''
process where event.action == "start" and
(
 (process.pe.original_file_name : ("wscript.exe", "cscript.exe", "cmd.exe") and
  process.command_line : "*SyncAppvPublishingServer.vbs*" and process.args : ("n;*", ";*", "Break;*")) or

  (process.name : "powershell.exe" and process.args : "Sync-AppvPublishingServer" and process.args : ("n;*", ";*", "Break;*"))
)
'''

min_endpoint_version = "7.15.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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"

[[threat.technique.subtechnique]]
id = "T1059.003"
name = "Windows Command Shell"
reference = "https://attack.mitre.org/techniques/T1059/003/"

[[threat.technique.subtechnique]]
id = "T1059.005"
name = "Visual Basic"
reference = "https://attack.mitre.org/techniques/T1059/005/"



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


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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies the deletion of an Identity and Access Management (IAM) service account key in Google Cloud Platform (GCP).
Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate. If a key
is deleted, the application will no longer be able to access Google Cloud resources using that key. A security best
practice is to rotate your service account keys regularly.
"""
false_positives = [
    """
    Service account key deletions 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. Key deletions by 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 IAM Service Account Key Deletion"
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 IAM Service Account Key Deletion

In GCP, IAM service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries might delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aiding in timely investigation and response.

### Possible investigation steps

- Review the audit logs for the specific event.action: google.iam.admin.v*.DeleteServiceAccountKey to identify the service account key that was deleted.
- Check the event.outcome: success to confirm the key deletion was successful and not an attempted action.
- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs.
- Investigate the context around the deletion event, including the timestamp and any preceding or subsequent actions in the logs, to understand the sequence of events.
- Verify if the key deletion aligns with the organization's key rotation policy or if it appears suspicious or unauthorized.
- Assess the impact of the key deletion on applications or services that rely on the affected service account for authentication.
- If unauthorized activity is suspected, initiate a broader investigation into potential unauthorized access or other malicious activities involving the affected service account.

### False positive analysis

- Routine key rotation activities by administrators can trigger alerts. To manage this, establish a baseline of expected key rotation schedules and exclude these from alerts.
- Automated scripts or tools that perform regular maintenance and key management might cause false positives. Identify these scripts and whitelist their actions in the monitoring system.
- Service account keys associated with non-critical or test environments may be deleted frequently as part of normal operations. Consider excluding these environments from the alerting criteria to reduce noise.
- Temporary service accounts used for short-term projects or testing may have keys deleted as part of their lifecycle. Document these accounts and adjust the detection rule to ignore deletions from these specific accounts.

### Response and remediation

- Immediately revoke any remaining access for the compromised service account to prevent further unauthorized access to Google Cloud resources.
- Investigate the audit logs to identify any unauthorized actions performed using the deleted key and assess the impact on affected resources.
- Recreate the deleted service account key if necessary, ensuring that the new key is securely stored and access is restricted to authorized personnel only.
- Implement additional monitoring on the affected service account to detect any further suspicious activities or unauthorized access attempts.
- Escalate the incident to the security operations team for a comprehensive review and to determine if further investigation or response is required.
- Review and update the key rotation policy to ensure that service account keys are rotated more frequently and securely managed to prevent similar incidents in the future.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://cloud.google.com/iam/docs/service-accounts",
    "https://cloud.google.com/iam/docs/creating-managing-service-account-keys",
]
risk_score = 21
rule_id = "9890ee61-d061-403d-9bf6-64934c51f638"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccountKey and event.outcome:success
'''


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

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

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

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

[[rule.threat.technique]]
id = "T1531"
name = "Account Access Removal"
reference = "https://attack.mitre.org/techniques/T1531/"

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

[metadata]
creation_date = "2023/12/14"
maturity = "production"
updated_date = "2025/03/20"

[rule]
author = ["Elastic"]
description = """
This rule is part of the "GitHub UEBA - Unusual Activity from Account Pack", and leverages alert data to determine when
multiple alerts are executed by the same user in a timespan of one hour. Analysts can use this to prioritize triage and
response, as these alerts are a higher indicator of compromised user accounts or PATs.
"""
from = "now-60m"
index = [".alerts-security.*"]
language = "kuery"
license = "Elastic License v2"
name = "GitHub UEBA - Multiple Alerts from a GitHub Account"
note = """## Triage and analysis

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

### Investigating GitHub UEBA - Multiple Alerts from a GitHub Account

User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify unusual patterns that may indicate compromised accounts or tokens. Adversaries might exploit GitHub by executing multiple unauthorized actions within a short period. This detection rule flags such anomalies by monitoring for multiple alerts from the same user within an hour, aiding in prioritizing potential threats for further investigation.

### Possible investigation steps

- Review the alert details in the security dashboard to identify the specific user account associated with the multiple alerts.
- Check the recent activity logs for the identified user in GitHub to determine the nature and frequency of actions performed within the alert timeframe.
- Investigate any recent changes to the user's permissions or access levels that might have facilitated unusual activity.
- Correlate the alert data with other security tools or logs to identify any additional suspicious behavior or related alerts involving the same user.
- Contact the user to verify if the actions were legitimate or if they suspect their account or personal access token (PAT) might be compromised.
- If a compromise is suspected, initiate a password reset and revoke any active PATs for the user, and monitor for any further suspicious activity.

### False positive analysis

- High-frequency automated workflows or CI/CD pipelines may trigger multiple alerts within an hour. Review these workflows to ensure they are legitimate and consider adding exceptions for known, non-threatening automation.
- Developers or teams working on time-sensitive projects might perform numerous actions in a short period, leading to false positives. Identify these users or teams and create exceptions to prevent unnecessary alerts.
- Scheduled tasks or scripts that interact with GitHub repositories can generate multiple alerts. Verify the legitimacy of these tasks and exclude them from the rule if they are deemed safe.
- Frequent use of GitHub Actions or bots that perform repetitive tasks could be misinterpreted as suspicious activity. Confirm their purpose and add them to an allowlist if they are part of normal operations.
- Consider implementing a review process for alerts that involve known trusted users or service accounts to quickly dismiss false positives without compromising security.

### Response and remediation

- Immediately isolate the affected GitHub account by revoking all active sessions and tokens to prevent further unauthorized actions.
- Conduct a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security.
- Review recent activity logs for the affected account to identify any unauthorized changes or data exfiltration, and revert any malicious modifications.
- Notify the account owner and relevant security teams about the potential compromise to ensure awareness and coordinated response efforts.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional accounts or systems are affected.
- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
- Update and refine access controls and permissions for the affected account to minimize the risk of future unauthorized actions."""
risk_score = 47
rule_id = "929223b4-fba3-4a1c-a943-ec4716ad23ec"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Execution",
    "Rule Type: Higher-Order Rule",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open"
'''


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

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

[rule.threshold]
field = ["user.name"]
value = 1
[[rule.threshold.cardinality]]
field = "signal.rule.name"
value = 5

[metadata]
creation_date = "2020/07/06"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/07/16"

[rule]
author = ["Elastic"]
description = """
Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity
algorithm leveraged by Halfbaked implant beacons for command and control.
"""
false_positives = [
    """
    This rule should be tailored to exclude systems, either as sources or destinations, in which this behavior is
    expected.
    """,
]
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Halfbaked Command and Control Beacon"
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 Halfbaked Command and Control Beacon

Halfbaked malware exploits common network protocols to maintain persistence and facilitate command and control (C2) operations within compromised networks. Adversaries leverage HTTP and TLS protocols to disguise malicious traffic as legitimate, often targeting specific ports like 53, 80, 8080, and 443. The detection rule identifies suspicious network patterns, such as unusual URL structures and specific transport protocols, to flag potential C2 beaconing activities.

### Possible investigation steps

- Review the network traffic logs to identify any connections to IP addresses matching the pattern specified in the query (e.g., http://[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/cd) and determine if these IPs are known or suspicious.
- Analyze the destination ports (53, 80, 8080, 443) used in the flagged traffic to assess if they align with typical usage patterns for the affected systems or if they indicate potential misuse.
- Examine the HTTP and TLS traffic details to identify any unusual URL structures or anomalies in the network.protocol field that could suggest malicious activity.
- Correlate the detected network activity with endpoint logs to identify any associated processes or applications that may have initiated the suspicious traffic.
- Investigate any related alerts or historical data for patterns of similar activity, which could indicate a persistent threat or ongoing compromise within the network.

### False positive analysis

- Legitimate software updates or patch management systems may use similar URL structures and ports, leading to false positives. Users can create exceptions for known update servers by whitelisting their IP addresses or domain names.
- Internal web applications or services that use non-standard ports like 8080 for HTTP traffic might trigger the rule. Identify these applications and exclude their traffic from the rule by specifying their IP addresses or domain names.
- Network monitoring tools or security appliances that perform regular scans or health checks over HTTP or TLS might mimic the detected patterns. Exclude these tools by adding their IP addresses to an exception list.
- Content delivery networks (CDNs) often use IP-based URLs for load balancing and might be mistaken for malicious activity. Verify the legitimacy of the CDN traffic and exclude it by whitelisting the associated IP ranges.
- Automated scripts or bots within the network that access external resources using IP-based URLs could trigger alerts. Review these scripts and, if deemed safe, exclude their traffic by specifying their source IP addresses.

### Response and remediation

- Isolate the affected systems from the network immediately to prevent further communication with the command and control server.
- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove the Halfbaked malware.
- Analyze network traffic logs to identify other potentially compromised systems by looking for similar suspicious network patterns and URL structures.
- Block the identified malicious IP addresses and domains at the network perimeter to prevent further communication attempts.
- Apply security patches and updates to all systems and applications to close vulnerabilities exploited by the malware.
- Restore affected systems from clean backups, ensuring that the backups are free from any signs of compromise.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach.

## Threat intel

This activity has been observed in FIN7 campaigns."""
references = [
    "https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html",
    "https://attack.mitre.org/software/S0151/",
]
risk_score = 73
rule_id = "2e580225-2a58-48ef-938b-572933be06fe"
severity = "high"
tags = [
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Domain: Endpoint",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from packetbeat-*, filebeat-*, logs-network_traffic.* metadata _id, _version, _index
| where (
    data_stream.dataset in ("network_traffic.tls", "network_traffic.http") or
    (event.category in ("network", "network_traffic") and network.protocol == "http")
  )
| where network.transport == "tcp"
| where url.full RLIKE "http://[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/cd"
| where destination.port in (53, 80, 8080, 443)
| keep @timestamp, url.full, source.ip, destination.ip, destination.port, network.protocol, data_stream.dataset, _id, _version, _index
'''


[[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.001"
name = "Web Protocols"
reference = "https://attack.mitre.org/techniques/T1071/001/"


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



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

[rule]
description = """
Identifies the execution of Windows utilities to tamper with system recovery settings. Adversaries may delete or remove
built-in operating system data and turn off services designed to aid in the recovery of a corrupted system and prevent
recovery.
"""
id = "d3588fad-43ae-4f2d-badd-15a27df72132"
license = "Elastic License v2"
name = "Inhibit System Recovery via Untrusted Parent Process"
os_list = ["windows"]
version = "1.0.33"

query = '''
sequence with maxspan=1m
  [process where event.action == "start" and
    process.Ext.token.integrity_level_name : ("high", "system") and
    not process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe", "?:\\Windows\\System32\\*.exe", "?:\\Windows\\SysWOW64\\*.exe") and
    not process.code_signature.trusted == true and
    not process.hash.sha256 : "60ccd4ba2566d96676b448203fb4414a39c7c1e004e8c3fa1bbce139403ef1fb"] by process.entity_id
  [process where event.action == "start" and
    (
      (process.pe.original_file_name : "wmic.exe" and process.command_line : "*shadowcopy*" and process.command_line : "*delete*") or
      (process.pe.original_file_name : "vssadmin.exe" and process.command_line : "*shadows*" and process.command_line : ("*delete*", "*resize*")) or
      (process.pe.original_file_name : "bcdedit.exe" and process.command_line : ("*bootstatuspolicy*", "*recoveryenabled*")) or
      (process.pe.original_file_name : "wbadmin.exe" and process.command_line : ("*catalog*", "*systemstatebackup*") and process.command_line : "*delete*")
    ) and
    not (process.name : "bcdedit.exe" and process.args in ("ignoreallfailures", "displayallfailures"))
  ] by process.parent.entity_id
'''

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

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

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


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Identifies the Osascript process accessing the Kerberos configuration file. Adversaries may attempt to access this file
in order to gain situational awareness regarding the Active Directory domain to include its structure and settings.
"""
id = "ac72d6b3-c647-42e3-bafc-03ccf3180204"
license = "Elastic License v2"
name = "Kerberos Config File Accessed by Osascript"
os_list = ["macos"]
version = "1.0.6"

query = '''
file where event.action == "open" and 
 file.path like "/etc/krb5.conf" and 
 process.name == "osascript"
'''

min_endpoint_version = "8.11.1"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.executable"
state = 0

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.002"
name = "AppleScript"
reference = "https://attack.mitre.org/techniques/T1059/002/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"


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

[internal]
min_endpoint_version = "8.11.1"

[metadata]
creation_date = "2020/03/25"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/29"

[rule]
author = ["Elastic"]
description = """
An instance of MSBuild, the Microsoft Build Engine, was started by an Office application. This is unusual behavior for
the Build Engine and could have been caused by a malicious document executing a script payload.
"""
false_positives = [
    """
    The Build Engine is commonly used by Windows developers but use by non-engineers is unusual. It is quite unusual for
    this program to be started by an Office application like Word or Excel.
    """,
]
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Microsoft Build Engine Started by an Office Application"
references = ["https://blog.talosintelligence.com/building-bypass-with-msbuild/"]
risk_score = 73
rule_id = "c5dc3223-13a2-44a2-946c-e9dc0aa0449c"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.name : "MSBuild.exe" and
  process.parent.name : ("eqnedt32.exe",
                         "excel.exe",
                         "fltldr.exe",
                         "msaccess.exe",
                         "mspub.exe",
                         "outlook.exe",
                         "powerpnt.exe",
                         "winword.exe" )
'''

note = """## Triage and analysis

### Investigating Microsoft Build Engine Started by an Office Application

#### Possible investigation steps

- What Office-to-MSBuild path did the alert capture?
  - Focus: `process.parent.name`, `process.parent.executable`, `process.executable`, and `process.command_line`.
  - Implication: escalate when Office launches MSBuild from a user-writable path or against a project, response, or import path unrelated to document work; lower suspicion only when the Office parent, working directory, project argument, and user-host pair align to one add-in, template-packaging, or test case.
- Is the MSBuild binary the expected Microsoft Build Engine instance?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
  - Implication: escalate when MSBuild is renamed, unsigned, recently introduced, user-writable, or not signed by the expected Microsoft publisher; lower suspicion when path, original name, signer, and hash history fit the installed Microsoft Build Engine. Identity alone does not clear the Office launch.
- Do the MSBuild arguments indicate inline-task or staged-project abuse?
  - Why: MSBuild can execute project-defined tasks, making project or response-file paths the alert-local clue for developer tooling versus payload staging.
  - Focus: `process.command_line` and same-process file activity for project or response artifacts. $investigate_0
  - Implication: escalate when arguments point to XML, project, response, or imported files in temp, downloads, archive, cache, mail, or relative paths, or when targets do not fit user compilation; lower suspicion when the same project path, target set, and working directory match a recognized developer or packaging workflow.
- Does the parent and user context explain this Office-launched build?
  - Focus: `process.parent.command_line`, `user.id`, `host.id`, and `host.name`.
  - Implication: escalate when a standard Office user, shared workstation, or unusual parent command line triggers MSBuild without a matching project path and child helper pattern; lower suspicion when `user.id`, `host.id`, parent command line, project path, and child helpers converge on developer packaging or authorized testing.
- Did MSBuild spawn compiler helpers only, or did it hand off to payload tooling?
  - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, then child `process.executable` and `process.command_line`. $investigate_1
  - Hint: if `process.entity_id` is absent, recover child starts with `host.id` + `process.pid` + a tight alert window; treat the result as weaker than exact lineage.
  - Implication: escalate when MSBuild launches shells, scripting engines, browsers, LOLBins, installers, or children from unexpected paths; lower suspicion when telemetry shows no child starts or only expected compiler helpers such as csc.exe and cvtres.exe for the same recognized project path. Missing child-process telemetry is unresolved, not benign.
- If local evidence is suspicious or unresolved, is this part of a broader Office proxy-execution pattern?
  - Focus: related alerts for the same `user.id`, especially Office-to-script, Office-to-LOLBin, persistence, or credential-access activity. $investigate_2
  - Hint: check whether the same `host.id` shows Office-launched rundll32.exe, regsvr32.exe, mshta.exe, PowerShell, or suspicious child-process alerts. $investigate_3
  - Implication: broaden scope and raise priority when either pivot shows related proxy execution or follow-on alerts; keep localized when related alerts are absent and local evidence points to one stable Office parent, MSBuild project path, child helper pattern, and user-host pair.

- Escalate when identity, arguments, parent context, child behavior, or related alerts show abnormal Office-launched MSBuild execution; close only when the same signer, parent command line, project path, child helper pattern, `host.id`, and `user.id` support a recognized workflow with no contradictory findings; preserve evidence and escalate when visibility or answers remain mixed.

### False positive analysis

- Office add-in, template, document-packaging, or controlled testing workflows can legitimately trigger this rule. Confirm from process evidence that `process.executable`, `process.code_signature.subject_name`, the project or response-file pattern in `process.command_line`, `process.parent.executable`, `process.parent.command_line`, child `process.executable`, and the `user.id` plus `host.id` pair align to the same workflow. When telemetry cannot prove purpose, require outside confirmation before closing; use recurrence only after confirmation to judge exception stability.
- Before creating an exception, validate that the same user-host cohort shows a stable recognized workflow across prior alerts. Keep `process.code_signature.subject_name`, `process.executable`, `process.parent.executable`, the project or response-file pattern in `process.command_line`, `user.id`, and `host.id` stable; allow `process.hash.sha256` changes only when signer, path, and workflow remain consistent with normal updates. Avoid exceptions on `process.name`, Office parent name, or `user.name` alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and record the evidence that validated the workflow: MSBuild signer and path, project-path pattern in `process.command_line`, Office parent context, child-process pattern, and the `user.id` plus `host.id` cohort. Create an exception only after the same pattern recurs consistently across prior alerts.
- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, recovered child entity IDs, `process.command_line`, Office parent command line, and project or response-file paths named in the command line before containment. Apply reversible controls first, such as heightened monitoring, temporary delivery blocks, or endpoint isolation when host criticality allows; avoid process termination or file deletion until lineage and scope are clearer.
- If confirmed malicious, preserve the same process and project evidence, then contain the affected `host.id` or `user.id` based on the child-process chain, payload handoff, or related alerts. Block confirmed malicious indicators recovered during the case, collect suspicious project or response files before deletion, and terminate malicious processes only after recording their entity IDs and command lines.
- Eradicate only artifacts tied to the investigated process chain: malicious Office content, MSBuild project or response files, scripts, build outputs, and follow-on payloads identified from child-process execution. Remediate the delivery path that let Office launch the build chain, then scope other `host.id` and `user.id` values for the same project-path pattern or child-process sequence before broader cleanup.
- Post-incident hardening: restrict Office macro, add-in, and template paths that can invoke developer utilities; retain the process evidence that supported the case; record adjacent Office-launched proxy-execution variants in the case notes for future triage.
"""

setup = """## Setup

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

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

### Additional data sources

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

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

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

[transform]

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

[[transform.investigate]]
label = "Child process events for MSBuild"
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.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"
[[rule.threat.technique.subtechnique]]
id = "T1127.001"
name = "MSBuild"
reference = "https://attack.mitre.org/techniques/T1127/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"

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

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

[rule]
author = ["Elastic"]
description = """
This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window.
By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior,
which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage
toward hosts with higher likelihood of compromise rather than signaling a single discrete event.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Multiple Alerts in Same ATT&CK Tactic by Host"
risk_score = 73
rule_id = "6e92a21a-58e7-449a-9cfd-9f563f59ac88"
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.*  metadata _id

| where kibana.alert.risk_score > 21 and
        kibana.alert.rule.name IS NOT NULL and
        host.id is not null and event.dataset is not null and

        // excluding ML and Threat Match rules as they tend to be noisy
        not kibana.alert.rule.type in ("threat_match", "machine_learning") and

        // excluding noisy tactics like Discovery, Persistence and Lateral Movement
        kibana.alert.rule.threat.tactic.name in ("Credential Access", "Defense Evasion", "Execution", "Command and Control") and

        // excluding some noisy rules
        not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Process Termination followed by Deletion") and
        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)

// extract unique counts and values by host.id and tactic name
| stats Esql.alerts_count = COUNT(*),
        Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.event_module_values = VALUES(event.module),
        Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.threat_technique_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.technique.id),
        Esql.threat_technique_name_values = VALUES(kibana.alert.rule.threat.technique.name),
        Esql.process_executable_values = VALUES(process.executable),
        Esql.process_parent_executable_values = VALUES(process.parent.executable),
        Esql.process_command_line_values = VALUES(process.command_line),
        Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, kibana.alert.rule.threat.tactic.name

// filter for at least 3 unique rules and exclude noisy patterns like high count of alerts or processes often associated with noisy FPs
| where Esql.kibana_alert_rule_name_distinct_count >= 3 and Esql.process_entity_id_distinct_count <= 10 and Esql.alerts_count <= 20

// fields populated in the resulting alerts
| Keep host.id, kibana.alert.rule.threat.tactic.name, 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 Multiple Alerts in Same ATT&CK Tactic by Host

The detection rule identifies hosts with alerts from the same ATT&CK tactic, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, defense evasion, and credential access. This rule prioritizes hosts with high-risk.

### Possible investigation steps

- Review the alert details to identify the specific host involved and the different techniques that triggered the alerts.
- 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 rules. Review and exclude known benign activities such as scheduled software updates or system maintenance.
- Security tools running on the host might generate multiple alerts. 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."""

[rule]
description = """
Detects when Node.js spawns osascript to execute a JavaScript payload. This technique has been seen being used in npm
typosquatting attacks to deploy credential harvesters that steal sensitive information from user systems. Attackers
abuse the osascript utility to execute malicious JavaScript code that maintains persistence and executes additional
malicious payloads.
"""
id = "177d5e00-0fb0-4469-9f7d-4f145e31f7cc"
license = "Elastic License v2"
name = "Nodejs Javascript Execution via Osascript"
os_list = ["macos"]
reference = ["https://socket.dev/blog/10-npm-typosquatted-packages-deploy-credential-harvester"]
version = "1.0.3"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "osascript" and 
 process.args == "-e" and process.command_line : "*/Users/*.js*" and process.parent.name == "node"
'''

min_endpoint_version = "8.11.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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



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

[internal]
min_endpoint_version = "8.11.0"

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

[rule]
author = ["Elastic"]
description = """
This rule detects the creation of pods or containers that execute suspicious commands often associated with persistence or
privilege escalation techniques. Attackers may use container orchestration tools like kubectl or container runtimes like
docker to create pods or containers that run shell commands with arguments that indicate attempts to establish persistence
(e.g., modifying startup scripts, creating backdoors).
"""
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 = "Pod or Container Creation with Suspicious Command-Line"
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 Pod or Container Creation with Suspicious Command-Line

This rule flags pods or containers started via orchestration or runtime tools that immediately execute a shell with commands linked to persistence, privilege changes, or covert I/O (cron, rc.local, sudoers, .ssh, base64, netcat/socat, /tmp). This matters because attackers often spin short‑lived workloads to modify startup paths or drop backdoors. Example: kubectl run --restart=Never -- sh -c 'echo ssh-rsa AAAA... >> /root/.ssh/authorized_keys && nc -lvp 4444 -e /bin/sh'.

### Possible investigation steps

- Pivot to Kubernetes audit logs to identify the actor (user or service account), namespace, source IP/workstation, and RBAC context that launched the workload, and validate whether this aligns with approved admin activity.
- Pull the pod/container spec and image metadata to quickly assess risk indicators like unapproved registry/image, privileged mode, hostNetwork/hostPID, and hostPath or sensitive volume mounts that could mutate the node.
- Parse the executed command to determine whether it attempts persistence or backdoor setup (editing cron/rc.local, sudoers or authorized_keys, base64 file drops, starting netcat/socat listeners), and verify those changes on the container or node.
- Correlate runtime and network telemetry for the workload to detect outbound connections or listening ports indicative of reverse shells, and identify destination endpoints and nodes involved.
- Trace the launcher context by reviewing kubectl client host artifacts (shell history, kubeconfig, IAM/MFA tokens) or CI/CD logs, and check for recent anomalous commits or pipeline runs that could have triggered it.

### False positive analysis

- Administrators performing network troubleshooting or node diagnostics may start ephemeral pods via kubectl run --restart=Never or ad hoc containers with docker/nerdctl that launch sh and use nc/socat/telnet, read /proc, or write to /tmp.
- Engineers may pass configs or test scripts into a shell using base64/xxd and touch cron, rc.local, /etc/ssh, ~/.ssh, or /etc/profile during validation or break-fix work, producing commands that resemble persistence behavior.

### Response and remediation

- Delete the offending pod/container, revoke the kubeconfig or runtime credentials used to launch it, and quarantine the image and namespace, cordoning the node if privileged, hostNetwork/hostPID, or hostPath were present.
- Kill any spawned shells or listeners (e.g., sh -c 'nc -lvp ...', socat, telnet) on affected nodes, remove unauthorized firewall/iptables rules, and apply temporary deny-all egress NetworkPolicies to cut C2.
- Eradicate persistence by restoring clean versions of /etc/cron*, /etc/rc.local, /etc/profile, /etc/sudoers, /etc/ssh/* and deleting unauthorized keys or scripts under /root/.ssh, ~/.ssh, /tmp, /dev/shm, /var/tmp, and hostPath-mounted directories.
- Rebuild compromised nodes or redeploy workloads with known-good images, rotate cluster secrets and SSH keys, and validate baseline integrity with file hashes and admission scans before returning to service.
- Escalate to incident response if the actor is unverified or commands touched /etc/shadow or /etc/sudoers, used privileged containers or hostPath to access the host, or opened external connections or listening ports on the node.
- Harden by enforcing admission controls to deny pods that start /bin/sh or /bin/bash as PID 1, block privileged/hostNetwork/hostPID/hostPath, apply per-namespace egress policies, and restrict RBAC so only approved admins can run kubectl run --restart=Never or docker/nerdctl run.
"""
risk_score = 47
rule_id = "c595363f-52a6-49e1-9257-0e08ae043dbd"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "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", "executed", "process_started") and (
  (process.name == "kubectl" and process.args == "run" and process.args == "--restart=Never" and process.args == "--") or
  (process.name in ("docker", "nerdctl", "ctl") and process.args == "run")
) and 
process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.command_line like~ (
  "*atd*", "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*", "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *",
  "*/etc/profile*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*autostart*", "*xxd *", "*/etc/shadow*", "*./.*",
  "*import*pty*spawn*", "*import*subprocess*call*", "*TCPSocket.new*", "*TCPSocket.open*", "*io.popen*", "*os.execute*", "*fsockopen*",
  "*disown*", "* ncat *", "* nc *", "* netcat *",  "* nc.traditional *", "*socat*", "*telnet*", "*/tmp/*", "*/dev/shm/*", "*/var/tmp/*",
  "*/boot/*", "*/sys/*", "*/lost+found/*", "*/media/*", "*/proc/*", "*/var/backups/*", "*/var/log/*", "*/var/mail/*", "*/var/spool/*"
)
'''

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

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

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

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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1548.003"
name = "Sudo and Sudo Caching"
reference = "https://attack.mitre.org/techniques/T1548/003/"

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

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/006/"

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

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

[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"

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

[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"

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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"

[[rule.threat.technique.subtechnique]]
id = "T1547.013"
name = "XDG Autostart Entries"
reference = "https://attack.mitre.org/techniques/T1547/013/"

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

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/006/"

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

[metadata]
creation_date = "2023/09/22"
integration = ["ded", "endpoint", "network_traffic"]
maturity = "production"
updated_date = "2026/07/27"
min_stack_version = "9.4.0"
min_stack_comments = "Use EA (Entity Analytics) fields"

[rule]
anomaly_threshold = 75
author = ["Elastic"]
description = """
A machine learning job has detected data exfiltration to a particular destination port. Data transfer patterns that are
outside the normal traffic patterns of an organization could indicate exfiltration over command and control channels.
"""
from = "now-6h"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = "ded_high_sent_bytes_destination_port_ea"
name = "Potential Data Exfiltration Activity to an Unusual Destination Port"
references = [
    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
    "https://docs.elastic.co/en/integrations/ded",
    "https://www.elastic.co/blog/detect-data-exfiltration-activity-with-kibanas-new-integration",
]
risk_score = 21
rule_id = "ef8cc01c-fc49-4954-a175-98569c646740"
setup = """## Setup

The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only).

### Data Exfiltration Detection Setup
The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature.

#### Prerequisite Requirements:
- Fleet is required for Data Exfiltration Detection.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
- Network events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) or [Network Packet Capture](https://docs.elastic.co/integrations/network_traffic) integration.
- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
- To add the Network Packet Capture integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.

#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration:
- Go to the Kibana homepage. Under Management, click Integrations.
- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it.
- Follow the instructions under the **Installation** section.
- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
"""
severity = "low"
tags = [
    "Data Source: Elastic Defend",
    "Data Source: Network Packet Capture",
    "Use Case: Data Exfiltration Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Exfiltration",
    "Resources: Investigation Guide",
]
type = "machine_learning"
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 Potential Data Exfiltration Activity to an Unusual Destination Port

Machine learning models analyze network traffic to identify anomalies, such as data transfers to uncommon destination ports, which may suggest exfiltration via command and control channels. Adversaries exploit these channels to stealthily siphon data. This detection rule leverages ML to flag deviations from normal traffic patterns, aiding in early identification of potential threats.

### Possible investigation steps

- Review the network traffic logs to identify the source IP address associated with the unusual destination port activity. Determine if this IP is known or expected within the organization's network.
- Analyze the destination port and associated IP address to assess whether it is commonly used for legitimate purposes or if it is known for malicious activity. Cross-reference with threat intelligence databases if necessary.
- Examine the volume and frequency of data transferred to the unusual destination port to identify any patterns or anomalies that deviate from normal behavior.
- Investigate the user or system account associated with the source IP to determine if there are any signs of compromise or unauthorized access.
- Check for any recent changes or updates in the network configuration or security policies that might explain the anomaly.
- Correlate this event with other security alerts or logs to identify any related suspicious activities or patterns that could indicate a broader threat.

### False positive analysis

- Routine data transfers to external services using uncommon ports may trigger false positives. Identify and document these services to create exceptions in the monitoring system.
- Internal applications that use non-standard ports for legitimate data transfers can be mistaken for exfiltration attempts. Regularly update the list of approved applications and their associated ports to minimize false alerts.
- Scheduled data backups to cloud services or remote servers might use unusual ports. Verify these activities and configure the system to recognize them as non-threatening.
- Development and testing environments often use non-standard ports for various operations. Ensure these environments are well-documented and excluded from exfiltration alerts when appropriate.
- Collaborate with network administrators to maintain an updated inventory of all legitimate network activities and their corresponding ports, reducing the likelihood of false positives.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat.
- Conduct a thorough analysis of the network traffic logs to identify the scope of the exfiltration and determine if other systems are affected.
- Block the identified unusual destination port at the network perimeter to prevent further unauthorized data transfers.
- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block similar exfiltration attempts in the future.
- Notify the incident response team and relevant stakeholders about the potential data breach for further investigation and escalation.
- Perform a comprehensive scan of the affected system for malware or unauthorized software that may have facilitated the exfiltration.
- Implement enhanced monitoring on the affected system and network segment to detect any further suspicious activity."""
[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1041"
name = "Exfiltration Over C2 Channel"
reference = "https://attack.mitre.org/techniques/T1041/"

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

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

[[rule.threat.technique]]
id = "T1571"
name = "Non-Standard Port"
reference = "https://attack.mitre.org/techniques/T1571/"

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