Elastic rules: 24

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

[rule]
author = ["Elastic"]
description = """
Detects the creation of an AWS Bedrock AgentCore resource (code interpreter, agent runtime, browser, or harness) with an
IAM execution role attached. When an attacker with iam:PassRole permission creates an AgentCore resource and attaches a
privileged role, subsequent invocations inside that resource execute as the attached role — enabling privilege
escalation to roles that trust bedrock-agentcore.amazonaws.com.
"""
false_positives = [
    """
    Legitimate provisioning of Bedrock AgentCore resources by CI/CD pipelines or platform engineers. Validate the caller
    identity against expected provisioning principals and verify the attached role is commensurate with the workload's
    documented requirements.
    """,
]
from = "now-9m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock AgentCore Resource Created with IAM Execution Role"
note = """## Triage and analysis

### Investigating AWS Bedrock AgentCore Resource Created with IAM Execution Role

AWS Bedrock AgentCore services (code interpreters, agent runtimes, browsers, harnesses) run user workloads inside isolated MicroVMs. When an IAM role is attached at creation time, all code executing inside the resource assumes that role's identity. An attacker with iam:PassRole and bedrock-agentcore:Create* permissions can attach a privileged role and then invoke the resource to operate as that role.

The four Create* events covered here are management-plane events logged to CloudTrail by default. The subsequent Start*/Invoke* data-plane events are NOT captured by the default management events trail and cannot be detected without enabling data-plane logging.

### Possible investigation steps

- Check the caller identity (`aws.cloudtrail.user_identity.arn`) against expected provisioning principals. Unexpected users or roles creating AgentCore resources should be investigated.
- Examine `aws.cloudtrail.request_parameters` for the attached role ARN (`executionRoleArn` or `roleArn`) and evaluate whether that role has permissions beyond what the AgentCore workload legitimately requires.
- Check for subsequent `StartCodeInterpreterSession`, `StartBrowserSession`, or `InvokeAgentRuntime` events from the same caller against the newly created resource (requires data-plane logging to be enabled).
- Review the IAM PassRole permission of the calling identity and whether it is constrained by `iam:PassedToService` conditions.

### False positive analysis

- Automated provisioning by CDK/CloudFormation/Terraform with a known service account.
- Platform engineering pipelines deploying Bedrock-based AI workloads.
- Filter on `user_agent.original` for known IaC tools.

### Response and remediation

- Suspend the calling identity's iam:PassRole permission while investigating.
- Delete the newly created AgentCore resource to stop active sessions.
- Rotate the attached execution role's credentials if exploitation is confirmed.
- Enable data-plane logging for bedrock-agentcore to detect subsequent session invocations.
"""
references = [
    "https://www.beyondtrust.com/blog/entry/aws-agentcore-privilege-escalation",
]
risk_score = 47
rule_id = "2d8f6e1a-4b7c-4f9d-8e3a-1c5d2f8b9a0e"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Bedrock",
    "Service: AWS IAM",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset: "aws.cloudtrail" and
  event.provider: "bedrock-agentcore.amazonaws.com" and
  event.action: (
    "CreateCodeInterpreter" or
    "CreateAgentRuntime" or
    "CreateBrowser" or
    "CreateHarness"
  ) and
  event.outcome: "success" and
  aws.cloudtrail.request_parameters: (*executionRoleArn* or *roleArn*) and
  not aws.cloudtrail.user_identity.invoked_by: ("bedrock-agentcore.amazonaws.com" or "cloudformation.amazonaws.com")
'''


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



[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "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/"

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

[rule]
author = ["Elastic"]
description = """
Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either
by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model
agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can
subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or
under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable
ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the
attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted.
"""
false_positives = [
    """
    Access-denied errors can result from benign permission gaps: a newly created role or user whose IAM policy has not
    yet been provisioned, automation pipelines running ahead of permission grants, or ML teams experimenting in
    non-production accounts during onboarding. Verify that the principal, source IP, and user agent are expected before
    escalating. Recurring denials from known onboarding or provisioning workflows can be exempted for specific users or
    roles.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Unauthorized Foundation Model Access Attempt"
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 Bedrock Unauthorized Foundation Model Access Attempt

Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls.

This rule detects Bedrock control-plane calls that enable model access at the account level but were denied (`AccessDenied` / unauthorized). A denial indicates an identity attempting an action it is not permitted to perform, which is a strong signal of boundary-testing by a compromised or under-privileged principal even though no model access was granted.

### Possible investigation steps

- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity has any legitimate reason to manage Bedrock model access. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient permission gap.
- Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason, and review `event.action` to determine which model-access action was attempted.
- Verify the `source.ip` and `user_agent.original` of the request. An unexpected IP, geolocation, or automation user agent is suspicious.
- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment.
- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or repeated denials across Bedrock/IAM APIs, which can indicate permission enumeration or escalation attempts.
- Determine whether the identity later succeeded on the same or related actions (e.g., after acquiring new permissions), and check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity.

### False positive analysis

- Newly provisioned roles/users or infrastructure-as-code pipelines running before model-access permissions are applied may generate transient denials. Validate against change-management records and known provisioning workflows.
- ML teams exploring model adoption in sandbox accounts may hit denials; confirm the account and identity context.

### Response and remediation

- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) and review the actor's recent activity.
- Review all Bedrock and IAM activity from the same identity in the surrounding window for successful access grants, permission changes, or other persistence attempts.
- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs, and alert on both denied and successful calls.
- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled.
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html"
]
risk_score = 21
rule_id = "3d2e8c90-5be7-4a57-9de4-58be75af933f"
severity = "low"
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",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "bedrock.amazonaws.com"
    and event.action: (
        "PutFoundationModelEntitlement" or
        "PutUseCaseForModelAccess" or
        "CreateFoundationModelAgreement"
    )
    and event.outcome: "failure"
    and aws.cloudtrail.error_code: (
        "AccessDenied" or
        "AccessDeniedException"
    )
'''

[[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.access_key_id",
    "event.action",
    "event.outcome",
    "aws.cloudtrail.error_code",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

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

[rule]
author = ["Elastic"]
description = """
Detects when an AWS Identity and Access Management (IAM) customer-managed policy is attached to a role by an unusual or
unauthorized user. Customer-managed policies are policies created and controlled within an AWS account, granting
specific permissions to roles or users when attached. This rule identifies potential privilege escalation by flagging
cases where a customer-managed policy is attached to a role by an unexpected actor, which could signal unauthorized
access or misuse. Attackers may attach policies to roles to expand permissions and elevate their privileges within the
AWS environment. This is a New Terms rule that uses the "cloud.account.id", "user.name" and "entity.target.id" fields to
check if the combination of the actor identity and target role name has not been seen before.
"""
false_positives = [
    """
    Legitimate IAM administrators may attach customer-managed policies to roles for various reasons, such as granting
    temporary permissions or updating existing policies. Ensure that the user attaching the policy is authorized to do
    so and that the action is expected.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM Customer-Managed Policy Attached to Role by Rare User"
note = """## Triage and analysis

### Investigating AWS IAM Customer-Managed Policy Attached to Role by Rare User

This rule detects when a customer-managed IAM policy is attached to a role by an unusual or unauthorized user. This activity may indicate a potential privilege escalation attempt within the AWS environment. Adversaries could attach policies to roles to expand permissions, thereby increasing their capabilities and achieving elevated access.

#### Possible Investigation Steps

- **Identify the Initiating User and Target Role**:
  - **User Identity**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the user who initiated the policy attachment. Confirm if this user typically has permissions to modify IAM roles and if their activity is consistent with their usual responsibilities.
  - **Target Role**: Review `entity.target.id` to identify the role to which the policy was attached. Assess whether modifying this role is expected for this user or if this action is unusual in your environment.

- **Analyze the Attached Policy**:
  - **Policy ARN**: Inspect the `aws.cloudtrail.request_parameters` field to identify the specific customer-managed policy attached to the role. Evaluate if this policy grants sensitive permissions, especially permissions that could enable privileged actions or data access.
  - **Policy Permissions**: Examine the policy content to determine the scope of permissions granted. Policies enabling actions like `s3:*`, `ec2:*`, or `iam:*` could be leveraged for broader access, persistence, or lateral movement.

- **Review Source and User Agent Details**:
  - **Source IP and Location**: Analyze the `source.ip` and `source.geo` fields to confirm the IP address and geographic location where the policy attachment originated. Verify if this matches expected locations for the initiating user.
  - **User Agent Analysis**: Examine `user_agent.original` to determine if AWS CLI, SDK, or other tooling was used to perform this action. Tool identifiers like `aws-cli` or `boto3` may indicate automation, while others may suggest interactive sessions.

- **Evaluate Anomalous Behavior Patterns**:
  - **User’s Historical Activity**: Check if the initiating user has a history of attaching policies to roles. An unusual pattern in policy attachments could indicate suspicious behavior, especially if the user lacks authorization.
  - **Role Modification History**: Investigate if the targeted role is frequently modified by this or other users. Repeated, unauthorized modifications to a role could signal an attempt to maintain elevated access.

- **Correlate with Related CloudTrail Events**:
  - **Other IAM or CloudTrail Activities**: Look for recent actions associated with the same user or role by reviewing `event.action` and `event.provider` to identify which AWS services were accessed. This may provide context on the user’s intent or additional actions taken.
  - **Broader Suspicious Patterns**: Identify if similar anomalous events have recently occurred, potentially suggesting a coordinated or escalating attack pattern within the AWS account.

### False Positive Analysis

- **Authorized Administrative Actions**: IAM administrators may legitimately attach policies to roles as part of routine role management. Verify if the user is authorized and if the activity aligns with expected administrative tasks.
- **Role-Specific Modifications**: Roles that frequently undergo policy updates may trigger this rule during standard operations. Consider monitoring for patterns or establishing known exceptions for specific users or roles where appropriate.

### Response and Remediation

- **Immediate Access Review**: If the policy attachment is unauthorized, consider detaching the policy and reviewing the permissions granted to the initiating user.
- **Restrict Role Modification Permissions**: Limit which users or roles can attach policies to critical IAM roles. Apply least privilege principles to reduce the risk of unauthorized policy changes.
- **Enhance Monitoring and Alerts**: Enable real-time alerts and monitoring on IAM policy modifications to detect similar actions promptly.
- **Regular Policy Audits**: Conduct periodic audits of IAM policies and role permissions to ensure that unauthorized changes are quickly identified and addressed.

### Additional Information

For more information on managing IAM policies and roles in AWS environments, refer to the [AWS IAM Documentation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) and AWS security best practices.
"""
references = ["https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html"]
risk_score = 21
rule_id = "f6d07a70-9ad0-11ef-954f-f661ea17fbcd"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS IAM",
    "Tactic: Privilege Escalation",
    "Rule Type: New Terms",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: "AttachRolePolicy"
    and event.outcome: "success"
    and not related.entity: arn\:aws\:iam\:\:aws\:policy*
    and not user_agent.original: (*Terraform* or *Pulumi*)
'''


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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1548.005"
name = "Temporary Elevated Cloud Access"
reference = "https://attack.mitre.org/techniques/T1548/005/"

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

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

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

[rule.threat.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",
    "entity.target.id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

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

[metadata]
creation_date = "2020/04/23"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/12/19"

[rule]
author = ["Elastic"]
description = """
Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet
network connections to non-publicly routable IP addresses.
"""
false_positives = [
    """
    Telnet can be used for both benign or malicious purposes. Telnet is included by default in some Linux distributions,
    so its presence is not inherently suspicious. The use of Telnet to manage devices remotely has declined in recent
    years in favor of more secure protocols such as SSH. Telnet usage by non-automated tools or frameworks may be
    suspicious.
    """,
]
from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
language = "eql"
license = "Elastic License v2"
name = "Connection to Internal Network via Telnet"
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 Connection to Internal Network via Telnet

Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response.

### Possible investigation steps

- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet.
- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt.
- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection.
- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt.
- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts.
- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat.

### False positive analysis

- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks.
- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts.
- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives.
- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives.
- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration.
- Terminate any active Telnet sessions on the affected host to stop unauthorized access.
- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed.
- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access.
- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation.
- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
risk_score = 47
rule_id = "1b21abcc-4d9f-4b08-a7f5-316f5f94b973"
setup = """## Setup

This rule requires data coming in from one of the following integrations:
- Elastic Defend
- Auditbeat

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

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

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

### Auditbeat Setup
Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by process.entity_id
  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name == "telnet"]
  [network where host.os.type == "linux" and process.name == "telnet" and cidrmatch(
     destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
     "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
     "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
     "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
     "FF00::/8"
    )
  ]
'''

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

[[rule.threat.technique]]
id = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"

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

[rule]
description = """
Detects the use of the Open binary to open a file from a suspicious location via the Apple Preview application. Threat
actors commonly display decoy files or images to appear legitimate and distract users from malicious activities running
in the background, often as part of Gatekeeper bypass or initial infection chains.
"""
id = "87bbe441-6b10-47b8-bd1b-0732cb4bb7c8"
license = "Elastic License v2"
name = "Decoy file Open via Preview App"
os_list = ["macos"]
reference = [
    "https://pberba.github.io/security/2025/11/11/macos-infection-vector-applescript-bypass-gatekeeper/",
]
version = "1.0.1"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "open" and
  process.args in ("-a", "-g") and process.args == "/System/Applications/Preview.app" and
  process.args like ("/Users/Shared/*", "/tmp/*", "/private/tmp/*", "/var/tmp/*", "/private/var/tmp/*", "/var/root/*", "/private/var/root/*") and
  process.args_count <= 4
'''

min_endpoint_version = "8.16.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 = "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 = "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.16.0"

[rule]
description = """
Identifies modifications to some Windows security related configurations settings via registry changes to disable
certain protection or hardening features and performed by a suspicious process.
"""
id = "e3938d6e-8f66-4871-88c7-442a530f8119"
license = "Elastic License v2"
name = "Defense Evasion via Registry Modification"
os_list = ["windows"]
version = "1.0.23"

query = '''
registry where not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and

 (process.code_signature.exists == false or
  process.name : ("powershell.exe", "reg.exe", "cscript.exe", "wscript.exe", "mshta.exe", "winword.exe", "excel.exe") or
  process.executable : ("?:\\Windows\\Microsoft.NET\\*", "?:\\Users\\Public\\*", "?:\\Users\\*\\AppData\\*")) and

 registry.path : ("HK*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\*") and

 (
   (registry.value : ("EnableUA", "ConsentPromptBehaviorAdmin", "PromptOnSecureDesktop") and registry.data.strings : "0") or

   (registry.value : ("DisableTaskMgr", "DisableRegistryTools", "DisableArchiveScanning") and registry.data.strings : "1") or

    registry.value : "DisableCMD" or

    (registry.path : "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Notifications\\Settings\\Windows.SystemToast.SecurityAndMaintenance\\Enabled" and
     registry.data.strings : "0")
 ) and
 not (registry.value : "DisableTaskMgr" and
      process.executable : ("?:\\Program Files (x86)\\Green's MCI\\MCI.exe",
                            "?:\\Program Files (x86)\\Green's NV-MSVT\\NV-MSVT.exe",
                            "?:\\Program Files (x86)\\Green's MSVT\\MSVT.exe")) and
 not (process.code_signature.subject_name : ("Barco N.V.", "Advantig Corporation") and process.code_signature.trusted == true)
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

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



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

[internal]
min_endpoint_version = "8.1.0"

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

[rule]
author = ["Elastic"]
description = """
Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker
(29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service
(01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the
authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This
behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary
Refresh Token (PRT) or establishing a trusted session.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID ADRS Token Request by Microsoft Authentication Broker"
note = """## Triage and analysis

### Investigating Entra ID ADRS Token Request by Microsoft Authentication Broker

Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session.

### Possible investigation steps
- Identify the user principal associated with the request by checking `azure.signinlogs.properties.user_principal_name` or `azure.signinlogs.properties.user_id`.
- Review the `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.resource_id` to confirm the request is made by the Microsoft Authentication Broker and targeting the Device Registration Service.
- Examine the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` for the presence of `adrs_access`, indicating an attempt to access ADRS.
- Check the `azure.signinlogs.properties.incoming_token_type` to confirm the request is made using a refresh token, which is typical for persistent access scenarios.
- Review the `azure.signinlogs.properties.user_type` to ensure it is a "Member" user, as this behavior is unusual for standard user accounts.
- Review the `source.address` and `source.geo.country_name` to identify the origin of the request. Look for any anomalies or unexpected locations.
- Check the `azure.signinlogs.properties.device_detail.operating_system` and `azure.signinlogs.properties.device_detail.browser` to identify the device and browser used for the request. Look for any unusual or unexpected devices for this user.
- Use the `azure.signinlogs.properties.session_id` to correlate this request with other sign-in events for the same user. Look for any patterns of suspicious activity or multiple requests in a short time frame.
- Correlate with Entra ID audit logs to identify any recent device registrations or changes to the user's device registration status.
- Pivot to primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse or unauthorized access attempts.

### False positive analysis
- Legitimate applications or services that require access to the Device Registration Service may trigger this rule. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user accounts.
- Users being onboarded or enrolled in new devices may also trigger this rule, especially if they are using the Microsoft Authentication Broker for the first time.

### Response and remediation
- If the request is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access.
- Disable the user account temporarily to prevent any potential compromise or unauthorized access.
- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access.
- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user.
- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources.
- Consider deactivating any newly registered devices associated with the user account until further investigation is complete.
"""
references = [
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
]
risk_score = 47
rule_id = "d121f0a8-4875-11f0-bb2b-f661ea17fbcd"
severity = "medium"
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: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "azure.signinlogs" and
    azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and
    azure.signinlogs.category: "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.authentication_processing_details: *adrs_access* and
    azure.signinlogs.properties.incoming_token_type: "refreshToken" and
    azure.signinlogs.properties.user_type: "Member"
'''


[[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.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"

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

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

[metadata]
creation_date = "2026/06/29"
integration = ["azure"]
maturity = "production"
updated_date = "2026/06/29"

[rule]
author = ["Elastic"]
description = """
Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is
"10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device
profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure
AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish
persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across
an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher
"10.0.19045.<revision>" value.
"""
false_positives = [
    """
    Legitimate device registrations may coincidentally use the `10.0.19045.2006` build (Windows 10 22H2) with a default
    `DESKTOP-` hostname, particularly on imaged or unmanaged Windows hosts that have not been updated. Validate against
    your device inventory, expected provisioning workflows, and the registering user before escalating.
    """,
    """
    Authorized red team or penetration testing engagements that register devices with this OS profile will match this
    rule. If this is expected, add exceptions for the specific user principal names, source IPs, or device names
    involved.
    """,
]
from = "now-9m"
index = ["logs-azure.auditlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Device Registration with Phishing Kit Default OS Build"
note = """## Triage and analysis

### Investigating Entra ID Device Registration with Phishing Kit Default OS Build

AiTM phishing kits including Tycoon2FA and Kali365 register a device in Entra ID with a frozen default cloud device OS build of `10.0.19045.2006` and a default display name of `DESKTOP-<random characters>`. This build is hardcoded by the tooling and differs from the OS version of legitimate, patched hosts (a current Windows 10 22H2 device reports a much higher `10.0.19045.<revision>` value), making the build a useful indicator of kit-driven device registration. Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access bypass, and persistent token-based access.

The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the modified properties record the registered device characteristics:

- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19045.2006`
- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*`

### Possible investigation steps

- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine whether that user is expected to register a new device.
- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use `azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, `Add registered owner to device`).
- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters.
- Inspect the registration user agent on the paired `Register device` event (`azure.auditlogs.properties.userAgent`), which is frequently a spoofed `Dsreg/10.0 (Windows 10.0.19045.2006)` string or a raw HTTP client such as `axios/*` or `python-requests/*`.
- Check whether the same user registered multiple devices in a short window (a single piece of kit infrastructure registering several devices is common for PRT persistence at scale).
- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag unexpected IPs, hosting/VPS ASNs (for example Tencent or Alibaba), or impossible-travel relative to the user's normal activity.
- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token type is a `primaryRefreshToken`, for AiTM sign-ins immediately preceding the registration, or for the broker subsequently minting tokens for other resources such as Microsoft Graph.

### False positive analysis

- Unmanaged or never-patched Windows 10 22H2 hosts may legitimately present the `10.0.19045.2006` build with a default `DESKTOP-` hostname. Validate against device inventory and known provisioning programs.
- Authorized security assessments that register devices with this OS profile will match. Document the engagement and add scoped exceptions.

### Response and remediation

- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`.
- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials).
- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access.
- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and require MFA for registration).
"""
references = [
    "https://any.run/malware-trends/tycoon/",
    "https://www.huntress.com/blog/kali365-device-code-phishing-kit",
    "https://any.run/malware-trends/kali365/",
    "https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/",
    "https://www.ic3.gov/PSA/2026/PSA260521",
]
risk_score = 47
rule_id = "82629eed-5516-446e-ad73-03b8c4f4d571"
severity = "medium"
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",
    "Use Case: Threat Detection",
    "Threat: Tycoon2FA",
    "Threat: Kali365",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and
    azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19045.2006* and
    azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-*
'''


[[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.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"



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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "event.outcome",
    "azure.auditlogs.identity",
    "azure.auditlogs.operation_name",
    "azure.auditlogs.properties.target_resources.0.display_name",
    "azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value",
    "azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value",
    "azure.auditlogs.properties.initiated_by.user.userPrincipalName",
    "azure.auditlogs.properties.initiated_by.user.ipAddress",
    "azure.correlation_id",
]

[metadata]
creation_date = "2026/02/02"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/04/07"

[rule]
author = ["Elastic"]
description = """
Detects suspicious child process execution from the OpenClaw, Moltbot, or Clawdbot AI coding agents running via Node.js.
These tools can execute arbitrary shell commands through skills or prompt injection attacks. Malicious skills from
public registries like ClawHub have been observed executing obfuscated download-and-execute commands targeting
cryptocurrency wallets and credentials. This rule identifies shells, scripting interpreters, and common LOLBins spawned
by these AI agents.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "Execution via OpenClaw Agent"
note = """## Triage and analysis

### Investigating Execution via OpenClaw Agent

OpenClaw (formerly Clawdbot, rebranded to Moltbot) is a personal AI coding assistant that can execute shell commands 
and scripts on behalf of users. Malicious actors have weaponized the skill ecosystem (ClawHub) to distribute skills 
that execute download-and-execute commands, targeting cryptocurrency wallets and credentials.

### Possible investigation steps

- Verify if OpenClaw/Moltbot is an approved application in your organization.
- Review the child process command line for indicators of malicious activity (encoded payloads, remote downloads, credential access).
- Check the parent Node.js process command line to identify which OpenClaw component initiated the execution.
- Examine recently installed skills from ClawHub for malicious or obfuscated code.
- Correlate with network events to identify data exfiltration or C2 communication.
- Review the user's AI conversation history for prompt injection attempts.

### False positive analysis

- Developers legitimately using OpenClaw/Moltbot for AI-assisted coding may trigger this rule when the AI executes build scripts, curl commands, or other legitimate automation.
- If the tool is approved, consider tuning based on specific command patterns or adding exception lists.

### Response and remediation

- If the child process activity appears malicious, terminate the OpenClaw gateway and investigate the skill that initiated the command.
- Review and remove any suspicious skills from the OpenClaw configuration.
- If credentials may have been accessed, rotate affected secrets and API keys.
- Block known typosquat domains (moltbot.you, clawbot.ai, clawdbot.you) at the network level.
"""
references = [
    "https://www.malwarebytes.com/blog/threat-intel/2026/01/clawdbots-rename-to-moltbot-sparks-impersonation-campaign",
    "https://www.tomshardware.com/tech-industry/cyber-security/malicious-moltbot-skill-targets-crypto-users-on-clawhub",
    "https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare",
    "https://blog.virustotal.com/2026/02/from-automation-to-infection-how.html",
]
risk_score = 47
rule_id = "a7c3e8f2-4b19-4d6a-9e5c-8f1a2b3c4d5e"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Domain: LLM",
    "OS: Linux",
    "OS: macOS",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type == "start" and
  process.parent.name : ("node", "node.exe") and 
  process.parent.command_line : ("*openclaw*", "*moltbot*", "*clawdbot*") and
   process.name : ("bash", "sh", "zsh", "bash.exe", "cmd.exe", "powershell.exe", "curl.exe", "curl", "base64", "xattr", "osascript", "python*", "chmod", "certutil.exe", "rundll32.exe") and
   not process.args in (
     "ip neigh show",
     "arp -a -n -l",
     "ip neighbor show dev wlan0",
     "ip neighbor show dev eth0",
     "arp -a | findstr /C:---"
   )
'''


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

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

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

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

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

[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when the configuration is modified for a storage bucket in Google Cloud Platform (GCP). An adversary may
modify the configuration of a storage bucket in order to weaken the security controls of their target's environment.
"""
false_positives = [
    """
    Storage bucket configuration may be modified by system administrators. Verify that the 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 Storage Bucket Configuration Modification"
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 Storage Bucket Configuration Modification

Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. Adversaries may alter bucket configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful configuration changes, flagging potential defense evasion attempts by identifying suspicious modifications to storage settings.

### Possible investigation steps

- Review the audit logs for the specific event.action "storage.buckets.update" to identify the user or service account responsible for the configuration change.
- Examine the event.outcome field to confirm the success of the configuration modification and gather details on what specific changes were made to the storage bucket settings.
- Investigate the context of the change by checking the timestamp of the event to determine if it aligns with any known maintenance or deployment activities.
- Assess the permissions and roles of the user or service account involved in the modification to ensure they have the appropriate level of access and determine if any privilege escalation occurred.
- Cross-reference the modified bucket's configuration with security policies and best practices to identify any potential security weaknesses introduced by the change.
- Check for any other recent suspicious activities or alerts related to the same user or service account to identify patterns of potentially malicious behavior.
- If unauthorized changes are suspected, initiate a response plan to revert the configuration to its previous state and strengthen access controls to prevent future incidents.

### False positive analysis

- Routine administrative updates to storage bucket configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their typical activities, and create exceptions for these actions in the monitoring system.
- Automated processes or scripts that regularly update bucket configurations for maintenance or compliance purposes may cause false positives. Identify these processes and exclude their actions from triggering alerts by using service accounts or specific identifiers.
- Changes made by cloud management tools or third-party services integrated with GCP might be flagged. Review and whitelist these tools if they are verified and necessary for operations.
- Scheduled updates or configuration changes as part of regular security audits can appear suspicious. Document these schedules and incorporate them into the monitoring system to prevent unnecessary alerts.
- Temporary configuration changes for testing or development purposes might be misinterpreted as threats. Ensure that such activities are logged and communicated to the security team to adjust monitoring rules accordingly.

### Response and remediation

- Immediately revoke any unauthorized access to the affected GCP storage bucket by reviewing and adjusting IAM policies to ensure only legitimate users have access.
- Conduct a thorough review of recent bucket configuration changes to identify any unauthorized modifications and revert them to their original secure state.
- Isolate the affected storage bucket from the network if suspicious activity is detected, to prevent further unauthorized access or data exfiltration.
- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts.
- Implement additional logging and monitoring on the affected bucket to detect any further unauthorized access attempts or configuration changes.
- Review and update security policies and access controls for all GCP storage buckets to prevent similar incidents in the future.
- Escalate the incident to the cloud security team for a comprehensive analysis and to determine if further action is required, such as involving legal or compliance teams.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
risk_score = 47
rule_id = "97359fd8-757d-4b1d-9af1-ef29e4a8680e"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:"storage.buckets.update" and event.outcome:success
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1578.005"
name = "Modify Cloud Compute Configurations"
reference = "https://attack.mitre.org/techniques/T1578/005/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer.
This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers
used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for
privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives
token revocation and RBAC changes.
"""
false_positives = [
    """
    Custom PKI or administrative tooling may legitimately request kubernetes.io/kube-apiserver-client certificates in
    self-managed clusters. Baseline approved operators and tune exclusions for known automation on GKE.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Certificate Signing Request API Client Signer Requested"
note = """## Triage and analysis

### Investigating GKE Certificate Signing Request API Client Signer Requested

Identify the actor (`client.user.email`), `source.ip`, and `user_agent.original`. Legitimate GKE node certificate
rotation uses `kubernetes.io/kube-apiserver-client-kubelet` or `kubernetes.io/kubelet-serving` — not this signer.
Review `gcp.audit.request.spec.signerName` and decode `gcp.audit.request.spec.request` when present to extract the
requested Common Name (CN).

```bash
# Full decoded PEM block
echo "<gcp.audit.request.spec.request>" | base64 -d

# Parsed CSR details (subject, key type/size, extensions, signature)
echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -text

# Subject only
echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -subject
```

### Possible investigation steps

- Confirm whether the principal is authorized to request API client certificates and whether the activity aligns with
  approved PKI workflows.
- Decode `gcp.audit.request.spec.request` and inspect the CSR subject for privileged identities such as
  `system:masters`, `system:kube-controller-manager`, or `system:admin`.
- Correlate with CSR approval or patch activity on the same `gcp.audit.resource_name` and follow-on API access from
  unusual networks.
- Review RBAC grants on `certificatesigningrequests` create and `certificatesigningrequests/approval` for the actor.

### False positive analysis

- Custom PKI or admin workflows may legitimately use this signer outside kube-system. Baseline and tune for known
  operators.

### Related rules

- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe
- GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e
- GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544

### Response and remediation

- Deny or delete suspicious CSRs, rotate cluster signing trust if abused, and remove excessive CSR RBAC from untrusted
  identities.

"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required. Request body capture for CSR create events (`gcp.audit.request.spec.signerName`) typically requires RequestResponse audit level on CertificateSigningRequest resources."
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/",
    "https://kubernetes.io/docs/concepts/security/rbac-good-practices/",
    "https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/",
    "https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/",
]
risk_score = 73
rule_id = "1e344fba-a2f7-462b-aaec-d6c8f80d5a28"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: GCP Audit Logs",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "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.certificates.v1.certificatesigningrequests.create" and
gcp.audit.request.spec.signerName:"kubernetes.io/kube-apiserver-client" and
not client.user.email:(
  "system:gcp-controller-manager" or
  "system:serviceaccount:kube-system:certificate-controller"
)
'''

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

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

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

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

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

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

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

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

[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.spec.signerName",
    "gcp.audit.request.spec.request",
    "data_stream.namespace",
]

[metadata]
creation_date = "2022/08/26"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a
compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and
making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges.
"""
false_positives = [
    """
    Administrators may remove 2-step verification (2SV) temporarily for testing or during maintenance. If 2SV was
    previously enabled, it is not common to disable this policy for extended periods of time.
    """,
]
from = "now-190m"
index = ["filebeat-*", "logs-google_workspace.login-*", "logs-google_workspace.user_accounts-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace 2SV Policy Disabled By User"
note = """## Triage and analysis

### Investigating Google Workspace 2SV Policy Disabled By User

Threat actors who compromise a Google Workspace account may disable 2-step verification (2SV) on that account to remove
the second authentication factor. With 2SV turned off, the account falls back to password-only authentication, which can
support session abuse, AiTM credential relay, and sustained access without MFA challenges on future sign-ins. This is
especially concerning for administrators, executives, and users with access to sensitive mail, data, or admin functions.

In AiTM and session-hijacking scenarios, an attacker with an active session may disable 2SV before the legitimate user
notices, making it easier to re-enter the account later using stolen credentials alone.

This rule identifies when a user disables 2SV on their account via the `2sv_disable` event. The event appears in
both the `google_workspace.login` and `google_workspace.user_accounts` data streams; alert suppression groups by
`user.email` and `source.ip` within the rule lookback to avoid duplicate alerts when both streams are ingested.

### Possible investigation steps

- Identify the user account that disabled 2SV by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps.
- Determine the account's privilege and data access — prioritize triage if the user is an administrator, holds delegated admin roles, or has access to sensitive resources.
- Determine whether the disable is expected or unauthorized:
  - Validate with the user or their manager whether they intentionally turned off 2SV (for example, device replacement).
  - If the `source.ip`, geolocation, or timing is unusual for the user, treat the alert as higher priority until proven benign.
- Search Kibana for precursor and follow-on account changes for the same `user.email` in the hours before and after the alert:
  - `password_edit`, `recovery_email_edit`, `recovery_phone_edit` in `google_workspace.login` or `google_workspace.user_accounts`
  - `login_success`, `login_failure`, `suspicious_login`, and `login_challenge` in `google_workspace.login`
  - OAuth activity in `google_workspace.token` if token abuse is suspected
- Review `google_workspace.login.challenge_method` on recent sign-ins to determine whether MFA was used, bypassed, or relayed before 2SV was disabled.

### False positive analysis

- Legitimate users may disable 2SV temporarily, but this weakens the account — confirm the change was authorized even when the actor appears benign.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the disable is not clearly authorized, re-enable 2SV on the affected account, reset the password, and revoke active sessions while the investigation proceeds.
- 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.
- Review the permissions assigned to the implicated user 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 190 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.
- 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) for Filebeat and 3 hours for the Fleet Integration `login` datastream. 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://support.google.com/a/answer/9176657?hl=en",
    "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 = "5e161522-2545-11ed-ac47-f661ea17fbce"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:("google_workspace.login" or "google_workspace.user_accounts") and event.action:"2sv_disable"
'''

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

[rule.investigation_fields]
field_names = [
    "user.name",
    "user.email",
    "source.ip",
    "event.action",
]

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

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

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

[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 = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

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

[metadata]
creation_date = "2020/11/06"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via
the ShellBrowserWindow or ShellWindows Application COM Object. This behavior may indicate an attacker abusing a DCOM
application to stealthily move laterally.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "logs-windows.sysmon_operational-*",
]
language = "eql"
license = "Elastic License v2"
name = "Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows"
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 Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows

DCOM enables software components to communicate over a network, often used in Windows environments for legitimate inter-process communication. Adversaries exploit DCOM, particularly ShellBrowserWindow or ShellWindows, to execute commands remotely, facilitating stealthy lateral movement. The detection rule identifies suspicious network activity and process creation patterns, such as incoming TCP connections to high ports and explorer.exe spawning processes, which may indicate DCOM abuse.

### Possible investigation steps

- Review the network activity to identify the source IP address of the incoming TCP connection. Verify if the source IP is known or expected within the network environment.
- Examine the process tree for explorer.exe to identify any unusual or unexpected child processes that were spawned. Investigate these processes for any signs of malicious activity.
- Check the destination port and source port numbers to determine if they are commonly used for legitimate services or if they are unusual for the environment.
- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns associated with the same source IP or process entity.
- Investigate the user account associated with the explorer.exe process to determine if there are any signs of compromise or unauthorized access.
- Review historical data for any previous occurrences of similar network connections or process creations to identify potential patterns or repeated attempts.

### False positive analysis

- Legitimate software updates or installations may trigger the rule due to the use of DCOM for remote management tasks. Users can create exceptions for known update processes by identifying their specific network and process patterns.
- Internal IT management tools that utilize DCOM for remote administration might cause false positives. Review and whitelist these tools by confirming their source IP addresses and process behaviors.
- Automated scripts or scheduled tasks that leverage DCOM for legitimate purposes can be mistaken for lateral movement. Document and exclude these tasks by correlating their execution times and process chains.
- Network scanning or monitoring tools that generate high-port TCP connections could be misinterpreted as suspicious activity. Validate and exclude these tools by cross-referencing their network traffic with known benign sources.
- User-initiated remote desktop sessions or file transfers using DCOM may appear as lateral movement. Verify and exclude these activities by checking user authentication logs and session details.

### Response and remediation

- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
- Terminate any suspicious processes spawned by explorer.exe that are not part of normal operations, focusing on those initiated through high TCP ports.
- Conduct a thorough review of recent network connections and process creation logs on the affected host to identify any additional compromised systems or lateral movement attempts.
- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access.
- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited during the attack.
- Enhance monitoring and logging on the network to detect similar DCOM abuse attempts, ensuring that alerts are configured for high TCP port activity and unusual process spawning by explorer.exe.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary."""
references = ["https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/"]
risk_score = 47
rule_id = "8f919d4b-a5af-47ca-a594-6be59cd924a4"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by host.id with maxspan=5s
 [network where host.os.type == "windows" and event.type == "start" and process.name : "explorer.exe" and
  network.direction : ("incoming", "ingress") and network.transport == "tcp" and
  source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1"
 ] by process.entity_id
 [process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "explorer.exe"
 ] by process.parent.entity_id
'''

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:

- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
"""


[[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.003"
name = "Distributed Component Object Model"
reference = "https://attack.mitre.org/techniques/T1021/003/"

[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 = "T1559"
name = "Inter-Process Communication"
reference = "https://attack.mitre.org/techniques/T1559/"

[[rule.threat.technique.subtechnique]]
id = "T1559.001"
name = "Component Object Model"
reference = "https://attack.mitre.org/techniques/T1559/001/"

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

[metadata]
creation_date = "2024/06/03"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Detects network connections initiated through Cross-Desktop Group (XDG) autostart entries for GNOME and XFCE-based Linux
distributions. XDG Autostart entries can be used to execute arbitrary commands or scripts when a user logs in. This rule
helps to identify potential malicious activity where an attacker may have modified XDG autostart scripts to establish
persistence on the system.
"""
from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Network Connections Initiated Through XDG Autostart Entry"
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 Network Connections Initiated Through XDG Autostart Entry

XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges.

### Possible investigation steps

- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry.
- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session.
- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query.
- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry.
- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism.
- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives.

### False positive analysis

- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule.
- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts.
- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening.
- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement.
- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity.
- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker.
- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation.
- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture."""
references = [
    "https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html",
    "https://hadess.io/the-art-of-linux-persistence/",
    "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
]
risk_score = 47
rule_id = "dd52d45a-4602-4195-9018-ebe0f219c273"
setup = """## Setup

This rule requires data coming in from one of the following integrations:
- Elastic Defend
- Auditbeat

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

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

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

### Auditbeat Setup
Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).

#### Custom Ingest Pipeline
For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the [guide](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by host.id, process.entity_id with maxspan=1s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
     (process.parent.executable == "/usr/bin/xfce4-session") or
     (process.executable == "/bin/sh" and process.args == "-e" and process.args == "-u" and
      process.args == "-c" and process.args : "export GIO_LAUNCHED_DESKTOP_FILE_PID=$$;*")
   )
  ]
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not (
     destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
       "FF00::/8", "172.31.0.0/16"
       ) or
       process.name in (
         "telegram-desktop", "firefox", "gnome-calculator", "remmina", "spotify", "librewolf", "fortitraylauncher",
         "flameshot", "thunderbird", "update-manager", "warp-terminal", "obs", "transmission-gtk", "telegram",
         "mintupdate-launcher", "firefox-bin", "xbrlapi", "gnome-software"
       )
     )
  ]
'''

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

[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"

[[rule.threat.technique.subtechnique]]
id = "T1547.013"
name = "XDG Autostart Entries"
reference = "https://attack.mitre.org/techniques/T1547/013/"

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

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

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

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

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

[metadata]
creation_date = "2026/02/02"
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/07/29"

[rule]
author = ["Elastic"]
description = """
This rule detects the execution of kubeletctl inside a container. Kubeletctl is a command-line tool that can be used to
interact with the Kubelet API directly. It allows easy access to this API, making the often undocumented Kubelet API
more accessible. It is often used to enumerate the Kubelet API or other resources inside the container, and may indicate
an attempt to move laterally within the pod.
"""
false_positives = [
    """
    There is a potential for false positives when the command line arguments looked for in this rule are used for legitimate purposes,
    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
    if they are indicative of malicious activity or part of legitimate container activity.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Potential Kubeletctl Execution Detected via Defend for Containers"
note = """ ## Triage and analysis

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

### Investigating Potential Kubeletctl Execution Detected via Defend for Containers

This detects execution of kubeletctl within a Linux container, a tool that simplifies direct access to the node’s Kubelet API. It matters because kubeletctl can expose pod and node details and enable actions that support discovery and lateral movement from a compromised container. A common attacker pattern is running `kubeletctl scan` against the Kubelet endpoint, then using `pods` or `exec/attach` to reach other workloads.

### Possible investigation steps

- Determine how an interactive shell was obtained in the container (e.g., kubectl exec, docker exec, or an app RCE) by correlating the timestamp with Kubernetes audit logs and upstream access logs for the initiating user or workload.  
- Review the full kubeletctl invocation to identify the intended operation and target Kubelet endpoint (node IP/hostname and port), then validate whether that endpoint should be reachable from this pod in the cluster design.  
- Correlate container network activity around the alert for connections to node addresses on Kubelet ports (commonly 10250/10255) and look for scanning patterns across multiple nodes indicating discovery or lateral movement attempts.  
- Check for access to Kubernetes credentials within the container (service account token, mounted certificates, kubeconfig, cloud metadata credentials) and verify whether any were used to authenticate to the Kubelet API.  
- Hunt for follow-on actions consistent with lateral movement or impact, such as kubeletctl exec/attach/portForward usage, access to other pod namespaces, or subsequent Kubernetes API activity that creates/patches workloads.

### False positive analysis

- An administrator or developer may have executed kubeletctl interactively inside the container during an incident response or troubleshooting session to enumerate pods/runningpods or validate Kubelet API connectivity, which can resemble discovery activity.  
- A container image or entrypoint script that includes kubeletctl may be invoked manually for routine diagnostics (e.g., running scan/pods/cri or using --server/-s to target a node), producing an interactive exec event without malicious intent.

### Response and remediation

- Isolate the affected pod by scaling it to zero or applying a deny-all egress policy while preserving the container filesystem and process history needed to reconstruct the kubeletctl command, its target node address, and any output artifacts.  
- Block and alert on pod-to-node access to the Kubelet API (typically 10250/10255) at the network layer, and rotate/revoke any Kubernetes service account tokens or kubeconfigs present in the container if kubeletctl attempted authenticated actions like exec/attach/portForward.  
- Remove kubeletctl and related tooling from the image and redeploy from a known-good build, then perform node/pod hygiene by evicting/restarting the workload and checking for persistence indicators such as added binaries, modified entrypoints, or unexpected cron/init scripts.  
- Recover by re-creating the workload in a clean namespace with least-privilege RBAC, validating no unauthorized pods/replicasets were created and that the service account permissions and mounts match the expected deployment spec.  
- Escalate to the incident response team immediately if kubeletctl targeted multiple nodes, invoked exec/attach/portForward/run/scan, or if there is evidence of access to other namespaces or credential material (service account tokens, cloud metadata credentials) from the container.  
- Harden by enforcing Pod Security Standards (no privileged pods, hostNetwork/hostPID/hostPath restrictions), restricting interactive exec into production pods, and limiting node API exposure by disabling unauthenticated Kubelet endpoints and requiring authenticated/authorized access.
"""
references = [
    "https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
    "https://github.com/cyberark/kubeletctl",
]
risk_score = 73
rule_id = "2572f7e0-7647-4c68-a42b-d3b1973deaae"
severity = "high"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  (process.name == "kubeletctl" or process.args like "*kubeletctl*") or
  (process.args in ("-s", "--server") and process.args in ("run", "portForward", "scan", "attach", "exec", "pods", "runningpods", "cri", "pid2pod"))
) and
container.id like "?*" 
'''

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

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

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

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

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

[[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 = "2024/09/17"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies the execution of a Python script that uses the ROT cipher for letters substitution. Adversaries may
use this method to encode and obfuscate part of their malicious code in legit python packages.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*", "logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "ROT Encoded Python Script Execution"
references = [
    "https://www.elastic.co/security-labs/dprk-code-of-conduct",
    "https://www.reversinglabs.com/blog/fake-recruiter-coding-tests-target-devs-with-malicious-python-packages"
]
risk_score = 47
rule_id = "5ab49127-b1b3-46e6-8a38-9e8512a2a363"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by process.entity_id with maxspan=1m
 [process where host.os.type in ("windows", "macos") and event.type == "start" and process.name : "python*" and
  not (
    process.args : ("*gcloud.py", "*conda-script.py", "*compileall.py", "*.lmstudio*") or
    process.parent.args : ("*gcloud.py", "*conda-script.py", "*compileall.py", "*.lmstudio*")
  )]
 [file where host.os.type in ("windows", "macos") and
  event.action != "deletion" and process.name : "python*" and file.name : "rot_??.cpython-*.pyc*"]
'''
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 ROT Encoded Python Script Execution

ROT encoding, a simple letter substitution cipher, is often used to obfuscate Python scripts, making them harder to analyze. Adversaries exploit this by embedding ROT-encoded scripts within legitimate packages to evade detection. The detection rule identifies such activities by monitoring Python script executions and the presence of ROT-encoded compiled files, flagging potential misuse on Windows and macOS systems.

### Possible investigation steps

- Review the process entity ID to identify the specific Python process that triggered the alert and gather details such as the process start time and command line arguments.
- Examine the file path and name of the ROT-encoded compiled file (e.g., "rot_??.cpython-*.pyc") to determine its origin and whether it is part of a legitimate package or potentially malicious.
- Check the parent process of the Python script to understand how it was initiated and whether it was executed by a legitimate application or user.
- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
- Analyze any network connections or file modifications made by the Python process to identify potential data exfiltration or further malicious activity.
- Correlate this alert with other security events or logs from the same host to identify patterns or additional indicators of compromise.

### False positive analysis

- Legitimate development activities may trigger the rule if developers use ROT encoding for testing or educational purposes. To manage this, create exceptions for known development environments or specific user accounts involved in such activities.
- Automated scripts or tools that use ROT encoding for legitimate data processing tasks can be flagged. Identify these scripts and whitelist their execution paths or associated process names to prevent false alerts.
- Some security tools or software may use ROT encoding as part of their normal operations. Review and document these tools, then configure the detection system to exclude their known file paths or process identifiers.
- Regularly scheduled tasks or cron jobs that involve ROT-encoded files for non-malicious purposes can cause false positives. Exclude these tasks by specifying their unique identifiers or execution schedules in the detection rule settings.

### Response and remediation

- Isolate the affected system from the network to prevent further spread of potentially malicious activity.
- Terminate any running Python processes that are identified as executing ROT-encoded scripts to halt the execution of obfuscated code.
- Conduct a thorough review of the affected system to identify and remove any ROT-encoded Python files, specifically targeting files matching the pattern "rot_??.cpython-*.pyc*".
- Restore any affected systems from a known good backup to ensure the removal of any persistent threats.
- Implement application whitelisting to prevent unauthorized Python scripts from executing, focusing on blocking scripts with ROT encoding patterns.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
- Update detection mechanisms to monitor for similar ROT-encoded script activities, enhancing the ability to detect and respond to future threats."""


[[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.013"
name = "Encrypted/Encoded File"
reference = "https://attack.mitre.org/techniques/T1027/013/"

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

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