Elastic rules: 31

[rule]
description = """
Detects when AppleScript is executed followed by the execution of the Base64 binary with the decode option set. Several
malware samples have been observed executing base64 encoded AppleScript in order to avoid detection.
"""
id = "9602ed93-b5cf-4397-ba37-6e752082847c"
license = "Elastic License v2"
name = "AppleScript Decoded via Base64"
os_list = ["macos"]
version = "1.0.8"

query = '''
sequence with maxspan=10s
[process where event.type == "start" and event.action == "exec" and process.parent.name == "osascript" and 
  (process.name in ("bash", "zsh", "sh", "dash", "csh", "tcsh", "ksh", "tclsh", "fish") or process.name like "tclsh*") and process.args == "-c"] by process.entity_id
[process where event.type == "start" and event.action == "exec" and (process.name in ("bash", "zsh", "sh", "dash", "csh", "tcsh", "ksh", "tclsh", "fish", "base64") or process.name like "tclsh*") and
  process.command_line like~ "*base64*-d*"] by process.parent.entity_id
'''

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

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

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



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

[[threat.technique]]
id = "T1140"
name = "Deobfuscate/Decode Files or Information"
reference = "https://attack.mitre.org/techniques/T1140/"


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

[internal]
min_endpoint_version = "8.11.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with
"AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact
only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch
metrics), so an execution role suddenly calling STS, EC2, IAM,
Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from
the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being
used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials
are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is
the detectable signal.
"""
false_positives = [
    """
    An AgentCore agent that legitimately integrates with additional AWS services will produce a first-time service call
    for its execution role. Verify the role in
    "aws.cloudtrail.user_identity.session_context.session_issuer.arn", the action in "event.action" and "event.provider",
    and the origin in "source.ip" and "source.as.organization.name", and confirm the activity matches the agent's
    intended design. Known agent integrations can be excluded after validation.
    """,
]
from = "now-9m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock AgentCore Execution Role Used Outside Its Runtime"
note = """## Triage and analysis

### Investigating AWS Bedrock AgentCore Execution Role Used Outside Its Runtime

AgentCore runtime and tool execution roles are assumed by the AgentCore service and normally only call Bedrock inference, AgentCore data-plane, and observability (CloudWatch Logs, X-Ray, CloudWatch metrics) APIs, all of which this rule excludes. Public research has shown the Code Interpreter microVM exposes the execution role's temporary credentials through the instance metadata service (IMDS), and that a string-filter bypass allows exfiltrating them outside the sandbox. Once stolen, the credentials are used to call other AWS services, but those calls are logged in CloudTrail under the execution role's identity rather than the attacker's, creating an attribution gap. This rule flags the first time an AgentCore execution role ("AgentCore-*" or "*BedrockAgentCore*") calls a non-Bedrock service, which is the point at which exfiltrated credentials are put to use.

### Possible investigation steps

- Identify the execution role in "aws.cloudtrail.user_identity.session_context.session_issuer.arn" and map it to its AgentCore runtime, gateway, or code interpreter.
- Review "event.provider" and "event.action" for reconnaissance (sts:GetCallerIdentity, ec2:Describe*, iam:List*/Get*), privilege escalation (sts:AssumeRole, iam:Put*/Attach*), or data access, and assess what the role can reach.
- Compare "source.ip", "source.as.organization.name", and "user_agent.original" against the AgentCore service origin; calls from an external network strongly indicate exfiltrated credentials.
- Determine whether the agent design legitimately added this integration, or whether the activity is unexpected for the role.

### False positive analysis

- A newly designed agent integration produces a first-time non-Bedrock call for its execution role. Confirm the integration is approved and exclude the role and service after validation.

### Response and remediation

- If unauthorized, revoke the execution role's active sessions, rotate any associated secrets, and review every action the role took since the first anomalous call.
- Restrict the execution role to least privilege, prefer VPC network mode for code interpreters, and ensure the metadata service requires session tokens.
"""
references = [
    "https://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/",
    "https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/",
]
risk_score = 73
rule_id = "ee066db8-4f2f-42d3-8ebd-ea25cd9bdc73"
setup = "This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. The AgentCore execution-role name prefix may differ in your environment; tune the role-name filter accordingly."
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.session_context.session_issuer.arn: (*role/AgentCore-* or *role/*BedrockAgentCore*)
    and event.outcome: "success"
    and not event.provider: (
        "bedrock.amazonaws.com" or
        "bedrock-runtime.amazonaws.com" or
        "bedrock-agentcore.amazonaws.com" or
        "bedrock-agentcore-control.amazonaws.com" or
        "logs.amazonaws.com" or
        "xray.amazonaws.com" or
        "monitoring.amazonaws.com" or
        "ecr.amazonaws.com" or
        "ecr-public.amazonaws.com"
    )
'''


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


[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"
[[rule.threat.technique.subtechnique]]
id = "T1552.005"
name = "Cloud Instance Metadata API"
reference = "https://attack.mitre.org/techniques/T1552/005/"


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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user_agent.original",
    "source.ip",
    "source.as.number",
    "source.as.organization.name",
    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "event.provider",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.session_context.session_issuer.arn", "event.provider"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2026/07/08"
integration = ["aws_bedrock_agentcore"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term
or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials
embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in
completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application,
or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear
text.
"""
false_positives = [
    """
    Documentation, examples, or test content may include sample key material. Confirm whether the key is live by
    reviewing "aws.bedrock_agentcore.request_payload.prompt" and the originating session and application.
    """,
]
from = "now-30m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS Bedrock AgentCore Runtime Prompt Containing Credentials"
note = """## Triage and analysis

### Investigating AWS Bedrock AgentCore Runtime Prompt Containing Credentials

Amazon Bedrock AgentCore runtime application logs capture the prompt supplied to the agent. When that prompt contains an AWS access key (AKIA/ASIA) or a PEM private key, the secret is exposed to the model provider and stored in observability logs, and it may be echoed in completions or consumed by the agent's tools. This usually reflects accidental leakage but can also be an attempt to stage credentials for abuse through the agent.

### Possible investigation steps

- Review "aws.bedrock_agentcore.request_payload.prompt" to identify the credential material and determine whether it is live.
- Identify the agent in "aws.bedrock_agentcore.agent_name"/"aws.bedrock_agentcore.resource_arn" and the conversation in "aws.bedrock_agentcore.session_id"; review surrounding prompts in the session.
- Determine the source application or identity invoking the runtime and whether passing secrets was intentional.
- If the key is an AWS access key, identify the IAM principal it belongs to and review its recent activity in CloudTrail for misuse.

### False positive analysis

- Sample or documentation key material can match. Confirm whether the credential is live before escalating.

### Response and remediation

- If the credential is live, rotate or revoke it immediately and review its activity for unauthorized use.
- Remove the secret from any retained logs or conversation stores where feasible, and notify the owning team.
- Educate users and applications to never pass secrets to agents in clear text, and consider input filtering or guardrails that block credential patterns.
"""
references = [
    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html",
]
risk_score = 73
rule_id = "b3e1f7a2-9d4c-4e8a-8f2b-1c6d5a0e3f77"
setup = """This rule requires Amazon Bedrock AgentCore runtime application logs collected via the Elastic AWS Bedrock AgentCore integration (observability logs delivered to S3 and ingested into the aws_bedrock_agentcore.runtime_application_logs dataset). See https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html for enabling AgentCore observability."""
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws_bedrock_agentcore.runtime_application_logs-* metadata _id, _version, _index
| where aws.bedrock_agentcore.operation == "InvokeAgentRuntime" and (
    aws.bedrock_agentcore.request_payload.prompt rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*"""
    or aws.bedrock_agentcore.request_payload.prompt rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*"""
    or aws.bedrock_agentcore.request_payload.prompt rlike """.*ABSK[A-Za-z0-9+/=]{20}.*"""
    or aws.bedrock_agentcore.request_payload.prompt rlike """.*bedrock-api-key-[-A-Za-z0-9+/=._~:]{20,}.*"""
  )
| keep _id, _version, _index, @timestamp, aws.*, cloud.*, event.*
'''


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


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

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

[rule]
author = ["Elastic"]
description = """
Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external
AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a
misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their
own data. This technique is a critical early signal of destructive intent or cross-account misuse.
"""
false_positives = [
    """
    Cross-account KMS key usage may be legitimate in multi-account AWS Organizations architectures where centralized
    encryption keys are used for data governance or auditing workflows. Confirm whether the external KMS key belongs to
    an expected account before taking action. Data migration or cross-account backup workflows may legitimately
    re-encrypt S3 objects using a key in another account. Ensure these workflows are documented, tied to known IAM
    roles, and occur on predictable schedules.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "AWS S3 Object Encryption Using External KMS Key"
note = """## Triage and analysis

### Investigating AWS S3 Object Encryption Using External KMS Key

This rule detects when an S3 `CopyObject` operation encrypts an object using a KMS key belonging to a different AWS account than the bucket owner. This behavior is unusual and a strong indicator of:

- Cloud ransomware techniques, where adversaries encrypt data using a key only they control.
- Cross-account privilege misuse, especially when an unauthorized principal has write access to S3.
- Misconfigured bucket permissions, enabling principals from another account to perform privileged copy operations.
- Early impact-stage activity in incidents where attackers prepare to destroy availability or deny the owner access.

The rule uses ESQL to identify cases where the `cloud.account.id` (bucket owner) differs from the dissected `kms_key_account_id` used for encrypting the new object version.


#### Possible investigation steps

**Identify the actor and access pathway**
- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
- Check whether the caller is:
  - A legitimate cross-account automation role,  
  - A compromised IAM user or workload identity, or  
  - A federated identity behaving outside of normal patterns.
- Inspect `user_agent.original` to determine whether the action came from the AWS Console, CLI, SDK, or unusual tooling.

**Analyze the encryption behavior**
- Inspect the dissected KMS key fields:
  - `Esql.aws_cloudtrail_request_parameters_kms_key_account_id`
  - `Esql.aws_cloudtrail_request_parameters_kms_key_id`
- Confirm whether the external key:
  - Belongs to an attacker-controlled account,  
  - Is unknown to your organization, or  
  - Lives in a shared or security tooling account.

**Assess the objects affected**
- Review:
  - `Esql.aws_cloudtrail_request_parameters_target_bucket_name`
  - `Esql.aws_cloudtrail_request_parameters_target_object_key`
- Identify:
  - Whether objects were overwritten or new encrypted copies were created.
  - The sensitivity or criticality of the affected data.
  - Whether object versioning is enabled (important for recovery).

**Correlate surrounding access patterns**
Pivot in CloudTrail on:
- The same access key ID  
- The same IAM principal  
- Affected bucket ARN  

Look for:
- `DeleteObject` or `DeleteObjects` calls (common in ransomware behavior)
- Mass enumeration prior to the event (`ListObjectsV2`, `GetObject`)
- Other impact-stage actions (`PutBucketPolicy`, `PutBucketAcl`, disabling logging)
- Attempts to encrypt additional objects in rapid succession

**Evaluate bucket permissions and exposure**
Review:
- S3 bucket policy changes
- IAM roles with `s3:PutObject` or `s3:PutObjectAcl` permissions
- Whether unintended cross-account `Principal` entries exist
- Whether the KMS key policy explicitly trusts your account or a foreign one

**Validate business justification**
- Confirm with storage, data engineering, or application teams whether:
  - Any migration, transformation, or backup workflows should be encrypting objects cross-account.
  - Scheduled jobs or CI/CD pipelines were operating at the time of the event.

### False positive analysis

- **Expected cross-account encryption**  
  Many organizations use centralized encryption accounts or shared security accounts. Validate:
  - Whether the KMS key account is part of your AWS Organization
  - Whether the workflow, role, or application is documented
  - Whether the principal routinely performs CopyObject operations

### Response and remediation

**Contain and prevent further impact**
- Immediately restrict S3 write access for the principal involved.
- If the KMS key is attacker-controlled, the impacted objects may be unrecoverable without versioning.
- If object versioning is disabled, enable it on the affected bucket to strengthen future resilience.

**Investigate scope and severity**
- Identify:
  - Additional objects encrypted using external keys
  - Related suspicious actions (delete, modify, exfiltration events)
  - Whether any ransom markers or unauthorized files were uploaded
- Validate whether the external KMS key grants *decrypt* permission back to the bucket owner (rare in attacker use).

**Recover and secure the bucket**
- Restore accessible previous versions if versioning is enabled.
- Revoke unauthorized access key pairs or session credentials.
- Audit bucket policies, ACLs, and IAM conditions (`aws:PrincipalArn`, `aws:SourceAccount`, `aws:SourceArn`).
- Tighten cross-account access controls:
  - Remove unintended `Principal` clauses
  - Restrict KMS usage to known accounts
  - Enforce SCPs that block cross-account KMS use unless explicitly approved

**Long-term hardening**
- Integrate object-level access logging and S3 server access logging into security monitoring.
- Add AWS Config rules (or Security Hub controls) detecting:
  - Public buckets
  - Cross-account access to S3
  - KMS policies permitting foreign principals
- Document required cross-account workflows and add explicit allowlists.

### Additional information

- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/",
    "https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/",
    "https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/",
    "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/",
]
risk_score = 47
rule_id = "ab8f074c-5565-4bc4-991c-d49770e19fc9"
setup = "AWS S3 data event types need to be enabled in the CloudTrail trail configuration for CopyObject events."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS S3",
    "Data Source: AWS KMS",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

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

// any successful S3 copy event
| where
  data_stream.dataset == "aws.cloudtrail"
  and event.provider == "s3.amazonaws.com"
  and event.action == "CopyObject"
  and event.outcome == "success"

// dissect request parameters to extract KMS key info and target object info
| dissect aws.cloudtrail.request_parameters
    "{%{?bucketName}=%{Esql.aws_cloudtrail_request_parameters_target_bucket_name},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{Esql.aws_cloudtrail_request_parameters_kms_key_account_id}:%{?key}/%{Esql.aws_cloudtrail_request_parameters_kms_key_id},%{?Host}=%{?tls.client.server.name},%{?x-amz-server-side-encryption}=%{?server_side_encryption},%{?x-amz-copy-source}=%{?bucket.object.name},%{?key}=%{Esql.aws_cloudtrail_request_parameters_target_object_key}}"

// detect cross-account key usage
| where cloud.account.id != Esql.aws_cloudtrail_request_parameters_kms_key_account_id

// keep ECS and dissected fields
| keep
  @timestamp,
  data_stream.namespace,
  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,
  Esql.aws_cloudtrail_request_parameters_target_bucket_name,
  Esql.aws_cloudtrail_request_parameters_target_object_key,
  Esql.aws_cloudtrail_request_parameters_kms_key_account_id,
  Esql.aws_cloudtrail_request_parameters_kms_key_id,
  _id,
  _version,
  _index
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1486"
name = "Data Encrypted for Impact"
reference = "https://attack.mitre.org/techniques/T1486/"


[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",
    "Esql.aws_cloudtrail_request_parameters_target_bucket_name",
    "Esql.aws_cloudtrail_request_parameters_target_object_key",
    "Esql.aws_cloudtrail_request_parameters_kms_key_account_id",
    "Esql.aws_cloudtrail_request_parameters_kms_key_id",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API
actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or
exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more
unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise
or automated secret harvesting.
"""
false_positives = [
    """
    Verify whether the user identity, user agent, and/or hostname should be using GetSecretValue or BatchGetSecretValue
    APIs for the specified SecretId. 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 Secrets Manager Rapid Secrets Retrieval"
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, validate and adapt it for your operational needs.

### Investigating AWS Secrets Manager Rapid Secrets Retrieval

AWS Secrets Manager stores sensitive credentials such as database passwords, API keys, OAuth tokens, and service 
configuration values. In credential compromise scenarios, attackers frequently attempt to retrieve as many secrets as 
possible in a short timeframe to escalate privileges or move laterally across the environment.

This threshold rule triggers when a single user identity successfully retrieves 20 or more unique secrets using 
`GetSecretValue` or `BatchGetSecretValue` within a short timespan. Retrieval of many different secrets in rapid succession is highly unusual and strongly associated with reconnaissance, secret harvesting, or compromised automation.

Note: `BatchGetSecretValue` API calls the `GetSecretValue` API for each secret value; this alert only captures the `GetSecretValue` calls rather than the `BatchGetSecretValue` call itself.

#### Possible investigation steps

- **Identify the user or role**
  - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `aws.cloudtrail.user_identity.type`.
  - Determine whether the identity normally accesses Secrets Manager or is tied to a known automation workload.

- **Analyze the set of secrets retrieved**
  - Expand the alert in Timeline and review `aws.cloudtrail.request_parameters` for all `SecretId` values in the grouped threshold event.
  - Identify whether the accessed secrets include:
    - Privileged database credentials  
    - IAM user or service account credentials  
    - Production application secrets  
    - Rarely accessed or high-sensitivity secrets  

- **Assess the runtime context**
  - Investigate `source.ip`, `source.geo.location`, and `user_agent.original`.
  - Validate whether the calls originated from known internal automation (e.g., ECS task, Lambda runtime, EC2 instance profile) 
    or from an unexpected IP or user agent.

- **Correlate with other activity from the same identity**
  - Look for related reconnaissance or credential-access events:
    - `ListSecrets`, `DescribeSecret`
    - IAM enumeration (`ListUsers`, `GetCallerIdentity`)
    - Role-chaining or unusual `AssumeRole` flows  
  - Check for subsequent use of exposed credentials (RDS login attempts, API activity, abnormal resource access).

- **Determine whether unusual automation or deployment activity is occurring**
  - Confirm with application owners whether a new deployment, config reload, or migration might explain the multi-secret access.

### False positive analysis

- Legitimate application initialization or rollouts may retrieve many secrets once on startup.
- CI/CD pipelines or configuration management tools may enumerate secrets as part of environment bootstrapping.

To reduce noise, consider exceptions based on:
- Known service roles  
- Expected source IP ranges  
- Specific application identities tied to secret orchestration  

### Response and remediation

- **Containment**
  - Immediately revoke or disable the IAM user, role session, or instance profile if compromise is suspected.
  - Quarantine EC2/ECS/Lambda resources originating suspicious calls.

- **Investigation**
  - Identify all secrets accessed in the grouped alert and determine where those credentials are used.
  - Review CloudTrail for any suspicious follow-on activity using the retrieved secrets.
  - Assess whether additional identities or workloads show similar enumeration behavior.

- **Recovery and hardening**
  - Rotate all accessed secrets and update dependent systems.
  - Rotate IAM access keys or temporary credentials for the impacted identity.
  - Restrict permissions to Secrets Manager following least privilege.
  - Review automation and application behavior to ensure secrets are accessed only when required.
"""
references = [
    "https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html",
    "https://detectioninthe.cloud/ttps/credential_access/access_secret_in_secrets_manager/",
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum",
]
risk_score = 47
rule_id = "185c782e-f86a-11ee-9d9f-f661ea17fbce"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Secrets Manager",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset: "aws.cloudtrail" 
    and event.provider: "secretsmanager.amazonaws.com" 
    and event.action: "GetSecretValue" 
    and event.outcome: "success" 
    and not (
        user_agent.name: ("Chrome" or "Firefox" or "Safari" or "Edge" or "Brave" or "Opera") 
        or source.address: ("kafka.amazonaws.com" or "apidestinations.events.amazonaws.com")
    )
'''


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

[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"

[[rule.threat.technique.subtechnique]]
id = "T1555.006"
name = "Cloud Secrets Management Stores"
reference = "https://attack.mitre.org/techniques/T1555/006/"

[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 = "T1213"
name = "Data from Information Repositories"
reference = "https://attack.mitre.org/techniques/T1213/"

[[rule.threat.technique.subtechnique]]
id = "T1213.006"
name = "Databases"
reference = "https://attack.mitre.org/techniques/T1213/006/"

[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"
[rule.threshold]
field = ["user.id"]
value = 1
[[rule.threshold.cardinality]]
field = "aws.cloudtrail.request_parameters"
value = 20

[metadata]
creation_date = "2025/09/18"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike", "auditd_manager"]
maturity = "production"
updated_date = "2026/04/07"

[rule]
author = ["Elastic"]
description = """
This rule detects the execution of TruffleHog, a tool used to search for high-entropy strings and secrets
in code repositories, which may indicate an attempt to access credentials. This tool was abused by the Shai-Hulud
worm to search for credentials in code repositories.
"""
false_positives = [
    """
    Trufflehog is a legitimate open-source tool used by security professionals and developers to search for sensitive
    information, such as passwords, API keys, and other secrets, within code repositories. It is commonly employed
    during security assessments and code reviews to identify potential vulnerabilities.
    """,
]
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*"
]
language = "eql"
license = "Elastic License v2"
name = "Credential Access via TruffleHog Execution"
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 Credential Access via TruffleHog Execution

This rule flags TruffleHog executed to scan the local filesystem with verified JSON results, a direct path to harvesting secrets from source code, configs, and build artifacts. Attackers gain shell access on a developer workstation or CI runner, clone or point to internal repositories, run 'trufflehog --results=verified --json filesystem .' to enumerate valid tokens, and then pivot using the recovered keys to pull private code or authenticate to cloud and CI/CD systems.

### Possible investigation steps

- Review binary path, code signature/hash, parent process chain, initiating user, and host role (developer workstation vs CI runner) to quickly decide if the execution matches an approved secret-scanning job or an ad‑hoc run.
- Determine the working directory and target path used by the scan to identify which repositories or configuration directories were inspected and whether sensitive files (e.g., .env, deployment keys, build secrets) were in scope.
- Pivot to same-session activity to spot credential use or exfiltration by correlating subsequent outbound connections to git remotes or cloud/CI APIs and launches of developer CLIs like git, gh, aws, az, gcloud, docker, kubectl, or vault.
- Look for output artifacts and exfil channels by checking for creation or deletion of JSON reports or archives, clipboard access, or piping of results to curl/wget/netcat and whether those artifacts were emailed or uploaded externally.
- Cross-check VCS and CI/CD audit logs for this identity and host for unusual pushes, pipeline changes, or new tokens issued shortly after the scan, which may indicate worm-like propagation or credential abuse.

### False positive analysis

- An approved secret-scanning task by a developer or security engineer runs trufflehog with --results=verified --json filesystem to audit local code and configuration, producing benign activity on a development host.
- An internal automation or scheduled job invokes trufflehog to baseline filesystem secrets for compliance or hygiene checks, leading to expected process-start logs without credential abuse.

### Response and remediation

- Immediately isolate the host or CI runner, terminate the trufflehog process and its parent shell/script, and block egress to git remotes and cloud APIs from that asset.
- Collect the verified findings from trufflehog output (stdout or JSON file), revoke and rotate any listed secrets (GitHub personal access tokens, AWS access keys, Azure service principal credentials, CI job tokens), and clear credential caches on the host.
- Remove unauthorized trufflehog binaries/packages, helper scripts, and scheduled tasks; delete report files and scanned working directories (local repo clones, .env/config folders), and purge shell history containing exfil commands like curl/wget/netcat.
- Restore the workstation or runner from a known-good image if tampering is suspected, re-enroll endpoint protection, reissue required developer or CI credentials with least privilege, and validate normal pulls to internal git and cloud services.
- Escalate to full incident response if trufflehog ran under a service account, on a build server/CI runner, or if any discovered secret was used to authenticate to external git remotes (e.g., github.com), cloud APIs, or private registries in the same session.
- Harden by blocking unapproved trufflehog execution via application control, moving approved secret scanning to a locked-down pipeline, enforcing short-lived PATs and key rotation, enabling egress filtering from developer hosts/runners, and deploying fleet-wide detections for "trufflehog --results=verified --json filesystem".
"""
references = [
    "https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise",
    "https://socket.dev/blog/shai-hulud-strikes-again-v2",
]
risk_score = 47
rule_id = "47595dea-452b-4d37-b82d-6dd691325139"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: Windows",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where event.type == "start" and process.name : ("trufflehog.exe", "trufflehog") and
process.args == "--json" and process.args == "filesystem"
'''

[[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 = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"

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

[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"

[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 = "T1005"
name = "Data from Local System"
reference = "https://attack.mitre.org/techniques/T1005/"

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

[metadata]
creation_date = "2025/05/23"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/03"

[rule]
author = ["Elastic"]
description = """
Detects modifications to the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an
unusual subject account. Attackers can abuse this attribute to inherit a target account's permissions and further
elevate privileges.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "Delegated Managed Service Account Modification by an Unusual User"
references = ["https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory"]
risk_score = 73
rule_id = "2c74e26b-dfe3-4644-b62b-d0482f124210"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Use Case: Active Directory Monitoring",
    "Data Source: Active Directory",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.code:5136 and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-ManagedAccountPrecededByLink"
'''

note = """## Triage and analysis

### Investigating Delegated Managed Service Account Modification by an Unusual User

#### Possible investigation steps

- What dMSA link did the alert record?
  - Focus: confirm 5136 with `winlog.event_data.AttributeLDAPDisplayName` "msDS-ManagedAccountPrecededByLink"; read `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, `winlog.event_data.AttributeValue`, and `winlog.event_data.OperationType` for dMSA, superseded account DN, and change type.
  - Implication: escalate when the link targets a privileged, sync, backup, or widely trusted service account, or the modified object is unexpected; lower suspicion only when object, link, and change type fit one low-impact migration pair.
- Did the controller operation look like bounded dMSA migration or direct link write?
  - Why: real migration should not be a lone sensitive attribute write; BadSuccessor risk rises when the link is isolated or paired with unrelated high-impact changes.
  - Focus: review same-controller 5136 changes by `winlog.event_data.OpCorrelationID`; compare `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. $investigate_0
  - Hint: if the operation ID is incomplete, query 5136 on `host.id` plus `winlog.event_data.SubjectLogonId` for same-session dMSA or privileged-object changes.
  - Implication: escalate on standalone link write, unexpected value replacement, or unrelated ACL, delegation, SPN, or service-account changes; lower suspicion when same-operation or same-session changes stay bounded to one expected migration pair.
- Who wrote the link, and does the identity fit dMSA management?
  - Focus: use `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name` to identify writer, controller session, and service vs human.
  - Implication: escalate when the writer is an unfamiliar human, helpdesk account, or low-privilege service identity for dMSA management; keep unresolved when a recognized writer is not tied to the exact dMSA pair.
- Did the writer session originate from an expected source and logon type?
  - Focus: pivot from `winlog.event_data.SubjectLogonId` and `host.id` to authentication where `winlog.event_data.TargetLogonId` matches; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. $investigate_1
  - Hint: search 4648 on `winlog.event_data.SubjectLogonId` for explicit-credential use; missing authentication records or `source.ip` are unresolved, not benign.
  - Implication: escalate when the session starts from an unexpected host, uses unusual interactive/RDP logon, or shows explicit-credential behavior outside the writer's role; expected source and logon type support closure only after link target and operation cohere.
- Did the linked dMSA or superseded account authenticate from unexpected systems after the change?
  - Why: risk peaks when the new dMSA relationship is exercised from hosts that should not use the inherited service account.
  - Focus: derive dMSA and superseded account names from `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue`, then review authentication by `winlog.event_data.TargetUserName`, `source.ip`, and `winlog.logon.type`.
  - Hint: missing authentication telemetry is unresolved, not benign; an unused link still needs disposition from link target, writer, and sequence.
  - Implication: escalate when either account authenticates from a new host, admin workstation, or service path after the change; unchanged or absent use does not clear suspicion.
- If still suspicious or unresolved, do recent writer or dMSA alerts show broader abuse?
  - Focus: review recent alerts for modifying `user.id`, then modified `winlog.event_data.ObjectGUID`. $investigate_2
  - Hint: use object alerts for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the dMSA. $investigate_3
  - Implication: escalate and widen scope when either alert set shows privilege abuse, directory tampering, or suspicious authentication; keep scope local when both are quiet and local evidence is the only unresolved signal.
- What disposition fits?
  - Weigh link target, operation, writer/session, follow-on use, and related alerts: escalate on high-value link, incoherent operation, unexpected writer/session, new use, or AD abuse; close only when all evidence proves one exact migration; mixed/incomplete evidence -> preserve directory-change and session records, then escalate.

### False positive analysis

- Planned dMSA migration by identity/service-account admins may set "msDS-ManagedAccountPrecededByLink". Confirm `winlog.event_data.ObjectDN`, planned `winlog.event_data.AttributeValue`, paired `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` match migration account/host path. Telemetry-only closure requires anchors proving one bounded migration; otherwise require records, tickets, or identity-admin confirmation for the exact dMSA pair and writer. Do not close from recurrence or role assumptions.
- Lab validation or staged service-account modernization may trigger. Confirm `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue` stay in the authorized test/staging OU, session avoids unrelated privileged objects, and follow-on `winlog.event_data.TargetUserName` or `source.ip` is limited to test hosts. Telemetry-only closure requires test OU, writer, bounded change set, and follow-on hosts proving lab scope; otherwise require test records or lab owner confirmation.
- Before exception, confirm the exact workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeValue`, bounded `winlog.event_data.OpCorrelationID`, and recovered controller or source path. Use exceptions only when that verified workflow should repeat; avoid exceptions on the attribute, 5136, or all dMSA changes.

### Response and remediation

- If confirmed benign, reverse containment and record: writer SID, dMSA DN, superseded account DN, bounded sequence, recovered source path, and external confirmation for the change. Create an exception only when that workflow should repeat.
- If suspicious but unconfirmed, export the triggering 5136 record, same-operation change sequence, writer-session auth records, explicit-credential evidence, and related alerts before destructive changes. Apply reversible containment first: restrict the recovered source host from domain controllers or monitor the writer, modified dMSA, and superseded account. Disable the writer or isolate the source host only if additional privileged changes, unexpected follow-on authentication, or related alerts appear.
- If confirmed malicious, preserve directory-change and session evidence first, then use endpoint response to isolate the recovered source host and disable/reset the malicious dMSA, compromised writer, and affected superseded service account. If endpoint response is unavailable on the source system, escalate with preserved `source.ip`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, and related 5136, 4624, or 4648 evidence to responders. Review hosts/services that used the same superseded account or new dMSA before cleanup, verify rollback replication across domain controllers, and only then remove the unauthorized `winlog.event_data.AttributeValue` link, roll back related migration/SPN/delegation changes in the same `winlog.event_data.OpCorrelationID` sequence, and rotate affected secrets or restore service bindings.
- Post-incident hardening: restrict dMSA creation/migration rights, verify domain-controller retention for 5136, 4624, and 4648, and record the migration workflow or BadSuccessor evidence for reuse.
"""

setup = """## Setup

Audit Directory Service Changes must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-directory-service-changes
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.code",
    "winlog.event_data.SubjectUserName",
    "winlog.event_data.SubjectUserSid",
    "winlog.event_data.SubjectDomainName",
    "winlog.event_data.SubjectLogonId",
    "winlog.event_data.ObjectDN",
    "winlog.event_data.ObjectGUID",
    "winlog.event_data.ObjectClass",
    "winlog.event_data.AttributeLDAPDisplayName",
    "winlog.event_data.AttributeValue",
    "winlog.event_data.OperationType",
    "winlog.event_data.OpCorrelationID",
    "host.id",
    "winlog.computer_name",
]

[transform]

[[transform.investigate]]
label = "Directory changes for the same operation on this controller"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.OpCorrelationID", queryType = "phrase", value = "{{winlog.event_data.OpCorrelationID}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Authentication events for the writer session on this controller"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the source account"
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" }
  ],
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

[rule.new_terms]
field = "new_terms_fields"
value = ["winlog.event_data.SubjectUserName"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[[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.002"
name = "Domain Accounts"
reference = "https://attack.mitre.org/techniques/T1078/002/"

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

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

[rule]
description = """
Identifies attempts to hook the Sleep function. This may indicate an attempt to evade detection by tampering the normal
behavior of this function to obfuscate the malware content in memory while sleeping.
"""
id = "a4e1883e-e203-4b65-9cb0-b582081b0bf8"
license = "Elastic License v2"
name = "Evasion via Sleep API Hooking"
os_list = ["windows"]
version = "1.0.6"

query = '''
api where process.Ext.api.name in ("WriteProcessMemory", "VirtualProtect", "VirtualProtectEx") and
 process.Ext.api.metadata.target_address_name == "kernel32.dll!Sleep" and
 process.Ext.token.integrity_level_name != "low" and
 not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true and
                  $entry.subject_name in ("FireEye, Inc.", "Sophos Ltd", "Microsoft Windows Hardware Compatibility Publisher", "Microsoft Windows Software Compatibility Publisher", "Trend Micro, Inc.", "Symantec Corporation", "Bitdefender SRL", "Carbon Black, Inc.")) and
 not process.thread.Ext.call_stack_final_user_module.protection_provenance like ("Kernel", "Kernel|*") and
 not _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: "c:\\windows\\system32\\kernel32.dll!ExitProcess*") and
 not process.thread.Ext.call_stack_final_user_module.name in ("Kernel", "Unknown", "Undetermined") and 
 not process.thread.Ext.call_stack_final_user_module.hash.sha256 in
                  ("d0fe1eecad868460c162fd40cacf2ac954008b2de1234b2d1cd3b1e361f5e6c0",
                   "e376f3c42c5806ccc2f9051db611d14057444dd6012b0a80f5e50aeea7a4d97a",
                   "c7d4e4d82e5d9b326c05e968c7236daf4ddefe35060049e079bf51910f81996e",
                   "519ee50c16137e1b1643a2b726cd34fff876719692cd37e06f08546ee44285e8",
                   "854156e019372fbf49b7d6f7278a05a74f0e41572572ca6beeb2dca672e53270")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"


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

[internal]
min_endpoint_version = "8.10.0"

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

[rule]
author = ["Elastic"]
description = """
Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use
WSL for Linux to avoid detection.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Execution via Windows Subsystem for Linux"
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 Execution via Windows Subsystem for Linux

Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion.

### Possible investigation steps

- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables.
- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks.
- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised.
- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host.
- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or SentinelOne to identify any related suspicious activities or patterns.
- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly.

### False positive analysis

- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL.
- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts.
- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives.
- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations.
- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list.
- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations.
- Remove any unauthorized or malicious scripts and binaries found within the WSL environment.
- Restore the system from a known good backup if malicious activity has compromised system integrity.
- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
references = ["https://learn.microsoft.com/en-us/windows/wsl/wsl-config"]
risk_score = 47
rule_id = "db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
    "Data Source: Sysmon",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type : "start" and process.command_line != null and
  process.parent.name : ("wsl.exe", "wslhost.exe") and
  not process.executable : (
        "?:\\Program Files (x86)\\*",
        "?:\\Program Files\\*",
        "?:\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe",
        "?:\\Windows\\System32\\conhost.exe",
        "?:\\Windows\\System32\\lxss\\wslhost.exe",
        "?:\\Windows\\System32\\WerFault.exe",
        "?:\\Windows\\System32\\wsl.exe",
        "?:\\Windows\\Sys?????\\wslconfig.exe"
  ) and
  not (
    /* Crowdstrike specific exclusion as it uses NT Object paths */
    (data_stream.dataset == "crowdstrike.fdr" or event.action == "ProcessRollup2") and
      process.executable : (
        "\\Device\\HarddiskVolume*\\Program Files (x86)\\*",
        "\\Device\\HarddiskVolume*\\Program Files\\*",
        "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe",
        "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe",
        "\\Device\\HarddiskVolume*\\Windows\\System32\\lxss\\wslhost.exe",
        "\\Device\\HarddiskVolume*\\Windows\\System32\\WerFault.exe",
        "\\Device\\HarddiskVolume*\\Windows\\System32\\wsl.exe",
        "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\wslconfig.exe"
      )
  ) and
  not (
    (process.name : "cmd.exe" and process.command_line : "*echo*%USERPROFILE%*") or
    (process.name : "git.exe" and process.command_line : "git.exe -c log.*") or
    (process.name : "powershell.exe" and process.command_line : "powershell.exe -Command $env:USERPROFILE") or
    (process.name : "Code.exe" and process.command_line : ("*cli.js --folder-uri=vscode-remote://wsl*", "ms-vscode-remote.remote-wsl"))
  )
'''

setup = """## Setup

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

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

### Additional data sources

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

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


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

[[rule.threat.technique]]
id = "T1202"
name = "Indirect Command Execution"
reference = "https://attack.mitre.org/techniques/T1202/"

[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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

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

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

[rule]
description = """
Identifies attempts to enumerate the state of keyboard keys by an unusual process. Adversaries may log user keystrokes
to intercept credentials or other information from the user as the user types them.
"""
id = "ef0a2322-641b-4127-8b48-2def55fe1f1f"
license = "Elastic License v2"
name = "GetAsyncKeyState API Call from Suspicious Process"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1056/001/",
    "https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getasynckeystate",
    "https://www.elastic.co/security-labs/protecting-your-devices-from-information-theft-keylogger-protection",
]
version = "1.0.5"

query = '''
sequence by process.entity_id with maxspan=5m
 [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 <= 500 and (process.code_signature.trusted == false or process.code_signature.exists == false)) or
   process.name in~ ("rundll32.exe", "regsvr32.exe", "powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe") or
   process.pe.original_file_name : ("python*.exe", "AutoIt*.exe") or
   (process.Ext.relative_file_creation_time <= 500 and
    process.executable :
                ("?:\\Users\\Public\\*",
                 "?:\\Users\\*\\Downloads\\*",
                 "?:\\Windows\\Temp\\*",
                 "?:\\Windows\\Tasks\\*",
                 "?:\\ProgramData\\*",
                 "?:\\Windows\\Microsoft.NET\\*")) or
    process.executable : ("?:\\Users\\*\\AppData\\Local\\Temp\\7z*\\",
                         "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*\\*",
                         "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*\\*",
                         "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*") or
   (process.parent.name : "svchost.exe" and process.parent.args : "Schedule")
  ) and
  not process.executable :
              ("?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe",
              "?:\\Program Files (x86)\\*.exe",
              "?:\\Program Files\\*.exe") and
  not (process.name : "rundll32.exe" and process.args : "C:\\Windows\\System32\\LogiLDA.dll,LogiFetch")
  ]
 [api where process.Ext.api.name == "GetAsyncKeyState" and
   process.Ext.api.metadata.background_callcount >= 400 and process.Ext.api.metadata.ms_since_last_keyevent >= 100 and 
   not (process.executable : "?:\\Windows\\System32\\rundll32.exe" and 
        process.command_line : "\"?:\\Windows\\System32\\rundll32.exe\" C:\\Windows\\System32\\LogiLDA.dll,LogiFetch" and 
        process.thread.Ext.call_stack_summary == "win32u.dll|winsrvext.dll|ntdll.dll")]
'''

min_endpoint_version = "8.12.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 = "T1056"
name = "Input Capture"
reference = "https://attack.mitre.org/techniques/T1056/"
[[threat.technique.subtechnique]]
id = "T1056.001"
name = "Keylogging"
reference = "https://attack.mitre.org/techniques/T1056/001/"



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

[internal]
min_endpoint_version = "8.12.0"

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

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Access to private GitHub organization resources was revoked for a PAT.\n"
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "GitHub PAT Access Revoked"
risk_score = 21
rule_id = "8a0fd93a-7df8-410d-8808-4cc5e340f2b9"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Impact",
    "Rule Type: BBR",
    "Data Source: Github",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
configuration where event.dataset == "github.audit" and event.action == "personal_access_token.access_revoked"
'''


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


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

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

[rule]
author = ["Elastic"]
description = """
Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques.
Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded.
"""
false_positives = [
    """
    Some platform or security images legitimately require elevated capabilities. Add image or namespace exceptions after
    review.
    """,
]
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Container Created with Excessive Linux Capabilities"
note = """## Triage and analysis

### Investigating GKE Container Created with Excessive Linux Capabilities

Capabilities such as SYS_ADMIN, NET_ADMIN, and BPF can enable host escape. Review `gcp.audit.request.spec.containers`
and the creating identity.

### Investigation steps

- Confirm which capability was added and whether the image requires it.
- Review `user.email`, namespace, and follow-on API activity from the same actor.

### False positives

- Known DaemonSet or operator images may need capabilities; exclude after validation.

## Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
references = [
    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container",
    "https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities",
]
risk_score = 47
rule_id = "a8a48752-58f3-43a9-beb5-14b9e9f6a8b0"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and
gcp.audit.request.spec.containers.securityContext.capabilities.add:(
  "BPF" or "DAC_READ_SEARCH" or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO" or
  "SYSLOG"
) and not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet")
'''

[[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 = "T1610"
name = "Deploy Container"
reference = "https://attack.mitre.org/techniques/T1610/"

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

[metadata]
creation_date = "2026/02/04"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions,
such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable
privilege escalation or unauthorized access within the cluster.
"""
language = "esql"
license = "Elastic License v2"
name = "Kubernetes Creation or Modification of Sensitive Role"
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 Kubernetes Creation or Modification of Sensitive Role

This rule detects allowed create, update, or patch actions on Roles and ClusterRoles that introduce high-risk RBAC permissions, including wildcard access and escalation verbs like bind, escalate, or impersonate. These changes matter because they can silently expand privileges and enable persistence or lateral movement across the cluster. Attackers commonly add a new ClusterRole with `*` verbs/resources and then use it to bind themselves or a service account to cluster-admin–equivalent access.

### Possible investigation steps

- Identify the responsible identity and origin by reviewing the audit event’s user/service account, userAgent, and source IPs, then confirm whether the action came from approved automation (e.g., GitOps/CI) or an interactive session.  
- Retrieve and diff the Role/ClusterRole manifest before vs after the change to pinpoint newly added wildcards, escalation verbs (bind/escalate/impersonate), or permissions over RBAC resources that enable privilege escalation.  
- Enumerate RoleBindings/ClusterRoleBindings that reference the modified role and determine which users/groups/service accounts gained effective permissions, prioritizing bindings created/changed near the same time.  
- Validate authorization intent by correlating the change with a change ticket/PR and the expected namespace/cluster scope, and flag any out-of-band edits (kubectl apply/edit) that bypass the normal workflow.  
- If suspicious, contain by reverting the role and removing or disabling newly privileged bindings/subjects, then hunt for follow-on activity from the same identity (e.g., creation of new service accounts, secrets access, or additional RBAC changes) within the incident window.

### False positive analysis

- Cluster administrators or platform automation legitimately create or update Roles/ClusterRoles to include wildcard verbs/resources or escalation-related verbs (bind/escalate/impersonate) during initial cluster bootstrapping, feature enablement, or maintenance, especially when enabling broad operational access for system components.  
- Routine RBAC refactoring such as consolidating multiple granular roles into a single reusable role, migrating permissions across namespaces, or adjusting access for incident response can temporarily add permissions over RBAC resources (roles/rolebindings/clusterroles/clusterrolebindings) and trigger the rule even when the change is approved and tracked.

### Response and remediation

- Immediately locate and quarantine the changed Role/ClusterRole by reverting it to the last known-good manifest (from Git/GitOps) or deleting it if unauthorized, and remove any new RoleBinding/ClusterRoleBinding subjects that reference it.  
- Contain the actor by disabling or rotating credentials for the responsible user/service account (and its tokens), and if the change came from a workload, isolate the namespace/workload (scale down, deny egress) until provenance is confirmed.  
- Eradicate persistence by searching for and removing additional RBAC changes made in the same window (new roles, bindings, service accounts) and by revoking any newly granted access to secrets or cluster-scoped resources discovered during review.  
- Recover by redeploying RBAC from a controlled pipeline, validating effective permissions for impacted subjects, and monitoring for re-creation of the same role name or re-binding attempts after rollback.  
- Escalate to platform security/incident response immediately if the role grants wildcard permissions, includes `impersonate`/`escalate`/`bind`, is cluster-scoped, or is bound to non-admin subjects or external identities without an approved change record.  
- Harden by enforcing RBAC guardrails (OPA Gatekeeper/Kyverno policies blocking wildcard/escalation verbs except for approved groups), restricting who can create/update RBAC objects, and requiring all RBAC changes to flow through code review and signed GitOps automation.
"""
references = [
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
]
risk_score = 47
rule_id = "0fb25791-d8d4-42ab-8fc7-4954642de85f"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version
| WHERE
  kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and
  kubernetes.audit.verb in ("create", "update", "patch") and
  `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and
  kubernetes.audit.level == "RequestResponse" and kubernetes.audit.stage == "ResponseComplete" and
  not kubernetes.audit.sourceIPs in ("::1", "127.0.0.1") and 
  not (user.name like "eks:*" and kubernetes.audit.objectRef.name like "eks:*") and 
  not (user.name == "aksService" and event.action == "create" and kubernetes.audit.objectRef.name like "aks:*") and 
  not (user.name == "system:serviceaccount:kube-system:clusterrole-aggregation-controller" and  kubernetes.audit.objectRef.name in ("admin", "edit") and event.action == "patch") and 
  (
    // using requestObject
    KQL(""" kubernetes.audit.requestObject.rules.verbs:("*" or "escalate" or "bind" or "impersonate") """) or 
    KQL(""" kubernetes.audit.requestObject.rules.verbs: ("*" or "create" or "patch" or "update") and kubernetes.audit.requestObject.rules.resources:("*" or "clusterroles" or "clusterrolebindings" or "roles" or "rolebindings" or "pods/exec" or "serviceaccounts/token" or "nodes/proxy" or "daemonsets") """) or 
    KQL(""" kubernetes.audit.requestObject.rules.verbs: ("*" or "get" or "list") and kubernetes.audit.requestObject.rules.resources:("*" or "secrets") """) or

    // using responseObject
    KQL(""" kubernetes.audit.responseObject.rules.verbs:("*" or "escalate" or "bind" or "impersonate") """) or 
    KQL(""" kubernetes.audit.responseObject.rules.verbs: ("*" or "create" or "patch" or "update") and kubernetes.audit.responseObject.rules.resources:("*" or "clusterroles" or "clusterrolebindings" or "roles" or "rolebindings" or "pods/exec" or "serviceaccounts/token" or "nodes/proxy" or "daemonsets") """) or 
    KQL(""" kubernetes.audit.responseObject.rules.verbs: ("*" or "get" or "list") and kubernetes.audit.responseObject.rules.resources:("*" or "secrets") """)
  )
| keep user.name, user_agent.original, event.action, source.ip, kubernetes.audit.verb, kubernetes.audit.objectRef.resource, kubernetes.audit.objectRef.name, kubernetes.audit.requestURI, kubernetes.audit.user.username, kubernetes.audit.user.groups, `kubernetes.audit.annotations.authorization_k8s_io/decision`, event.original, _id, _version, _index, data_stream.namespace
'''

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

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

[metadata]
creation_date = "2026/04/22"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/08/18"

[rule]
author = ["Elastic"]
description = """
Kubernetes audit identities for kubelet (system:node:*) and workloads (system:serviceaccount:*) are meant to
operate with tight, predictable API usage. Direct get or list on the Secrets API from those principals is
often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for
tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to
reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable
when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at
all).
"""
false_positives = [
    """
    In-cluster operators, CSI drivers, GitOps agents, and some platform controllers legitimately list or get Secrets in
    namespaces they manage; exclude known service accounts, namespaces, or user agents after baselining.
    """,
    """
    Rare kubelet or node maintenance tooling may touch Secret APIs; validate against change windows and approved node
    management paths.
    """,
]
index = ["logs-kubernetes.audit_logs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Kubernetes Secret Get or List from Node or Pod Service Account"
note = """## Triage and analysis

### Investigating Kubernetes Secret Get or List from Node or Pod Service Account

This rule fires on Kubernetes audit events where the authenticated user is a node (`system:node:<nodename>`) or a
pod service account (`system:serviceaccount:<namespace>:<name>`) and the verb maps to read-style access
(`get`, `list`) on the **secrets** resource. Treat node-originated secret reads as high priority: kubelet should
not broadly enumerate cluster secrets. For service accounts, prioritize cross-namespace access, access to
high-value secret names, and clients that do not match the workload’s normal user agent or deployment.

### Possible investigation steps

- Resolve `user.name` (or `kubernetes.audit.user.username` if present) to the node or workload and review RBAC
  RoleBindings and ClusterRoleBindings for secret `get`/`list` scope.
- Inspect `kubernetes.audit.objectRef.namespace`, `kubernetes.audit.objectRef.name`, source IP, and
  `user_agent.original` for automation you recognize versus anomalous scripts or generic HTTP clients.
- Review `kubernetes.audit.annotations.authorization_k8s_io/decision` for successful reads versus probing denials.
- Correlate with pod exec, token creation, RoleBinding changes, or secret modification in the same time window.

### False positive analysis

- Controllers that reconcile Secrets (e.g. cert-manager, external-secrets, sealed-secrets) may match; allowlist their
  service accounts if behavior is expected and scoped.
- Helm and package managers can list release secrets during deploys; correlate with pipelines and chart releases.

### Response and remediation

- If malicious, revoke the token or node credentials, cordon or isolate the host or workload, rotate exposed secrets, and
  tighten RBAC to least privilege for the affected identity.
"""
references = [
    "https://attack.mitre.org/techniques/T1552/007/",
    "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens",
]
risk_score = 47
rule_id = "f8a31c62-0d4e-4b9a-b7e1-6c2a9d4e8f10"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Data Source: Kubernetes API Server Audit Logs",
    "Domain: Kubernetes",
    "Platform: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"kubernetes.audit_logs" and
event.action:(get or list) and
kubernetes.audit.objectRef.resource:"secrets" and
user.name:(system\:serviceaccount\:* or system\:node\:*) and source.ip:(* and not "127.0.0.1") and 
not kubernetes.audit.user.groups:(
  "system:serviceaccounts:flux-system"
  or "system:serviceaccounts:kyverno"
  or "system:serviceaccounts:ibm-csi"
  or "system:serviceaccounts:harvester-system"
  or "system:serviceaccounts:cattle-system"
  or "system:serviceaccounts:cattle-monitoring-system"
  or system\:serviceaccounts\:cluster-fleet-local-local-*
  or "system:serviceaccounts:rabbitmq-system"
  or "system:serviceaccounts:cattle-fleet-system"
) and 
not (kubernetes.audit.user.username:"system:serviceaccount:security:trivy-operator" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name :trivy-operator-*) and 
not (kubernetes.audit.user.username:"system:serviceaccount:cert-manager:cert-manager-cainjector" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:cert-manager-cainjector-*) and 
not (kubernetes.audit.user.username:"system:serviceaccount:monitoring:plat-central-monitoring-pr-operator" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:plat-central-monitoring-pr-operator*) and 
not (kubernetes.audit.user.username:"system:serviceaccount:cert-manager:cert-manager" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:cert-manager-*)
'''

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

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

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

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