Elastic rules: 1z

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

[rule]
author = ["Elastic"]
description = """
Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Kubernetes service account and the source 
autonomous system organization is present but not `Amazon.com, Inc.` EKS workloads that obtain IAM credentials via IAM Roles 
for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly 
external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.
"""
false_positives = [
    """
    Traffic may leave the cluster via corporate proxies, VPNs, or non-AWS NAT providers that populate a non-Amazon ASN
    organization name while still being legitimate. AWS IP ranges are also labeled with other organization strings
    (for example `AMAZON-02`); this rule only excludes `Amazon.com, Inc.` per the match condition—tune with additional
    approved ASNs, CIDRs, or known automation identities if needed.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
interval = "5m"
language = "kuery"
license = "Elastic License v2"
name = "AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN"
note = """## Triage and analysis

### Investigating AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

IRSA maps a Kubernetes service account to an IAM role via OIDC. CloudTrail records `AssumeRoleWithWebIdentity` with
`user.name` like `system:serviceaccount:<namespace>:<sa>`. If geolocation/ASN enrichment shows a non-Amazon source
organization while the identity is still a cluster service account, validate whether the token could have been used
outside the cluster (exfiltrated JWT, misrouted traffic, or operator tooling).

### Possible investigation steps

- Confirm `event.action`, `event.provider`, and `event.outcome` for a successful STS assume.
- Review `user.name`, `aws.cloudtrail.user_identity.arn`, role trust (`aws.cloudtrail.resources`, request parameters for
  `roleArn` / `roleSessionName`), and OIDC `sub` / `aud` if present in CloudTrail.
- Compare `source.ip`, `source.geo.*`, and `source.as.organization.name` to known cluster egress, NAT gateways, and
  approved operator networks.
- In Kubernetes: map the service account to workloads and audit activity around the event time (exec, secret access,
  new deployments).

### False positive analysis

- Egress through third-party security stacks or multi-cloud connectors can change how ASN organization is attributed.
- Expand exclusions for known `source.as.organization.name` values used by your egress path.

### Response and remediation

- If unauthorized: revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce
  service account and role permissions.

### Additional information

- [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
- [EKS IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)
"""
references = [
    "https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html",
    "https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html",
]
risk_score = 73
rule_id = "ae32268b-bfd0-4c35-b002-13461b5830ca"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:aws.cloudtrail and 
 event.provider:sts.amazonaws.com and 
 event.action:AssumeRoleWithWebIdentity and 
 event.outcome:success and user.name:(system\:serviceaccount\:* and not system\:serviceaccount\:kube-system\:aws-load-balancer-controller) and 
 source.as.organization.name:(* and not (Amazon* or AMAZON*))
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "source.geo.city_name",
    "source.geo.country_name",
    "source.as.organization.name",
    "source.as.number",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "aws.cloudtrail.resources.arn",
    "aws.cloudtrail.resources.type",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
]

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

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

[rule]
author = ["Elastic"]
description = """
Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure.
This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub
Actions secrets and is using them from their own infrastructure.
"""
false_positives = [
    """
    AWS credentials legitimately shared between GitHub Actions and another Microsoft/Azure service
    may trigger this rule. Verify whether the non-CI/CD source IP is expected for the workload.
    """,
    """
    GitHub Actions self-hosted runners running on non-Microsoft/Amazon/Google infrastructure will
    appear as suspicious. Add the ASN of your self-hosted runner infrastructure to the is_cicd_infra
    allowlist.
    """,
]
from = "now-7d"
interval = "1h"
language = "esql"
license = "Elastic License v2"
name = "AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure"
note = """## Triage and analysis

### Investigating AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure

This rule detects when an AWS access key appears in CloudTrail from both GitHub Actions runners
(identified by Microsoft ASN or the `github-actions` user agent string) and from infrastructure
outside the expected CI/CD provider ASNs. This is a strong indicator that AWS credentials stored
as GitHub repository or organization secrets have been exfiltrated and are being used by an
attacker from their own infrastructure.

### Possible investigation steps

- Identify which GitHub repository owns the credential by cross-referencing the access key ID with
  your GitHub Actions workflow configurations and AWS IAM user/role assignments.
- Review the suspicious source IPs and ASNs — residential ISPs, VPN providers, or budget hosting
  providers are high-confidence indicators of credential theft.
- Check the actions performed from the suspicious source — `sts:GetCallerIdentity` followed by
  enumeration calls (`ListBuckets`, `DescribeInstances`, `ListUsers`) is a common attacker recon
  pattern after credential theft.
- Review the user agent strings from the suspicious source — `aws-cli` or `boto3` from a non-runner
  IP confirms manual/scripted usage outside CI/CD.
- Check GitHub audit logs for recent workflow changes, new collaborators, or secret access events
  that could indicate how the credential was stolen.
- Determine if the credential is a long-lived IAM user key or a temporary STS session — temporary
  credentials from `AssumeRoleWithWebIdentity` (OIDC) are less likely to be exfiltrated but still
  possible.

### Response and remediation

- Immediately rotate the compromised AWS access key in IAM and update the GitHub repository/org secret.
- Review and revoke any resources created or modified by the suspicious source IP using CloudTrail
  event history filtered by the access key ID.
- Audit the GitHub repository for signs of compromise — check for unauthorized workflow modifications,
  new secrets, or suspicious pull requests that could have exfiltrated the credential.
- Implement OIDC-based authentication (`aws-actions/configure-aws-credentials` with `role-to-assume`)
  instead of long-lived access keys to eliminate the credential theft vector entirely.
- If using OIDC, add IP condition policies to the IAM role trust policy to restrict
  `AssumeRoleWithWebIdentity` to known GitHub runner IP ranges.
- Enable GitHub's secret scanning and push protection to detect accidental credential exposure in
  code or logs.
"""
references = [
    "https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services",
    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html",
]
risk_score = 73
rule_id = "b8c7d6e5-f4a3-4b2c-9d8e-7f6a5b4c3d2e"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS IAM",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

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

| WHERE event.dataset == "aws.cloudtrail"
  AND aws.cloudtrail.user_identity.access_key_id IS NOT NULL
  AND @timestamp >= NOW() - 7 days
  AND source.as.organization.name IS NOT NULL

// AWS API key used from github actions 
| EVAL is_aws_github = user_agent.original LIKE "*aws-credentials-for-github-actions"

// non CI/CD related ASN 
| EVAL is_not_cicd_infra = not source.as.organization.name IN ("Microsoft Corporation", "Amazon.com, Inc.", "Amazon Technologies Inc.", "Google LLC")

| STATS Esql.is_github_aws_key = MAX(CASE(is_aws_github, 1, 0)),
        Esql.has_suspicious_asn = MAX(CASE(is_not_cicd_infra, 1, 0)),
        Esql.last_seen_suspicious_asn = MAX(CASE(is_not_cicd_infra, @timestamp, NULL)),
        Esql.source_ip_values = VALUES(source.address), 
        Esql.source_asn_values = VALUES(source.as.organization.name) BY aws.cloudtrail.user_identity.access_key_id, user.name, cloud.account.id

// AWS API key tied to a GH action used from unusual ASN (non CI/CD infra)
| WHERE Esql.is_github_aws_key == 1 AND  Esql.has_suspicious_asn == 1 

        // avoid alert duplicates within 1h interval
        AND Esql.last_seen_suspicious_asn >= NOW() - 1 hour

| KEEP user.name, aws.cloudtrail.user_identity.access_key_id, Esql.*
'''

[rule.investigation_fields]
field_names = [
    "aws.cloudtrail.user_identity.access_key_id",
    "user.name"
]

[[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 = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

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

[rule]
author = ["Austin Songer", "Elastic"]
description = """
Identifies when an Amazon EventBridge rule is disabled or deleted. EventBridge rules are commonly used to automate
operational workflows and security-relevant routing (for example, forwarding events to Lambda, SNS/SQS, or security
tooling). Disabling or deleting a rule can break critical integrations, suppress detections, and reduce visibility.
Adversaries may intentionally impair EventBridge rules to disrupt monitoring, delay response, or hide follow-on actions.
"""
false_positives = [
    """
    EventBridge rules may be disabled or deleted during legitimate maintenance, refactoring, environment teardown, or
    migration to new event patterns/targets. Verify whether the initiating identity, user agent, and source host are
    expected to administer EventBridge and whether the change aligns with an approved change window or deployment.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EventBridge Rule Disabled or Deleted"
note = """## Triage and analysis

### Investigating AWS EventBridge Rule Disabled or Deleted

EventBridge rules define when events are matched and where they are delivered. Disabling or deleting a rule can interrupt
automation, break alerting pipelines, and create blind spots in detection coverage. In security-focused designs, EventBridge
is frequently used to forward CloudTrail findings, Config/Security Hub events, GuardDuty findings, or application security
signals to downstream responders.

This rule detects successful `DisableRule` or `DeleteRule` actions. Depending on what the affected rule does, this activity
may indicate routine operational work or deliberate impairment of monitoring and response paths.

### Possible investigation steps

**Identify the actor and access path**
- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal performed the change.
- Review `user.name`, `user_agent.original`, and `source.ip` to understand how the action was performed (console vs CLI/SDK/automation) and from where.

**Confirm what changed and what it impacts**
- Use `aws.cloudtrail.request_parameters` to identify the rule name/ARN and whether the action was `DisableRule` or `DeleteRule`.
- Determine what the rule was used for and assess blast radius:
  - Was the rule on a shared event bus or a critical account/region?
  - Was it a centralized “security routing” rule that aggregates events from many accounts?

**Reconstruct timing and sequence**
- Correlate `@timestamp` with surrounding CloudTrail activity for the same actor and the same rule name/ARN.
- Look for companion actions that often occur with impairment attempts:
  - IAM changes that expand permissions (`PutRolePolicy`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`, access key creation).
  - Changes that disable other telemetry or controls (CloudTrail changes, Config recorder stopped, GuardDuty/Security Hub changes).
  - Follow-on actions against sensitive services immediately after the rule was disabled/deleted.

**Validate authorization and change management**
- Check whether the change aligns with a known deployment, infrastructure-as-code run, or approved change ticket. Confirm with the owning team whether the rule was intentionally disabled/deleted and whether there is a documented replacement.

### False positive analysis

- **Planned maintenance and refactoring**
  - Rules may be removed during redesign of event patterns, target migrations, or application decommissioning.
- **Infrastructure-as-code or automation**
  - CI/CD pipelines and IaC (Terraform/CloudFormation/CDK) can disable/delete rules during drift correction or environment rotation.

### Response and remediation

**Restore visibility and business function**
- If the rule is security- or business-critical, restore functionality immediately:
  - Re-enable the rule if it was disabled.
  - If deleted, recreate it from the last known-good baseline (IaC state, templates, or documented configuration).
- Validate delivery by confirming new matching events reach intended targets (for example, downstream Lambda/SNS/SQS) and that monitoring pipelines resume.

**Contain potential compromise**
- If the actor is unexpected or the access path is suspicious:
  - Restrict the principal’s permissions to EventBridge and related services while you investigate (least-privilege containment).
  - Rotate/disable credentials associated with `aws.cloudtrail.user_identity.access_key_id` when applicable.
  - For assumed roles, investigate the originating principal and consider temporarily limiting role assumption via IAM conditions or trust policy changes.

**Scope the incident**
- Pivot in CloudTrail using the same `aws.cloudtrail.user_identity.arn`, access key, and `source.ip` to identify additional EventBridge rule modifications, changes to event buses, permissions, or resource policies that could enable unauthorized routing.
- Determine whether the rule impairment created a monitoring gap and identify the time window of reduced visibility for retrospective review.

**Hardening and prevention**
- Reduce the likelihood of silent impairment:
  - Restrict `events:DisableRule` and `events:DeleteRule` to a small set of administrative roles; use IAM conditions (for example, `aws:PrincipalArn`, `aws:RequestedRegion`, source VPC/IP conditions where appropriate).
  - Consider AWS Organizations SCP guardrails in production accounts to limit destructive EventBridge changes.

### Additional information
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
"""
references = [
    "https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DeleteRule.html",
    "https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DisableRule.html",
]
risk_score = 21
rule_id = "87594192-4539-4bc4-8543-23bc3d5bd2b4"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EventBridge",
    "Tactic: Impact",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: aws.cloudtrail 
    and event.provider: events.amazonaws.com 
    and event.action: (DeleteRule or DisableRule) 
    and event.outcome: success
    and not user_agent.original: (*Terraform* or *Pulumi*)
'''


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

[[rule.threat.technique]]
id = "T1489"
name = "Service Stop"
reference = "https://attack.mitre.org/techniques/T1489/"

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

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

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

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

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.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",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations
or encryption settings. These actions are typically administrative but may also represent
adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious
activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to
disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public
access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic
backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with
related S3 or IAM events.
"""
false_positives = [
    """
    Bucket configurations may be deleted by a system or network administrator. Verify whether the user identity, user agent,
    and/or hostname should be making changes in your environment. Bucket configuration deletions 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 S3 Bucket Configuration Deletion"
note = """## Triage and analysis

### Investigating AWS S3 Bucket Configuration Deletion

Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity.  
Deleting or disabling important configurations may hamper audit trails, hide malicious changes, or reduce the ability for recovery. The detection of these deletes is therefore a potential indicator of defense evasion or impact techniques.

#### Possible investigation steps

- **Identify the Actor and Context**  
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` and `aws.cloudtrail.user_identity.type` to identify who performed the deletion.  
  - Determine whether the actor typically manages bucket configurations, or if this is an unusual identity for this kind of operation.  
  - Check `source.ip`, `user_agent.original`, `cloud.region` for anomalous behaviour (unfamiliar IPs, new tooling or region, off-hours actions).

- **Determine the Affected Bucket and Configuration Type**  
  - Examine `aws.cloudtrail.request_parameters` (and `aws.cloudtrail.resources.arn`) to identify the bucket and the sub-resource that was removed. 
  - Determine whether the bucket is used for critical data (audit logs, backups, data warehouse). If so, the deletion is higher risk.

- **Correlate with Other Activity to Establish Chain of Events**  
  - Search for preceding or concurrent CloudTrail events by the same actor or on the same bucket, e.g.:  
    - Removal of logging or access controls (`PutBucketLogging`, `PutBucketAcl`, `PutBucketPolicy`).  
    - Object-level actions soon after configuration removal (`DeleteObject`, `DeleteObjects`, `PutObject`, cross-account copy) that suggest data removal or exfiltration.  
  - Review for configuration additions or changes immediately prior (e.g., versioning disabled, replication removed) — could form part of a larger attack sequence.  

- **Evaluate Intent and Risk**  
  - Confirm whether the change is aligned with an approved change control process (maintenance, re-architecting, cost-optimization).  
  - If no documented justification, or if it affects buckets with sensitive or compliance-related data, treat it as potential malicious behavior.  
  - Prioritize buckets where configuration deletion significantly reduces visibility or recovery capability.

### False positive analysis

- **Scheduled Maintenance or Re-architecture**:  
  - Valid operations may include migrating buckets, retiring services, or reorganizing storage; verify through change logs.  
- **Automation/DevOps Activity**:  
  - Infrastructure-as-Code pipelines or lifecycle clean-up tasks may remove configurations; validate known automation scopes and service-principals.  
- **Test/Development Buckets**:  
  - Non-production environments may frequently change bucket configurations; document and consider whitelisting accordingly.

### Response and remediation

**Containment & Immediate Actions**  
- Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`. 
- Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots.

**Investigation & Scope Assessment**  
- Using CloudTrail and S3 Data Events, check object‐level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts.  
- Check whether other buckets in the account suffered similar configuration changes – potentially part of a wider campaign.

**Recovery & Hardening**  
- Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active).  
- Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes.  
- Apply least‐privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval.

**Lessons Learned & Prevention**  
- Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly.

"""
references = [
    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketPolicy.html",
    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketReplication.html",
    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketCors.html",
    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketEncryption.html",
    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html",
]
risk_score = 21
rule_id = "227dc608-e558-43d9-b521-150772250bae"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS S3",
    "Tactic: Defense Evasion",
    "Tactic: Impact",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:aws.cloudtrail and 
    event.provider:s3.amazonaws.com and
    event.action:(DeleteBucketPolicy or 
                    DeleteBucketReplication or 
                    DeleteBucketCors or 
                    DeleteBucketEncryption or 
                    DeleteBucketLifecycle) and 
    event.outcome:success
    and not user_agent.original: (*Terraform* or *Pulumi*)
'''


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

[[rule.threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"

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

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

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

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

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

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

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

[metadata]
creation_date = "2026/03/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/04/06"

[rule]
author = ["Elastic"]
description = """
This rule detects when chroot is executed inside a container. Chroot is a Linux utility that allows a user to
run a command in a different directory. This can be used to escape a container and gain access to the host system.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Chroot Execution Detected via Defend for Containers"
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 Chroot Execution Detected via Defend for Containers

This alert flags a process inside a Linux container that launches chroot, which can let code run against an alternate root filesystem and is often used to break container isolation. An attacker who has landed in a privileged or misconfigured container may chroot into a mounted host path such as /host or /proc/1/root, then spawn a shell to access host files, binaries, and credentials.

### Possible investigation steps

- Review the full execution chain and command arguments to identify the target root path and spawned program, prioritizing cases that reference host-linked locations such as /host, /proc/1/root, /mnt, or other node filesystem mounts.
- Validate the container’s security posture at the time of execution, including whether it ran as root, used privileged mode, exposed host namespaces, or mounted sensitive host paths that would make a chroot attempt capable of escaping isolation.
- Examine nearby process, file, and network activity from the same container or pod for follow-on actions against the host, such as shell launches, access to container runtime sockets, kubelet paths, SSH material, or other credential-bearing files.
- Compare the behavior with the container image’s normal purpose, entrypoint, recent image or deployment changes, and any approved troubleshooting activity to determine whether the chroot was expected administration or anomalous runtime behavior.
- If the activity is unexplained or hostile, isolate or terminate the workload, collect the container filesystem and runtime metadata for forensics, and assess the underlying node for compromise before rotating any potentially exposed secrets.

### False positive analysis

- Some build, initialization, or package-maintenance containers legitimately call chroot to install files into a staged root filesystem; verify the image or startup script is intended to prepare an alternate root and that the target path is an expected internal mount rather than a host-linked location.
- An approved troubleshooting or recovery session in a privileged container may use chroot to inspect or repair an intentionally mounted filesystem; verify the user and timing align with authorized maintenance and confirm the command did not pivot to paths such as /proc/1/root, /host, or other node filesystems.

### Response and remediation

- Immediately isolate the affected pod or container, cordon the worker node it ran on, stop the malicious workload, and preserve the container filesystem, mounted volumes, and node logs for forensic review.
- Hunt for and remove persistence related to the compromise, including rogue CronJobs or DaemonSets, modified entrypoint or startup scripts, unauthorized SSH authorized_keys, new sudoers entries, and unexpected systemd services on the node.
- If the chroot targeted host-linked paths such as /proc/1/root or /host, or you find access to the container runtime socket, kubelet credentials, or new privileged workloads, escalate immediately to incident response and treat the node as potentially fully compromised.
- Restore the environment from a known-good state by reimaging or replacing affected nodes, redeploying the workload from a trusted image digest, and rotating any credentials, service account tokens, kubeconfigs, or cloud keys exposed to the container or host.
- Harden the environment to prevent recurrence by removing privileged mode and hostPath mounts, enforcing non-root containers, dropping unnecessary Linux capabilities, applying seccomp or AppArmor or SELinux profiles, and restricting access to host namespaces and runtime sockets.
"""
references = [
    "https://some-natalie.dev/container-escapes-chroot/",
]
risk_score = 21
rule_id = "47661529-15ed-4848-93da-9fbded7a3a0e"
severity = "low"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  process.name == "chroot" 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 (
      "chroot", "/bin/chroot", "/usr/bin/chroot", "/usr/local/bin/chroot"
    ) and
    /* default exclusion list to not FP on default multi-process commands */
    not process.args in (
      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
    )
  )
) and container.id like "?*"
'''

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

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

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

[metadata]
creation_date = "2026/02/12"
maturity = "production"
min_stack_comments = "ES|QL COMPLETION and INLINE STATS require Elastic Stack 9.3.0 or later."
min_stack_version = "9.3.0"
updated_date = "2026/08/06"

[rule]
author = ["Elastic"]
description = """
This rule correlates alerts from multiple integrations and event categories that involve different user.name values which
may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers
(e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Correlated Alerts on Similar User Identities"
references = [
    "https://www.elastic.co/docs/reference/query-languages/esql/esql-commands#esql-completion",
    "https://www.elastic.co/docs/explore-analyze/elastic-inference/eis-supported-models",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 73
rule_id = "1bb329a5-2168-4da5-b7b9-d42a51deb6dd"
setup = """## Setup

### LLM Configuration

This rule uses the ES|QL COMPLETION command with Elastic Inference Service Claude Sonnet 4.6
(`.anthropic-claude-4.6-sonnet-completion`), which is available out-of-the-box in Elastic Cloud deployments
with an appropriate subscription. See [EIS supported models](https://www.elastic.co/docs/explore-analyze/elastic-inference/eis-supported-models).

To use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector
following the [LLM connector documentation](https://www.elastic.co/docs/explore-analyze/ai-features/llm-guides/llm-connectors)
and update the `inference_id` parameter in the query to reference your configured connector.
"""
severity = "high"
tags = [
    "Domain: Identity",
    "Domain: LLM",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Resources: LLM",
    "Rule Type: Higher-Order Rule",
]
timestamp_override = "event.ingested"
type = "esql"

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

// truncate timestamp to 5-minute window
| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)

// high severity alerts excluding system standard user.ids
| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == "open" and 
        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")

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

// filter for alerts from different integrations with unique categories
| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2

// build context for LLM analysis
| eval users_list = MV_CONCAT(Esql.user_name_values, ",")

// LLM analysis
| eval instructions = "Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identity or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict=<verdict> confidence=<score between 0.0 and 1.0> summary=<short reason max 500 words> without any other response statements on a single line."
| eval prompt = CONCAT("User identities extracted from different alerts: ", users_list, instructions)
| COMPLETION triage_result = prompt WITH { "inference_id": ".anthropic-claude-4.6-sonnet-completion"}

// parse LLM response
| DISSECT triage_result """verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}"""

// filter for similar user values
| where TO_LOWER(Esql.verdict) == "true"
| keep 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, analysts should validate findings against their environment and identity architecture.

### Investigating Correlated Alerts on Similar User Identities

This rule identifies alerts from multiple integrations and event categories involving different `user.name` values that may represent the same real-world identity.
An LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems.

### Possible investigation steps

- Review the correlated `user.name` values and validate whether they represent naming variations, aliases, or identity mappings.
- Examine the LLM output fields (`verdict`, `confidence`, `summary`) as decision support, not ground truth.
- Analyze the diversity of alert sources, event categories, and detection rules involved.
- Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence.
- Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts.
- Validate identities against directory services, identity providers, and federation mappings.

### False positive analysis

- Identity format variations across systems (e.g., `first.last`, `flast`, `user@domain`).
- Federated identity mappings between on-prem, cloud, and SaaS platforms.
- Service, automation, and CI/CD accounts with similar naming conventions.
- Separate admin and standard user accounts for the same individual.
- Shared credentials or naming templates in development and test environments.

### Response and remediation

- Temporarily disable or suspend correlated accounts if compromise is suspected.
- Revoke active sessions, tokens, and credentials.
- Investigate access scope, privileges, and lateral movement paths.
- Perform endpoint and identity forensics to identify persistence mechanisms.
- Remediate IAM misconfigurations and federation issues.
- Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse."""

[rule]
description = """
Detects the abnormal spawning of curl or nscurl by a shell script within an applications directory structure. Threat
actors have executed and abused shell scripts within a benign applications directory structures in order to evade
detection and download a second stage payload. This specific activity has been observed when the shell script creates a
new shell child process ,via a fork, which is then used to execute curl or nscurl. The use of shell scripts within a
macOS application to execute curl is highly abnormal espcially in this specific manner.
"""
id = "fce1ba4a-596c-445c-938d-3ffd73152bf2"
license = "Elastic License v2"
name = "Curl Execution via Application Shell Script"
os_list = ["macos"]
reference = [
    "https://www.sentinelone.com/blog/from-the-front-lines-new-macos-covid-malware-masquerades-as-apple-wears-face-of-apt/",
    "https://github.com/D00MFist/Mystikal/blob/main/Modules/DMG.py",
]
version = "1.0.11"

query = '''
sequence by process.parent.entity_id with maxspan=30s
[process where event.type == "start" and event.action == "fork" and process.name like~ ("bash", "sh", "zsh", "tclsh*") and
  process.args_count == 2 and process.args like~ ("/Applications/*", "/Volumes/*", "/Users/*/Applications/*") and 
  process.parent.name like~ ("bash", "sh", "zsh", "tclsh*")]
[process where event.type == "start" and event.action == "exec" and process.name in ("curl", "nscurl") and
  process.args in ("-o", "--output", "-O", "--remote-name") and
  not process.args like~
              ("https://github.com/*",
               "http://localhost:*",
               "https://localhost:*",
               "https://download.elastic.co/cloud/elastic-cloud-enterprise.sh") and
  not process.args == "-X" and
  not process.args == "-H" and
  not process.args == "-d"]
'''

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

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

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


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

[internal]
min_endpoint_version = "8.7.0"

[rule]
description = """
Identifies DNS queries to commonly abused Top Level Domains by a process running from a mounted virtual disk (.iso,
.vhd) or that was recently dropped and not signed by a trusted code signature or commonly abused Microsoft signed
binaries.
"""
id = "d37ffe39-8e58-460f-938d-3bafbae60711"
license = "Elastic License v2"
name = "DNS Query to Suspicious Top Level Domain"
os_list = ["windows"]
version = "1.0.43"

query = '''
sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  (
   (process.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk") and
    not process.executable : "C:\\*") or

   ((process.Ext.relative_file_creation_time <= 300 or process.Ext.relative_file_name_modify_time <= 300) and
     not process.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*") and
     not process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe")) or

   process.executable :
	        ("?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*",
	         "?:\\Users\\*\\AppData\\Local\\Temp\\7z*",
	         "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*") or

   process.name : ("powershell.exe", "wscript.exe", "cscript.exe", "rundll32.exe", "msiexec.exe", "mshta.exe") or

   (process.name : "python*" or process.code_signature.subject_name : "Python Software Foundation") or

   (process.Ext.relative_file_creation_time <= 500 and process.pe.original_file_name : ("node.exe", "AutoIt*.exe"))
   ) and

   not (process.name : "rundll32.exe" and
        process.args : ("?:\\windows\\system32\\davclnt.dll,DavSetCookie",
                        "?:\\Windows\\SysWOW64\\davclnt.dll,DavSetCookie",
                        "cryptext.dll,CryptExtOpenCER",
                        "cryptext.dll,CryptExtAddCER",
                        "?:\\Windows\\system32\\cryptext.dll,CryptExt*",
                        "shell32.dll,Control_RunDLL",
                        "?:\\Program Files\\*",
                        "?:\\Program Files (x86)\\*",
                        "?:\\PROGRA~?\\MICROS~?\\*",
                        "?:\\WINDOWS\\Sys*\\shell32.dll,#44",
                        "?:\\PROGRA~?\\MICROS~2\\Office*\\MLCFG32.CPL,@0")) and
   not process.parent.executable :
                    ("C:\\Program Files\\Windows Defender Advanced Threat Protection\\SenseIR.exe",
                     "C:\\Program Files\\Microsoft Visual Studio\\*.exe",
                     "C:\\Program Files\\Nitro\\PDF Pro\\??\\NitroPDF.exe") and
   not process.hash.sha256 :
                   ("19a9ed41a69c74f130f53572aa1b07b1fa35d93a408dcf9d3f16f0fd72dd1e69",
                    "005f63a30438bf91d23790bfd6ab43d298e73c48024d7f48aec322b798035130",
                    "39508f47cd1220a313928d983139a3a27afdb676082c58ac2db71dfcceab4b00",
                    "b0136acc093fe905257da3fc0591de3f6209b24f6b943ff73b9939ec5f80099d",
                    "454dc1f557995b4c1570d74110673b72172640eb3a5a3f5da304faa4a081650f",
                    "bd8c182176f4e177c62240e8f5941446df01c21c57ad6f304e4e0af21cba52de",
                    "6422aea329efdcc7385541801ee271f9104382cc5e9b8eafb0deae25886bd3ff",
                    "93b47471ca51a22f08d489d6a17764dbfb492989f7f6add5f09243719c6bb73b",
                    "d0557e9aca48065910225cd5776de67c0d887ae1d7346204a01bc85d870d7c1d",
                    "454dc1f557995b4c1570d74110673b72172640eb3a5a3f5da304faa4a081650f",
                    "bd8c182176f4e177c62240e8f5941446df01c21c57ad6f304e4e0af21cba52de",
                    "e1684e5c9589d2947df49a0c8382a06040a5443d9ba32d06374049fcb88643b4",
                    "7af4edd697f6881671d661d343dfaef243c6b630bd7d0816ddec9e049931e841",
                    "3281760911711b9ccb262b217e8cbb625c8c5f2d585c3a7a04a2ba2a4f4e918b",
                    "2167901996b1deff1f165c2d1575820a1c20840b19f8d98b4fd84b7a996cef42",
                    "b8aabf174578bfc91c9ab46fab0c75c12efd66da00402a41259acef53e0ebefd",
                    "bcfa1343b6bd0176785ecacfeda0c2eefd2c391d0f7c21a9c465fdb9f5143f63",
                    "f5e8d65a3ad7ded72c27addfd2d2ef98f8e2c9255adec4a216353eee0e8ec482",
                    "9421439e100d116173d28edbf180a04d3c677bca4e88c3ef46911fbd12a63426",
                    "8ca10f59fe3c6c1b44331f7a7378f717481d58fbad53d7ea25894469ef563e0c",
                    "a68a4b4101bb097f886548b13991db8d71f9cfb55801c403ad7b57844bbc288f",
                    "b25fc6258895702c5fd0297cba15b1bd733b5443e7f6f43137877198f27b1322",
                    "4b0f6852329ae6118124956e95c091fbf5c7592b8dd717c9163a07b72074c65d",
                    "143d4b9e429bb10860298c16feab3bf0f132e26547ee28eecd1f7de9f5cf926c",
                    "3b49c90ff2571e045cb5fd985b7397b37d7bb83e58729a0b4e44b0e5543135df",
                    "ca2a11a3fbebc36ff3a3ec7428263f07a3aeb09db2215f882a66a7c1c61d9e6f",
                    "6b1880dce6f28d4a79f4fa3be148ee55793e679485c3db156d26abd6d277b44a",
                    "d3a1446ff14a77a4beb61f4db93afec24a6daa8fad566ddbddbc74943169b5b1",
                    "f79605915297ceac917d58e629bbfb7c50cac8d7c563bf207c5c84abd2956008",
                    "f0822cd0265b889d65c3bd6af51b5ebd9f13b7e067b97b62d923d3693f9b22ca",
                    "9e039448344e4f70122a9cb2416cf282d26033ec8a81b3084c8e7076e3242d8b") and
   not process.executable : ("?:\\Program Files\\Makeblock\\xTool Creative Space\\xTool Creative Space.exe",
                             "?:\\Program Files (x86)\\Popcorn Time\\PopcornTimeDesktop.exe",
                             "?:\\Program Files\\ArcGIS\\DataStore\\framework\\runtime\\pgsql\\bin\\postgres.exe",
                             "?:\\Program Files\\OpenVPN Connect\\OpenVPNConnect.exe",
                             "?:\\Program Files\\Softdeluxe\\Free Download Manager\\fdm.exe",
                             "C:\\Program Files\\ArcGIS\\Pro\\bin\\Python\\envs\\arcgispro-py?\\python.exe",
                             "C:\\Program Files (x86)\\Wondershare\\MobileTrans\\MobileTrans.exe",
                             "C:\\Program Files (x86)\\Wondershare\\drfone\\DrFoneToolKit.exe",
                             "C:\\Program Files\\RFMS\\Measure\\msr6.exe") and
   not (process.name : "powershell.exe" and process.parent.executable : "?:\\Program Files\\Sophos\\Endpoint Defense\\SEDService.exe") and
   not (process.name : "powershell.exe" and process.args : "C:\\ProgramData\\NinjaRMMAgent\\uscripting\\customscript_gen_*.ps1")]
 [dns where
  dns.question.name : ("*.top", "*.buzz", "*.xyz", "*.rest", "*.ml", "*.cf", "*.gq", "*.ga", "*.onion",
                       "*.monster", "*.cyou", "*.quest", "*.cc", "*.bar", "*.cfd", "*.click", "*.cam",
                       "*.surf", "*.tk", "*.shop", "*.club", "*.icu", "*.pw", "*.ws",
                      "*.online", "*.fun", "*.life", "*.boats", "*.store",
                       "*.hair", "*.skin", "*.motorcycles", "*.christmas", "*.lol", "*.makeup",
                       "*.mom", "*.rest", "*.monster", "*.bond", "*.beauty", "*.biz", "*.live", "*.zone", ".cloud") and
  not (process.name : "powershell.exe" and dns.question.name : "*.engage.xyz") and
  not dns.question.name like ("wfdownloader.xyz", "licenseauth.online", "nexaquest.store", "api.ratna.pw", "bo3.ezz.lol", "acesso.ws", "*.thomsonreuters.biz", "bestpractice.online", "*.ad-alliance.biz",
                              "www.frontierpestcontrol.biz", "krauseconstruction.click", "whois.nic.biz", "*.manatron.biz",
                              "ppmc02p.salzburg.ssk.cc", "*.envlab.cc",
                              "mastodon.online", "api.hyperliquid.xyz", "publica.cnpj.ws",
                              "aristotle.harmonic.fun", "*.lighter.xyz")]
'''

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

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

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



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

[internal]
min_endpoint_version = "8.4.0"

[rule]
description = """
This rule detects DNS requests initiated by recently created 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 = "0c393c67-6eb3-4936-ab44-b807ef8af0f7"
license = "Elastic License v2"
name = "DNS Request by Recently Created Executable"
os_list = ["linux"]
version = "1.0.4"

query = '''
sequence by process.parent.entity_id with maxspan=10s
  [file where event.type == "creation" 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
  file.path like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/root/*", "/var/www/*") and
  not (
    file.path like (
      "/home/*/.claude/downloads/claude-*-linux-x64", "/home/*/.aimee-code/bin/aimee-code"
    ) or
    (
      process.executable like "/home/*/go/pkg/mod/golang.org/*/pkg/tool/linux_amd64/link" and
      file.path like "/tmp/go-*/exe/vuln-stats"
    ) or
    process.executable like (
      "/home/*/.local/share/claude/versions/*", "/home/*/.vscode-server/cli/servers/Stable-*/server/node",
      "/tmp/*/.vscode-server/.vscode-server/cli/servers/Stable-*/server/node", "/home/*/.vscode-server/bin/*/node",
      "*/.opencode/bin/opencode*", "*/.claude/remote/ccd-cli/*", "*/.claude/downloads/claude-*", "*/.aimee-code/bin/*"
    )
  )] as event0
  [dns where event.action == "lookup_result" and startswith~(process.executable, event0.file.path) and
  dns.question.name != "localhost"]
'''

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 = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[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 attempts to patch Microsoft Event Tracing for Windows via memory modification. This may indicate an attempt
to disrupt detection of malicious activity by the Event Tracing facility for Windows.
"""
id = "3046168a-91cb-4ecd-a061-b75b1df1c107"
license = "Elastic License v2"
name = "Evasion via Event Tracing for Windows Patching"
os_list = ["windows"]
reference = [
    "https://blog.xpnsec.com/hiding-your-dotnet-etw/",
    "https://www.elastic.co/security-labs/doubling-down-etw-callstacks",
]
version = "1.0.16"

query = '''
api where process.Ext.api.name :  "WriteProcessMemory*" and
 process.Ext.api.summary : ("*ntdll.dll!Etw*", "*ntdll.dll!NtTrace*") and
 process.executable != null and
 not process.executable : ("?:\\Windows\\System32\\lsass.exe",
                           "\\Device\\HarddiskVolume*\\Windows\\System32\\lsass.exe",
                           "?:\\Windows\\System32\\csrss.exe") and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 != "7d678faf97ffbd27c01161ec6aaf9854226bef44ef70542e973aae004a85ea16" and
 not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true and
                  $entry.subject_name in ("Microsoft Windows Hardware Compatibility Publisher",
                                          "Microsoft Windows Software Compatibility Publisher",
                                          "SentinelOne Inc."))
'''

min_endpoint_version = "8.10.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 = "8.10.0"

[rule]
description = "Identifies suspicious execution via interactive logon using the seclogon service."
id = "dd9f4c9b-657a-463e-9d5e-70848c7aa27e"
license = "Elastic License v2"
name = "Execution via Interactive Secondary Logon"
os_list = ["windows"]
reference = [
    "https://splintercod3.blogspot.com/p/the-hidden-side-of-seclogon-part-2.html",
    "https://github.com/CarlosG13/SecLogon-RPC",
]
version = "1.0.3"

query = '''
sequence with maxspan=1m
 [authentication where event.action == "log_on" and process.Ext.session_info.logon_type == "Interactive" and
   process.executable : "?:\\Windows\\System32\\svchost.exe" and user.effective.id != "S-1-0-0"] by Target.process.Ext.authentication_id, user.effective.id, process.entity_id
 [process where event.action == "start" and
  process.parent.thread.Ext.call_stack_summary like "ntdll.dll|*kernelbase.dll|kernel32.dll|seclogon.dll|rpcrt4.dll|ntdll.dll|kernel32.dll|ntdll.dll" and
  not process.parent.executable : ("C:\\Windows\\System32\\runas.exe",
                                   "C:\\Program Files (x86)\\EGS\\EGS_WeighingScaleService\\runasspc.exe",
                                   "C:\\Program Files (x86)\\Historia Clinica Agente\\PsExec.exe") and
  not (process.name == "rundll32.exe" and process.args : "C:\\WINDOWS\\System32\\SHELL32.dll,RunAsNewUser_RunDLL"
       and process.parent.executable : ("C:\\Windows\\explorer.exe", "C:\\Windows\\System32\\RuntimeBroker.exe")) and
  not (process.code_signature.trusted == true and
       process.code_signature.subject_name in ("Ghisler Software GmbH", "ISL Online Ltd.", "TeamViewer GmbH", "TeamViewer Germany GmbH",
                                               "CAS Software AG", "N-ABLE TECHNOLOGIES LTD", "Bomgar Corporation", "Splashtop Inc.",
                                               "GoTo Technologies USA, LLC", "BeyondTrust Corporation", "AnyDesk Software GmbH",
                                               "SCHNEIDER ELECTRIC USA, INC.", "PURSLANE")) and
  not (process.parent.code_signature.subject_name == "Oliver Hessing" and process.parent.code_signature.trusted == true)
  ] by process.Ext.authentication_id, user.id, process.parent.Ext.real.entity_id
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 1
tree = true

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1134"
name = "Access Token Manipulation"
reference = "https://attack.mitre.org/techniques/T1134/"
[[threat.technique.subtechnique]]
id = "T1134.004"
name = "Parent PID Spoofing"
reference = "https://attack.mitre.org/techniques/T1134/004/"



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

[internal]
min_endpoint_version = "8.16.0"

[rule]
description = """
Identifies default indicator of compromise related to the Loki Electron backdoor. Loki is a stage-1 command and control
(C2) framework written in Node.js, built to script-jack vulnerable Electron apps.
"""
id = "56958f85-4a0e-40fb-8e1c-dd6a42db1338"
license = "Elastic License v2"
name = "Execution via Loki Command and Control"
os_list = ["windows"]
reference = ["https://lolbas-project.github.io/lolbas/OtherMSBinaries/Teams/", "https://github.com/boku7/Loki/"]
version = "1.0.4"

query = '''
process where event.action == "start" and
(
 (process.parent.name : ("cursor.exe", "code.exe", "GithubDesktop.exe", "Postman.exe", "Obsidian.exe", "Joplin.exe", "Discord.exe", "Windsurf.exe", "Figma.exe", "RingCentral.exe", "azuredatastudio.exe", "atom.exe", "Bruno.exe", "KeeWeb.exe", "Wordpress.com.exe", "Arduino IDE.exe", "QRLWallet.exe", "DevHub.exe", "Asana.exe", "insomnia-*.exe", "Ferdium.exe", "Franz.exe", "TIDAL.exe", "1Password.exe", "Signal.exe", "slack.exe", "Notion.exe") and
  process.args : ("--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\super-app",
                 "--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\cool-tool",
                 "--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\ai-wizard",
                 "--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\dev-helper")) or 
                 
  descendant of [process where event.action == "start" and process.parent.name : ("cursor.exe", "code.exe", "GithubDesktop.exe", "Postman.exe", "Obsidian.exe", "Joplin.exe", "Discord.exe", "Windsurf.exe", "Figma.exe", "RingCentral.exe", "azuredatastudio.exe", "atom.exe", "Bruno.exe", "KeeWeb.exe", "Wordpress.com.exe", "Arduino IDE.exe", "QRLWallet.exe", "DevHub.exe", "Asana.exe", "insomnia-*.exe", "Ferdium.exe", "Franz.exe", "TIDAL.exe", "1Password.exe", "Signal.exe", "slack.exe", "Notion.exe") and
  process.args : ("--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\super-app",
                 "--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\cool-tool",
                 "--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\ai-wizard",
                 "--user-data-dir=C:\\Users\\*\\AppData\\Roaming\\dev-helper")]
 )
'''

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Malware or other files dropped or created on a system by an adversary may leave traces behind as to what was done within
a network and how. Adversaries may remove these files over the course of an intrusion to keep their footprint low or
remove them at the end as part of the post-intrusion cleanup process.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-auditd_manager.auditd-*",
]
language = "eql"
license = "Elastic License v2"
name = "File Deletion via Shred"
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 Deletion via Shred

The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts.

### Possible investigation steps

- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero".
- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user.
- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious.
- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications.
- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise.
- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security.

### False positive analysis

- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts.
- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts.
- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management.
- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration.
- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion.
- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary.
- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source.
- 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 on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools.
- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users."""
risk_score = 47
rule_id = "a1329140-8de3-4445-9f87-908fb6d824f4"
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 = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Auditd Manager",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "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 == "shred" and (
// Any short-flag cluster containing at least one of u/z, and containing no extra "-" after the first one
process.args regex~ "-[^-]*[uz][^-]*" or
process.args in ("--remove", "--zero")
) and
not process.parent.name == "logrotate"
'''

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

[[rule.threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
This rule detects the use of the built-in Linux DebugFS utility from inside a container. DebugFS is a special
file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside
a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access
sensitive host level files which could be used for further privilege escalation and container escapes to the host
machine.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "File System Debugger Launched Inside a Container"
references = [
    "https://cyberark.wistia.com/medias/ygbzkzx93q?wvideo=ygbzkzx93q",
    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged",
]
risk_score = 47
rule_id = "35c029c3-090e-4a25-b613-0b8099970fc1"
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 = "medium"
tags = [
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend",
    "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.entry_leader.entry_meta.type == "container" and process.name == "debugfs" and
process.command_line like~ "/dev/sd*" and not process.args == "-R"
'''
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 System Debugger Launched Inside a Container

DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in containers, flagging potential misuse.

### Possible investigation steps

- Review the alert details to confirm the process name is "debugfs" and check the specific arguments used, particularly looking for "/dev/sd*" to identify potential access to host file systems.
- Verify the container's security context to ensure it is indeed privileged, as this increases the risk of host-level access.
- Investigate the origin of the container image and deployment configuration to determine if the use of a privileged container was intentional or necessary.
- Check the user or service account that initiated the process to assess if it aligns with expected behavior or if it indicates potential unauthorized access.
- Examine recent logs and events from the container and host to identify any unusual activities or patterns that coincide with the alert.
- Assess the potential impact by identifying any sensitive files or directories that may have been accessed or modified by the debugfs process.

### False positive analysis

- Routine maintenance tasks using DebugFS in privileged containers can trigger alerts. To manage this, identify and document regular maintenance processes and create exceptions for these specific processes.
- Automated scripts or tools that utilize DebugFS for legitimate monitoring or debugging purposes may cause false positives. Review these scripts and whitelist them by excluding their specific process arguments or execution contexts.
- Development and testing environments often run privileged containers with DebugFS for debugging purposes. Establish a separate set of rules or exceptions for these environments to prevent unnecessary alerts.
- Backup or recovery operations that involve direct disk access might use DebugFS. Ensure these operations are well-documented and create exceptions based on their unique process signatures or execution schedules.

### Response and remediation

- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or removing its network access.
- Conduct a thorough review of the container's security context and capabilities to ensure it does not have unnecessary privileges. Adjust the container's configuration to remove privileged access if not required.
- Analyze the container's logs and process history to identify any unauthorized access or actions taken by the DebugFS utility. This will help determine the extent of the potential breach.
- If unauthorized access to host files is confirmed, perform a security assessment of the host system to identify any changes or breaches. This may include checking for new user accounts, modified files, or unexpected network connections.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. Provide them with all relevant logs and findings.
- Implement additional monitoring and alerting for similar activities across other containers and hosts to detect any recurrence of this threat.
- Review and update container deployment policies to enforce the principle of least privilege, ensuring containers only have the necessary permissions to perform their intended functions."""

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

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

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

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

[[rule.threat.technique]]
id = "T1006"
name = "Direct Volume Access"
reference = "https://attack.mitre.org/techniques/T1006/"

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