Elastic rules: 3d

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

[rule]
author = ["Elastic"]
description = """
Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy
and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may
access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy
granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable
cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for
principal ownership and least-privilege intent.
"""
false_positives = [
    """
    Resource policy changes may be performed by administrators, infrastructure-as-code pipelines, or automation during
    legitimate onboarding, sharing, or access-management activities. Verify whether the user identity, user agent, and
    source IP are expected to manage Bedrock resource policies in your environment. Known automation can be exempted
    from the rule.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Resource-Based Policy Modified or Deleted"
note = """## Triage and analysis

### Investigating AWS Bedrock Resource-Based Policy Modified or Deleted

AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents,
knowledge bases, and custom models. Adversaries can attach a policy that grants an external principal
access for persistence or cross-account access, or delete a policy to break existing access controls. This
rule detects successful `PutResourcePolicy` and `DeleteResourcePolicy` calls against the Bedrock control
plane.

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`,
    `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`.
  - Confirm the identity is expected to manage Bedrock resource policies and that a related change request
    exists.
- **Validate the policy change**
  - For `PutResourcePolicy`, inspect `aws.cloudtrail.request_parameters` and
    `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the policy document.
    Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles.
  - For `DeleteResourcePolicy`, determine which resource lost its policy and whether that resource should
    have remained restricted.
- **Correlate activity**
  - Look for related Bedrock actions (model invocation, agent updates, knowledge base access) from the same
    identity or the newly granted principal.
  - Check for prior enumeration of Bedrock resources or other recent IAM/resource-policy changes.

### False positive analysis

- **Planned access management**: Legitimate sharing or onboarding may add or remove resource policies.
  Validate against change tickets and standard templates.
- **Automation**: IaC or platform pipelines may set or remove resource policies during deployment. Confirm
  the actor matches known automation infrastructure.

### Response and remediation

- If the change is unauthorized, revert the resource policy to its approved state and remove any external
  or overly permissive principals.
- Disable or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is
  suspected.
- Review all Bedrock and IAM activity from the same identity in the surrounding time window for further
  access grants or persistence.
- Restrict `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy` to administrative roles and
  enforce least-privilege resource policies.
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html"
]
risk_score = 47
rule_id = "de0e9ed8-b68f-4249-957a-2c2bbdbd1c1b"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail" and
    event.provider: "bedrock.amazonaws.com" and
    event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and
    event.outcome: "success"
'''


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

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

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

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

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2025/06/10"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true.
"""
false_positives = [
    """
    There is no known legitimate reason for padding policies with white spaces to the extent it would take to trigger Cloudtrail's logging constraints. Any instance of this should be investigated.
    """,
]
from = "now-6m"
interval = "5m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS CloudTrail Log Evasion"
note = """## Triage and analysis

### Investigating AWS CloudTrail Log Evasion

Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your Amazon Web Services infrastructure. In the `requestParameters` field of CloudTrail logs, a policy that was created/updated is typically displayed, including details such as the policy name and the full policy document content. However, when policies padded with large amounts of insignificant whitespace (such as spaces, tabs, or line breaks), reach a size range of 102,401 to 131,072 characters they begin to be omitted from CloudTrail logs and are instead rendered as "requestParameters too large". Attackers can do this to cover their tracks and impact security monitoring that relies on this source. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true.

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Investigate other alerts associated with the user account during the past 48 hours.
- Contact the account and resource owners and confirm whether they are aware of this activity.
- Check if this operation was approved and performed according to the organization's change management policy.
- Considering the source IP address and geolocation of the user who issued the command:
    - Do they look normal for the user?
    - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
    - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
- Examine the newly created or modified policy.
- If no policy name is included for event.actions like `PutRolePolicy`, analyze the inline policies attached for unexpected permission changes or additions.
- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.

### False positive analysis

- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions. However, this behavior is rarely seen in legitimate operations and should be thoroughly investigated. 

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
- Consider enabling multi-factor authentication for users.
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS.
- Take the actions needed to return affected systems, data, or services to their normal operational levels.
- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://permiso.io/blog/cloudtrail-logging-evasion-where-policy-size-matters",
]
risk_score = 47
rule_id = "9ebd48ac-a0e2-430a-a219-fe072a50146b"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Log Auditing",
    "Resources: Investigation Guide",
    "Tactic: Defense Evasion",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: aws.cloudtrail and event.provider: iam.amazonaws.com and aws.cloudtrail.flattened.request_parameters.reason: "requestParameters too large" and aws.cloudtrail.flattened.request_parameters.omitted : true and event.outcome: success
'''

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[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/"

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

[rule]
author = ["Elastic"]
description = """
Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server
and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following
compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare
and should align with approved maintenance or cost optimization workflows.
"""
false_positives = [
    """
    Legitimate changes to EKS logging configuration during cluster provisioning, troubleshooting, or cost optimization
    may match. Validate the caller identity and change records, and baseline expected automation roles.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EKS Control Plane Logging Disabled"
note = """## Triage and analysis

### Investigating AWS EKS Control Plane Logging Disabled

Review the caller (user.name, aws.cloudtrail.user_identity.arn, type), source.ip, user_agent.original, cloud.account.id, and cloud.region. Confirm which log types were disabled and whether the change aligns with a planned change window.

### Possible investigation steps

- Inspect aws.cloudtrail.request_parameters and response elements for cluster name and logging settings.
- Correlate with adjacent EKS and IAM activity from the same principal (access entry changes, iam policy attachments, sts assume events) and with any Kubernetes audit telemetry available.
- Check whether control plane logs stopped ingesting shortly after the change and scope potential visibility gaps.

### Response and remediation

- If unauthorized, re-enable EKS control plane logging and restrict IAM permissions that allow eks:UpdateClusterConfig.
- Rotate or revoke compromised credentials and review for additional EKS or IAM persistence changes.
"""
references = [
    "https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html",
    "https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html",
]
risk_score = 73
rule_id = "0f189343-dac7-4c1b-aca7-be8baa6bd02b"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"aws.cloudtrail" and
event.provider:"eks.amazonaws.com" and
event.action:"UpdateClusterConfig" and
event.outcome:"success" and
aws.cloudtrail.request_parameters:*logging*enabled=false*
'''

[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 = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

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

[metadata]
creation_date = "2025/11/13"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/30"

[rule]
author = ["Elastic"]
description = """
Identifies the presence of Unicode modifier letters in the process command_line. Adversaries sometimes replace ASCII
characters with visually similar Unicode modifier letters to evade simple string-based detections.
"""
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 = "Command Obfuscation via Unicode Modifier Letters"
references = ["https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation"]
risk_score = 73
rule_id = "37148ae6-c6ec-4fe4-88b1-02f40aed93a9"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  (
    process.name : (
      "reg.exe", "net.exe", "net1.exe", "certutil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe",
      "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EXE",
      "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump.exe", "ntdsutil.exe",
      "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE",
      "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe"
    ) or
    ?process.pe.original_file_name in (
      "reg.exe", "net.exe", "net1.exe", "CertUtil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe",
      "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EXE",
      "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump", "ntdsutil.exe",
      "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE",
      "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe"
    )
 ) and
 process.command_line regex """.*[ʰ-˿ᴬ-ᶻ]+.*"""
'''

note = """## Triage and analysis

### Investigating Command Obfuscation via Unicode Modifier Letters

#### Possible investigation steps

- What did the raw modifier-letter command hide after ASCII normalization?
  - Focus: raw `process.command_line` and modifier-letter code points in `U+02B0-U+02FF` or `U+1D2C-U+1D7B`.
  - Hint: preserve the raw string, view code points, then compare with NFKC or ASCII-folded rendering; visual review can miss modifier letters a Windows utility may parse as ASCII.
  - Implication: escalate when normalization reveals a behavior-changing verb, flag, URL, path, or target; lower suspicion when characters remain in localized names, package names, or path text and behavior is unchanged.

- What operational intent does the normalized command express?
  - Focus: normalized `process.command_line`, `process.name`, and the hidden verb, option, URL, path, or target after ASCII normalization.
  - Hint: map the hidden token to the utility family: "urlcache" or remote retrieval for certutil/bitsadmin/curl/wget, "encodedcommand" or script execution for PowerShell/cmd/script hosts, add/create/delete for reg/sc/schtasks, shadow/log deletion for vssadmin/wevtutil, and dump/export for procdump/ntdsutil. Treat paired quote insertion or shorthand options as adjacent obfuscation on the same decision path.
  - Implication: escalate when the normalized token enables high-risk utility behavior; lower suspicion when it remains read-only status, inventory, or installer activity fitting the same process context.

- Is the utility identity consistent with the normalized behavior?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
  - Implication: escalate when the binary is renamed, user-writable, unsigned/untrusted, mismatched to its original file name, or new for the host; lower suspicion when a signed, stable utility path fits the normalized behavior. Identity alone never clears obfuscation.

- Does the launch and session context explain why this utility received obfuscated text?
  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `process.Ext.token.elevation_level`, and the `user.id` / `host.id` cohort.
  - Implication: escalate when a document, browser, archive tool, script host, unexpected interactive user, remote session, or unexplained service chain introduces the command; lower suspicion when a recognized management, installer, or testing launcher runs the same unchanged pattern under the expected account and host cohort.

- Did the obfuscated process launch follow-on process activity?
  - Focus: child process starts on the same `host.id` where `process.parent.entity_id` matches alert `process.entity_id`; read child `process.name`, `process.executable`, and `process.command_line`. $investigate_0
  - Hint: inspect same-process file, network, or registry activity for utility effects without child processes. $investigate_1 Missing network telemetry is unresolved, not benign. If `process.entity_id` is absent, pivot with `host.id`, alert `process.pid`, child `process.parent.pid`, and a tight alert window.
  - Implication: escalate when child activity shows shells, script hosts, installers, remote clients, credential tools, service/task utilities, or cleanup commands matching normalized intent; lower suspicion when no suspicious child follows and the normalized command fits the local workflow.

- If local evidence is suspicious or unresolved, does related alert history change scope?
  - Focus: related alerts for the same `host.id`, using the strongest local suspicious anchor: normalized command fragment, modifier-letter sequence, utility identity, or parent launcher. $investigate_2
  - Hint: if host history does not explain the activity, compare related alerts for the same `user.id` with the same anchors. $investigate_3
  - Implication: broaden containment when the same obfuscation pattern appears across unrelated hosts or users; keep local when the pattern stays confined to one confirmed workflow and process evidence has no contradiction.

- Based on command meaning, utility identity, lineage/session, follow-on processes, and scope, what disposition is supported?
  - Implication: escalate when normalization changes behavior and identity, lineage, child-process, or scope evidence supports abuse; close only when normalized meaning is unchanged or clearly benign and every process-context category fits one exact workflow; preserve raw command evidence and escalate when evidence is mixed or incomplete.

### False positive analysis

- Localized product names, internationalized paths, user-supplied file names, vendor installers, deployment frameworks, or internal admin tools can introduce non-ASCII package names or paths. Confirm only when normalization leaves behavior unchanged, modifier letters sit in content rather than a verb or flag, utility identity and parent command line match one recognized workflow, and `user.id` plus `host.id` fit the same local task. If records exist, use them as corroboration; otherwise require prior alerts from this rule with the same normalized command pattern, launcher, host, and user.
- Security testing or detection-validation exercises may intentionally use obfuscated commands. Confirm by matching normalized `process.command_line`, modifier-letter sequence, `process.parent.executable`, `host.id`, and `user.id` to the test scope; outside test records can corroborate but should not override contradictory process evidence.
- Before creating an exception, build it from the minimum confirmed pattern: normalized `process.command_line`, modifier-letter sequence or code-point range, utility identity in `process.executable` or `process.pe.original_file_name`, launcher context in `process.parent.executable`, and the stable `host.id` or `user.id` cohort. Avoid exceptions on `process.name` alone or the mere presence of non-ASCII characters.

### Response and remediation

- If confirmed benign, reverse any temporary containment and record the raw and normalized `process.command_line`, recovered code points, utility identity, parent command line, and `user.id` / `host.id` evidence that validated the workflow. Create an exception only for the same recurring pattern.
- If suspicious but unconfirmed, preserve the raw command string, normalized rendering, recovered code points, alerting and child `process.entity_id` values, parent command line, and `user.id` / `host.id` scope before containment. Apply reversible containment first, such as heightened monitoring, temporary account restrictions, or host isolation only when the normalized command, lineage, or follow-on process activity suggests active compromise and the host can tolerate isolation.
- If confirmed malicious, isolate the host or restrict the affected account based on the normalized intent, launcher chain, child process activity, and related-alert scope. Record alerting and child `process.entity_id` values before suspending or terminating processes, then eradicate only the payloads, configuration changes, or destructive actions identified in the case evidence.
- Post-incident hardening: replace scripts that require modifier-letter arguments, pin administrative automation to stable signed launcher paths and expected parent command lines, and retain full process command-line, parentage, child-process, and user-host telemetry for future alerts.
"""

setup = """## Setup

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

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

### Additional data sources

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.pid",
    "process.executable",
    "process.command_line",
    "process.Ext.session_info.logon_type",
    "process.Ext.token.elevation_level",
    "process.hash.sha256",
    "process.pe.original_file_name",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
    "process.parent.executable",
    "process.parent.command_line",
]

[transform]

[[transform.investigate]]
label = "Child process activity from the obfuscated process"
description = ""
providers = [
  [
    { 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 = "event.type", queryType = "phrase", value = "start", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "File, network, or registry activity by the obfuscated process"
description = ""
providers = [
  [
    { 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 = "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" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", 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 = "registry", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
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 = "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"

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

[[rule.threat.technique.subtechnique]]
id = "T1027.010"
name = "Command Obfuscation"
reference = "https://attack.mitre.org/techniques/T1027/010/"

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

[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2025/03/21"

[rule]
author = ["Elastic"]
description = """
Elastic Endgame prevented Credential Dumping. Click the Elastic Endgame icon in the event.module column or the link in
the rule.reference column for additional information.
"""
from = "now-2m"
index = ["endgame-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Credential Dumping - Prevented - Elastic Endgame"
risk_score = 47
rule_id = "db8c33a8-03cd-4988-9e2c-d0a4863adb13"
setup = """## Setup

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "medium"
tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event)
'''
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 Dumping - Prevented - Elastic Endgame

Elastic Endgame is a security solution that proactively prevents credential dumping, a technique where attackers extract sensitive authentication data from systems. Adversaries exploit this to gain unauthorized access to networks. The detection rule identifies prevention alerts by monitoring specific event actions and metadata, signaling attempts to steal credentials, thus enabling timely threat mitigation.

### Possible investigation steps

- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention of credential dumping.
- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft attempt that was prevented.
- Investigate the source and destination systems involved in the alert to identify potential points of compromise or targeted systems.
- Check for any related alerts or events in the same timeframe that might indicate a coordinated attack or further attempts at credential access.
- Assess the user accounts involved in the alert to determine if they have been compromised or if there are any unauthorized access attempts.
- Review the risk score and severity to prioritize the investigation and response actions based on the potential impact on the organization.

### False positive analysis

- Routine administrative tools or scripts that access credential stores may trigger alerts. Review and whitelist these tools if they are verified as non-threatening.
- Security software performing legitimate credential checks can be mistaken for credential dumping. Identify and exclude these processes from alert generation.
- Automated backup systems accessing credential data for legitimate purposes might be flagged. Ensure these systems are recognized and excluded from the rule.
- Regular system maintenance activities that involve credential verification could cause false positives. Document and exclude these activities if they are part of standard operations.
- User behavior analytics might misinterpret legitimate user actions as credential theft. Implement user behavior baselines to reduce such false positives.

### Response and remediation

- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network.
- Terminate any suspicious processes identified as part of the credential dumping attempt to halt ongoing malicious activities.
- Change all potentially compromised credentials, especially those with elevated privileges, to prevent unauthorized access using stolen credentials.
- Conduct a thorough review of access logs and event data to identify any additional systems that may have been targeted or compromised.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.
- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at credential theft.
- Review and update endpoint protection configurations to ensure that similar threats are detected and prevented in the future, leveraging insights from the MITRE ATT&CK framework."""


[[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.subtechnique]]
id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/001/"



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

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

[rule]
author = ["Elastic"]
description = """
This rule detects the execution of a base64 decoded payload to an interpreter inside a container. Attackers
may use this technique to execute malicious code, while attempting to evade detection.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Decoded Payload Piped to Interpreter Detected via Defend for Containers"
note = """## Triage and analysis

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

### Investigating Decoded Payload Piped to Interpreter Detected via Defend for Containers

This detection flags a container process that decodes an obfuscated payload (commonly base64 or similar) and immediately feeds the output into an interpreter, a high-signal pattern for fileless execution and defense evasion. Attackers use it to deliver short-lived scripts without writing them to disk, reducing forensic artifacts and bypassing simple content controls. A common pattern is echoing an encoded blob, decoding it, and piping it into `sh`/`bash` or `python` to run a downloader or backdoor inline.

### Possible investigation steps

- Correlate the paired exec events to reconstruct the full pipeline and determine whether it originated from an interactive exec session, the container entrypoint, or an orchestrated task.  
- Extract the encoded blob from the command invocation or captured stdin, decode it in an isolated environment, and assess the decoded script for downloader/backdoor logic, persistence attempts, or secret access.  
- Pivot from the interpreter execution to spawned children and concurrent outbound connections to identify second-stage payload retrieval, command-and-control, or lateral movement activity.  
- Validate workload legitimacy by reviewing the container’s image tag/digest and the owning pod/deployment, namespace, and service account, and compare against recent changes or redeploys for compromise indicators.  
- Look for post-execution artifacts in writable layers and mounted volumes (new scripts/binaries, modified init files, scheduled tasks), and if suspicious preserve evidence and rotate potentially exposed credentials.

### False positive analysis

- Containerized init/entrypoint or CI job logic decodes embedded base64 configuration or a small helper script at runtime (e.g., `base64 -d | sh` or `python -c ...b64decode...`) to avoid shipping plaintext in the image and to support templating across environments.  
- An operator troubleshooting a container uses an interactive exec session to paste an encoded one-liner that decodes and pipes into a shell or interpreter to quickly run diagnostics or apply a transient fix without creating files in the container filesystem.

### Response and remediation

- Immediately isolate or stop the affected container/pod and block further `kubectl exec`/interactive sessions into the workload while preserving the full command line, container image digest, and recent stdout/stderr logs for evidence.  
- Decode the observed base64/openssl/python/perl/ruby payload in a sandbox to identify its actions, then terminate any spawned interpreter children and remove any dropped binaries/scripts from writable layers and mounted volumes.  
- If the decoded script performs outbound retrieval or C2, quarantine the node or restrict egress for the namespace and rotate any secrets, tokens, or cloud credentials accessible to the container’s service account.  
- Rebuild and redeploy the workload from a known-good image (pin by digest), revoke the compromised image/tag from the registry, and validate the deployment manifests for unauthorized entrypoint/command changes.  
- Escalate to incident response if the payload includes credential access, lateral movement tooling, or creates persistence on the node (e.g., cron/systemd changes, modified kubelet paths), or if multiple containers show similar decode-to-interpreter pipelines.  
- Harden by enforcing admission controls to deny privileged containers and runtime `exec`, require read-only root filesystems and least-privilege service accounts, and add detections/blocks for decode-to-interpreter patterns and unexpected interpreters in production images.
"""
references = [
    "https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware",
]
risk_score = 73
rule_id = "0fb83aa0-3d17-41e9-b09c-56397bf7a7d9"
severity = "high"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by process.parent.entity_id, container.id with maxspan=3s
  [process where event.type == "start" and event.action == "exec" and container.id like "?*" and (
    (
      (
        process.name in ("base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16") or
        (
          process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
          process.args in ("base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16")
        )
      ) and
      process.args like~ "*-*d*"
    ) or
    (
      process.name == "openssl" and
      process.args == "enc" and process.args in ("-d", "-base64", "-a", "-A")
    ) or
    (
      process.name like "python*" and (
        (process.args == "base64" and process.args in ("-d", "-u", "-t")) or
        (process.args == "-c" and process.args like "*base64*" and process.args like~ "*b64decode*")
      )
    ) or
    (
      process.name like "perl*" and
      process.args like~ "*decode_base64*"
    ) or
    (
      process.name like "ruby*" and
      process.args == "-e" and
      process.args like~ "*Base64.decode64*"
    )
  )]
  [process where event.type == "start" and event.action == "exec" and process.name like (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
    "python*", "perl*", "ruby*", "lua*", "php*"
  ) and
  process.args like (
    "-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish", "-busybox",
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
    "/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh",
    "/bin/zsh", "/bin/ksh", "/bin/fish", "/bin/busybox",
    "/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh",
    "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish",
    "/usr/bin/busybox",
    "*python*", "*perl*", "*ruby*", "*lua*", "*php*", "/dev/fd/*"
  ) and
  not (
    process.working_directory like (
      "/usr/local/zeek", "/opt/zeek", "/var/lib/docker/overlay2/*/opt/zeek", "/usr/local/zeek_old_install",
      "/var/lib/docker/overlay2/*/usr/local/zeek", "/proc/self/fd/*/usr/local/zeek"
    ) or
    process.args in (
      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
    )
  )]
'''

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

[[rule.threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

[[rule.threat.technique.subtechnique]]
id = "T1027.010"
name = "Command Obfuscation"
reference = "https://attack.mitre.org/techniques/T1027/010/"

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

[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.technique.subtechnique]]
id = "T1059.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"

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

[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"

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

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

[rule]
description = """
This rule detects DNS requests initiated by suspicious process executables. Malware authors may use these requests to
communicate with command and control infrastructure, exfiltrate data from the target system, or to download payloads for
later execution.
"""
id = "503823dd-722f-4f23-84fc-8a6024f505f2"
license = "Elastic License v2"
name = "DNS Request by Suspicious Process Executable"
os_list = ["linux"]
version = "1.0.7"

query = '''
sequence by process.entity_id with maxspan=10s
  [process where event.type == "start" and event.action == "exec" and (
    process.executable like (
      "./*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/boot/*", "/sys/*",
      "/lost+found/*", "/var/mail/*"
    ) or
    process.name like ".*"
  ) and
  not (
    process.executable like (
      "./usr/bin/podman", "./", "/dev/.buildkit_qemu_emulator", "/u01/*/webtier/ohs/bin/.apachectl",
      "/usr/local/share/npm-global/lib/node_modules/opencode-ai/bin/.opencode",
      "./usr/bin/qemu-aarch64-static", "/nix/store/*/bin/.opencode-wrapped", "/home/agent/.local/share/coursier/bin/.bloop.aux",
      "/var/tmp/pamac-build-richard/*/bin/node", "/nix/store/*/bin/.rclone-wrapped", "/nix/store/*/bin/.glab-wrapped"
    ) or
    (
      process.executable like "/nix/store/*/bin/.gh-wrapped" and
      process.command_line like "/home/*/.nix-profile/bin/gh *"
    ) or
    (
      process.executable == "./usr/bin/qemu-x86_64-static" and
      process.command_line like "/usr/libexec/qemu-binfmt/x86_64-binfmt-P *"
    ) or
    process.parent.executable in ("/usr/bin/skopeo", "/usr/bin/buildah") or
    process.args == "datadog-ipc-helper" or
    process.executable like (
      "/nix/store/*claude-code-*/bin/.claude-wrapped",
      "*/node_modules/@kilocode/cli/bin/.kilo"
    )
  )]
  [dns where event.action == "lookup_result" and dns.question.name != "localhost" and
  not (
    dns.question.name == "pypi.org" or
    (process.executable like "/home/*/.elastic-ramen" and dns.question.name in ("registry.npmjs.org", "models.dev")) 
  )
  ]
'''

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

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

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

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

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



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



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

[internal]
min_endpoint_version = "9.3.0"

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

[rule]
author = ["Elastic"]
description = """
Detects when a custom domain is added or verified in an Entra ID tenant. Adding and verifying a custom domain are
precursor steps to configuring domain federation, which can be abused by adversaries to route authentication through an
attacker-controlled identity provider (Golden SAML). In most organizations, custom domains are added infrequently and
these events should be investigated to ensure they are part of a legitimate administrative workflow.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.auditlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Custom Domain Added or Verified"
note = """## Triage and analysis

### Investigating Entra ID Custom Domain Added or Verified

This rule detects when a custom domain is added or verified in an Entra ID tenant. These are precursor steps required before an adversary can configure domain federation. While adding and verifying domains are legitimate administrative activities, they are infrequent in most organizations. When observed without a corresponding change request or IT workflow, they may indicate the early stages of a Golden SAML or BYOIDP (Bring Your Own Identity Provider) attack.

While adding and verifying domains are legitimate administrative activities, they are infrequent in most organizations. When observed without a corresponding change request or IT workflow, they may indicate the early stages of a Golden SAML or BYOIDP (Bring Your Own Identity Provider) attack.

### Possible investigation steps

- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who performed the action and from where.
- For `"Add unverified domain"` events, check `azure.auditlogs.properties.target_resources.0.display_name` for the domain name that was added.
- Determine whether the domain is known to the organization or is potentially adversary-controlled.
- Check if a corresponding `"Verify domain"` event follows shortly after and from the same actor.
- Look for subsequent `"Set domain authentication"` or `"Set federation settings on domain"` events that would indicate the domain was federated — this escalates the severity significantly.
- Verify with the Global Administrator or IT team whether a domain addition was planned.
- Check DNS records for the domain to understand who owns it and when the verification TXT record was added.
- Review the `user_agent.original` field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action.

### False positive analysis

- Legitimate domain additions during initial tenant setup, organizational expansion, or mergers and acquisitions.
- IT administrators adding domains for new email routing, SharePoint vanity URLs, or multi-domain configurations.
- Automated provisioning systems that manage domain lifecycle.
- Validate with the identity or IT team before dismissing these events.

### Response and remediation

- If the domain addition is unauthorized, immediately remove the unverified or verified domain: `Remove-MgDomain -DomainId "<domain>"`.
- Investigate how the actor obtained privileges to add domains (requires Global Administrator or Domain Administrator role).
- Review the tenant for any other unauthorized changes made by the same actor using the `azure.correlation_id` or actor identity.
- If the domain was already federated, escalate to the response steps in the companion rule `Entra ID Domain Federation Configuration Change`.
- Restrict domain management operations by implementing PIM (Privileged Identity Management) for Global Administrator roles.
"""
references = [
    "https://cloud.google.com/blog/topics/threat-intelligence/unc2452-merged-into-apt29",
    "https://learn.microsoft.com/en-us/graph/api/domain-post-domains",
    "https://learn.microsoft.com/en-us/graph/api/domain-verify",
    "https://medium.com/tenable-techblog/roles-allowing-to-abuse-entra-id-federation-for-persistence-and-privilege-escalation-df9ca6e58360",
    "https://securitylabs.datadoghq.com/articles/i-spy-escalating-to-entra-id-global-admin/",
]
risk_score = 21
rule_id = "7dc921db-4cd3-48ef-88bf-2bfa91f29f5c"
setup = """### Microsoft Entra ID Audit Logs
This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the [Microsoft Entra ID Audit Logs integration documentation](https://www.elastic.co/docs/reference/integrations/azure/adlogs).
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Discovery",
    "Tactic: Resource Development",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: azure.auditlogs
    and azure.auditlogs.properties.category: DirectoryManagement
    and event.action: ("Add unverified domain" or "Verify domain")
    and event.outcome: success
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1584"
name = "Compromise Infrastructure"
reference = "https://attack.mitre.org/techniques/T1584/"
[[rule.threat.technique.subtechnique]]
id = "T1584.001"
name = "Domains"
reference = "https://attack.mitre.org/techniques/T1584/001/"



[rule.threat.tactic]
id = "TA0042"
name = "Resource Development"
reference = "https://attack.mitre.org/tactics/TA0042/"

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

[rule]
author = ["Elastic"]
description = """
Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user
from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate
onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies
fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their
own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard
session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them.
"""
false_positives = [
    """
    Legitimate WHfB and passwordless onboarding commonly generate this event, especially for new users or users
    enrolling from a new network ASN. This rule fires only on first-seen combinations of tenant, user, and source ASN
    over 14 days. Investigate unexpected ASNs, users outside the enrollment population, or enrollments preceded by
    anomalous sign-ins.
    """,
]
from = "now-9m"
index = ["logs-azure.auditlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Windows Hello for Business Credential Registered"
note = """## Triage and analysis

### Investigating Entra ID Windows Hello for Business Credential Registered

This is a first-seen (new_terms) signal: a WHfB credential was registered for a tenant/user/source-ASN combination not observed in the prior 14 days. Enrollment is often legitimate onboarding, but adversaries abuse the same action as persistence - after borrowing an existing WHfB key or passkey to satisfy fresh MFA, they enroll their own credential, which survives password resets and ordinary session revocation.

### Possible investigation steps
- Identify the target (`target_resources.0.user_principal_name`) and initiator (`initiated_by.user.userPrincipalName`), confirm whether WHfB enrollment was expected, and check whether the source ASN is new for that user.
- Correlate with `azure.signinlogs` shortly before for a deviceless WHfB/passkey sign-in, device-code flow, or attacker device registration/PRT issuance; an additional credential from a new ASN on an established account is more suspicious. Examine the preceding sign-in's source IP/geo and user agent for automation or hosting/VPS origins.

### False positive analysis
- First-time WHfB enrollment during onboarding/passwordless rollout is expected; repeat enrollments from the same tenant/user/ASN within 14 days don't fire.
- Users traveling or switching ISP/VPN may appear as a new ASN - validate against known networks before treating as suspicious.

### Response and remediation
- If unauthorized, delete the WHfB credential and any attacker-registered device via Graph or the Entra portal, revoke sessions and refresh tokens (delete devices first, to break device-bound PRT persistence), reset credentials, and re-enroll from a trusted device.
- Review the sign-in that authorized the enrollment to determine the initial access vector.
"""
references = ["https://dirkjanm.io/borrowing-windows-hello-keys/"]
risk_score = 21
rule_id = "8c6f8cca-f730-4cdd-93a7-d65f087a4116"
setup = """#### Required Microsoft Entra ID Audit Logs
This rule requires the Azure integration with Microsoft Entra ID Audit logs enabled and collected via Azure Event Hub.
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Platform: Entra ID",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Rule Type: New Terms",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.auditlogs" and
    azure.auditlogs.operation_name: "Add Windows Hello for Business credential" and
    event.outcome: ("Success" or "success") and
    azure.tenant_id: * and
    azure.auditlogs.properties.initiated_by.user.userPrincipalName: * and
    source.as.number: *
'''


[[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.001"
name = "Additional Cloud Credentials"
reference = "https://attack.mitre.org/techniques/T1098/001/"



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

[rule.new_terms]
field = "new_terms_fields"
value = [
    "azure.tenant_id",
    "azure.auditlogs.properties.initiated_by.user.userPrincipalName",
    "source.as.number",
]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"

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

[rule]
author = ["Elastic", "Massimo Bertocchi"]
description = """
Detects applications making a curl request to a known public IP address lookup web service. Malware commonly 
performs this action during reconnaissance to assess potential targets and identify the victim's external 
IP address.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "External IP Address Discovery via Curl"
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 External IP Address Discovery via Curl

This rule detects macOS processes launching curl (or nscurl) to query common public “what is my IP” and geolocation services, often from unusual parent applications or untrusted/unsigned code. Attackers use this to learn the victim’s outward-facing address and network context to guide follow-on targeting, routing, or staging decisions. A typical pattern is a script or dropped binary spawning curl with a short command that hits ipify/ipinfo/ifconfig-style endpoints immediately after execution.

### Possible investigation steps

- Review the full process tree and timeline around the curl execution to identify the initiating app/script, preceding download or execution activity, and any rapid follow-on discovery or persistence commands.  
- Examine the curl/nscurl command line and stdout/stderr capture (if available) to confirm the external-IP lookup intent and whether results were written to disk, environment variables, or passed to subsequent processes.  
- Correlate with network telemetry for the same host and time window to verify the outbound connection, destination IP/ASN, DNS resolution, TLS/SNI details, and any additional unexpected egress to non-lookup infrastructure.  
- Validate the provenance of the parent executable by checking its path, quarantine/notarization status, signature trust, and recent file creation/modification events to assess whether it was dropped or launched from a user-writable location.  
- Hunt for repeat occurrences across the endpoint (and fleet) that share the same parent, script content, or destination services, then check for associated indicators like new launch agents/daemons, cron jobs, or suspicious login items.

### False positive analysis

- A user or admin runs a short shell one-liner (bash/zsh with an http-containing command line) that uses curl to quickly confirm the Mac’s external IP during routine troubleshooting, VPN verification, or connectivity checks.  
- A legitimate but unsigned/not-yet-trusted macOS app launched from /Applications, a mounted /Volumes installer/dmg, or a temporary /private/var/folders path performs an external IP lookup via curl as part of initialization, telemetry, or network diagnostics.

### Response and remediation

- Isolate the affected Mac from the network if the curl/nscurl external-IP lookup is spawned by an unsigned/untrusted parent or from user-writable paths (e.g., /private/var/folders, mounted /Volumes) to prevent follow-on command-and-control.  
- Quarantine and remove the initiating artifact (app/script/binary) and any associated installers or DMGs, then block its hash and the specific lookup domains contacted (e.g., ipinfo.io, api.ipify.org, ifconfig.me) at egress/DNS to stop repeat discovery.  
- Hunt for and delete persistence created around the event (LaunchAgents/LaunchDaemons, login items, cron entries) and terminate any remaining suspicious processes that inherit environment/output from the curl call.  
- Reset exposed credentials and invalidate active sessions if the same parent process also accessed browsers, keychain, SSH keys, or configuration files shortly before/after the lookup, and rotate VPN/API tokens used on the host.  
- Reimage or restore the endpoint from a known-good snapshot if additional unknown binaries, repeated external-IP lookups, or unexpected outbound connections are observed after cleanup, then validate with a follow-up scan and a clean process baseline.  
- Escalate to IR leadership immediately if the external-IP lookup is followed by downloads/execution, persistence creation, or connections to newly registered/rare domains, and harden by restricting curl execution for non-admin contexts and tightening macOS app execution controls (Gatekeeper/notarization).
"""
risk_score = 21
rule_id = "3ad362a9-40cb-4536-8f8b-6a8b5cc24d3c"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and
  ((process.parent.executable like ("/Applications/*", "/Volumes/*", "/private/var/folders/*")) or
   (process.parent.name in ("bash", "sh", "zsh") and process.parent.command_line like "*http*") or
   (process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false or process.code_signature.exists == false)) and
  process.name in ("curl", "nscurl") and
  process.args_count <= 5 and
  process.command_line like ("*ip-api.com*", "*ipwho.is*", "*checkip.dyndns.org*", "*api.ipify.org*",
                             "*whatismyip.akamai.com*", "*ifcfg.me*", "*ifconfig.me*", "*ident.me*",
                             "*icanhazip.com*", "*ipecho.net*", "*api.myip.com*", "*checkip.amazonaws.com*",
                             "*wtfismyip.com*", "*iplogger.*", "*freegeoip.net*", "*ipinfo.io*",
                             "*geoplugin.net*", "*httpbin.org*", "*myip.opendns.com*")
'''

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

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

  [[rule.threat.technique]]
  name = "System Network Configuration Discovery"
  id = "T1016"
  reference = "https://attack.mitre.org/techniques/T1016/"

    [[rule.threat.technique.subtechnique]]
    name = "Internet Connection Discovery"
    id = "T1016.001"
    reference = "https://attack.mitre.org/techniques/T1016/001/"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a firewall rule is created in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine.
These firewall rules can be configured to allow or deny connections to or from virtual machine (VM) instances or
specific applications. An adversary may create a new firewall rule in order to weaken their target's security controls
and allow more permissive ingress or egress traffic flows for their benefit.
"""
false_positives = [
    """
    Firewall rules may be created by system administrators. Verify that the firewall configuration change was expected.
    Exceptions can be added to this rule to filter expected behavior.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Firewall Rule Creation"
note = """## Triage and analysis

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

### Investigating GCP Firewall Rule Creation

In GCP, firewall rules manage network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may exploit this by creating rules that permit unauthorized access, bypassing security measures. The detection rule monitors audit logs for specific actions indicating new rule creation, flagging potential defense evasion attempts to ensure timely investigation and response.

### Possible investigation steps

- Review the audit logs for the specific event.dataset:gcp.audit entries to identify the source of the firewall rule creation, focusing on the event.action fields: *.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule.
- Identify the user or service account responsible for the action by examining the actor information in the audit logs, such as the principalEmail field.
- Determine the network or application affected by the new firewall rule by analyzing the target resources, such as the VPC or App Engine application, to understand the potential impact.
- Assess the rule's configuration details, including the allowed or denied IP ranges, protocols, and ports, to evaluate if it introduces any security risks or deviates from established security policies.
- Check for any recent changes in permissions or roles assigned to the user or service account involved, which might indicate privilege escalation or misuse.
- Correlate the firewall rule creation event with other security events or alerts in the same timeframe to identify any suspicious patterns or activities that might suggest a coordinated attack.
- Consult with relevant stakeholders or teams to verify if the firewall rule creation was authorized and aligns with current operational requirements or projects.

### False positive analysis

- Routine administrative actions by authorized personnel can trigger alerts when they create or update firewall rules for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these actions and create exceptions for them in the detection rule.
- Automated processes or scripts that regularly update firewall configurations as part of normal operations may also cause false positives. Identify these processes and adjust the rule to exclude their specific actions or service accounts.
- Changes made during scheduled maintenance windows might be flagged as suspicious. Implement time-based exceptions to ignore rule creation events during these predefined periods.
- Integration with third-party security tools or services that modify firewall rules for enhanced protection can be mistaken for unauthorized activity. Verify these integrations and whitelist their actions to prevent unnecessary alerts.
- Development and testing environments often require frequent firewall rule changes, which can lead to false positives. Differentiate these environments from production by tagging them appropriately and excluding their events from the detection rule.

### Response and remediation

- Immediately review the newly created firewall rule to determine its source and intent. Verify if the rule aligns with organizational security policies and intended network configurations.
- Temporarily disable or delete the suspicious firewall rule to prevent unauthorized access while further investigation is conducted.
- Conduct a thorough audit of recent firewall rule changes in the affected GCP project to identify any other unauthorized modifications.
- Isolate affected systems or applications that may have been exposed due to the unauthorized firewall rule to prevent further exploitation.
- Notify the security operations team and relevant stakeholders about the incident for awareness and further action.
- Implement additional monitoring on the affected VPC or App Engine environment to detect any further unauthorized changes or suspicious activities.
- Review and update access controls and permissions for creating and modifying firewall rules to ensure only authorized personnel have the necessary privileges.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://cloud.google.com/vpc/docs/firewalls",
    "https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls",
]
risk_score = 21
rule_id = "30562697-9859-4ae0-a8c5-dab45d664170"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule)
'''


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

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

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

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

[metadata]
creation_date = "2026/08/12"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/08/12"

[rule]
author = ["Elastic"]
description = """
Detects a single identity listing Google Cloud Secret Manager secrets across many distinct projects in a short window.
ListSecrets does not return secret values, but sweeping many projects is a common reconnaissance step before targeted
AccessSecretVersion calls. Legitimate workloads typically list secrets within one project or a small set of projects;
cross-project bursts from one user and source IP are uncommon outside security tooling or compromise.
"""
false_positives = [
    """
    Organization-wide security scanners, CSPM products, inventory jobs, or approved red-team exercises may list secrets
    across many projects. Validate the principal, source IP, user agent, and schedule against known tooling before
    treating the activity as malicious, and exclude documented automation identities when baselined.
    """,
    """
    Platform or IAM administrators troubleshooting Secret Manager access across environments may briefly exceed the
    project cardinality threshold. Correlate with change tickets and expected administrative clients.
    """,
]
from = "now-6m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "GCP Secret Manager ListSecrets Across Multiple Projects"
note = """## Triage and analysis

### Investigating GCP Secret Manager ListSecrets Across Multiple Projects

This rule aggregates Secret Manager `ListSecrets` audit events per `client.user.email` and `source.ip` over the rule
lookback. It alerts when the same actor lists secrets in 10 or more distinct `cloud.project.id` values. Listing does
not retrieve secret payloads, but multi-project enumeration is a strong discovery signal ahead of credential access.

### Possible investigation steps

- Review `Esql.cloud_project_id_values` to identify which projects were
  enumerated and whether they include high-value or production workloads.
- Confirm whether `client.user.email`, `source.ip`, and
  `Esql.user_agent_original_values` match expected administrators, CI/CD, or approved security scanners.
- Check `Esql.event_outcome_values` for mixed success and failure, which can indicate permission probing across projects
  the identity cannot fully access.
- Hunt for follow-on Secret Manager activity from the same identity or IP, especially
  `AccessSecretVersion`, `GetSecret`, and IAM policy changes on secrets or projects.
- Bound the burst with `Esql.earliest_timestamp` and `Esql.latest_timestamp`, then pivot in Discover on the same
  `client.user.email` / `source.ip` for related GCP audit activity.

### False positive analysis

- Documented CSPM, secret inventory, or compliance scanners that walk many projects will match; exclude those
  principals after validation.
- Break-glass or org-admin troubleshooting can look similar; require change-management correlation before raising
  severity.

### Response and remediation

- If unauthorized, revoke or rotate the implicated credentials, review IAM bindings that grant
  `secretmanager.secrets.list` across projects, and inspect for subsequent secret access or exfiltration.
- Restrict Secret Manager list permissions to least privilege and prefer per-project roles over org-wide grants for
  human users.
"""
setup = """The GCP Fleet integration (or Filebeat module) with audit logs for Secret Manager is required. `ListSecrets` is a
data-access method; enable DATA_READ audit logging for the Secret Manager API so these events are ingested into
`logs-gcp.audit-*`.

See [Secret Manager audit logging](https://cloud.google.com/secret-manager/docs/audit-logging) and
[Configure Data Access audit logs](https://cloud.google.com/logging/docs/audit/configure-data-access).
"""
references = [
    "https://cloud.google.com/secret-manager/docs/reference/rest/v1/projects.secrets/list",
]
risk_score = 73
rule_id = "642ac343-e7d6-4cf2-bb0b-7db412e614ad"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Data Source: GCP Audit Logs",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
    "Rule Type: ESQL",
    "Platform: GCP",
    "Service: GCP Secret Manager",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-gcp.audit-* metadata _id, _version, _index
| where data_stream.dataset == "gcp.audit"
    and event.action == "google.cloud.secretmanager.v1.SecretManagerService.ListSecrets"
    and cloud.project.id is not null
    and client.user.email is not null
    and source.ip is not null
| stats
    Esql.cloud_project_id_count_distinct = count_distinct(cloud.project.id),
    Esql.cloud_project_id_values = values(cloud.project.id),
    Esql.event_count = count(*),
    Esql.event_outcome_values = values(event.outcome),
    Esql.client_user_id_values = values(client.user.id),
    Esql.user_agent_original_values = values(user_agent.original),
    Esql.earliest_timestamp = min(@timestamp),
    Esql.latest_timestamp = max(@timestamp)
  by client.user.email, source.ip, data_stream.namespace
| where Esql.cloud_project_id_count_distinct >= 10
| keep
    client.user.email,
    source.ip,
    Esql.cloud_project_id_count_distinct,
    Esql.cloud_project_id_values,
    Esql.event_count,
    Esql.event_outcome_values,
    Esql.client_user_id_values,
    Esql.user_agent_original_values,
    Esql.earliest_timestamp,
    Esql.latest_timestamp, 
    data_stream.namespace
'''

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

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

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

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

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "A new GitHub repository was created.\n"
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "GitHub Repo Created"
risk_score = 21
rule_id = "6cea88e4-6ce2-4238-9981-a54c140d6336"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Execution",
    "Rule Type: BBR",
    "Data Source: Github",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
configuration where event.dataset == "github.audit" and event.action == "repo.create"
'''


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

[[rule.threat.technique]]
id = "T1648"
name = "Serverless Execution"
reference = "https://attack.mitre.org/techniques/T1648/"

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

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

[[rule.threat.technique]]
id = "T1583"
name = "Acquire Infrastructure"
reference = "https://attack.mitre.org/techniques/T1583/"

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

[rule.threat.tactic]
id = "TA0042"
name = "Resource Development"
reference = "https://attack.mitre.org/tactics/TA0042/"

[metadata]
creation_date = "2020/11/12"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service
account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant.
Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based
persistence and access mail, drive, and directory data without relying on a single user's password alone.
"""
false_positives = [
    """
    Domain-wide delegation of authority may be granted to service accounts by system administrators. Verify that the
    configuration change was expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-130m"
interval = "10m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace API Access Granted via Domain-Wide Delegation"
note = """## Triage and analysis

### Investigating Google Workspace API Access Granted via Domain-Wide Delegation

Domain-wide delegation (DWD) allows a Google Cloud service account or OAuth client to access Workspace user data on
behalf of users across the domain. Only super administrators can authorize DWD, and each grant specifies API scopes
that define what the client can read or modify (for example Gmail, Drive, Directory, or Calendar APIs). Over-scoped DWD
grants create durable third-party access paths that survive individual user password resets.

This rule matches `AUTHORIZE_API_CLIENT_ACCESS` events in the `google_workspace.admin` data stream.

### Possible investigation steps

- Identify the administrator who authorized access by reviewing `user.email` or `user.name`, and note `user.domain` and
  `event.ingested` if present in the alert.
- Identify the authorized client by reviewing `google_workspace.admin.api.client.name` and confirm the affected tenant
  with `google_workspace.admin.domain.name`.
- Review granted API scopes in `google_workspace.admin.api.scopes` against least-privilege expectations. Broad scopes
  (for example full mail or drive access) warrant higher urgency.
- Determine whether the change is expected and authorized:
  - Validate there is an approved change request or vendor onboarding record for the client and scopes.
  - If the actor account is unusual or the scopes exceed documented requirements, treat as higher priority until proven benign.
- Review DWD configuration in the Google Admin console:
  - Sign in to [admin.google.com](https://admin.google.com) with an authorized administrator account.
  - Navigate to Security > Access and data control > API controls > Domain-wide delegation.
  - Confirm the client ID, client name, and scopes match the alert fields.
- Search Kibana for related admin activity:
  - Find other DWD grants or revocations by the same administrator:
    ```
    data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("AUTHORIZE_API_CLIENT_ACCESS" or "REVOKE_API_CLIENT_ACCESS")
    ```
  - Scope for all grants to the same API client:
    ```
    data_stream.dataset: "google_workspace.admin" and event.action: "AUTHORIZE_API_CLIENT_ACCESS" and google_workspace.admin.api.client.name: "<CLIENT_NAME>"
    ```
  - Correlate with other high-risk admin actions from the same actor in the last 48 hours:
    ```
    data_stream.dataset: "google_workspace.admin" and user.email: "<ACTOR_EMAIL>" and event.action: ("ASSIGN_ROLE" or "ADD_APPLICATION" or "CREATE_ROLE")
    ```
- If GCP audit logs are ingested, pivot on the service account or client:
  - Search for the client name in `gcp.audit.resource_name` and review `event.action` over the last 48 hours to determine
    how the service account is being used after authorization.

### False positive analysis

- Platform or security teams may authorize DWD for approved automation, backup, or migration tooling — validate against
  known service accounts and documented scope requirements.
- Vendor onboarding sometimes requires temporary broad scopes; confirm timing against change windows before closing as benign.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the grant is not clearly authorized, revoke domain-wide delegation for the client under Security > Access and data
  control > API controls > Domain-wide delegation while the investigation proceeds.
- Rotate or disable the associated GCP service account keys if the client is suspected malicious.
- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review
  delegated admin roles assigned to that account.
- Review activity performed with the authorized client based on scopes in `google_workspace.admin.api.scopes`.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://developers.google.com/admin-sdk/directory/v1/guides/delegation",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
]
risk_score = 73
rule_id = "acbc8bb9-2486-49a8-8779-45fb5f9a93ee"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:google_workspace.admin
  and event.action:AUTHORIZE_API_CLIENT_ACCESS
'''

[rule.investigation_fields]
field_names = [
    "user.name",
    "user.email",
    "user.domain",
    "event.action",
    "google_workspace.admin.api.client.name",
    "google_workspace.admin.api.scopes",
    "google_workspace.admin.domain.name",
]

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

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

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

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

[[rule.threat.technique]]
id = "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/"