Elastic rules: 0q

[metadata]
creation_date = "2025/11/23"
integration = ["aws", "endpoint"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on EC2 instances via AWS Systems Manager
(SSM) `SendCommand` API. This detection correlates AWS CloudTrail `SendCommand` events with endpoint process execution
by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals
the actual commands executed on EC2 instances. Adversaries may abuse SSM to execute malicious commands remotely without
requiring SSH or RDP access, using legitimate system utilities for data exfiltration, establishing reverse shells, or
lateral movement.
"""
false_positives = [
    """
    Legitimate administrative tasks using SSM to run system utilities may trigger this rule. Review the command context,
    user identity, and timing to determine if the activity is authorized.
    """,
    """
    Automated configuration management or monitoring scripts that use LOLBins via SSM for legitimate purposes. Consider
    excluding known automation accounts or specific command patterns.
    """,
]
from = "now-9m"
interval = "8m"
language = "esql"
license = "Elastic License v2"
name = "AWS EC2 LOLBin Execution via SSM SendCommand"
note = """## Triage and analysis

### Investigating AWS EC2 LOLBin Execution via SSM SendCommand

AWS Systems Manager (SSM) enables remote command execution on EC2 instances without SSH/RDP access. While legitimate for administration, adversaries exploit this by running LOLBins—system utilities abused for malicious purposes like data theft or backdoors. This detection correlates CloudTrail API logs with endpoint telemetry using SSM command IDs, bypassing AWS's parameter redaction to reveal actual executed commands and identify suspicious activity.

This is an ESQL aggregation-based rule, thus all original event fields and detail may not be present in the alert. It is recommended to pivot into the raw events from both data sources for full context during investigation.

### Possible investigation steps

- Review the SSM command ID in the alert to track the full lifecycle of the command from initiation to execution across both CloudTrail and endpoint data
- Examine the CloudTrail user identity, including the ARN and access key ID, to determine who initiated the SSM command and verify if the activity is authorized
- Analyze the command lines of the executed LOLBins to understand what commands were run and assess their intent, looking for indicators of data exfiltration, reverse shells, or reconnaissance
- Check the source IP address and user agent from the CloudTrail event to identify if the request came from an expected location or tool
- Investigate the affected EC2 instances for other suspicious activities or signs of compromise during the same timeframe, including network connections and file modifications
- Review the SSM shell process details to see the full context of what the SSM agent executed and identify the parent-child process relationships
- Correlate the timing between the CloudTrail event and endpoint execution to ensure they occurred within the detection window and represent the same activity
- Check if the same user identity or source IP has executed similar SSM commands on other EC2 instances in your environment

### False positive analysis

- Routine administrative scripts that use utilities like curl, wget, or python for legitimate configuration management should be documented and excluded by user identity or source IP
- Automated monitoring tools that execute commands via SSM for health checks or data collection can be filtered by identifying their consistent patterns and access key IDs
- DevOps CI/CD pipelines that deploy or test applications using SSM may trigger alerts; create exceptions based on known automation roles or specific command patterns
- Security scanning tools that legitimately use SSM for vulnerability assessments should be allowlisted by their known IAM roles or source IPs
- Scheduled maintenance tasks using LOLBins for backup, log rotation, or data synchronization can be excluded by command pattern matching or execution timing

### Response and remediation

- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution or lateral movement
- Review AWS CloudTrail logs to identify the IAM user, role, or access key associated with the suspicious SSM command and revoke or rotate compromised credentials
- Terminate any unauthorized processes identified on the endpoint that match the LOLBin execution patterns detected in the alert
- Conduct a forensic analysis of the affected EC2 instance to identify any persistence mechanisms, backdoors, or data exfiltration indicators
- Implement stricter IAM policies to limit SSM `SendCommand` permissions to only trusted users and roles, following the principle of least privilege
- Enable multi-factor authentication (MFA) for IAM users with SSM execution privileges to reduce the risk of credential compromise
- Review and update VPC security groups and network ACLs to restrict outbound traffic from EC2 instances to only necessary destinations, preventing data exfiltration
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional AWS resources or accounts have been compromised
"""
references = [
    "https://www.mitiga.io/blog/abusing-the-amazon-web-services-ssm-agent-as-a-remote-access-trojan",
    "https://www.kali.org/tools/pacu/",
    "https://www.100daysofredteam.com/p/ghost-in-the-cloud-abusing-aws-ssm",
    "https://hackingthe.cloud/aws/post_exploitation/run_shell_commands_on_ec2/",
    "https://gtfobins.github.io/",
]
risk_score = 47
rule_id = "a8b3e2f0-8c7d-11ef-b4c6-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Command and Control",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS EC2",
    "Data Source: AWS SSM",
    "Data Source: AWS Systems Manager",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail*, logs-endpoint.events.process-* METADATA _id, _version, _index
| WHERE
  // CloudTrail SSM SendCommand with AWS-RunShellScript
  (
    data_stream.dataset == "aws.cloudtrail"
    AND event.action == "SendCommand"
    AND aws.cloudtrail.request_parameters LIKE "*documentName=AWS-RunShellScript*"
  )
  // Linux endpoint process events, prefiltered to SSM shell runner OR LOLBins/GTFOBins
  OR
  (
    data_stream.dataset == "endpoint.events.process"
    AND host.os.type == "linux"
    AND (
      // SSM shell (_script.sh) runner
      process.command_line LIKE "%/document/orchestration/%/awsrunShellScript/%/_script.sh"
      // LOLBins / GTFOBins
      OR process.name IN (
        "base64",
        "curl",
        "wget",
        "openssl",
        "nc", "ncat", "netcat",
        "socat",
        "python", "python3",
        "perl",
        "php",
        "ruby",
        "ssh",
        "scp",
        "sftp",
        "rsync"
      )
    )
  )

// Endpoint leg: extract SSM command ID from parent command line
| DISSECT process.parent.command_line
    "%{}/document/orchestration/%{Esql.process_parent_command_line_ssm_command_id}/%{}"

// CloudTrail leg: extract SSM command ID from response_elements
| DISSECT aws.cloudtrail.response_elements
    "%{}commandId=%{Esql.aws_cloudtrail_response_elements_ssm_command_id},%{}"

// Coalesce SSM command ID from both data sources
| EVAL Esql.aws_ssm_command_id = COALESCE(
    Esql.aws_cloudtrail_response_elements_ssm_command_id,
    Esql.process_parent_command_line_ssm_command_id
)
| WHERE Esql.aws_ssm_command_id IS NOT NULL

// Role flags
| EVAL Esql.is_cloud_event    = data_stream.dataset == "aws.cloudtrail"
| EVAL Esql.is_endpoint_event = data_stream.dataset == "endpoint.events.process"

// Identify the SSM shell processes (the _script.sh runners)
| EVAL Esql.is_ssm_shell_process =
    Esql.is_endpoint_event
    AND process.command_line LIKE "%/document/orchestration/%/awsrunShellScript/%/_script.sh"

// LOLBins / GTFOBins on Linux
| EVAL Esql.is_lolbin_process =
    Esql.is_endpoint_event AND NOT Esql.is_ssm_shell_process

// Aggregate per SSM command ID
| STATS
    // Core correlation counts & timing
    Esql.aws_cloudtrail_event_count                 = SUM(CASE(Esql.is_cloud_event, 1, 0)),
    Esql.endpoint_events_process_lolbin_count       = SUM(CASE(Esql.is_lolbin_process, 1, 0)),
    Esql.endpoint_events_process_ssm_shell_count    = SUM(CASE(Esql.is_ssm_shell_process, 1, 0)),
    Esql.aws_cloudtrail_first_event_ts              = MIN(CASE(Esql.is_cloud_event, @timestamp, null)),
    Esql.endpoint_events_process_first_lolbin_ts    = MIN(CASE(Esql.is_lolbin_process, @timestamp, null)),

    // AWS / CloudTrail identity & request context
    Esql_priv.aws_cloudtrail_user_identity_arn_values          =
      VALUES(CASE(Esql.is_cloud_event, aws.cloudtrail.user_identity.arn, null)),
    Esql_priv.aws_cloudtrail_user_identity_access_key_id_values =
      VALUES(CASE(Esql.is_cloud_event, aws.cloudtrail.user_identity.access_key_id, null)),
    Esql_priv.user_name_values                                 =
      VALUES(CASE(Esql.is_cloud_event, user.name, null)),

    // AWS environment / request metadata
    Esql.cloud_region_values     = VALUES(CASE(Esql.is_cloud_event, cloud.region, null)),
    Esql.source_ip_values        = VALUES(CASE(Esql.is_cloud_event, source.ip, null)),
    Esql.user_agent_original_values =
      VALUES(CASE(Esql.is_cloud_event, user_agent.original, null)),

    // Endpoint host & user context
    Esql.host_name_values        = VALUES(CASE(Esql.is_endpoint_event, host.name, null)),
    Esql_priv.endpoint_user_name_values =
      VALUES(CASE(Esql.is_endpoint_event, user.name, null)),

    // SSM shell processes on endpoint
    Esql.process_command_line_ssm_shell_values =
      VALUES(CASE(Esql.is_ssm_shell_process, process.command_line, null)),
    Esql.process_pid_ssm_shell_values =
      VALUES(CASE(Esql.is_ssm_shell_process, process.pid, null)),

    // LOLBin processes on endpoint
    Esql.process_name_lolbin_values =
      VALUES(CASE(Esql.is_lolbin_process, process.name, null)),
    Esql.process_executable_lolbin_values =
      VALUES(CASE(Esql.is_lolbin_process, process.executable, null)),
    Esql.process_command_line_lolbin_values =
      VALUES(CASE(Esql.is_lolbin_process, process.command_line, null)),
    Esql.process_pid_lolbin_values =
      VALUES(CASE(Esql.is_lolbin_process, process.pid, null)),
    Esql.process_parent_command_line_lolbin_values =
      VALUES(CASE(Esql.is_lolbin_process, process.parent.command_line, null)),

    Esql.data_stream_namespace_values = VALUES(data_stream.namespace)
  BY Esql.aws_ssm_command_id

// Detection condition: SSM SendCommand + AWS-RunShellScript + LOLBin on endpoint
| WHERE Esql.aws_cloudtrail_event_count > 0
  AND Esql.endpoint_events_process_lolbin_count > 0
  AND DATE_DIFF(
        "minutes",
        Esql.endpoint_events_process_first_lolbin_ts,
        Esql.aws_cloudtrail_first_event_ts
      ) <= 5
| SORT Esql.aws_cloudtrail_first_event_ts ASC
| KEEP Esql.*, Esql_priv.*
'''


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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS
Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the
legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in
CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS
access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM
identities to cluster-admin privileges without modifying any Kubernetes resources.
"""
false_positives = [
    """
    Platform or security teams may legitimately associate these policies during cluster onboarding, break-glass admin
    setup, or controlled RBAC migrations from aws-auth. Validate the caller, change ticket, and target IAM principal.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EKS Access Entry Granted Cluster Admin Policy"
note = """## Triage and analysis

### Investigating AWS EKS Access Entry Granted Cluster Admin Policy

Successful AssociateAccessPolicy with AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy binds highly privileged
Kubernetes access to an IAM principal. Review who invoked the API (user.name, aws.cloudtrail.user_identity fields),
source.ip, user_agent.original, cloud.account.id, and cloud.region.

### Possible investigation steps

- Parse aws.cloudtrail.request_parameters and response elements for cluster name, access entry ARN, and policy ARN.
- Confirm whether the IAM principal receiving the policy is expected to have cluster-admin-class access.
- Correlate with other EKS API calls (CreateAccessEntry, UpdateAccessEntry) and with Kubernetes audit activity from
  newly authorized principals.
- Compare against change records for migrations from aws-auth or new administrator onboarding.

### Response and remediation

- If unauthorized, disassociate the policy or remove the access entry per AWS guidance; audit who can call eks:*
  APIs in IAM.
- Rotate credentials for any suspected compromised IAM principal; review organizational SCPs and cluster auth mode.

### Additional information

- [Amazon EKS access entries](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)
- [AssociateAccessPolicy](https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html)
"""
references = [
    "https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html",
    "https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html",
]
risk_score = 73
rule_id = "9550ec87-e73c-4baa-ad44-e448a33fbc3d"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"aws.cloudtrail" and
event.provider:"eks.amazonaws.com" and
event.action:"AssociateAccessPolicy" and
event.outcome:"success" and
aws.cloudtrail.request_parameters:(*AmazonEKSClusterAdminPolicy* or *AmazonEKSAdminPolicy*)
'''

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

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2026/04/02"
integration = ["aws"]
maturity = "production"
min_stack_comments = "Changing min stack to 9.3.0, the latest minimum supported version for 9.X releases."
min_stack_version = "9.3.0"
updated_date = "2026/07/20"

[rule]
author = ["Elastic"]
description = """
Identifies when the same AWS principal, from the same source IP, successfully invokes read-only S3 control-plane APIs
that reveal bucket posture across many buckets in a short period. This pattern can indicate automated reconnaissance or
security scanning, similar to CSPM tools and post-compromise enumeration. The rule excludes AWS service principals,
requires programmatic-style sessions (not Management Console credentials), and requires populated resource and identity
fields so nulls do not skew cardinality.
"""
false_positives = [
    """
    Legitimate security scanners, CSPM products, compliance jobs, and inventory automation may call the same read-only
    bucket APIs across many buckets quickly. Verify the principal ARN, source IP, user agent, and schedule against known
    approved tooling before treating the activity as malicious.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "AWS S3 Rapid Bucket Posture API Calls from a Single Principal"
note = """## Triage and analysis

### Investigating AWS S3 Rapid Bucket Posture API Calls from a Single Principal

This rule detects when the same AWS principal (`aws.cloudtrail.user_identity.arn`), from the same `source.ip`, successfully invokes read-only S3 control-plane APIs that reveal bucket posture across more than 15 distinct `aws.cloudtrail.resources.arn` values within a 10-second window.

Security scanners, compliance tools, and post-compromise reconnaissance often walk many buckets quickly to map public access, policies, and versioning. Bursts of distinct buckets in seconds are less typical of one-off console administration or single-bucket troubleshooting. This could be indicative of reconnaissance as seen by threat actors like Team PCP. 

### Possible investigation steps

**Identify the actor and session context**
- **Actor ARN (`aws.cloudtrail.user_identity.arn`)**: Determine which IAM user, role, or federated principal performed the reads. Confirm whether this identity is approved for broad S3 read or security auditing. Unusual types or unfamiliar roles may warrant deeper review.
- **Access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`)**: Identify which access key or temporary credential was used. Correlate with IAM last-used metadata for the key or role session.

**Characterize the bucket sweep**
- **Distinct bucket count (`Esql.aws_cloudtrail_resources_arn_count_distinct`)**: Compare to normal baselines for this identity; values at or just above the threshold may still warrant review for new automation.
- **Bucket ARNs (`Esql.aws_cloudtrail_resources_arn_values`)**: Identify which buckets were touched. Prioritize buckets that store logs, backups, credentials, or regulated data. Search the same time range for write or policy-change APIs (`PutBucket*`, `DeleteBucket*`) on the same buckets.

**Analyze source and client**
- **Source IP (`Esql.source_ip_values`)**: Map to corporate egress, a known runner or bastion, an EC2 instance, or an unfamiliar ASN. Compare with VPC Flow Logs or proxy logs when available.
- **User agent (`Esql.user_agent_original_values`, `Esql.user_agent_name_values`)**: Identify the AWS CLI, Boto3, a specific scanner, or custom scripts. Unusual or minimal user agents may align with tooling and require investigation.

**Correlate in time**
- Query CloudTrail for the same `aws.cloudtrail.user_identity.arn` and `source.ip` within approximately ±30 minutes for follow-on patterns: `ListBuckets`, `GetObject`, `PutBucketPolicy`, `AssumeRole`, or IAM changes.
- Check for overlapping alerts related to credential access, unusual geolocation, or new external bucket policy grants.

### False positive analysis

Legitimate causes can include:
- **Security and compliance scanners** (for example CSPM or assessment tools) using API credentials with `s3:Get*` permissions across many buckets.
- **Inventory or backup catalog tools** that enumerate bucket metadata for reporting.
- **CI/CD or infrastructure-as-code validation** jobs that verify bucket settings across environments.

Validate whether the principal is a documented service account, the IP belongs to known infrastructure, and the timing matches scheduled jobs. If behavior is expected, consider raising the distinct-bucket threshold, adding `user_agent` filters, or documenting exception identities.

### Response and remediation

**Contain**
- If activity is unexpected, rotate or disable keys for the affected identity, revoke active role sessions where possible, and restrict the source IP at the network layer if it is not authorized.

**Investigate**
- Export CloudTrail for the window around `Esql.time_window_date_trunc` and review all S3 and IAM events for the same actor.
- Review IAM policies attached to the principal for excessive `s3:Get*` or `s3:List*` scope.

**Harden**
- Enforce least privilege on S3 read APIs; use permission boundaries or service control policies where appropriate.
- Ensure sensitive buckets are not unnecessarily reachable from the observed network context.
- Document approved scanning accounts and tune the rule to reduce noise from those identities.

### Additional information

- [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf)
- [AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/)
- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework)

"""
references = [
    "https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise",
]
risk_score = 21
rule_id = "a7577205-88a1-4a08-85d4-7b72a9a2e969"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS S3",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws.cloudtrail-* metadata _id, _version, _index
| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp)

| where
    data_stream.dataset == "aws.cloudtrail"
    and event.provider == "s3.amazonaws.com"
    and event.outcome == "success"
    and event.action in (
      "GetBucketAcl",
      "GetBucketPublicAccessBlock",
      "GetBucketPolicy",
      "GetBucketPolicyStatus",
      "GetBucketVersioning"
    )
    and aws.cloudtrail.user_identity.type != "AWSService"
    and source.ip IS NOT NULL
    and aws.cloudtrail.resources.arn IS NOT NULL
    and aws.cloudtrail.user_identity.arn IS NOT NULL
    and aws.cloudtrail.session_credential_from_console IS NULL

| keep
    @timestamp,
    Esql.time_window_date_trunc,
    event.action,
    aws.cloudtrail.user_identity.arn,
    aws.cloudtrail.user_identity.type,
    aws.cloudtrail.user_identity.access_key_id,
    source.ip,
    aws.cloudtrail.resources.arn,
    cloud.account.id,
    cloud.region,
    user_agent.original,
    source.as.organization.name,
    data_stream.namespace

| stats
    Esql.aws_cloudtrail_resources_arn_count_distinct = count_distinct(aws.cloudtrail.resources.arn),
    Esql.aws_cloudtrail_resources_arn_values = VALUES(aws.cloudtrail.resources.arn),
    Esql.event_action_values = VALUES(event.action),
    Esql.timestamp_values = VALUES(@timestamp),
    Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type),
    Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id),
    Esql.cloud_account_id_values = VALUES(cloud.account.id),
    Esql.cloud_region_values = VALUES(cloud.region),
    Esql.user_agent_original_values = VALUES(user_agent.original),
    Esql.source_as_organization_name_values = VALUES(source.as.organization.name),
    Esql.data_stream_namespace_values = VALUES(data_stream.namespace)
  by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn, source.ip

| where Esql.aws_cloudtrail_resources_arn_count_distinct > 15

| keep
    aws.cloudtrail.user_identity.arn,
    source.ip,
    Esql.time_window_date_trunc,
    Esql.aws_cloudtrail_resources_arn_count_distinct,
    Esql.aws_cloudtrail_resources_arn_values,
    Esql.event_action_values,
    Esql.timestamp_values,
    Esql.aws_cloudtrail_user_identity_type_values,
    Esql.aws_cloudtrail_user_identity_access_key_id_values,
    Esql.cloud_account_id_values,
    Esql.cloud_region_values,
    Esql.user_agent_original_values,
    Esql.source_as_organization_name_values,
    Esql.data_stream_namespace_values
'''


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

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

[[rule.threat.technique]]
id = "T1619"
name = "Cloud Storage Object Discovery"
reference = "https://attack.mitre.org/techniques/T1619/"


[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"


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

[rule.investigation_fields]
field_names = [
    "Esql.aws_cloudtrail_resources_arn_count_distinct",
    "Esql.time_window_date_trunc",
    "aws.cloudtrail.user_identity.arn",
    "source.ip",
    "Esql.aws_cloudtrail_resources_arn_values",
    "Esql.event_action_values",
    "Esql.timestamp_values",
    "Esql.aws_cloudtrail_user_identity_type_values",
    "Esql.aws_cloudtrail_user_identity_access_key_id_values",
    "Esql.cloud_account_id_values",
    "Esql.cloud_region_values",
    "Esql.user_agent_original_values",
    "Esql.source_as_organization_name_values",
    "Esql.data_stream_namespace_values",
]

[metadata]
creation_date = "2020/08/17"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations.
An adversary may delete diagnostic settings in an attempt to evade defenses.
"""
false_positives = [
    """
    Deletion of diagnostic settings may be done by a system or network administrator. Verify whether the username,
    hostname, and/or resource name should be making changes in your environment. Diagnostic settings deletion from
    unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
    from the rule.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Diagnostic Settings Deleted"
note = """## Triage and analysis

### Investigating Azure Diagnostic Settings Deleted

Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts.

### Possible investigation steps

- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise.
- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources.
- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.
- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.
- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.
- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities.

### False positive analysis

- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity.
- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.
- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.
- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.
- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations.

### Response and remediation

- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.
- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious.
- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.
- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.
- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.
- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.
"""
references = [
    "https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings",
    "https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/",
]
risk_score = 47
rule_id = "5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:azure.activitylogs
    and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
    and event.outcome:(Success or success)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.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.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "source.ip",
    "azure.activitylogs.identity.authorization.evidence.principal_type",
    "azure.activitylogs.identity.authorization.evidence.role_assignment_scope",
    "azure.activitylogs.properties.entity",
    "azure.activitylogs.identity.claims.appid",
    "azure.resource.name",
    "azure.resource.provider",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.resource.group"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2026/06/25"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/06/25"

[rule]
author = ["Elastic"]
description = """
Identifies successful outbound TLS sessions that negotiate deprecated protocol versions (SSLv3, TLS 1.0, or TLS 1.1) or
weak cipher suites such as RC4, 3DES, NULL, EXPORT, or anonymous Diffie-Hellman. Adversaries-in-the-middle and legacy
malware often force these negotiations to decrypt or intercept traffic. Modern clients and services should negotiate TLS
1.2 or 1.3 with strong ciphers on internet-bound connections.
"""
false_positives = [
    """
    Legacy internal applications, industrial control systems, or embedded devices may still require deprecated TLS
    versions or weak ciphers. Exclude known legacy destination IPs or subnets after validation.
    """,
]
from = "now-9m"
index = ["logs-network_traffic.tls-*"]
language = "kuery"
license = "Elastic License v2"
name = "Deprecated TLS Version or Weak Cipher Negotiated Externally"
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 Deprecated TLS Version or Weak Cipher Negotiated Externally

TLS downgrade and weak-cipher negotiation expose sessions to interception or decryption. This rule flags completed
outbound TLS handshakes from internal hosts to external destinations that negotiated SSLv3, TLS 1.0, TLS 1.1, or a
cipher suite containing RC4, 3DES, NULL, EXPORT, or anonymous key exchange material.

### Possible investigation steps

- Review `source.ip`, `destination.ip`, `destination.port`, `tls.version`, `tls.version_protocol`, and `tls.cipher`.
- Determine whether the destination is a known legacy partner, vendor appliance, or unmanaged IoT device.
- Check for concurrent alerts on the source host (credential access, C2, or proxy manipulation).
- Compare against baseline: does this destination normally negotiate modern TLS from other clients?

### False positive analysis

- Exclude validated legacy B2B endpoints, mainframe gateways, or SCADA systems that cannot be upgraded immediately.
- Some older mobile or embedded clients may still offer weak ciphers even when connecting to modern services; confirm
  whether the server accepted the weak option (this rule requires `tls.established:true`).

### Response and remediation

- Block or proxy traffic to the destination if downgrade appears attacker-driven.
- Patch or replace the client or server that accepted deprecated TLS.
- Enable TLS 1.2+ minimums on egress proxies and inspect for MITM appliances forcing weak negotiation.
"""
references = [
    "https://attack.mitre.org/techniques/T1557/",
    "https://www.elastic.co/docs/reference/integrations/network_traffic",
    "https://www.elastic.co/docs/reference/ecs/ecs-tls",
    "https://www.rfc-editor.org/rfc/rfc9325.html",
]
risk_score = 47
rule_id = "d994a184-ab93-4cff-8fb6-31a4b4dd18b1"
setup = """## Setup

This rule requires TLS metadata from the Elastic network_traffic integration (`network_traffic.tls` data stream) that
populates ECS `tls.version`, `tls.version_protocol`, `tls.cipher`, and `tls.established` fields.
"""
severity = "medium"
tags = [
    "Domain: Network",
    "Use Case: Network Security Monitoring",
    "Use Case: Threat Detection",
    "Data Source: Network Traffic",
    "Tactic: Credential Access",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:network_traffic.tls
  and network.protocol: tls
  and network.transport: tcp
  and tls.established: true
  and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16)
  and not destination.ip:(
    10.0.0.0/8 or
    100.64.0.0/10 or
    127.0.0.0/8 or
    169.254.0.0/16 or
    172.16.0.0/12 or
    192.0.0.0/24 or
    192.0.0.0/29 or
    192.0.0.10/32 or
    192.0.0.170/32 or
    192.0.0.171/32 or
    192.0.0.8/32 or
    192.0.0.9/32 or
    192.0.2.0/24 or
    192.168.0.0/16 or
    192.175.48.0/24 or
    192.31.196.0/24 or
    192.52.193.0/24 or
    192.88.99.0/24 or
    198.18.0.0/15 or
    198.51.100.0/24 or
    203.0.113.0/24 or
    224.0.0.0/4 or
    240.0.0.0/4 or
    "::1" or
    "FE80::/10" or
    "FF00::/8"
  )
  and (
    tls.version:(1.0 or 1.1) or
    (tls.version_protocol:ssl and tls.version:3.0) or
    (
      not tls.version:1.3 and (
        tls.cipher:(
          *RC4* or
          *3DES* or
          *NULL* or
          *EXPORT* or
          *_anon_* or
          *ADH* or
          *AECDH*
        )
      )
    )
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1573"
name = "Encrypted Channel"
reference = "https://attack.mitre.org/techniques/T1573/"


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

[rule.new_terms]
field = "new_terms_fields"
value = ["source.ip", "destination.ip", "tls.version"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2026/01/30"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Detects the use of process environment variables (DYLD_INSERT_LIBRARIES or LD_PRELOAD) to inject a shared 
library into a binary at or prior to execution. A threat actor may use this technique to load a malicious 
shared library for persistence, privilege escalation, and defense evasion. This activity is uncommon and 
typically indicates malicious behavior.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*", "logs-endpoint.events.library-*"]
language = "eql"
license = "Elastic License v2"
name = "Dylib Injection via Process Environment Variables"
references = [
    "https://wojciechregula.blog/post/learn-xpc-exploitation-part-3-code-injections/",
    "https://attack.mitre.org/techniques/T1574/006/"
]
risk_score = 73
rule_id = "fb8790fc-d485-45e2-8d6e-2fb813f4af95"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide"
]
type = "eql"
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 Dylib Injection via Process Environment Variables

Dynamic library injection using DYLD_INSERT_LIBRARIES or LD_PRELOAD environment variables is a powerful technique that allows code to be loaded into a process's address space at runtime. While this capability exists for legitimate debugging and development purposes, threat actors abuse it to hook application functionality, steal credentials, intercept keystrokes, or execute malicious code within trusted processes. This detection rule identifies processes started with these injection environment variables set to non-empty values.

### Possible investigation steps

- Review the process.env_vars field to identify the specific dylib being injected via DYLD_INSERT_LIBRARIES or LD_PRELOAD and determine its file path.
- Locate the injected dylib file on the file system using the path from the environment variable and calculate its hash for threat intelligence lookups.
- Analyze the process.executable and process.name fields to identify the target application being hijacked and assess whether dylib injection makes sense for its normal operation.
- Examine the process.parent.executable and process.command_line to understand how the process with injection was launched and trace back to the initial execution vector.
- Review the code signature of the injected dylib using codesign or similar tools to determine if it is signed, and by whom.
- Check for file creation events to determine when the malicious dylib was placed on the system and how it was delivered.
- Correlate with other security events on the same host to identify if the injection is part of a larger attack chain, such as credential theft or keylogging.

### False positive analysis

- Xcode and iOS Simulator use DYLD_INSERT_LIBRARIES for debugging and testing purposes during application development. These paths are already excluded in the query.
- Security research and reverse engineering tools may use library injection for analysis. Verify with security teams if such activities are expected.
- Some legitimate applications use library injection for specific functionality. Document these applications and create targeted exceptions after verification.
- Homebrew and development environments may occasionally use these environment variables. Confirm with development teams before creating exclusions.

### Response and remediation

- Immediately terminate the process using malicious dylib injection to stop any ongoing malicious activity such as credential theft or keylogging.
- Quarantine the injected dylib file for forensic analysis and malware reverse engineering.
- Remove the malicious dylib from the system and ensure it cannot be reloaded through persistence mechanisms.
- Investigate how the dylib was placed on the system and remediate the initial access or delivery mechanism.
- Review System Integrity Protection (SIP) status on the affected system, as SIP should normally prevent DYLD injection into protected system processes.
- Scan the system for additional indicators of compromise, persistence mechanisms, or lateral movement.
- Reset any credentials that may have been exposed through the injection, particularly if the target application handles sensitive authentication data.
- Escalate to the incident response team for comprehensive analysis if the injection indicates active compromise.
"""
query = '''
sequence by process.entity_id with maxspan=15s
  [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and
    process.env_vars like ("DYLD_INSERT_LIBRARIES=?*", "LD_PRELOAD=?*") and
    not process.env_vars like ("DYLD_INSERT_LIBRARIES=", "LD_PRELOAD=", "LD_PRELOAD=<null>") and
    not process.executable like ("/Users/*/Library/Developer/Xcode/*", "/Users/*/Library/Developer/CoreSimulator/*") and
    not process.parent.executable like ("/usr/bin/xcrun", "/Applications/Xcode*.app/*", "/Library/Developer/*")]
  [library where host.os.type == "macos" and event.action == "load" and
    not dll.name like ("*.aot", "*.so") and
    not dll.code_signature.trusted == true and
    not dll.path like ("/System/*", "/usr/lib/*", "/opt/homebrew/*", "/private/var/folders/*",
                       "/Library/Apple/*", "/Library/Developer/*",
                       "/Users/*/Library/Developer/Xcode/*", "/Users/*/Library/Developer/CoreSimulator/*")]
'''

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

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

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

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

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

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

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

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

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

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

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

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

[rule]
description = """
This rule detects when a process executes a file descriptor in the proc (temporary) file system. This activity indicates
an active attempt to execute a fileless payload and should be considered highly abnormal or suspicious. This activity
can occur when the memfd syscall is utilized to create a memory resident file, like a payload, and then uses it to
execute a process via a command and control channel.
"""
id = "dccab9ab-1b40-4d52-85ed-cb41310b0160"
license = "Elastic License v2"
name = "Execution of Memory File Descriptor via Suspicious Process"
os_list = ["linux"]
reference = ["https://man7.org/linux/man-pages/man2/memfd_create.2.html"]
version = "1.0.10"

query = '''
process where event.type == "start" and event.action == "exec" and (
  process.executable regex """/proc/(self|[0-9]{1,7})/fd/[0-9]{1,7}""" or
  (
    process.args regex """/proc/(self|[0-9]{1,7})/fd/[0-9]{1,7}""" and
    process.executable like (
      "memfd:*", "?memfd:*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/user/*", "/var/run/user/*",
      "/boot/*", "/sys/*", "/lost+found/*", "/proc/*", "/var/mail/*", "/root/*"
    )
  )
) and
not (
  process.parent.executable like (
    "/home/*/*steam*", "/usr/bin/podman", "./usr/bin/podman", "/dev/.buildkit_qemu_emulator",
    "/opt/omni/bin/drim/linux-amd64/coolie", "/usr/lib/systemd/systemd", "/usr/libexec/nordlayer/nordlayer-setcap",
    "/usr/bin/nordlayer", "/home/*/playground/general/edgeless/tools/contrast", "/bin/nvidia-cdi-hook",
    "/usr/bin/nvidia-ctk", "/sbin/apk", "/tmp/newroot/usr/bin/podman", "/usr/libexec/nordlayer/nordlayer-resolvconf",
    "/usr/sbin/docker-runc", "/usr/bin/runc", "/opt/teleport/system/bin/teleport", "/usr/local/bin/teleport",
    "/opt/sophos-spl/plugins/runtimedetections/bin/runtimedetections*", "/opt/fireeye/bin/rte-sensor", "/usr/local/sbin/thor-cloud-*",
    "/tmp/newroot/run/media/mm1/RIG_Drive_2/SteamLibrary/steamapps/common/SteamLinuxRuntime_4/pressure-vessel/bin/pressure-vessel-wrap",
    "/tmp/newroot/bin/sh", "/opt/sophos-spl/base/bin/launcher", "/usr/bin/containerd-shim-runc-v2", "/opt/sophos-spl/base/bin/sophos_watchdog.*"
  ) or
  process.executable like (
    "./home/*/.local/share/claude/versions/*", "/tmp/newroot/usr/bin/ls", "/tmp/newroot/var/lib/docker/rootfs/overlayfs/*/usr/bin/chown",
    "/tmp/newroot/*"
  ) or
  process.command_line like (
    "runc init", "/usr/local/bin/runc init", "*/home/*/.claude/shell-snapshots/snapshot*",
    "/proc/self/fd/? -config /etc/nordlayer/config.hcl", "storage-untar / /proc/self/fd/*",
    "/proc/self/exe init"
  ) or
  process.parent.args == "/usr/local/bin/teleport" or
  process.parent.command_line like (
    "/opt/teleport/system/bin/teleport exec", "/opt/teleport/default/versions/*/bin/teleport exec"
  ) or
  (
    process.parent.command_line == "/usr/local/bin/teleport exec" and
    process.command_line == "/memfd:teleport-sessionhelper checkhomedir"
  ) or
  (
    process.command_line like "/usr/lib/podman/netavark --config /run/containers/networks --rootless=false --aardvark-binary=/usr/lib/podman/aardvark-dns *" and
    process.args == "/usr/lib/podman/netavark"
  ) or
  (
    process.args == "lxc-attach" and
    process.args == "-n"
  ) or
  (
    process.args == "bwrap" and
    process.args == "--new-session" and
    process.args == "--die-with-parent"
  ) or
  (
    process.parent.executable in ("/bin/php", "/usr/bin/php") and
    process.args == "datadog-ipc-helper"
  ) or
  process.args like ("/usr/lib/systemd/systemd-executor", "/nix/store/*/lib/systemd/systemd-executor") or
  (
    process.executable like (
      "/tmp/newroot/proc/self/exe", "/tmp/newroot/home/*/.local/share/containers/storage/overlay/*/merged/proc/self/exe",
      "./usr/bin/podman"
    ) and
    process.args == "storage-untar"
  ) or
  (
    process.parent.executable == "/usr/libexec/docker/docker-runc-current" and
    process.command_line == "/proc/self/exe init"
  ) or
  (
    process.parent.executable == "/opt/sentinelone/bin/addon-host" and
    process.args like "/opt/sentinelone/addons/executables/SentinelAppVulnerability/*"
  ) or
  (
    process.executable == "memfd:spawn_worker_trampoline" and
    process.parent.executable == "/usr/local/bin/php"
  ) or
  (
    process.executable like "/tmp/agy-nsjail-exe-*" and
    process.parent.executable like "/home/*/resources/app/extensions/antigravity/bin/language_server_linux_x64"
  ) or
  (
    process.working_directory like "/var/lib/docker/overlay2/*/merged" and
    process.command_line == "/proc/self/exe init"
  ) or
  (
    process.executable == "memfd:spawn_worker_trampoline" and
    process.args == "datadog-ipc-helper"
  ) or
  (
    process.parent.executable == "/usr/bin/docker-runc" and
    process.command_line == "docker-runc init"
  ) or
  process.parent.executable like "*/.codex/tmp/arg0/*/codex-linux-sandbox"
)
'''

min_endpoint_version = "9.1.4"
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 = "T1106"
name = "Native API"
reference = "https://attack.mitre.org/techniques/T1106/"


[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"
[[threat.technique.subtechnique]]
id = "T1055.009"
name = "Proc Memory"
reference = "https://attack.mitre.org/techniques/T1055/009/"


[[threat.technique]]
id = "T1620"
name = "Reflective Code Loading"
reference = "https://attack.mitre.org/techniques/T1620/"


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

[internal]
min_endpoint_version = "9.1.4"

[metadata]
creation_date = "2026/05/30"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/05/30"

[rule]
author = ["Elastic", "Aryu Zaw"]
description = """
Identifies when a service account impersonation role is granted on a Google Cloud Platform (GCP) service account via a
SetIamPolicy operation. Roles such as "roles/iam.serviceAccountTokenCreator", "roles/iam.serviceAccountUser", and
"roles/iam.serviceAccountOpenIdTokenCreator" allow a principal to mint access or identity tokens for the target service
account, or to act as it when deploying resources. Adversaries who have obtained sufficient privileges may grant
themselves or an attacker-controlled principal one of these roles to impersonate a higher-privileged service account,
escalating privileges and establishing durable, key-less persistence that survives credential rotation. This is a New
Terms rule that alerts when the granting principal has not been observed performing this action in the last weeks.
"""
false_positives = [
    """
    Infrastructure-as-code tooling (e.g. Terraform), CI/CD pipelines, and platform automation routinely grant
    serviceAccountUser or serviceAccountTokenCreator when wiring up workloads, deployments, or impersonation chains.
    Identify the expected automation principals and target service accounts and add exceptions for them.
    """,
    """
    Administrators may grant impersonation roles when onboarding new applications or delegating access. Verify that the
    grant aligns with a known change and that both the granting principal and the added member are expected.
    """,
]
from = "now-9m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP IAM Service Account Impersonation Role Granted"
note = """## Triage and analysis

### Investigating GCP IAM Service Account Impersonation Role Granted

Granting an impersonation role on a service account lets the bound member obtain that service account's credentials
without creating a long-lived key. `roles/iam.serviceAccountTokenCreator` and `roles/iam.serviceAccountOpenIdTokenCreator`
allow minting OAuth2 access tokens and OpenID Connect identity tokens, while `roles/iam.serviceAccountUser` allows the
member to attach (actAs) the service account to new resources. Adversaries abuse these grants to pivot to a
higher-privileged identity, escalate privileges, and persist in a way that is unaffected by key rotation or password
resets.

### Possible investigation steps

- Identify the granting principal via `user.email` and `user.id` and confirm whether that identity is expected to modify
IAM policy on service accounts.
- Review the target service account in `gcp.audit.resource_name` and determine the permissions it holds. Impersonating a
service account with broad project or organization roles represents a significant escalation.
- Inspect the granted binding in `gcp.audit.request` / `gcp.audit.response` to identify the member that was added
(`user:`, `serviceAccount:`, `group:`, or an external domain). External or newly created members are higher risk.
- Examine `gcp.audit.request_metadata.caller_ip` and `gcp.audit.request_metadata.caller_supplied_user_agent` to assess
whether the change originated from an expected location or tool.
- Correlate with recent activity by the granting principal, such as service account key creation, custom role creation,
or `GenerateAccessToken` / `GenerateIdToken` calls that use the newly granted impersonation rights.

### False positive analysis

- Terraform, Deployment Manager, and CI/CD service accounts commonly grant serviceAccountUser and
serviceAccountTokenCreator as part of normal provisioning. Baseline these principals and exclude them with exceptions.
- One-time grants during application onboarding or delegation may be legitimate. Validate against change management
before escalating.

### Response and remediation

- If the grant is unauthorized, remove the impersonation binding from the service account's IAM policy.
- Revoke any access or identity tokens issued for the impacted service account and review its recent activity for abuse.
- Investigate the granting principal for compromise, rotate its credentials if necessary, and review what other IAM
changes it has made.
- Restrict who can set IAM policy on service accounts and require justification or approval for impersonation grants."""
references = [
    "https://securitylabs.datadoghq.com/cloud-security-atlas/attacks/backdooring-service-account/",
    "https://stratus-red-team.cloud/attack-techniques/GCP/gcp.persistence.backdoor-service-account-policy/",
    "https://cloud.google.com/iam/docs/service-account-impersonation",
    "https://cloud.google.com/iam/docs/audit-logging/examples-service-accounts",
]
risk_score = 47
rule_id = "197d2757-eea1-46f9-9ebd-84646d2b45fa"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: GCP Audit Logs",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "gcp.audit"
  and event.action: google.iam.admin.v*.SetIAMPolicy
  and event.outcome: "success"
  and gcp.audit.service_data.policy_delta.binding_deltas:{
    action: "ADD" and
    role: (
      "roles/iam.serviceAccountTokenCreator" or
      "roles/iam.serviceAccountUser" or
      "roles/iam.serviceAccountOpenIdTokenCreator"
    )
  }
'''


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

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

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

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

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

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

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

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

[rule.new_terms]
field = "new_terms_fields"
value = ["user.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

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

[rule]
author = ["Elastic"]
description = """
Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control
cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS
names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server,
database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently
connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database
credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod
in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration
changes are rare in normal operations and any unexpected modification should be investigated immediately.
"""
false_positives = [
    """
    Cluster administrators may legitimately update CoreDNS configuration for forwarding, stub domains, or cluster DNS
    troubleshooting. Baseline approved operators and automation identities; tune exclusions for known change pipelines.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE CoreDNS or Kube-DNS Configuration Modified"
note = """## Triage and analysis

### Investigating GKE CoreDNS or Kube-DNS Configuration Modified

Identify who performed the change (user.email, groups), from where (source.ip), and which ConfigMap was modified.
If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard
rewrites, or unexpected forward/proxy targets.

### Possible investigation steps

- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window.
- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs.
- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications.
- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces.

### Response and remediation

- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment.
- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity.

## Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
references = [
    "https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/",
    "https://coredns.io/plugins/rewrite/",
]
risk_score = 73
rule_id = "80528e81-949f-4d38-b0c7-aef4b160212e"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:("io.k8s.core.v1.configmaps.update" or "io.k8s.core.v1.configmaps.patch" or "io.k8s.core.v1.configmaps.delete") and
orchestrator.resource.name:("coredns" or "kube-dns" or "coredns-custom") and orchestrator.namespace:"kube-system" and
gcp.audit.labels.authorization.k8s.io/decision:"allow" and
not user.email:(
  "system:serviceaccount:kube-system:coredns" or
  "system:serviceaccount:kube-system:kube-dns" or
  system\:node* or system\:serviceaccount\:kube-system*
)
'''


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



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

[metadata]
creation_date = "2023/08/23"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/24"

[rule]
author = ["Elastic"]
description = """
Identifies the creation of .kirbi files, a suspicious Kerberos ticket artifact often produced by ticket export or
dumping tools such as Rubeus or Mimikatz. This can indicate preparation for Kerberos ticket theft or later abuse,
including Pass-The-Ticket (PTT), and should be validated with writer process and follow-on activity.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-m365_defender.event-*",
    "winlogbeat-*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Kirbi File Creation"
references = [
    "https://attack.mitre.org/techniques/T1558/",
]
risk_score = 73
rule_id = "b8f8da2d-a9dc-48c0-90e4-955c0aa1259a"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"
'''

note = """## Triage and analysis

### Investigating Kirbi File Creation
#### Possible investigation steps

- What does the alert-local ticket artifact show?
  - Focus: `file.path`, `file.name`, `file.extension`, `file.size`, and `@timestamp`, plus `host.id` and `user.id` for scope.
  - Implication: escalate when a ".kirbi" file lands in temp, public, user-profile, archive, or tool-staging paths, when `file.name` encodes a user, service, or realm, or when size and naming fit ticket export; lower suspicion only when the artifact path, name, host, and user match one known evidence-collection pattern before any workflow corroboration.

- Which process wrote the ticket file?
  - Focus: writer identity and launch context: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.executable`; use `process.entity_id` only to scope this process instance.
  - Hint: if only `process.pid` is present, recover the writer with `host.id`, `process.pid`, and a tight window around `@timestamp`.
  - Implication: escalate when unsigned, renamed, script- or shell-launched, or user-writable tooling writes the file; lower suspicion only when identity, signer, parent, and path match a recognized testing or IR workflow. Trusted identity alone does not clear ticket export.

- Does the command line or lineage show ticket export or ticket-use intent?
  - Focus: `process.command_line`, `process.parent.command_line`, and surrounding process events for the same `host.id` and `process.entity_id`, or `process.pid` when entity IDs are absent. $investigate_3
  - Implication: escalate when arguments or lineage show dump, export, outfile, archive staging, Mimikatz/Rubeus-style verbs, "ptt", "kerberos::ptt", scripting, or remote-admin chains; lower suspicion only when command line and lineage fit the same confirmed test or troubleshooting workflow.

- Did the same writer stage more tickets or hide them?
  - Focus: file events for `host.id` and `process.entity_id`: `file.path` and `file.name` for additional ".kirbi" writes, renames, archives, or extension changes. $investigate_0
  - Implication: escalate when the writer creates several ticket files, renames them into archives, removes the extension, or stores them beside collection tools; one unchanged ticket in a controlled evidence directory lowers scope but does not close by itself.

- How sensitive is the user and host context?
  - Focus: `host.name`, `user.id`, `user.name`, and `user.domain`.
  - Implication: escalate faster when a domain, service, or privileged identity writes the ticket, or when the same host/user also shows staging or follow-on use; lower severity only when a constrained lab identity and lab host match the telemetry and corroborating case evidence.

- Is there follow-on ticket import, remote access, or lateral movement after export?
  - Why: ".kirbi" creation proves ticket material was written; risk increases sharply if the same host or user tries to use it.
  - Focus: start with direct child process events from the writer process using `host.id` with `process.parent.entity_id`, or `process.parent.pid` when entity IDs are absent. $investigate_4 Expand manually to broader later process activity for the same `host.id` or `user.id` when needed, especially `process.command_line`.
  - Implication: escalate when later commands show "ptt", "kerberos::ptt", "klist", remote execution, archive movement, or access to new systems after export; matching authentication or connection telemetry can corroborate impact, but missing telemetry is unresolved, not benign.

- If local evidence stays suspicious or unresolved, do related alerts broaden the case?
  - Focus: related credential-access, lateral-movement, archive, and suspicious-authentication alerts for `user.id` in the last 48 hours. $investigate_1
  - Hint: use the same alert families for `host.id` when host scope, not user scope, decides containment. $investigate_2
  - Implication: broaden containment when related alerts align with ticket export, dumping, archive staging, remote access, or privilege escalation; keep response local when related alerts are absent or unrelated, but do not use absence alone to close the ".kirbi" alert.

- Based on the evidence gathered, what disposition is supported?
  - Focus: artifact path and naming, writer identity and lineage, command intent, staging, user/host sensitivity, and follow-on activity.
  - Implication: escalate when artifact, writer, command, staging, sensitive-context, or follow-on evidence points to unauthorized ticket export or use; close only when the same evidence categories tightly bind one recognized red-team, IR, or Kerberos-troubleshooting workflow and no contradictory evidence remains; preserve and escalate when evidence is mixed or incomplete.

### False positive analysis

- Red-team, purple-team, IR, and Kerberos troubleshooting workflows can legitimately export tickets, but close only after telemetry binds the exact workflow. Confirm that writer identity, parent context, command line, `user.id`, `host.id`, and output `file.path` all align, and that no ticket-import or remote-access follow-on appears; use case, exercise, or troubleshooting records only as corroboration. Use prior alerts only to validate exception stability after the current evidence aligns; do not close the current alert on recurrence alone. Treat production-domain-controller, admin-workstation, or service-account activity as suspicious unless it is explicitly in scope for the same case or exercise.
- Build exceptions from the minimum confirmed workflow pattern: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.parent.executable`, `process.command_line`, `user.id`, `host.id`, and output path pattern. Avoid exceptions on ".kirbi" extension, host, or user alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and document the writer identity, parent context, command line, user, host, and output path that proved the recognized workflow. Create an exception only after the same pattern recurs across prior alerts.
- If suspicious but unconfirmed, preserve the ".kirbi" file path, any archive path, the writing `process.entity_id`, command line, parent chain, user/host context, same-process file events, and follow-on process or authentication evidence before containment. Apply reversible containment first, such as suspending the exporting process or temporarily restricting administrative egress if the host role can tolerate it. Escalate to host isolation or account containment only when follow-on ticket use, privileged-host involvement, or repeated exports show progression.
- If confirmed malicious, preserve the process, file, parent-chain, identity, staging, and follow-on evidence set before containment or cleanup. Then isolate or otherwise contain the affected host when artifact, writer, command, staging, or follow-on evidence establishes unauthorized ticket export or use, weighing critical host role before isolation. Contain impacted accounts or service principals when the user context or follow-on activity shows their tickets may be usable. If direct endpoint response is unavailable, hand off the preserved evidence to the team that can act.
- Record process and file identifiers before deleting ticket files, terminating tools, or removing scripts. Revoke or expire exposed Kerberos sessions for affected identities and force reauthentication where appropriate. If evidence shows privileged-ticket theft or Pass-the-Ticket from administrative systems, reset or rotate affected credentials by privilege tier; reserve KRBTGT rotation for confirmed broader Kerberos compromise under the organization's runbook.
- Eradicate only the dumping tools, scripts, staged ".kirbi" files, archives, and persistence mechanisms found during the investigation, then remediate the initial access or privilege path that allowed ticket export.
- After containment, hunt for the same output paths, writer lineage, ticket-import commands, and staged archives across other systems.
"""

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 11 - File Create](https://ela.st/sysmon-event-11-setup)
"""

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

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

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

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

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

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

[[rule.threat.technique]]
id = "T1558"
name = "Steal or Forge Kerberos Tickets"
reference = "https://attack.mitre.org/techniques/T1558/"

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