Elastic rules: 1w

[metadata]
creation_date = "2024/07/23"
integration = ["endpoint", "system"]
maturity = "production"
updated_date = "2025/02/21"

[rule]
author = ["Elastic"]
description = """
Identifies a potential forced authentication using related SMB named pipes. Attackers may attempt to force targets to
authenticate to a host controlled by them to capture hashes or enable relay attacks.
"""
from = "now-9m"
index = ["logs-endpoint.events.network-*", "logs-system.security*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Active Directory Forced Authentication from Linux Host - SMB Named Pipes"
references = [
    "https://github.com/p0dalirius/windows-coerced-authentication-methods",
    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
    "https://attack.mitre.org/techniques/T1187/",
]
risk_score = 47
rule_id = "c24e9a43-f67e-431d-991b-09cdb83b3c0c"
setup = """## Setup

This rule uses Elastic Endpoint network events from Linux hosts and system integration events from Domain controllers
for correlation. Both data sources should be collected from the hosts for this detection to work.

The 'Audit Detailed File Share' audit policy must be configured (Success Failure).
Steps to implement the logging policy with Advanced Audit Configuration:
```
Computer Configuration >
Policies >
Windows Settings >
Security Settings >
Advanced Audit Policies Configuration >
Audit Policies >
Object Access >
Audit Detailed File Share (Success,Failure)
```
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Data Source: Active Directory",
    "Use Case: Active Directory Monitoring",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence with maxspan=15s
[network where host.os.type == "linux" and event.action == "connection_attempted" and destination.port == 445 and not startswith~(string(destination.ip), string(host.ip))] by host.ip, data_stream.namespace
[file where host.os.type == "windows" and event.code == "5145" and file.name : ("Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc")] by source.ip, data_stream.namespace
'''
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 Active Directory Forced Authentication from Linux Host - SMB Named Pipes

Active Directory (AD) and SMB named pipes facilitate network resource access and inter-process communication. Adversaries exploit these by forcing authentication from a Linux host to capture credentials or perform relay attacks. The detection rule identifies suspicious SMB connection attempts from Linux to Windows hosts, focusing on specific named pipes indicative of forced authentication attempts, thus highlighting potential credential access threats.

### Possible investigation steps

- Review the network logs to identify the Linux host IP address that attempted the SMB connection on port 445 and verify if this activity is expected or authorized.
- Check the Windows host logs for event code 5145 to determine which named pipes were accessed and assess if these accesses align with normal operations or indicate suspicious activity.
- Investigate the source IP address from the Windows logs to determine if it matches the Linux host IP and evaluate if this connection is part of a known and legitimate process.
- Analyze historical data for any previous similar connection attempts from the same Linux host to identify patterns or repeated unauthorized access attempts.
- Consult with system administrators to confirm if there have been any recent changes or updates in the network configuration that could explain the connection attempts.

### False positive analysis

- Routine administrative tasks from Linux hosts may trigger alerts. Identify and document these tasks to create exceptions for known IP addresses or hostnames involved in regular operations.
- Automated backup or monitoring systems that connect to Windows hosts using SMB may cause false positives. Review and whitelist these systems by their IP addresses or specific named pipes they access.
- Development or testing environments where Linux hosts frequently interact with Windows systems can generate alerts. Establish a separate monitoring policy or exclude these environments from the rule to reduce noise.
- Security tools or scripts that perform network scans or audits might mimic suspicious behavior. Verify these tools and exclude their activities by specifying their source IPs or associated user accounts.
- Cross-platform file sharing services that use SMB for legitimate purposes may be flagged. Identify these services and adjust the rule to ignore their specific connection patterns or named pipes.

### Response and remediation

- Isolate the affected Linux host from the network to prevent further unauthorized SMB connection attempts and potential credential capture.
- Conduct a thorough review of the Linux host's network activity logs to identify any unauthorized access or data exfiltration attempts.
- Reset passwords for any accounts that may have been exposed or compromised during the forced authentication attempt to mitigate the risk of credential misuse.
- Implement network segmentation to limit SMB traffic between Linux and Windows hosts, reducing the attack surface for similar threats.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional hosts or systems are affected.
- Deploy enhanced monitoring on the identified named pipes and associated network traffic to detect and respond to future forced authentication attempts promptly.
- Review and update firewall rules to restrict unnecessary SMB traffic and ensure only authorized systems can communicate over port 445."""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1187"
name = "Forced Authentication"
reference = "https://attack.mitre.org/techniques/T1187/"


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

[metadata]
creation_date = "2020/09/03"
integration = ["auditd_manager", "endpoint", "network_traffic"]
maturity = "production"
min_stack_version = "9.4.0"
min_stack_comments = "Use EA (Entity Analytics) fields"
updated_date = "2026/07/27"

[rule]
anomaly_threshold = 50
author = ["Elastic"]
description = """
Looks for compiler activity by a user context which does not normally run compilers. This can be the result of ad-hoc
software changes or unauthorized software deployment. This can also be due to local privilege elevation via locally run
exploits or malware activity.
"""
false_positives = [
    """
    Uncommon compiler activity can be due to an engineer running a local build on a production or staging instance in
    the course of troubleshooting or fixing a software issue.
    """,
]
from = "now-45m"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = ["v3_linux_rare_user_compiler_ea"]
name = "Anomalous Linux Compiler Activity"
setup = """## Setup

This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
- Elastic Defend
- Auditd Manager
- Network Packet Capture

### Anomaly Detection Setup

Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).

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

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

#### The following steps should be executed in order to add the Elastic Defend integration to your system:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).

### Auditd Manager Integration Setup
The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.

#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
- Click “Add Auditd Manager”.
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click “Save and Continue”.
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).

#### Rule Specific Setup Note
Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
- For this detection rule no additional audit rules are required.

### Network Packet Capture Integration Setup
The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.

#### The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it.
- Click “Add Network Packet Capture”.
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.
- Click “Save and Continue”.
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).
"""
risk_score = 21
rule_id = "cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Data Source: Network Packet Capture",
    "Use Case: Threat Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Resource Development",
    "Resources: Investigation Guide",
]
type = "machine_learning"
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 Anomalous Linux Compiler Activity

Compilers transform source code into executable programs, a crucial step in software development. In Linux environments, unexpected compiler use by atypical users may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit this by deploying malicious code or exploits. The detection rule leverages machine learning to identify unusual compiler activity, flagging potential threats by analyzing user behavior patterns and deviations from normal operations.

### Possible investigation steps

- Review the user account associated with the anomalous compiler activity to determine if the user typically engages in software development or has a history of using compilers.
- Check the specific compiler and version used in the activity to identify if it is a known or legitimate tool within the organization.
- Analyze the source and destination of the compiler activity, including the IP addresses and hostnames, to identify any unusual or unauthorized access patterns.
- Investigate recent changes or deployments on the system where the compiler activity was detected to identify any unauthorized software installations or modifications.
- Examine system logs and audit trails for any signs of privilege escalation attempts or other suspicious activities around the time of the compiler usage.
- Cross-reference the detected activity with known threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise.

### False positive analysis

- Development environments where multiple users compile code can trigger false positives. Regularly update the list of authorized users who are expected to use compilers to prevent unnecessary alerts.
- Automated build systems or continuous integration pipelines may be flagged. Exclude these systems from monitoring or adjust the rule to recognize their activity as normal.
- Educational or training sessions involving compilers might cause alerts. Temporarily adjust the rule settings or add exceptions for the duration of the training.
- Users compiling open-source software for personal use can be mistaken for threats. Implement a process for users to notify the security team of legitimate compiler use to preemptively adjust monitoring rules.
- System administrators performing maintenance or updates that involve compiling software may trigger alerts. Maintain a log of scheduled maintenance activities and adjust the rule to account for these periods.

### Response and remediation

- Isolate the affected system from the network to prevent potential lateral movement or further exploitation.
- Terminate any suspicious processes associated with the anomalous compiler activity to halt any ongoing malicious operations.
- Conduct a thorough review of recent user activity and permissions to identify unauthorized access or privilege escalation attempts.
- Remove any unauthorized or malicious software identified during the investigation to prevent further compromise.
- Restore the system from a known good backup if malicious code execution is confirmed, ensuring that the backup is free from compromise.
- Implement stricter access controls and monitoring for compiler usage, ensuring only authorized users can execute compilers.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1588"
name = "Obtain Capabilities"
reference = "https://attack.mitre.org/techniques/T1588/"

[[rule.threat.technique.subtechnique]]
id = "T1588.001"
name = "Malware"
reference = "https://attack.mitre.org/techniques/T1588/001/"

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

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

[[rule.threat.technique]]
id = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"

[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 = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or
registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or
RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's
trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications
subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint
registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether
the model originates from an approved internal pipeline.
"""
false_positives = [
    """
    Machine learning engineers, MLOps automation, or platform teams may legitimately import custom models or stand up
    marketplace model endpoints as part of normal model lifecycle operations. Verify whether the user identity, user
    agent, source IP, and model artifact source (S3 location) are expected for your environment. Imports performed by
    approved CI/CD or IaC pipelines can be exempted from this rule. Activity from unfamiliar identities or untrusted
    artifact sources should be investigated.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered"
note = """## Triage and analysis

### Investigating AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered

Amazon Bedrock allows organizations to import custom models, deploy them, and register marketplace model endpoints for inference. Each of these paths introduces a model artifact that did not necessarily originate from the organization's trusted training and approval pipeline. Adversaries who can import a backdoored or poisoned model — or register an untrusted marketplace endpoint — can influence the output of any downstream application that invokes that model, constituting a supply-chain compromise. This detection identifies `CreateModelImportJob`, `CreateCustomModelDeployment`, `CreateMarketplaceModelEndpoint`, and `RegisterMarketplaceModelEndpoint` calls so responders can verify model provenance before the model is trusted for inference.

#### 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 whether a related change request or model onboarding ticket exists.
  - Determine if the identity is an approved ML/MLOps role or automation principal.
- **Validate the model artifact source**
  - In `aws.cloudtrail.flattened.request_parameters`, review the model source location (e.g., the S3 URI for an import job) and confirm the bucket belongs to your organization and is not attacker-controlled.
  - For marketplace endpoints, confirm the model package ARN / product corresponds to an approved vendor.
- **Correlate activity**
  - Look for subsequent `InvokeModel` / `InvokeModelWithResponseStream` activity targeting the new model or endpoint.
  - Check for prior enumeration such as `ListFoundationModels`, `ListCustomModels`, or `ListImportedModels`.
  - Review other recent actions by the same identity for signs of broader compromise.

### False positive analysis
- **Planned model onboarding**: ML teams routinely import models and register endpoints. Validate against a ticket and confirm the artifact source.
- **Automation**: IaC or MLOps pipelines may create these resources during deployment. Confirm the source IP and ARN match expected automation infrastructure.

### Response and remediation
- **If unauthorized**
  - Delete or disable the imported model, custom model deployment, or marketplace endpoint.
  - Prevent downstream applications from invoking the untrusted model until provenance is established.
  - Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and rotate credentials if compromise is suspected.
  - Audit the S3 source bucket for tampering and review the model artifact for backdoors.
- **Hardening**
  - Restrict `bedrock:CreateModelImportJob`, `bedrock:CreateCustomModelDeployment`, and marketplace endpoint creation/registration permissions to approved roles.
  - Enforce that model artifacts originate only from organization-owned, controlled S3 locations.

### Additional information

"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelImportJob.html",
    "https://docs.aws.amazon.com/bedrock/latest/userguide/model-import.html"
]
risk_score = 47
rule_id = "c435defe-8438-4d5a-b4d0-86ab0faf9a49"
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: Threat Detection",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "bedrock.amazonaws.com"
    and event.action: (
        "CreateModelImportJob" or
        "CreateCustomModelDeployment" or
        "CreateMarketplaceModelEndpoint" or
        "RegisterMarketplaceModelEndpoint"
    )
    and event.outcome: "success"
'''


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

[[rule.threat.technique]]
id = "T1525"
name = "Implant Internal Image"
reference = "https://attack.mitre.org/techniques/T1525/"

[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.flattened.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a
network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP
data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new
terms baseline on `user_identity.arn` suppresses repeated noise from the same principal while still surfacing the initial
suspicious creation from an unusual egress label.
"""
false_positives = [
    """
    Engineers creating key pairs from home ISP, corporate VPN, or colocation AS names will match until baselined.
    GeoIP databases vary by vendor; organization labels may differ slightly from the excluded strings (for example
    alternate Amazon or Google legal names). Tune exclusions on `source.as.organization.name` or principal ARN after
    validation.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 CreateKeyPair by New Principal from Non-Cloud AS Organization"
note = """## Triage and analysis

### Investigating AWS EC2 CreateKeyPair by New Principal from Non-Cloud AS Organization

`CreateKeyPair` creates an Amazon EC2 SSH key pair in the account; the private key material is returned to the caller
once. This is useful for persistence or preparation for instance access.

This **new terms** rule alerts the **first** time `aws.cloudtrail.user_identity.arn` matches the query within the
configured history window. Subsequent key-pair creations by the same principal (still matching the query) are
suppressed until the term ages out of the window.

#### Possible investigation steps

- Review `aws.cloudtrail.request_parameters` / `response_elements` for `keyName` and whether the key aligns with change
  management.
- Correlate `source.ip`, `source.geo`, and `user_agent.original` with the principal’s normal admin paths.
- Hunt for `RunInstances`, `ImportKeyPair`, or Instance Connect activity involving the same key name or actor.

### False positive analysis

- First-time legitimate admin activity from a new office or VPN provider.
- Missing `source.as.organization.name` enrichment would **not** match the query’s positive wildcard; confirm fields are
  populated if you expect coverage.

### Response and remediation

- If unauthorized: delete the key pair (`DeleteKeyPair`), review IAM for `ec2:CreateKeyPair`, and rotate any credentials
  used by the actor.

### Additional information

- [CreateKeyPair](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateKeyPair.html)
"""
references = [
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateKeyPair.html",
]
risk_score = 73
rule_id = "c8e4f1a2-9b3d-4c5e-a6f7-8b9c0d1e2f3a"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon EC2",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Credential Access",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.dataset: "aws.cloudtrail"
    and event.provider: "ec2.amazonaws.com"
    and event.action: "CreateKeyPair"
    and event.outcome: "success"
    and source.as.organization.name: (
        * and not (
            "Amazon.com, Inc." or AMAZ* or "Google LLC" or "Microsoft Corporation"
        )
    )
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "source.as.organization.name",
    "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 = "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 = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"

[[rule.threat.technique.subtechnique]]
id = "T1552.004"
name = "Private Keys"
reference = "https://attack.mitre.org/techniques/T1552/004/"

[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 = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"

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

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

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

[metadata]
bypass_bbr_timing = true
creation_date = "2021/05/17"
integration = ["aws"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Austin Songer", "Elastic"]
building_block_type = "default"
description = """
Identifies the use of GetSessionToken API calls by IAM users or Root Account. While this is a common and legitimate
operation used to obtain temporary credentials, it also provides adversaries with a method to generate short-lived
tokens for stealthy activity. Attackers who compromise IAM user access keys may call GetSessionToken to create temporary
credentials, which they can then use to move laterally, escalate privileges, or persist after key rotation. This rule is
intended as a BBR to establish patterns of typical STS usage and support correlation with higher-fidelity detections.
"""
false_positives = [
    """
    GetSessionToken is widely used by legitimate automation, CLI users, and administrative scripts to acquire temporary
    credentials. Frequent, authorized usage is expected in most environments, especially where IAM users authenticate
    with MFA or use short-lived tokens. Review IAM and CI/CD users, SDKs, and service accounts that regularly perform
    this action and document them in an allowlist. Suppress or tune accordingly to reduce noise.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS STS GetSessionToken Usage"
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 AWS STS GetSessionToken Usage

AWS Security Token Service (STS) provides temporary credentials for AWS resources, crucial for managing access without long-term credentials. Adversaries may exploit `GetSessionToken` to create temporary credentials, enabling lateral movement and privilege escalation. The detection rule identifies successful `GetSessionToken` requests, flagging potential misuse for further investigation.

#### Possible investigation steps
- **Establish normal baseline behavior**
  - Use this rule’s data to determine which IAM users or automation scripts routinely perform `GetSessionToken`.
  - Monitor frequency, regions, and user agents (CLI, SDK, console) for each identity over time.

- **Identify anomalies**
  - Look for first-time or rare `GetSessionToken` usage by an IAM user.
  - Detect tokens issued without MFA when MFA is normally required.
  - Identify new or unexpected source IPs, geographies, or user agents (e.g., API calls from unfamiliar networks).
  - Check for multiple temporary tokens minted in rapid succession by the same user or access key.

- **Correlate with downstream activity**
  - Search for immediate follow-on events within 15 minutes of token creation:
    - `AssumeRole` into higher-privileged roles or cross-account roles.
    - Privileged API calls (e.g., `iam:*`, `s3:PutBucketPolicy`, `ec2:CreateSnapshot`).
    - New region access, resource enumeration, or credential operations (`GetCallerIdentity`, `ListUsers`, etc.).
  - Use this correlation to elevate contextual `GetSessionToken` behavior into actionable detections.

### Usage Notes
- This rule’s telemetry can support hunting queries such as:
  - `GetSessionToken` without `TokenCode` (no MFA)
  - New IP + `GetSessionToken` + `AssumeRole`
  - Rapid token issuance followed by API activity from a new ASN

Use these patterns in combination with related BBRs or detection rules for `AssumeRole` abuse, cross-account access,
or credential pivoting for more reliable threat detection.
"""
references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html"]
risk_score = 21
rule_id = "b45ab1d2-712f-4f01-a751-df3826969807"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS STS",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset: aws.cloudtrail 
  and event.provider: sts.amazonaws.com 
  and event.action: GetSessionToken 
  and event.outcome: success
'''


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

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

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

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

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

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

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

[[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 = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic"]
description = """
Detects creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse weak
child-object or msDS-DelegatedManagedServiceAccount rights during account migration to elevate privileges.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "dMSA Account Creation 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 = "f0dbff4c-1aa7-4458-9ed5-ada472f64970"
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:5137 and host.os.type:"windows" and winlog.event_data.ObjectClass:"msDS-DelegatedManagedServiceAccount"
'''

note = """## Triage and analysis

### Investigating dMSA Account Creation by an Unusual User

#### Possible investigation steps

- What dMSA object did the alert show, and where was it created?
  - Focus: use `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.SubjectUserName`, and `winlog.computer_name` to identify the new msDS-DelegatedManagedServiceAccount, new-to-this-rule writer, and controller.
  - Implication: escalate when the object is in a privileged service, sync, backup, DC, or identity-infrastructure path, or when name or writer lacks a narrow service-account purpose; lower only when DN, writer, and controller match one exact planned dMSA rollout or lab path.
- Did the same dMSA receive migration or privilege-enabling attributes?
  - Why: BadSuccessor-style abuse elevates creation with `5136` changes such as msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPNs, delegation attributes, or gMSA membership.
  - Focus: review same-object `5136` and `5137` records on this controller with `winlog.event_data.ObjectGUID`, comparing `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`. $investigate_0
  - Hint: if same-controller results have gaps, repeat the `winlog.event_data.ObjectGUID` search across DC Windows Security logs before treating missing follow-on changes as lower risk.
  - Implication: escalate when values link the dMSA to a privileged predecessor, advance migration state, or add SPN/delegation material; lower suspicion only when attributes form one bounded migration to the intended legacy service account.
- Who created the dMSA, and what session reached the domain controller?
  - Focus: identify writer and session with `winlog.event_data.SubjectUserSid` and `winlog.event_data.SubjectLogonId`, then recover `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. $investigate_1
  - Hint: this pivot uses `winlog.event_data.TargetLogonId` for `4624` or `4634`; search `4648` separately with `winlog.event_data.SubjectLogonId` when explicit-credential use matters. Missing authentication telemetry is unresolved, not benign.
  - Implication: escalate for an unexpected human, helpdesk account, low-privilege service identity, unusual source, interactive/RDP session, or explicit-credential path; lower suspicion only when actor and source match the narrow identity-management path for this object.
- Did the same session touch other directory objects?
  - Focus: compare surrounding `5137` and `5136` records on the same `host.id` for `winlog.event_data.SubjectLogonId`, reading `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, and `winlog.event_data.AttributeLDAPDisplayName`.
  - Implication: escalate when the session creates multiple dMSAs, edits ACLs, changes delegation, or touches unrelated privileged users, computers, groups, or service accounts; lower when every change stays tied to one bounded dMSA rollout.
- Did the new dMSA get used from systems that should not touch it?
  - Focus: derive the dMSA from the CN in `winlog.event_data.ObjectDN`, confirm it in `winlog.event_data.TargetUserName`, then review `4624` records for `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`; search `4648` separately for explicit credential use.
  - Hint: absent dMSA authentication is a timing or visibility gap, not proof creation is harmless.
  - Implication: escalate when the dMSA authenticates from unexpected servers, workstations, jump hosts, or non-service logon types; lower suspicion only when use stays inside the exact service host set for the confirmed rollout.
- If local evidence is suspicious or incomplete, do related Windows Security events show broader AD abuse?
  - Focus: review events for writer `user.id`, then compare records referencing the new `winlog.event_data.ObjectGUID`. $investigate_2
  - Hint: use the object-event view for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the same dMSA. $investigate_3
  - Implication: escalate and expand scope when either entity is tied to privilege abuse, directory tampering, or suspicious authentication; keep scope to this object when related events are quiet, but do not close solely because no other event exists.
- Escalate for sensitive placement, privileged migration links, unexpected writer/session context, broader directory edits, unexpected dMSA authentication, or related AD-abuse events; close only when telemetry and outside confirmation prove one exact planned migration or lab activity; if mixed or incomplete, preserve directory-change and session evidence and escalate.

### False positive analysis

- Planned dMSA rollout or service-account migration can legitimately create msDS-DelegatedManagedServiceAccount objects. Confirm expected `winlog.event_data.ObjectDN`, same-object `5136` attributes limited to the intended legacy service account, and `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` matching the narrow migration account and host path. If change records, migration tickets, or owner confirmation are unavailable, leave unresolved unless telemetry proves the exact authorized workflow.
- Lab validation or staged service-account modernization can also trigger this rule. Confirm `winlog.event_data.ObjectDN` stays in the test/staging OU, the same `winlog.event_data.SubjectLogonId` avoids unrelated privileged objects, and any `winlog.event_data.TargetUserName`, `source.ip`, or `winlog.logon.type` activity stays limited to designated test systems. If test scope lacks outside confirmation, treat the alert as unresolved.
- Before creating an exception, validate exact writer `winlog.event_data.SubjectUserSid`, dMSA path pattern, bounded same-object `5136` attributes, controller path, and recovered source. Use a temporary or tightly scoped exception for one-time migrations, and avoid exceptions on event `5137`, all msDS-DelegatedManagedServiceAccount objects, or all dMSA creation activity.

### Response and remediation

- If confirmed benign, reverse any temporary containment and document the evidence that proved the authorized workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, same-object `5136` sequence, recovered `source.ip`, `winlog.logon.type`, and exact rollout or lab scope.
- If suspicious but unconfirmed, preserve a case export with the triggering `5137`, related same-object `5136` records, recovered `4624` or `4648` records, and key object/session identifiers before containment. Apply reversible containment first, such as temporary DC access restrictions for the recovered source or heightened monitoring on the writer and dMSA. Disable the writer or isolate the source host only if privileged follow-on changes, unexpected authentication, or related events appear.
- If confirmed malicious, preserve the same directory-change and session evidence first, then remove the unauthorized dMSA and roll back related msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPN, delegation, or membership changes found in the same-object sequence. Isolate the recovered source host when endpoint response is available and host criticality permits, then disable or reset the compromised writer and any linked service accounts.
- Before deleting objects or closing the case, review hosts and services that used the new dMSA, verify rollback replication across domain controllers, then rotate affected secrets or restore service bindings.
- Post-incident hardening: restrict who can create dMSAs or start service-account migration, review CreateChild and delegated managed service account rights on service-account OUs, retain `5136`, `5137`, `4624`, and `4648` coverage on domain controllers, and record the confirmed workflow or BadSuccessor evidence pattern for future triage.
"""

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",
    "user.name",
    "user.id",
    "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.DSName",
    "host.name",
    "host.id",
    "winlog.computer_name",
]

[transform]

[[transform.investigate]]
label = "Directory changes for the same dMSA object on this controller"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" },
    { excluded = false, field = "event.code", queryType = "phrase", value = "5137", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", 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 = "Windows Security events associated with the modifying account"
description = ""
providers = [
  [
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", 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 = "Windows Security events associated with the new dMSA object"
description = ""
providers = [
  [
    { 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.threat]]
framework = "MITRE ATT&CK"

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

[[rule.threat.technique.subtechnique]]
id = "T1136.002"
name = "Domain Account"
reference = "https://attack.mitre.org/techniques/T1136/002/"

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

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

[rule]
author = ["Elastic"]
description = """
Identifies a sign-in using the Azure Active Directory PowerShell module. PowerShell for Azure Active Directory allows
for managing settings from the command line, which is intended for users who are members of an admin role.
"""
false_positives = [
    """
    Sign-ins using PowerShell may be done by a system or network administrator. Verify whether the username, hostname,
    and/or resource name should be signing into your environment. Sign-ins from unfamiliar users or hosts should be
    investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-9m"
index = ["logs-azure.signinlogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID PowerShell Sign-in"
note = """## Triage and analysis

### Investigating Entra ID PowerShell Sign-in

Azure Active Directory PowerShell for Graph (Azure AD PowerShell) is a module IT professionals commonly use to manage their Azure Active Directory. The cmdlets in the Azure AD PowerShell module enable you to retrieve data from the directory, create new objects in the directory, update existing objects, remove objects, as well as configure the directory and its features.

This rule identifies sign-ins that use the Azure Active Directory PowerShell module, which can indicate unauthorized access if done outside of IT or engineering.

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Evaluate whether the user needs to access Azure AD using PowerShell to complete its tasks.
- Investigate other alerts associated with the user account during the past 48 hours.
- Consider the source IP address and geolocation for the involved user account. Do they look normal?
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate suspicious actions taken by the user using the module, for example, modifications in security settings that weakens the security policy, persistence-related tasks, and data access.
- 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 activity is expected and noisy in your environment, consider adding IT, Engineering, and other authorized users as exceptions — preferably with a combination of user and device conditions.

### 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.
- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.
- 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 Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/",
    "https://docs.microsoft.com/en-us/microsoft-365/enterprise/connect-to-microsoft-365-powershell?view=o365-worldwide",
]
risk_score = 21
rule_id = "a605c51a-73ad-406d-bf3a-f24cc41d5c97"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Initial Access",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.signinlogs and
  azure.signinlogs.properties.app_display_name:"Azure Active Directory PowerShell" and
  azure.signinlogs.properties.token_issuer_type:AzureAD and event.outcome:(success or Success)
'''


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



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"



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

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

[rule]
author = ["Elastic"]
description = """
Identifies when a service principal authenticates using a federated identity credential for the first time in the
historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity
provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries
may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time
federated credential usage for a service principal warrants investigation to determine if the external identity provider
is legitimate.
"""
false_positives = [
    """
    New CI/CD pipeline deployments using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule when
    federated authentication is first used. Validate the issuer URL against approved identity providers.
    """,
    """
    Application migrations or reconfigurations that switch from certificate/secret authentication to federated
    credentials will appear as new behavior. Confirm with application owners.
    """,
    """New workload identity federation configurations for legitimate automation will trigger on first use.
    """
]
from = "now-9m"
index = ["logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Service Principal Federated Credential Authentication by Unusual Client"
note = """## Triage and analysis

### Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client

If this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the
compromised application for the first time.

### Possible investigation steps

- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`.
- Critical: Check the application's federated credential configuration in Entra ID:
  - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)?
  - When was the federated credential added? Was it recent?
  - Who added the federated credential?
- Review the `service_principal_credential_thumbprint` - does it match expected certificates?
- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure?
- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`.
- Correlate with Graph Activity logs to see what API calls were made with this token.
- Use the `correlation_id` to find related sign-in and activity events.
- Review audit logs for recent changes to this application's federated credentials.

### False positive analysis

- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use.
- New application deployments with workload identity federation are expected to show as new behavior.
- Validate the issuer URL against approved identity providers before dismissing.
- Create baseline of applications expected to use federated credentials.

### Response and remediation

- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration.
- Review the external IdP issuer URL configured on the application - is it legitimate?
- If BYOIDP is confirmed:
    - Remove the malicious federated credential immediately.
    - Revoke active sessions and tokens for the affected service principal.
    - Audit what actions were performed using the compromised identity.
    - Investigate how the federated credential was added (compromised admin account)."""
references = [
    "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/",
    "https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation",
    "https://github.com/dirkjanm/ROADtools",
]
risk_score = 73
rule_id = "616b8d00-05f8-11f1-8f33-f661ea17fbce"
setup = """#### Required Microsoft Entra ID Sign-In Logs
To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration.
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-In Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Tactic: Defense Evasion",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs"
    and azure.signinlogs.category: "ServicePrincipalSignInLogs"
    and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential"
    and azure.signinlogs.result_signature: "SUCCESS"
    and azure.signinlogs.properties.app_id: *
    and not azure.signinlogs.properties.app_owner_tenant_id: (
        "f8cdef31-a31e-4b4a-93e4-5f571e91255a" or
        "72f988bf-86f1-41af-91ab-2d7cd011db47"
    )
'''

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

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

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

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

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

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

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

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

[[rule.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.investigation_fields]
field_names = [
    "azure.signinlogs.properties.service_principal_name",
    "azure.signinlogs.properties.service_principal_id",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.app_owner_tenant_id",
    "azure.signinlogs.properties.client_credential_type",
    "azure.signinlogs.properties.service_principal_credential_thumbprint",
    "azure.signinlogs.caller_ip_address",
    "azure.signinlogs.properties.resource_display_name",
    "azure.signinlogs.properties.unique_token_identifier",
    "azure.correlation_id",
    "azure.signinlogs.properties.session_id",
    "source.geo.country_name",
    "source.geo.city_name",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.signinlogs.properties.app_id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[rule]
description = """
Identifies when a Windows script interpreter executes a file downloaded via commonly abused legit Windows binaries such
as Certutil or BitsAdmin.
"""
id = "f60d4c82-2de5-4c70-95f5-cde9f3ad41a7"
license = "Elastic License v2"
name = "Execution of a Windows Script Downloaded via a LOLBIN"
os_list = ["windows"]
version = "1.0.30"

query = '''
sequence by process.parent.entity_id with maxspan=1m
 [process where event.type == "start" and
  (process.pe.original_file_name : ("certutil.exe", "bitsadmin.exe", "CertReq.exe", "curl.exe") or
   process.executable : "?:\\Windows\\Sys*\\OpenSSH\\sftp.exe") and
  process.command_line : ("*download*", "*transfer*", "*-decode*", "*http*", "* -o*", "* --output*")]
 [process where event.type == "start" and process.pe.original_file_name : ("wscript.exe", "mshta.exe") and
  not (process.working_directory : "E:\\*" and process.name : "cscript.exe" and process.args : ("loadpromo.vbs", "LoadMasterStocks.vbs")) and
  not (process.parent.name : "cmd.exe" and
       process.parent.args :
            ("C:\\ProgramData\\NinjaRMMAgent\\scripting\\customscript_gen_?.bat-ninjascript.bat",
             "C:\\Storage\\VisualStudioProjects\\connect_wise_script\\install_speerity.bat"))]
'''

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

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

[[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.005"
name = "Visual Basic"
reference = "https://attack.mitre.org/techniques/T1059/005/"

[[threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1197"
name = "BITS Jobs"
reference = "https://attack.mitre.org/techniques/T1197/"

[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[threat.technique.subtechnique]]
id = "T1218.005"
name = "Mshta"
reference = "https://attack.mitre.org/techniques/T1218/005/"



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


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Detects the execution of an un-executable file, per file extension, via a shell interpreter. Sometimes threat actors
will masquerade their payloads as non-executable files in order to avoid suspicion and go unnoticed.
"""
id = "c0770406-7ede-4049-a7a1-999c15fb60bd"
license = "Elastic License v2"
name = "Execution of Non-Executable File via Shell"
os_list = ["macos"]
version = "1.0.22"

query = '''
process where event.type == "start" and event.action == "exec" and 
 (process.name in ("bash", "sh", "zsh", "dash", "csh", "tcsh", "ksh", "tclsh", "fish") or process.name like "tclsh*") and
 process.command_line like ("/bin/bash *", "/bin/sh *", "/bin/zsh *", "/bin/dash *", "/bin/csh *", "/bin/tcsh *", "/bin/ksh *", "/bin/tclsh*", "/bin/fish *",
                            "/usr/bin/bash *", "/usr/bin/sh *", "/usr/bin/zsh *", "/usr/bin/dash *", "/usr/bin/csh *", "/usr/bin/tcsh *", "/usr/bin/ksh *", "/usr/bin/tclsh*", "/usr/bin/fish *",
                            "/usr/local/bin/bash *", "/usr/local/bin/sh *", "/usr/local/bin/zsh *", "/usr/local/bin/dash *", "/usr/local/bin/csh *", "/usr/local/bin/tcsh *", "/usr/local/bin/ksh *", "/usr/local/bin/tclsh*", "/usr/local/bin/fish *",
                            "/opt/homebrew/bin/bash *", "/opt/homebrew/bin/sh *", "/opt/homebrew/bin/zsh *", "/opt/homebrew/bin/dash *", "/opt/homebrew/bin/csh *", "/opt/homebrew/bin/tcsh *", "/opt/homebrew/bin/ksh *", "/opt/homebrew/bin/tclsh*", "/opt/homebrew/bin/fish *") and
 process.command_line like ("*.pid", "*.plist", "*.txt", "*.json", "*.tmp", "*.bin", "*.js", "*.nib", "*.log", "*.dat") and
 process.args_count == 2
'''

min_endpoint_version = "8.10.2"
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.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"


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

[internal]
min_endpoint_version = "8.10.2"

[metadata]
creation_date = "2023/11/07"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = "Identifies the first occurrence of an Okta user session started via a proxy."
index = ["filebeat-*", "logs-okta.system-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Occurrence of Okta User Session Started via Proxy"
note = """## Triage and analysis

### Investigating First Occurrence of Okta User Session Started via Proxy

This rule detects the first occurrence of an Okta user session started via a proxy. This rule is designed to help identify suspicious authentication behavior that may be indicative of an attacker attempting to gain access to an Okta account while remaining anonymous. This rule leverages the New Terms rule type feature where the `okta.actor.id` value is checked against the previous 7 days of data to determine if the value has been seen before for this activity.

#### Possible investigation steps:
- Identify the user involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
- Examine the `okta.debug_context.debug_data.flattened` field for more information about the proxy used.
- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy.
- Review the past activities of the actor involved in this action by checking their previous actions.
- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.

### False positive analysis:
- A user may have legitimately started a session via a proxy for security or privacy reasons.

### Response and remediation:
- Review the profile of the user involved in this action to determine if proxy usage may be expected.
- If the user is legitimate and the authentication behavior is not suspicious, no action is required.
- If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA).
    - If MFA is already enabled, consider resetting MFA for the user.
- If the user is not legitimate, consider deactivating the user's account.
- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
"""
references = [
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://developer.okta.com/docs/reference/api/system-log/#issuer-object",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
    "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft"
]
risk_score = 47
rule_id = "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Identity",
    "Tactic: Initial Access",
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Data Source: Okta System Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:okta.system and
    okta.event_type: (
        user.session.start or
        user.authentication.verify or
        user.authentication.sso or
        user.authentication.auth_via_mfa
    ) and
    okta.security_context.is_proxy:true and
    not okta.actor.id: okta*
'''


[[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.technique]]
id = "T1133"
name = "External Remote Services"
reference = "https://attack.mitre.org/techniques/T1133/"

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

[rule.new_terms]
field = "new_terms_fields"
value = ["okta.actor.id", "cloud.account.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

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

[rule]
author = ["Elastic"]
description = """
Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before
exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is
partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API
resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and
orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that
cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC
resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on
actions.
"""
false_positives = [
    """
    Platform operators, installers, or runbooks that reconcile RBAC and workload state may span these resource types
    in a short window; tune by identity, source IP, or user agent when documented.
    """,
    """
    GitOps controllers and cluster scanners can still match if not covered by built-in exclusions; baseline approved
    service accounts after review.
    """,
]
from = "now-6m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "GKE Multi-Resource Discovery"
note = """## Triage and analysis

### Investigating GKE Multi-Resource Discovery

The rule groups GKE audit get/list events on namespaces, nodes, pods, configmaps, serviceaccounts, roles,
rolebindings, clusterroles, and clusterrolebindings into one-minute windows per `client.user.email`, `source.ip`,
and `user_agent.original`. It alerts when five or more distinct resource kinds appear and the burst includes both
cluster-layout kinds (namespaces, pods, or nodes) and RBAC kinds. Allowed and denied authorizations are both
included: failures still signal probing.

### Possible investigation steps

- Review `Esql.enumerated_resources`, `Esql.enumerated_namespaces`, and `Esql.enumerated_resource_names` for
  ordering and targeted APIs.
- Confirm whether `source.ip` and `user_agent.original` match expected admin or automation clients.
- Correlate with follow-on secret reads, RoleBinding changes, pod exec, or unusual user agents from the same actor.

### False positive analysis

- Documented platform sync jobs that read layout and RBAC together; exclude known service accounts after validation.
- Upgrade or install windows that briefly query many resource kinds; correlate with change records.

### Response and remediation

- If malicious, revoke or rotate the implicated credentials, tighten RBAC, and inspect for data access or persistence
  established after the burst.
"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
]
risk_score = 47
rule_id = "0302d3b2-1892-4448-a805-980aa4a36ba3"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-gcp.audit-* metadata _id, _index, _version
| where data_stream.dataset == "gcp.audit"
    and service.name == "k8s.io"
    and event.action in (
      "io.k8s.core.v1.namespaces.get",
      "io.k8s.core.v1.namespaces.list",
      "io.k8s.core.v1.nodes.get",
      "io.k8s.core.v1.nodes.list",
      "io.k8s.core.v1.pods.get",
      "io.k8s.core.v1.pods.list",
      "io.k8s.core.v1.configmaps.get",
      "io.k8s.core.v1.configmaps.list",
      "io.k8s.core.v1.serviceaccounts.get",
      "io.k8s.core.v1.serviceaccounts.list",
      "io.k8s.authorization.rbac.v1.roles.get",
      "io.k8s.authorization.rbac.v1.roles.list",
      "io.k8s.authorization.rbac.v1.rolebindings.get",
      "io.k8s.authorization.rbac.v1.rolebindings.list",
      "io.k8s.authorization.rbac.v1.clusterroles.get",
      "io.k8s.authorization.rbac.v1.clusterroles.list",
      "io.k8s.authorization.rbac.v1.clusterrolebindings.get",
      "io.k8s.authorization.rbac.v1.clusterrolebindings.list"
    )
    and source.ip is not null
    and client.user.email is not null
    and not to_string(source.ip) in ("127.0.0.1", "::1")
    and not client.user.email like "system:kube-*"
    and not client.user.email like "system:gke-*"
    and not client.user.email like "system:node:*"
    and not client.user.email like "system:serviceaccount:kube-system:*"
    and not client.user.email like "system:serviceaccount:gke-managed*"
    and not client.user.email in (
      "system:apiserver",
      "system:addon-manager",
      "system:kubestore-collector",
      "gcp:kube-bootstrap",
      "system:serviceaccount:security:trivy-operator"
    )
    and not client.user.email like "system:serviceaccount:flux-system:*"
    and not client.user.email like "system:serviceaccount:argocd:*"
    and not client.user.email like "system:serviceaccount:argocd-system:*"
    and not client.user.email like "system:serviceaccount:cattle-turtles-system:*"
    and not client.user.email like "system:serviceaccount:*:palette-manager"
| eval Esql.time_interval = date_trunc(1 minute, @timestamp),
  Esql.resource_kind = case(
    event.action in ("io.k8s.core.v1.namespaces.get", "io.k8s.core.v1.namespaces.list"), "namespaces",
    event.action in ("io.k8s.core.v1.nodes.get", "io.k8s.core.v1.nodes.list"), "nodes",
    event.action in ("io.k8s.core.v1.pods.get", "io.k8s.core.v1.pods.list"), "pods",
    event.action in ("io.k8s.core.v1.configmaps.get", "io.k8s.core.v1.configmaps.list"), "configmaps",
    event.action in ("io.k8s.core.v1.serviceaccounts.get", "io.k8s.core.v1.serviceaccounts.list"), "serviceaccounts",
    event.action in ("io.k8s.authorization.rbac.v1.roles.get", "io.k8s.authorization.rbac.v1.roles.list"), "roles",
    event.action in ("io.k8s.authorization.rbac.v1.rolebindings.get", "io.k8s.authorization.rbac.v1.rolebindings.list"), "rolebindings",
    event.action in ("io.k8s.authorization.rbac.v1.clusterroles.get", "io.k8s.authorization.rbac.v1.clusterroles.list"), "clusterroles",
    event.action in ("io.k8s.authorization.rbac.v1.clusterrolebindings.get", "io.k8s.authorization.rbac.v1.clusterrolebindings.list"), "clusterrolebindings",
    null
  ),
  Esql.is_rbac = case(
    event.action in (
      "io.k8s.authorization.rbac.v1.roles.get",
      "io.k8s.authorization.rbac.v1.roles.list",
      "io.k8s.authorization.rbac.v1.rolebindings.get",
      "io.k8s.authorization.rbac.v1.rolebindings.list",
      "io.k8s.authorization.rbac.v1.clusterroles.get",
      "io.k8s.authorization.rbac.v1.clusterroles.list",
      "io.k8s.authorization.rbac.v1.clusterrolebindings.get",
      "io.k8s.authorization.rbac.v1.clusterrolebindings.list"
    ),
    1,
    0
  ),
  Esql.is_layout = case(
    event.action in (
      "io.k8s.core.v1.namespaces.get",
      "io.k8s.core.v1.namespaces.list",
      "io.k8s.core.v1.pods.get",
      "io.k8s.core.v1.pods.list",
      "io.k8s.core.v1.nodes.get",
      "io.k8s.core.v1.nodes.list"
    ),
    1,
    0
  )
| stats
    Esql.unique_resources = count_distinct(Esql.resource_kind),
    Esql.rbac_event_count = sum(Esql.is_rbac),
    Esql.layout_event_count = sum(Esql.is_layout),
    Esql.enumerated_resources = values(Esql.resource_kind),
    Esql.enumerated_namespaces = values(orchestrator.namespace),
    Esql.enumerated_resource_names = values(gcp.audit.resource_name),
    Esql.event_outcome_values = values(event.outcome)
  by client.user.email, source.ip, user_agent.original, Esql.time_interval
| where Esql.unique_resources >= 5
    and Esql.rbac_event_count > 0
    and Esql.layout_event_count > 0
| keep Esql.*, client.user.email, source.ip, user_agent.original
'''

[rule.alert_suppression]
group_by = ["client.user.email", "source.ip"]
duration = {value = 30, unit = "m"}
missing_fields_strategy = "suppress"

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become
cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege
expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role
after apply; loopback source IPs are ignored.
"""
false_positives = [
    """
    Platform installers, GitOps controllers, and emergency break-glass roles sometimes ship or widen wildcard
    ClusterRoles; correlate with change records and narrow by user or service account when baselined.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE RBAC Wildcard Elevation on Existing Role"
note = """## Triage and analysis

### Investigating GKE RBAC Wildcard Elevation on Existing Role

Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near
cluster-admin breadth on that scope. Confirm the actor (user.email, groups), client, and non-loopback source IP;
then see who can bind that role.

### Possible investigation steps

- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects
  gained the widened access.
- Review `gcp.audit.resource_name`, `gcp.audit.response.rules.verbs`, and `gcp.audit.response.rules.resources`.
- In the same window, check secret reads, exec, and further RBAC changes from the same identity.

### False positive analysis

- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented.

### Response and remediation

- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside
  governed pipelines (policy-as-code, PR-only RBAC).

"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
]
risk_score = 73
rule_id = "563a38e9-9790-4a6a-8889-24d26055b832"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:(
  "io.k8s.authorization.rbac.v1.roles.update" or
  "io.k8s.authorization.rbac.v1.roles.patch" or
  "io.k8s.authorization.rbac.v1.clusterroles.update" or
  "io.k8s.authorization.rbac.v1.clusterroles.patch"
) and source.ip:(* and not ("127.0.0.1" or "::1")) and not (
  client.user.email:"system:addon-manager" and
  event.action:(
    "io.k8s.authorization.rbac.v1.roles.patch" or
    "io.k8s.authorization.rbac.v1.clusterroles.patch"
  )
) and
gcp.audit.response.rules.verbs:"*" and gcp.audit.response.rules.resources:"*"
'''

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

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

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

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

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

[rule]
description = """
This rule identifies when a built-in utility is used to decode and decrypt a payload on a Linux system. Malware authors
may attempt to evade detection and trick users into executing malicious code by encoding and encrypting their payload.
"""
id = "cc8a82b6-eb6e-4e35-8c9e-e6ec3339e12d"
license = "Elastic License v2"
name = "Linux Payload Decoded and Decrypted via Built-in Utility"
os_list = ["linux"]
version = "1.0.14"

query = '''
process where event.type == "start" and event.action == "exec" and process.parent.executable like (
  "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/run/*", "/root/*", "/boot/*", "/var/www/html/*", "/opt/.*"
) and (
  (process.name in ("base64", "base32", "base16") and process.args like "*-*d*") or
  (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-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*")
) and not (
  process.parent.executable like (
    "/tmp/newroot/*", "/tmp/jwt_vf.sh", "/root/*.sh", "/tmp/.criu.mntns*", "/var/tmp/buildah*/mnt/rootfs/var/lib/dpkg/info/nmap-common.postinst",
    "/tmp/.mount_*/usr/share/cursor/cursor", "/root/.local/share/claude/versions/*"
  ) or
  process.parent.command_line like ("*/tmp/__salt.tmp.*.sh", "*/home/*/.claude/shell-snapshots/snapshot-*", "claude", "/root/.claude/*") or
  process.args == "/usr/bin/coreutils" or
  (
    process.parent.name like "python*" and (
      (process.parent.args == "test.regrtest" and process.parent.args == "--pgo") or
      (process.parent.command_line like~ "./python -m test --pgo*")
    )
  )
)
'''

min_endpoint_version = "7.15.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.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"


[[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 = "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 = "7.15.0"