Elastic rules: 1d

[rule]
description = """
Identifies attempts to disable the Microsoft Antimalware Scan Interface via registry modification. This may indicate an
attempt to tamper with certain Windows native protections.
"""
id = "0a3152e5-122f-4145-a107-7ec789b9b1a3"
license = "Elastic License v2"
name = "AMSI Bypass via COM Registry Modification"
os_list = ["windows"]
version = "1.0.4"

query = '''
registry where event.action == "modification" and  
 registry.path : "HKEY_USERS\\*_Classes\\CLSID\\{fdb00e52-a214-4aa1-8fba-4357bb0072ec}\\InProcServer*" and 
 not registry.data.strings : ("?:\\Windows\\System32\\amsi.dll", "?:\\Windows\\SysWOW64\\amsi.dll")
'''

min_endpoint_version = "7.16.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 = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"



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

[internal]
min_endpoint_version = "7.16.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies a short sequence of EC2 management APIs against the same instance that is consistent with modifying instance
user data and forcing it to run on the next boot: `ModifyInstanceAttribute` with user data, followed by stop and start.
Adversaries may update `userData` and cycle instance state so malicious scripts execute as root on Linux or as the
system context on Windows. This rule correlates successful `StopInstances`, `StartInstances`, and
`ModifyInstanceAttribute` events that reference `userData` within a five-minute window, grouped by instance,
`user.name`, account, source IP, and user agent. A hit requires exactly three distinct API names in that bucket.
"""
false_positives = [
    """
    Legitimate automation or administrators may change user data and restart instances during maintenance, image
    baking, or configuration fixes. Review the caller identity, change tickets, and whether `user_agent.original` and
    `source.ip` match known tooling and networks (the rule groups on both together with `user.name`).
    """,
]
from = "now-20m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "AWS EC2 Stop, Start, and User Data Modification Correlation"
note = """## Triage and analysis

### Investigating AWS EC2 Stop, Start, and User Data Modification Correlation

This detection aggregates successful EC2 `StopInstances`, `StartInstances`, and `ModifyInstanceAttribute` (with
`userData` in request parameters) over **five-minute** windows. Rows are keyed by **instance ID** (`Esql.instance_id`
from the grok on `aws.cloudtrail.request_parameters`), **`user.name`**, **`cloud.account.id`**, **`user_agent.original`**,
and **`source.ip`**. The rule fires only when **`Esql.event_action_unique_count` is 3**, meaning all three API names
appear in the same bucket—consistent with changing user data and cycling the instance to run it.

The aggregated result does **not** include raw `request_parameters`; use the alert’s instance, account, user, IP, user
agent, and time bucket to query CloudTrail for the underlying events and payloads.

#### Possible investigation steps

- **Interpret the alert columns**: Review `Esql.event_action_values` to confirm the three actions are present (typically
  `ModifyInstanceAttribute`, `StopInstances`, `StartInstances`). Use `Esql.event_action_unique_count` to verify the
  rule logic (expect `3`).
- **Confirm the instance**: Use `Esql.instance_id` plus `cloud.account.id` in CMDB or AWS Resource Groups. Ensure the
  grok-derived ID matches the instance you expect (multi-instance API calls can affect extraction).
- **Identify the caller**: Tie `user.name` to an IAM user or role session name as shown in CloudTrail; for assumed roles,
  pivot in raw logs on `aws.cloudtrail.user_identity.arn` and session context in the same time window.
- **Validate client and origin**: Compare `user_agent.original` and `source.ip` to known admin workstations, bastions,
  or CI/CD egress. The rule intentionally groups by these fields so unrelated sessions do not merge into one bucket.
- **Recover user data context**: In CloudTrail (or the integration’s `aws.cloudtrail.request_parameters` on raw events),
  inspect the `ModifyInstanceAttribute` record for `userData` and whether values are base64 or placeholders.
- **Hunt for follow-on activity**: After the window, look for IAM changes, role assumption, or data access from the
  instance or the same principal.

### False positive analysis

- **Infrastructure as code**: Terraform, Ansible, and Pulumi user agents are excluded, but other automation may still
  match. Validate pipeline identity, change tickets, and whether stop/start is part of approved maintenance.
- **Break-glass or support workflows**: Some teams modify user data and restart instances during recovery; confirm with
  the workload owner.
- **Shared `user.name` or NAT**: If many callers share one identity or IP, bucketing may still separate sessions when IP
  or user agent differs; conversely, identical UA/IP across benign bulk operations can resemble this pattern—confirm
  intent.

### Response and remediation

- If unauthorized, isolate the instance, revoke or restrict the principal’s EC2 permissions, and rotate any credentials
  that may have been exposed in user data.
- Prefer Secrets Manager or Parameter Store over long-lived secrets in user data.

### Additional information

- [AWS EC2 User Data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)
- [ModifyInstanceAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html)
- [Local EC2 privilege escalation through user data](https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data)
"""
references = [
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html",
    "https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data",
]
risk_score = 73
rule_id = "7e5c0e5a-95a5-404e-a5b0-278d35dc3325"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS EC2",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail-* 
| WHERE event.provider == "ec2.amazonaws.com" 
    and event.outcome == "success"
    and aws.cloudtrail.user_identity.type != "AWSService"
    and not (
      user_agent.original like "*Terraform*"
      or user_agent.original like "*Ansible*"
      or user_agent.original like "*Pulumi*"
    ) and not source.address in ("cloudformation.amazonaws.com", "servicecatalog.amazonaws.com")
    and
  (
   event.action in ("StopInstances", "StartInstances") or 
   (event.action == "ModifyInstanceAttribute" and aws.cloudtrail.request_parameters like "*userData=*")
   )
| grok aws.cloudtrail.request_parameters """instanceId=(?<Esql.instance_id>[^,}\]]+)"""
| STATS Esql.event_action_unique_count = COUNT_DISTINCT(event.action), 
        Esql.event_action_values = VALUES(event.action) by Esql.instance_id, user.name, cloud.account.id, Esql.time_bucket = DATE_TRUNC(5 minute, @timestamp) , user_agent.original, source.ip, source.as.organization.name, source.geo.country_name
| where Esql.event_action_unique_count == 3
| Keep Esql.*, user.name, cloud.account.id, user_agent.original, source.ip, source.as.organization.name, source.geo.country_name
'''


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

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

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

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

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

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

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

[rule.investigation_fields]
field_names = [
  "Esql.event_action_unique_count",
  "Esql.event_action_values",
  "Esql.instance_id",
  "user.name",
  "cloud.account.id",
  "user_agent.original",
  "source.ip",
  "Esql.time_bucket",
]

[metadata]
creation_date = "2026/07/13"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/13"

[rule]
author = ["Elastic"]
description = """
Identifies the first time an IAM principal passes a given execution role (`roleArn`) to an Amazon SageMaker resource,
via `CreateNotebookInstance`, `CreateTrainingJob`, `CreateProcessingJob`, `CreateAutoMLJob`, or `CreatePipeline`. These
actions require `iam:PassRole` and attach an IAM role that the created resource then runs as. An adversary holding both
SageMaker create permissions and a broad `iam:PassRole` grant can pass a more privileged role to a resource they control
and execute code as that role, escalating privileges. The rule keys on the combination of the calling principal and the
passed `roleArn`, so it surfaces a principal using an execution role it has not used before in the last 7 days; a role
whose account differs from the caller's, or that is more privileged than the caller, is especially suspicious.
"""
false_positives = [
    """
    MLOps pipelines and data science teams routinely create SageMaker resources with execution roles, and new pipelines
    or team members appear as new principals on first use. Verify the principal in `aws.cloudtrail.user_identity.arn`,
    the passed roleArn in `aws.cloudtrail.request_parameters`, and whether the role's privileges and the activity are
    approved. Known automation roles can be excluded after validation.
    """,
]
from = "now-7d"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS SageMaker Execution Role Passed by Unusual Principal"
note = """## Triage and analysis

### Investigating AWS SageMaker Execution Role Passed by Unusual Principal

SageMaker resource-creation actions accept a `roleArn` execution role and require the caller to hold `iam:PassRole`
for it. The created resource (notebook, training job, processing job, AutoML job, or pipeline) then runs as that
role. This is a known cloud privilege-escalation path: a principal with SageMaker create rights and a broad
`PassRole` permission can attach a more privileged role to a resource it controls and run code as that role. This
rule keys on the principal and the passed `roleArn` together, so it flags the first time a principal uses a given
execution role within the last 7 days, which should then be reviewed for over-privilege or a cross-account owner.

#### Possible investigation steps

- Identify the actor in `aws.cloudtrail.user_identity.arn`, and review `Esql.source_ip_values` and
  `Esql.user_agent_original_values` for an unexpected origin.
- Inspect `Esql.aws_cloudtrail_request_parameters_role_arn` and review that role's policies; determine whether it is
  more privileged than the caller.
- Determine whether the principal normally creates SageMaker resources and whether this aligns with an approved
  pipeline or project.
- Correlate with follow-on activity by the passed role, such as actions outside SageMaker, presigned URL generation,
  or lifecycle configuration changes that would provide interactive execution as the role.

### False positive analysis

- Legitimate MLOps creates SageMaker resources with execution roles; new pipelines and users appear as new
  principals on first use. Confirm the role and activity are approved and exclude known automation roles on
  `aws.cloudtrail.user_identity.arn` after validation.

### Response and remediation

- If unauthorized, stop and delete the created resource, and review any actions taken by the passed role.
- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:PassRole` and
  SageMaker create permissions so principals can only pass narrowly scoped, approved execution roles.

"""
references = [
    "https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html",
    "https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateNotebookInstance.html",
    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.execution.sagemaker-update-lifecycle-config/",
]
risk_score = 73
rule_id = "ca8c2751-5507-44f2-b58d-08958200cde9"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS SageMaker",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail-*
| WHERE data_stream.dataset == "aws.cloudtrail"
    AND event.provider == "sagemaker.amazonaws.com"
    AND event.action IN (
      "CreateNotebookInstance",
      "CreateTrainingJob",
      "CreateProcessingJob",
      "CreateAutoMLJob",
      "CreatePipeline"
    )
    AND event.outcome == "success"
    AND aws.cloudtrail.user_identity.type != "AWSService"
| GROK aws.cloudtrail.request_parameters """.*roleArn=(?<Esql.aws_cloudtrail_request_parameters_role_arn>arn:aws[a-z-]*:iam::[0-9]{12}:role/[^,}]+).*"""
| WHERE Esql.aws_cloudtrail_request_parameters_role_arn IS NOT NULL
| EVAL Esql.principal_arn = COALESCE(
    aws.cloudtrail.user_identity.session_context.session_issuer.arn,
    aws.cloudtrail.user_identity.arn
  )
| STATS
    Esql.timestamp_min = MIN(@timestamp),
    Esql.timestamp_max = MAX(@timestamp),
    Esql.ingested_min = MIN(COALESCE(event.ingested, @timestamp)),
    Esql.event_count = COUNT(*),
    Esql.event_action_values = VALUES(event.action),
    Esql.source_ip_values = VALUES(source.ip),
    Esql.user_agent_original_values = VALUES(user_agent.original),
    Esql.user_identity_arn_values = VALUES(aws.cloudtrail.user_identity.arn),
    Esql.cloud_account_id_values = VALUES(cloud.account.id),
    Esql.cloud_region_values = VALUES(cloud.region)
  BY Esql.principal_arn,
     Esql.aws_cloudtrail_request_parameters_role_arn
| WHERE Esql.ingested_min >= NOW() - 10 minutes
| KEEP Esql.*
'''

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

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

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

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

[rule.investigation_fields]
field_names = [
    "Esql.principal_arn",
    "Esql.aws_cloudtrail_request_parameters_role_arn",
    "Esql.user_identity_arn_values",
    "Esql.timestamp_min",
    "Esql.timestamp_max",
    "Esql.event_count",
    "Esql.event_action_values",
    "Esql.source_ip_values",
    "Esql.user_agent_original_values",
    "Esql.cloud_account_id_values",
    "Esql.cloud_region_values",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding,
contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential
access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script
with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's
credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal
indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change.
"""
false_positives = [
    """
    Legitimate setup scripts may reference metadata endpoints or download tooling. Review the decoded script in
    "Esql_priv.aws_cloudtrail_lifecycle_script", verify the principal in "aws.cloudtrail.user_identity.arn", and confirm
    the activity is approved. Note this rule only matches unobfuscated patterns; a clean result does not guarantee a
    benign script.
    """,
]
from = "now-60m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS SageMaker Notebook Lifecycle Configuration With Suspicious Script Content"
note = """## Triage and analysis

### Investigating AWS SageMaker Notebook Lifecycle Configuration With Suspicious Script Content

A SageMaker notebook lifecycle configuration is a shell script that runs as root on the notebook instance at create or start. This rule base64-decodes the OnStart/OnCreate script from the request (surfaced as "Esql_priv.aws_cloudtrail_lifecycle_script") and flags high-signal indicators across several categories: reverse shells ("/dev/tcp/", "/dev/udp/", "bash -i", "nc -e", "ncat", "socat", "mkfifo", "import socket", "pty.spawn", "perl"/"ruby"/"php" socket idioms), IMDS credential access ("169.254.169.254", "/latest/meta-data/", "/latest/api/token"), download-and-execute and decode-and-execute ("| sh", "| bash", "base64 -d"), cryptominers ("xmrig", "minerd", "stratum+"), and persistence ("authorized_keys", "crontab", "/etc/cron"). A match is a strong indicator of an implant attempt.

### Possible investigation steps

- Review the decoded "Esql_priv.aws_cloudtrail_lifecycle_script" field and the full "aws.cloudtrail.request_parameters" to understand what the script does.
- Identify the actor in "aws.cloudtrail.user_identity.arn" and review "source.ip" and "user_agent.original" for an unexpected origin.
- Determine which notebook instances reference this configuration and whether they have started since the change.
- Correlate with adjacent activity by the same principal, such as notebook creation, presigned URL generation, or use of the execution role's credentials outside SageMaker.

### False positive analysis

- Setup scripts can legitimately reference metadata endpoints or download tooling. Confirm the script is expected and exclude known automation roles after validation. This rule only matches unobfuscated indicators, so it can miss obfuscated scripts (use the broad lifecycle-configuration-change rule for full coverage) and can match benign scripts that contain these strings.

### Response and remediation

- If unauthorized, remove the lifecycle configuration, stop affected notebook instances, and rotate the notebook execution role's credentials.
- Review actions taken by the execution role since the change, and restrict "sagemaker:CreateNotebookInstanceLifecycleConfig" and "sagemaker:UpdateNotebookInstanceLifecycleConfig" to trusted administrators.
"""
references = ["https://docs.aws.amazon.com/sagemaker/latest/dg/notebook-lifecycle-config.html"]
risk_score = 73
rule_id = "0471a12b-c740-4a72-91f0-12bf95014d3c"
setup = "This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details."
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS SageMaker",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail-* METADATA _id, _version, _index
| WHERE event.provider == "sagemaker.amazonaws.com"
  AND event.action IN ("CreateNotebookInstanceLifecycleConfig", "UpdateNotebookInstanceLifecycleConfig")
  AND event.outcome == "success"
  AND aws.cloudtrail.user_identity.type != "AWSService"
| GROK aws.cloudtrail.request_parameters "[Cc]ontent=(?<script_b64>[A-Za-z0-9+/=]+)"
| EVAL Esql_priv.aws_cloudtrail_lifecycle_script = FROM_BASE64(script_b64)
| WHERE TO_LOWER(Esql_priv.aws_cloudtrail_lifecycle_script) RLIKE """.*(/dev/tcp/|/dev/udp/|bash -i|sh -i|nc -e|ncat |socat |mkfifo|169\.254\.169\.254|/latest/meta-data/|/latest/api/token|\| ?sh|\| ?bash|base64 -d|import socket|pty\.spawn|perl -e|ruby -rsocket|php -r|xmrig|minerd|stratum\+|authorized_keys|/etc/cron|crontab ).*"""
| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*, Esql_priv.aws_cloudtrail_lifecycle_script
'''


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


[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"



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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "source.ip",
    "cloud.account.id",
    "event.action",
    "Esql_priv.aws_cloudtrail_lifecycle_script",
    "aws.cloudtrail.request_parameters",
]

[metadata]
creation_date = "2026/07/30"
integration = ["endpoint", "sentinel_one_cloud_funnel", "auditd_manager"]
maturity = "production"
updated_date = "2026/08/03"

[rule]
author = ["Elastic"]
description = """
This is a New Terms rule that identifies the first occurrence of setsid or nohup being used to directly
execute a process on a host. Attackers may leverage these tools to execute commands in a new session
and/or to ignore signals.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*",
]
language = "kuery"
license = "Elastic License v2"
name = "Direct Process Execution via Background Utility"
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 Direct Process Execution via Background Utility

This rule flags the first time a Linux host uses setsid, nohup, or disown to launch another process directly, which often means someone is detaching execution from the current terminal or login session. Attackers commonly use nohup to start a backdoor, reverse shell, or cryptominer after SSH access so the process keeps running after they disconnect and ignores normal hangup signals.

### Possible investigation steps

- Review the child process launched by the utility, including its full command line, executable path, working directory, and any redirected output files, to quickly separate routine administration from suspicious payload execution.
- Trace the full ancestry and session context around the launch, such as an interactive shell, SSH login, sudo elevation, script runner, or service account, to determine whether the execution came from an expected workflow or an unusual entry point.
- Assess the user and host history for similar behavior by checking recent logins, shell history, and prior detached launches on the same asset or by the same account, since a first-seen event from a normally quiet user often increases concern.
- Inspect immediate follow-on activity from the spawned process, especially outbound network connections, file downloads, child process creation, or persistence changes, because detached execution is commonly used to keep malicious tooling running after logout.
- Confirm with the system owner whether the command aligns with approved long-running tasks such as maintenance, backups, or software updates, and if not, preserve the binary and related artifacts for deeper analysis and potential containment.

### False positive analysis

- A Linux administrator may legitimately use nohup or setsid to launch an approved maintenance, backup, or data-processing script from an interactive shell so it continues after logout; verify the child command, executable path, initiating user, and execution time match expected operational activity on that host.
- An engineer troubleshooting or restarting a local application may detach the process with setsid during a remote session to avoid terminal interruption; verify the parent shell and account are authorized and that the spawned binary or script and working directory align with the host's normal application files.

### Response and remediation

- Isolate the affected Linux host from the network, terminate the detached child process started with `nohup`, `setsid`, or `disown` and any descendants, and preserve the executable, shell script, redirected output files, and shell history for evidence.
- Remove attacker persistence by deleting malicious cron jobs, systemd service or timer units, `rc.local` or shell profile modifications, unauthorized `authorized_keys` entries, and any dropped binaries or scripts referenced by the detached command.
- Reset compromised access by disabling or rotating credentials for the initiating account and any accounts used afterward, revoking active SSH sessions and tokens, and reviewing `sudoers`, newly added local users, and group memberships for unauthorized changes.
- Rebuild the host from a known-good image or restore from a trusted backup if the detached process ran a backdoor, reverse shell, downloader, or altered system binaries, and verify only approved packages, services, and startup items remain before returning it to production.
- Escalate to incident response immediately if the detached process contacted an external command-and-control address, executed from a writable temporary or home directory as root, spread to other hosts, or evidence shows credential theft or persistence beyond the original system.
- Harden the environment by restricting interactive use of backgrounding utilities where not required, tightening SSH and `sudo` access, enforcing application allowlisting and least privilege, and adding detections for detached launches from temporary directories, user home directories, and unexpected service accounts.

"""
references = [
  "https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en"
]
risk_score = 21
rule_id = "9dc1d59c-fc5f-4a73-8ca6-1473eabdff2a"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

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

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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1036.009"
name = "Break Process Trees"
reference = "https://attack.mitre.org/techniques/T1036/009/"

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

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

[rule.new_terms]
field = "new_terms_fields"
value = ["process.parent.executable", "host.id", "process.command_line"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

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

[rule]
author = ["Elastic"]
description = """
This rule detects the creation of Dracut module files on Linux systems. Dracut is a tool used to generate an initramfs
image that is used to boot the system. Dracut modules are scripts that are executed during the initramfs image
generation process. Attackers may create malicious Dracut modules to execute arbitrary code at boot time, which can be
leveraged to maintain persistence on a Linux system.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
language = "eql"
license = "Elastic License v2"
name = "Dracut Module Creation"
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 Dracut Module Creation

Dracut is a utility for generating initramfs images, crucial for booting Linux systems. It uses modules, which are scripts executed during image creation. Adversaries may exploit this by crafting malicious modules to execute code at boot, ensuring persistence. The detection rule identifies unauthorized module creation by monitoring file paths and excluding known legitimate processes, helping to flag potential threats.

### Possible investigation steps

- Review the file path of the created Dracut module to determine if it matches known legitimate paths or if it appears suspicious, focusing on paths like "/lib/dracut/modules.d/*" and "/usr/lib/dracut/modules.d/*".
- Identify the process that created the Dracut module by examining the process.executable field, and verify if it is listed in the known legitimate processes or if it is an unexpected process.
- Check the file extension of the created module to ensure it is not one of the excluded extensions such as "swp", "swpx", "swx", or "dpkg-remove".
- Investigate the history and behavior of the process that created the module, including its parent process and any associated network activity, to assess if it has been involved in other suspicious activities.
- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest malicious activity.
- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or file path involved in the alert.

### False positive analysis

- Package managers like dpkg, rpm, and yum may trigger false positives when they update or install packages. To handle this, ensure these processes are included in the exclusion list within the detection rule.
- Automated system management tools such as Puppet, Chef, and Ansible can create or modify Dracut modules as part of their configuration management tasks. Add these tools to the exclusion list to prevent false alerts.
- System updates or maintenance scripts that run as part of regular system operations might be flagged. Review these scripts and add their executables to the exclusion list if they are verified as non-threatening.
- Custom scripts or applications that interact with Dracut modules for legitimate purposes should be reviewed and, if deemed safe, added to the exclusion list to avoid unnecessary alerts.
- Temporary files or backup files with extensions like swp or dpkg-remove may be mistakenly flagged. Ensure these extensions are included in the exclusion criteria to reduce false positives.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
- Conduct a thorough review of the Dracut module files located in the specified directories (/lib/dracut/modules.d/*, /usr/lib/dracut/modules.d/*) to identify and remove any unauthorized or suspicious modules.
- Restore the system from a known good backup if malicious Dracut modules are confirmed, ensuring that the backup predates the unauthorized changes.
- Implement additional monitoring on the affected system to detect any further unauthorized Dracut module creation or other suspicious activities.
- Review and tighten access controls and permissions for the directories and processes involved in Dracut module creation to prevent unauthorized modifications.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Update and enhance detection capabilities to include alerts for any future unauthorized Dracut module creation attempts, leveraging the specific indicators identified in this incident."""
risk_score = 21
rule_id = "dc765fb2-0c99-4e57-8c11-dafdf1992b66"
setup = """## Setup
This rule requires data coming in from Elastic Defend.
### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "creation" and process.executable != null and
file.path like~ ("/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*") and not (
  // Too many FPs from Python automation
  process.name like ("python*", "platform-python*") or
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon",
    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond",
    "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor",
    "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd",
    "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install",
    "/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/pacman", "/usr/libexec/packagekitd",
    "./usr/bin/podman", "/usr/lib/dracut/dracut-install", "/usr/bin/dnf5", "/kaniko/executor", "/usr/bin/buildah",
    "/usr/sbin/yum-cron"
  ) or
  process.executable like~ (
    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*",
    "/var/lib/docker/overlay2/*/dockerd"
  ) or
  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
  (process.name == "sed" and file.name : "sed*")
)
'''

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

[[rule.threat.technique]]
id = "T1542"
name = "Pre-OS Boot"
reference = "https://attack.mitre.org/techniques/T1542/"

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

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

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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1542"
name = "Pre-OS Boot"
reference = "https://attack.mitre.org/techniques/T1542/"

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

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

[rule]
author = ["Elastic"]
description = """
Identifies the use of dsquery.exe for domain trust discovery purposes. Adversaries may use this command-line utility to
enumerate trust relationships that may be used for Lateral Movement opportunities in Windows multi-domain forest
environments.
"""
false_positives = [
    "Domain administrators may use this command-line utility for legitimate information gathering purposes.",
]
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 = "Enumerating Domain Trusts via DSQUERY.EXE"
note = """## Triage and analysis

### Investigating Enumerating Domain Trusts via DSQUERY.EXE

Active Directory (AD) domain trusts define relationships between domains within a Windows AD environment. In this setup, a "trusting" domain permits users from a "trusted" domain to access resources. These trust relationships can be configurable as one-way, two-way, transitive, or non-transitive, enabling controlled access and resource sharing across domains.

This rule identifies the usage of the `dsquery.exe` utility to enumerate domain trusts. Attackers can use this information to enable the next actions in a target environment, such as lateral movement.

#### Possible investigation steps

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

### False positive analysis

- Discovery activities are not inherently malicious if they occur in isolation and are done within the user business context (e.g., an administrator in this context). As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed.

### Related rules

- Enumerating Domain Trusts via NLTEST.EXE - 84da2554-e12a-11ec-b896-f661ea17fbcd

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

setup = """## Setup

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

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

### Additional data sources

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

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

references = [
    "https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc732952(v=ws.11)",
    "https://posts.specterops.io/a-guide-to-attacking-domain-trusts-971e52cb2944",
]
risk_score = 21
rule_id = "06a7a03c-c735-47a6-a313-51c354aef6c3"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
    "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 : "dsquery.exe" or ?process.pe.original_file_name: "dsquery.exe") and 
    process.args : "*objectClass=trustedDomain*"
'''


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

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


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

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

[rule]
author = ["Elastic"]
description = """
This rule detects when chmod is used to add the execute permission to a file inside a container. Modifying file
permissions to make a file executable could indicate malicious activity, as an attacker may attempt to run unauthorized
or malicious code inside the container.
"""
from = "now-6m"
index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "File Execution Permission Modification Detected via Defend for Containers"
note = """## Setup

## Triage and analysis

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

### Investigating File Execution Permission Modification Detected via Defend for Containers

Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers.

### Possible investigation steps

- Review the container ID associated with the alert to identify the specific container where the `chmod` command was executed.
- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable.
- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior.
- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions.
- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code.
- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack.

### False positive analysis

- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations.
- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise.
- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities.
- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening.
- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly.

### Response and remediation

- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network.
- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary.
- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities.
- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets.
- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.
- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance.
- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed."""
references = [
    "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
]
risk_score = 21
rule_id = "ec604672-bed9-43e1-8871-cf591c052550"
severity = "low"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
any where event.category in ("file", "process") and event.type in ("change", "creation", "start") and (
  process.name == "chmod" or
  (
    /* account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
    process.args in (
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod"
    ) and
    /* default exclusion list to not FP on default multi-process commands */
    not process.args in (
      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man"
    )
  )
) and process.args in ("4755", "755", "0755", "777", "0777", "444", "+x", "a+x", "700", "0700") and
container.id like "?*" and not process.args == "-x"
'''

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1222.002"
name = "Linux and Mac File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/002/"

[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 = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.001"
name = "Setuid and Setgid"
reference = "https://attack.mitre.org/techniques/T1548/001/"

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

[rule]
description = """
Detects when SetFile is used to modify the file attributes of a file in order to make that file invisible. Malware on
macOS has been observed using this technique in order to hide their payload from users.
"""
id = "2ed9c6bf-025e-4edf-a9ec-1493d0bb4f81"
license = "Elastic License v2"
name = "File Hidden via SetFile"
os_list = ["macos"]
reference = [
    "https://www.virustotal.com/gui/file/d64e2688344c685c4156819156bdb15630d1168314b21c919eee5540b1beb54a",
]
version = "1.0.3"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "SetFile" and 
 process.args == "-a" and 
 process.args == "V"
'''

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 = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"



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

[internal]
min_endpoint_version = "8.11.0"

[metadata]
creation_date = "2025/02/21"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use
these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert
documents. Make sure to review the original documents to aid in the investigation of this alert.
"""
from = "now-61m"
interval = "1h"
language = "esql"
license = "Elastic License v2"
name = "File Transfer Utility Launched from Unusual Parent"
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 File Transfer Utility Launched from Unusual Parent

File transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches.

### Possible investigation steps

- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious.
- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity.
- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context.
- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution.
- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule.

### False positive analysis

- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs.
- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives.
- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts.
- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration.
- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made.

### Response and remediation

- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access.
- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers.
- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer.
- Change credentials and access keys associated with the compromised system to prevent further unauthorized access.
- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems.
- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system.
- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.
"""
risk_score = 47
rule_id = "8eeeda11-dca6-4c3e-910f-7089db412d1c"
setup = """## Setup

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

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-endpoint.events.process-* metadata _id, _index, _version
| mv_expand event.action 
| where
    host.os.type == "linux" and
    event.type == "start" and
    event.action == "exec" and
    process.name in ("scp", "ftp", "sftp", "vsftpd", "sftp-server", "rsync") and (
        (process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or
        (
          process.parent.name like ".*" or
          process.parent.name like "*.elf" or
          process.parent.name like "*.sh" or
          process.parent.name like "*.py" or
          process.parent.name like "*.rb" or
          process.parent.name like "*.pl" or
          process.parent.name like "*.lua*" or
          process.parent.name like "*.php*" or
          process.parent.name like "*.js"
        ) or
        (
          process.parent.executable like "/tmp/*" or
          process.parent.executable like "/var/tmp/*" or
          process.parent.executable like "/dev/shm/*" or
          process.parent.executable like "./*" or
          process.parent.executable like "/run/*" or
          process.parent.executable like "/var/run/*" or
          process.parent.executable like "/boot/*" or
          process.parent.executable like "/sys/*" or
          process.parent.executable like "/lost+found/*" or
          process.parent.executable like "/proc/*" or
          process.parent.executable like "/var/mail/*" or
          process.parent.executable like "/var/www/*" or
          process.parent.executable like "/home/*" or
          process.parent.executable like "/root/*"
        )
    )

| keep
    @timestamp,
    _id,
    _index,
    _version,
    host.os.type,
    event.type,
    event.action,
    process.name,
    process.parent.name,
    process.parent.executable,
    process.executable,
    agent.id,
    host.name,
    data_stream.dataset,
    data_stream.namespace

| stats
    Esql.event_count = count(),
    Esql.agent_id_count_distinct = count_distinct(agent.id),
    Esql.host_name_values = values(host.name),
    Esql.agent_id_values = values(agent.id),
    Esql.data_stream_dataset_values = values(data_stream.dataset),
    Esql.data_stream_namespace_values = values(data_stream.namespace)

  by process.executable, process.parent.executable

| where
    Esql.agent_id_count_distinct == 1 and
    Esql.event_count < 5
| sort Esql.event_count asc

// Extract unique values to ECS fields for alerts exclusion
| eval agent.id = mv_min(Esql.agent_id_values),
       host.name = mv_min(Esql.host_name_values)

| keep agent.id, host.name, process.executable, process.parent.executable, Esql.*
'''

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

[[rule.threat.technique]]
id = "T1048"
name = "Exfiltration Over Alternative Protocol"
reference = "https://attack.mitre.org/techniques/T1048/"

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.new_terms]
field = "new_terms_fields"
value = ["github.hashed_token", "github.user_agent"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2026/02/20"
integration = ["fortinet_fortigate"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a
short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise
used from a VPN session, or initial access via VPN followed by post-compromise behavior.
"""
from = "now-9m"
index = ["logs-fortinet_fortigate.log-*", ".alerts-security.*"]
language = "eql"
license = "Elastic License v2"
name = "FortiGate SSL VPN Login Followed by SIEM Alert by User"
references = [
    "https://attack.mitre.org/tactics/TA0001/",
    "https://www.elastic.co/docs/reference/integrations/fortinet_fortigate",
]
risk_score = 47
rule_id = "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e"
severity = "medium"
tags = [
    "Use Case: Threat Detection",
    "Rule Type: Higher-Order Rule",
    "Tactic: Initial Access",
    "Data Source: Fortinet",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by user.name with maxspan=10m
 [authentication where data_stream.dataset == "fortinet_fortigate.log" and event.action == "login" and event.code in ("0101039426", "0101039427") and
  user.name != "root"]
 [any where event.kind == "signal" and kibana.alert.rule.name != null and data_stream.dataset != "fortinet_fortigate.log" and
  kibana.alert.risk_score > 21 and kibana.alert.rule.rule_id != "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e" and user.name != null]
'''
note = """## Triage and analysis

### Investigating FortiGate SSL VPN Login Followed by SIEM Alert by User

This rule correlates a FortiGate SSL VPN login with a subsequent security alert for the same user name, highlighting possible abuse of VPN access or activity shortly after remote access.

### Possible investigation steps

- Review the FortiGate login event (source IP, user, time) and the SIEM alert(s) that followed for the same user.
- Determine whether the user is expected to use VPN and whether the subsequent alert is related to legitimate work (e.g. admin tools, updates).
- Check for other alerts or logins for the same user in the same time window to assess scope.
- Correlate with authentication logs to identify impossible travel or credential reuse from the VPN session.

### False positive analysis

- Legitimate VPN users triggering detections (e.g. scripted tasks, admin tooling) after login.
- Security scans or automated jobs that run in the context of a VPN-authenticated user.

### Response and remediation

- If abuse or compromise is suspected, disable or reset the user’s VPN access and credentials.
- Investigate the host and process associated with the SIEM alert.
- Escalate to the security or incident response team if the alert indicates malicious activity.
"""


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


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

[metadata]
creation_date = "2026/07/22"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/07/22"

[rule]
author = ["Elastic"]
description = """
Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent,
excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use
curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or
application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated
probing.
"""
false_positives = [
    """
    Administrators or CI jobs using a new workstation, bastion, VPN egress, or nonstandard API client can produce a
    first-seen alert; confirm against change records and expected automation.
    """,
    """
    Workloads or operators that change client libraries after a deploy may introduce a new user agent for an otherwise
    known identity; baseline after validation.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Secret Access via Unusual User Agent"
note = """## Triage and analysis

### Investigating GKE Secret Access via Unusual User Agent

This new-terms rule alerts on secrets `get`/`list` when the (`source.ip`, `client.user.email`, `user_agent.original`)
triple is new in the history window.

### Possible investigation steps

- Review `client.user.email`, `source.ip`, `user_agent.original`, and `gcp.audit.resource_name` for the secret and
  namespace accessed.
- Determine whether the client fingerprint matches an approved admin path, CI runner, or controller upgrade.
- Pivot on the same identity or IP for secret bursts, pod exec, token creation, or RBAC changes.

### False positive analysis

- New admin workstations, VPN egress IPs, or SDK version bumps can first-seen alert; tune after confirming ownership.
- First enablement surfaces legitimate clients until the history window fills.

### Response and remediation

- If malicious, revoke the credential, rotate exposed secrets, isolate the source host or workload, and tighten who
  can read secrets.
"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://attack.mitre.org/techniques/T1552/007/",
]
risk_score = 21
rule_id = "854e89c1-f70c-4180-bc53-65999df9d3c3"
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:gcp.audit and service.name:k8s.io and
event.action:("io.k8s.core.v1.secrets.get" or "io.k8s.core.v1.secrets.list") and
user_agent.original:(* and not (*kubernetes/$Format* or kube-probe* or gke-exec-auth-plugin*)) and
source.ip:(* and not (127.0.0.1 or "::1")) and
client.user.email:(* and not (
  "system:anonymous" or "system:unauthenticated" or "system:addon-manager" or
  "system:serviceaccount:kube-system:namespace-controller"
))
'''

[rule.new_terms]
field = "new_terms_fields"
value = ["source.ip", "client.user.email", "user_agent.original"]

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

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

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

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "gcp.audit.resource_name",
    "data_stream.namespace",
]

[metadata]
creation_date = "2025/06/17"
integration = ["endpoint", "cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
The kubeconfig file is a critical component in Kubernetes environments, containing configuration
details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to,
create, or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or
move laterally within the cluster. This rule detects process discovery executions that involve
kubeconfig files, particularly those executed from common shell environments or world-writeable
directories.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process*",
    "logs-cloud_defend.process*",
]
language = "eql"
license = "Elastic License v2"
name = "Kubeconfig File Discovery"
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 Kubeconfig File Discovery

Kubeconfig files are essential in Kubernetes, storing credentials and configurations for cluster access. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious processes interacting with kubeconfig files, especially from common shell environments or risky directories, flagging potential misuse by excluding benign commands like 'stat' or 'md5sum'.

### Possible investigation steps

- Review the process details to identify the parent process name and executable path, focusing on those originating from common shell environments or risky directories like /tmp, /var/tmp, or /dev/shm.
- Examine the process arguments to determine if they include references to sensitive kubeconfig files such as admin.conf, kubelet.conf, or any files within /etc/kubernetes or ~/.kube directories.
- Check the working directory of the process to see if it aligns with known Kubernetes configuration paths like /etc/kubernetes or ~/.kube, which may indicate an attempt to access or modify kubeconfig files.
- Investigate the user account associated with the process to assess whether it has legitimate access to Kubernetes configurations or if it might be compromised.
- Correlate the event with other recent activities from the same user or IP address to identify any patterns of suspicious behavior or potential lateral movement within the cluster.
- Review any related alerts or logs for the same host or container to gather additional context on the system's state and any other potential indicators of compromise.

### False positive analysis

- Processes like 'stat' and 'md5sum' are excluded from detection as they are commonly used for legitimate file checks. Ensure these exclusions are correctly configured to prevent unnecessary alerts.
- Scripts located in user directories such as '/home/*/.kube' may trigger alerts if they interact with kubeconfig files. Consider adding exceptions for known scripts or users that regularly access these files for legitimate purposes.
- Processes originating from world-writeable directories like '/tmp' or '/var/tmp' can be flagged. Review these alerts to identify routine operations and whitelist specific processes or directories that are part of regular maintenance tasks.
- Alerts triggered by processes with names matching patterns like '*.sh' may include legitimate scripts. Evaluate these scripts and exclude them if they are part of standard operations or administrative tasks.
- Regular administrative tasks involving kubeconfig files in directories like '/etc/kubernetes' may be flagged. Implement exceptions for known administrative processes to reduce false positives while maintaining security oversight.

### Response and remediation

- Immediately isolate the affected system to prevent further unauthorized access to the Kubernetes cluster.
- Revoke any compromised credentials associated with the kubeconfig files and issue new credentials to authorized users.
- Conduct a thorough review of recent access logs and audit trails for the Kubernetes cluster to identify any unauthorized access or lateral movement attempts.
- Restore any modified or deleted kubeconfig files from a secure backup to ensure the integrity of the cluster configuration.
- Implement stricter access controls and permissions for directories containing kubeconfig files, ensuring only authorized personnel have access.
- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected.
- Enhance monitoring and alerting for suspicious activities related to kubeconfig files, leveraging the MITRE ATT&CK framework to identify potential discovery tactics.
"""
references = [
    "https://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/",
    "https://kubenomicon.com/Initial_access/Kubeconfig_file.html",
    ]
risk_score = 21
rule_id = "9a6f5d74-c7e7-4a8b-945e-462c102daee4"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Defend for Containers",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
  (
    process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or
    process.parent.name like (".*", "*.sh")
  )
) and
(
  (
    process.working_directory like ("/etc/kubernetes", "/root/.kube", "/home/*/.kube") and
    process.args in ("kubeconfig", "admin.conf", "super-admin.conf", "kubelet.conf", "controller-manager.conf", "scheduler.conf")
  ) or
  process.args like (
    "/etc/kubernetes/admin.conf",
    "/etc/kubernetes/super-admin.conf",
    "/etc/kubernetes/kubelet.conf",
    "/etc/kubernetes/controller-manager.conf",
    "/etc/kubernetes/scheduler.conf",
    "/home/*/.kube/config",
    "/root/.kube/config",
    "/var/lib/*/kubeconfig"
  )
) and not (
  process.name in ("stat", "md5sum", "dirname") or
  (process.name like "python*" and process.args == "/usr/bin/yq" and process.parent.name == "fish") or
  process.executable in (
    "/usr/bin/file", "/usr/bin/readlink", "/bin/readlink", "/bin/file", "/tmp/newroot/bin/readlink",
    "/tmp/newroot/bin/file", "/usr/local/bin/helm"
  )
)
'''

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

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

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

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

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

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

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

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