Elastic rules: 0u

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

[rule]
author = ["Elastic"]
description = """
Detects attempts to reset an Okta user's enrolled multi-factor authentication (MFA) factors. An adversary may attempt to
reset the MFA factors for an Okta user's account in order to register new MFA factors and abuse the account to blend in
with normal activity in the victim's environment.
"""
false_positives = [
    """
    Consider adding exceptions to this rule to filter false positives if the MFA factors for Okta user accounts are
    regularly reset in your organization.
    """,
]
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Attempt to Reset MFA Factors for an Okta User Account"
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 Attempt to Reset MFA Factors for an Okta User Account

Okta is a widely used identity management service that provides multi-factor authentication (MFA) to enhance security. Adversaries may attempt to reset MFA factors to register their own, gaining unauthorized access while appearing legitimate. The detection rule identifies such attempts by monitoring specific Okta system events, helping to flag potential account manipulation activities.

### Possible investigation steps

- Review the Okta system logs for the specific event.action:user.mfa.factor.reset_all to identify the user account involved in the MFA reset attempt.
- Check the timestamp of the event to determine when the reset attempt occurred and correlate it with any other suspicious activities around the same time.
- Investigate the IP address and location associated with the event to assess if it aligns with the user's typical access patterns or if it appears unusual.
- Examine the user account's recent activity history for any anomalies or unauthorized access attempts that might indicate compromise.
- Verify if there have been any recent changes to the user's account settings or permissions that could suggest account manipulation.
- Contact the affected user to confirm whether they initiated the MFA reset or if it was unauthorized, and advise them on securing their account if necessary.

### False positive analysis

- Routine administrative actions may trigger the rule if IT staff reset MFA factors for legitimate reasons such as assisting users who have lost access to their MFA devices. To manage this, create exceptions for known IT personnel or specific administrative actions.
- User-initiated resets due to lost or changed devices can also appear as suspicious activity. Implement a process to verify user requests and document these instances to differentiate them from malicious attempts.
- Automated scripts or tools used for account management might reset MFA factors as part of their operations. Identify and whitelist these tools to prevent false positives.
- Scheduled security audits or compliance checks that involve resetting MFA factors should be documented and excluded from triggering alerts by setting up time-based exceptions during these activities.

### Response and remediation

- Immediately disable the affected Okta user account to prevent further unauthorized access.
- Review recent login activity and MFA changes for the affected account to identify any unauthorized access or suspicious behavior.
- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices.
- Notify the legitimate user of the account compromise and advise them to change their password and review their account activity.
- Conduct a security review of the affected user's permissions and access to sensitive resources to ensure no unauthorized changes were made.
- Escalate the incident to the security operations team for further investigation and to determine if other accounts may be affected.
- Update security monitoring and alerting to enhance detection of similar MFA reset attempts, leveraging the MITRE ATT&CK framework for guidance on persistence and account manipulation tactics.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
]
risk_score = 21
rule_id = "729aa18d-06a6-41c7-b175-b65b739b1181"
severity = "low"
tags = [
    "Tactic: Persistence",
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:user.mfa.factor.reset_all
'''


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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"

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

[metadata]
bypass_bbr_timing = true
creation_date = "2025/10/09"
integration = ["aws"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Captures requests to the AWS federation endpoint (signin.amazonaws.com) for GetSigninToken. This API exchanges existing
temporary AWS credentials (e.g., from STS GetFederationToken or AssumeRole) for a short-lived sign-in token that is
embedded in a one-click URL to the AWS Management Console. It is commonly used by custom federation tools and automation
to pivot from programmatic access to a browser session. This is a building block rule meant to be used for correlation
with other rules to detect suspicious activity.
"""
false_positives = [
    """
    Legitimate federation workflows, admin portals, SSO helpers, CI/CD jobs, or internal scripts that create one-click
    console links, commonly invoke GetSigninToken and may generate frequent benign events.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Sign-In Token Created"
references = ["https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/"]
risk_score = 21
rule_id = "f754e348-f36f-4510-8087-d7f29874cc12"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Sign-In",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset: "aws.cloudtrail" and 
    event.provider: "signin.amazonaws.com" and 
    event.action : "GetSigninToken" and 
    event.outcome: "success"
'''


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

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

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

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

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

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

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

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
    "aws.cloudtrail.user_identity.session_context.session_issuer.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
]

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

[rule]
author = ["Austin Songer"]
description = """
Identifies the creation of role binding or cluster role bindings. You can assign these roles to Kubernetes subjects
(users, groups, or service accounts) with role bindings and cluster role bindings. An adversary who has permissions to
create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other
high privileges roles.
"""
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created"
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 Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created
Azure Kubernetes role bindings are crucial for managing access control within Kubernetes clusters, allowing specific permissions to be assigned to users, groups, or service accounts. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others high-level roles, such as cluster-admin. The detection rule monitors Azure activity logs for successful creation events of role or cluster role bindings, signaling potential unauthorized privilege escalation attempts.

### Possible investigation steps

- Review the Azure activity logs to identify the user or service account associated with the role binding creation event. Focus on the `event.dataset` and `azure.activitylogs.operation_name` fields to confirm the specific operation.
- Check the `event.outcome` field to ensure the operation was successful and not a failed attempt, which might indicate a misconfiguration or testing.
- Investigate the permissions and roles assigned to the identified user or service account to determine if they have legitimate reasons to create role bindings or cluster role bindings.
- Examine the context of the role binding creation, such as the time of the event and any related activities, to identify any unusual patterns or correlations with other suspicious activities.
- Verify if the role binding grants elevated privileges, such as cluster-admin, and assess the potential impact on the cluster's security posture.
- Cross-reference the event with any recent changes in the cluster's configuration or access policies to understand if the role binding creation aligns with authorized administrative actions.

### False positive analysis

- Routine administrative tasks may trigger alerts when legitimate users create role bindings for operational purposes. To manage this, identify and whitelist specific user accounts or service accounts that regularly perform these tasks.
- Automated deployment tools or scripts that configure Kubernetes clusters might create role bindings as part of their normal operation. Exclude these tools by filtering out known service accounts or IP addresses associated with these automated processes.
- Scheduled maintenance or updates to the Kubernetes environment can result in multiple role binding creation events. Establish a maintenance window and suppress alerts during this period to avoid unnecessary noise.
- Development and testing environments often have frequent role binding changes. Consider creating separate monitoring rules with adjusted thresholds or risk scores for these environments to reduce false positives.
- Collaboration with the DevOps team can help identify expected role binding changes, allowing for preemptive exclusion of these events from triggering alerts.

### Response and remediation

- Immediately revoke any newly created role bindings or cluster role bindings that are unauthorized or suspicious to prevent further privilege escalation.
- Isolate the affected Kubernetes cluster from the network to prevent potential lateral movement or further exploitation by the adversary.
- Conduct a thorough review of recent activity logs to identify any unauthorized access or changes made by the adversary, focusing on the time frame around the alert.
- Reset credentials and access tokens for any compromised accounts or service accounts involved in the unauthorized role binding creation.
- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected.
- Implement additional monitoring and alerting for any future role binding or cluster role binding creation events to ensure rapid detection and response.
- Review and tighten role-based access control (RBAC) policies to ensure that only necessary permissions are granted to users, groups, and service accounts, minimizing the risk of privilege escalation.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes",
    "https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/",
]
risk_score = 21
rule_id = "1c966416-60c1-436b-bfd0-e002fddbfd89"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:
	("MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/ROLEBINDINGS/WRITE" or
	 "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/CLUSTERROLEBINDINGS/WRITE") and
event.outcome:(Success or success)
'''


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

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

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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows
Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business
(WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally
accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty
`device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by
an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint
device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong
precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are
excluded because they are a common benign source of empty device identifiers.
"""
false_positives = [
    """
    Rare edge cases during initial passwordless onboarding may briefly produce a Windows Hello for Business or passkey
    sign-in before the device is fully registered. Validate against the user's device registration timeline. Genuine
    WHfB and passkey sign-ins are otherwise accompanied by a populated device identifier.
    """,
]
from = "now-9m"
index = ["logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Windows Hello or Passkey Sign-in from Unregistered Device"
note = """## Triage and analysis

### Investigating Entra ID Windows Hello or Passkey Sign-in from Unregistered Device

WHfB and passkey credentials are bound to a device's TPM, so a legitimate sign-in with one of these methods is normally accompanied by its registered device. A same-tenant sign-in with an empty `device_detail.device_id` means the key material is being used away from its bound device - the core signal of the "borrowing Windows Hello keys" technique, where an adversary replays a WHfB/NGC key or passkey to mint device-agnostic tokens from their own infrastructure.

### Possible investigation steps
- Identify the user via `user_principal_name` and confirm `authentication_details.authentication_method` is WHfB, FIDO2, or a passkey with `device_detail.device_id` empty (a `device_id` present on an unmanaged device is a different, noisier condition, not this rule).
- Review `app_id`/`resource_display_name` for Graph or Device Registration Service access right after, check `source.ip`, `source.geo.*`, and `user_agent.original` for automation (python-requests) or hosting/VPS ASNs (ROADtools/roadtx), and pivot on `user_id` in `azure.auditlogs` for a subsequent "Register device" or "Add Windows Hello for Business credential" event; if the user didn't enroll a new key/passkey, treat it as compromised.

### False positive analysis
- Initial passwordless onboarding can briefly produce this sign-in before device registration completes; correlate with the registration timeline.

### Response and remediation
- Treat the key/passkey as compromised: delete the credential and any attacker-registered device via Graph/the Entra portal, revoke sessions/refresh tokens (delete devices first, since that breaks device-bound PRT persistence), and re-enroll from a trusted device.
- Hunt for device registrations and PRT issuance after the sign-in, and consider Conditional Access requiring device compliance for sensitive resources.
"""
references = [
    "https://dirkjanm.io/borrowing-windows-hello-keys/",
    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
]
risk_score = 47
rule_id = "763b0a74-2961-4396-bb4b-8cd850e1ebe4"
setup = """#### Required Microsoft Entra ID Sign-In Logs
This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect sign-in logs via Azure Event Hub.
"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Platform: Entra ID",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Initial Access",
    "Rule Type: New Terms",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs" and
    event.category: "authentication" and
    azure.signinlogs.result_signature: "SUCCESS" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.authentication_details.authentication_method: (
        "Windows Hello for Business" or *passkey* or FIDO2* or *Passkey*
    ) and
    azure.signinlogs.properties.device_detail.device_id: ("" or not *) and
    azure.signinlogs.properties.cross_tenant_access_type: "none" and
    azure.signinlogs.properties.user_principal_name: *
'''


[[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/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



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

[rule.investigation_fields]
field_names = [
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.authentication_details.authentication_method",
    "azure.signinlogs.properties.device_detail.device_id",
    "azure.signinlogs.properties.device_detail.is_managed",
    "azure.signinlogs.properties.cross_tenant_access_type",
    "azure.signinlogs.properties.incoming_token_type",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.resource_display_name",
    "source.geo.country_name",
    "source.address",
    "user_agent.original",
]

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

[metadata]
creation_date = "2023/04/11"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/03/20"

[rule]
author = ["Elastic"]
description = """
Identifies instances where the 'touch' command is executed on a Linux system with the "-r" flag, which is used to modify
the timestamp of a file based on another file's timestamp. The rule targets specific VM-related paths, such as
"/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". These paths are associated with VMware virtualization software, and
their presence in the touch command arguments may indicate that a threat actor is attempting to tamper with timestamps
of VM-related files and configurations on the system.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "ESXI Timestomping using Touch Command"
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 ESXI Timestomping using Touch Command

VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths.

### Possible investigation steps

- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*".
- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account.
- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities.
- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies.
- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor.

### False positive analysis

- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions.
- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows.
- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives.
- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files.
- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities.
- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations.
- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot.
- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited.
- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
references = [
    "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
]
risk_score = 47
rule_id = "30bfddd7-2954-4c9d-bbc6-19a99ca47e23"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### 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).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "linux" and event.type == "start" and
 event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 process.name == "touch" and process.args == "-r" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"
[[rule.threat.technique.subtechnique]]
id = "T1070.006"
name = "Timestomp"
reference = "https://attack.mitre.org/techniques/T1070/006/"



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

[metadata]
creation_date = "2023/08/29"
integration = ["github"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule detects when a GitHub repository is deleted within your organization. Repositories are a critical component
used within an organization to manage work, collaborate with others and release products to the public. Any delete
action against a repository should be investigated to determine it's validity. Unauthorized deletion of organization
repositories could cause irreversible loss of intellectual property and indicate compromise within your organization.
"""
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "GitHub Repository Deleted"
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 GitHub Repository Deleted
GitHub repositories are essential for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase critical data, potentially indicating a security breach. The detection rule monitors GitHub audit logs for repository deletion events, enabling analysts to swiftly identify and investigate unauthorized actions, thereby mitigating potential data loss and compromise.

### Possible investigation steps

- Review the GitHub audit logs to confirm the repository deletion event by checking for entries where event.module is "github", event.dataset is "github.audit", and event.action is "repo.destroy".
- Identify the user account associated with the deletion event and verify their access permissions and recent activity to determine if the action was authorized.
- Contact the user or team responsible for the repository to confirm whether the deletion was intentional and documented.
- Check for any recent changes in user access or permissions that could indicate a compromised account or unauthorized access.
- Investigate any other suspicious activities or alerts related to the same user or repository around the time of the deletion event to identify potential patterns of malicious behavior.
- Assess the impact of the repository deletion on ongoing projects and data availability, and initiate recovery procedures if necessary.

### False positive analysis

- Routine repository clean-up activities by authorized personnel may trigger alerts. To manage this, maintain a list of users or teams responsible for such tasks and create exceptions for their actions.
- Automated scripts or tools used for repository management might delete repositories as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
- Test or temporary repositories that are frequently created and deleted during development cycles can cause false positives. Implement naming conventions for these repositories and configure the rule to ignore deletions matching these patterns.
- Scheduled repository deletions as part of a lifecycle management policy can be mistaken for unauthorized actions. Document these schedules and adjust the detection rule to accommodate these planned activities.

### Response and remediation

- Immediately revoke access for any user account associated with the unauthorized repository deletion to prevent further malicious actions.
- Restore the deleted repository from backups or snapshots, if available, to recover lost data and minimize operational disruption.
- Conduct a thorough review of recent access logs and user activities to identify any other suspicious actions or potential indicators of compromise.
- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and awareness.
- Implement additional access controls, such as multi-factor authentication and role-based access, to prevent unauthorized deletions in the future.
- Escalate the incident to higher management and legal teams if intellectual property theft or significant data loss is suspected.
- Enhance monitoring and alerting mechanisms to detect similar unauthorized actions promptly, leveraging the MITRE ATT&CK framework for guidance on potential threat vectors."""
risk_score = 47
rule_id = "345889c4-23a8-4bc0-b7ca-756bd17ce83b"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Impact",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
configuration where event.module == "github" and data_stream.dataset == "github.audit" and event.action == "repo.destroy"
'''


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


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

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

[rule]
author = ["Elastic"]
description = """
Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a
critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access.
Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on
unauthenticated Unauthorized/forbidden pod writes).
"""
false_positives = [
    """
    Anonymous pod writes should be rare. If observed from expected automation, anonymous authentication or RBAC for
    system:anonymous is likely misconfigured and should be remediated rather than broadly excluded.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Anonymous Pod Create/Update/Patch"
note = """## Triage and analysis

### Investigating GKE Anonymous Pod Create/Update/Patch

Anonymous identities creating or mutating pods indicates the API server accepts unauthenticated workload changes.
Failed unauthenticated creates may appear with an empty `client.user.email` and `Unauthorized` / forbidden status.

### Investigation steps

- Review `client.user.email`, `event.action`, `event.outcome`, `orchestrator.resource.name`, `orchestrator.namespace`,
  and `source.ip`.
- Inspect the pod image, command, and volume mounts for credential theft or reverse shells.
- Check whether anonymous authentication is enabled and remove RBAC grants to `system:anonymous`.

### False positives

- Essentially none in production; treat as high-priority misconfiguration until proven otherwise.

"""
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests",
    "https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging",
]
risk_score = 73
rule_id = "92980750-3373-4f0c-aebd-c2a8563d8e8a"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."

query = '''
data_stream.dataset:gcp.audit and service.name:k8s.io and client.user.email:("system:anonymous" or "system:unauthenticated" or not *) and event.action:(io.k8s.core.v1.pods.create or io.k8s.core.v1.pods.patch or io.k8s.core.v1.pods.update)
'''

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

[[rule.threat.technique]]
id = "T1610"
name = "Deploy Container"
reference = "https://attack.mitre.org/techniques/T1610/"

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

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

[metadata]
creation_date = "2022/08/25"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/28"

[rule]
author = ["Elastic"]
description = """
Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace.
Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed
within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for
security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google
Workspace environment prior to distributing the malicious APK to the end user.
"""
false_positives = [
    """
    Applications can be added and removed from blocklists by Google Workspace administrators, but they can all be
    explicitly allowed for users. Verify that the configuration change was expected. Exceptions can be added to this
    rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Restrictions for Marketplace Modified to Allow Any App"
note = """## Triage and analysis

### Investigating Google Workspace Restrictions for Marketplace Modified to Allow Any App

Google Workspace Marketplace is an online store for free and paid web applications that work with Google Workspace services and third-party software. Listed applications are based on Google APIs or Google Apps Script and created by both Google and third-party developers.

Marketplace applications require access to specific Google Workspace resources. Applications can be installed by individual users, if they have permission, or can be installed for an entire Google Workspace domain by administrators. Consent screens typically display what permissions and privileges the application requires during installation. As a result, malicious Marketplace applications may require more permissions than necessary or have malicious intent.

Google clearly states that they are not responsible for any product on the Marketplace that originates from a source other than Google.

This rule identifies when the global allow-all setting is enabled for Google Workspace Marketplace applications.

### Possible investigation steps

- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert.
- Confirm `google_workspace.admin.new_value` is `ALLOW_ALL` and review `google_workspace.admin.old_value` for the prior restriction.
- In the admin console, verify the change under `Apps > Google Workspace Marketplace apps` (global allowlist access setting).
- This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace.
- Search for `event.action` is `ADD_APPLICATION` to identify applications installed after these changes were made.
    - The `google_workspace.admin.application.name` field will help identify what applications were added.
- With the user account, review other potentially related events within the last 48 hours.
- Re-assess the permissions and reviews of the Marketplace applications to determine if they violate organizational policies or introduce unexpected risks.
- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace Apps`.

### False positive analysis

- Identify the user account associated with this action and assess their administrative privileges with Google Workspace Marketplace.
- Google Workspace administrators may intentionally enable allow-all marketplace access based on organizational needs.
    - Follow up with the administrator who made the change to ensure this was intended.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- 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.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/6089179?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 = 47
rule_id = "a2795334-2499-11ed-9e1a-f661ea17fbce"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING"
    and google_workspace.event.type:"APPLICATION_SETTINGS" and google_workspace.admin.application.name:"Google Workspace Marketplace"
        and google_workspace.admin.setting.name:"Apps Access Setting Allowlist access"  and google_workspace.admin.new_value:"ALLOW_ALL"
'''

[rule.investigation_fields]
field_names = [
    "source.ip",
    "user.name",
    "user.email",
    "event.action",
    "google_workspace.admin.org_unit.name",
    "google_workspace.admin.setting.name",
    "google_workspace.admin.old_value",
    "google_workspace.admin.new_value",
]

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

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

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

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

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

[metadata]
creation_date = "2026/03/10"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/08/18"

[rule]
author = ["Elastic"]
description = """
Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc
AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit
log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller
identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure
ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries
with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and
configmaps while appearing as the Arc proxy service account in K8s audit logs. This rule uses a 5-day new-terms history
window keyed on the impersonated identity and alerts the first time that Azure AD principal performs this activity.
"""
false_positives = [
    """
    Azure Arc system components may create or update secrets and configmaps in the azure-arc and azure-arc-release
    namespaces during normal cluster management. Filter by namespace to exclude these.
    """,
    """
    Helm operations managed through Arc may create release secrets (prefixed with sh.helm.release.v1). These are normal
    Arc lifecycle operations.
    """,
]
from = "now-5d"
interval = "9m"
language = "esql"
license = "Elastic License v2"
name = "Kubernetes Secret or ConfigMap Access via Azure Arc Proxy"
note = """## Triage and analysis

### Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy

When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy
service account as the authenticated user, with the actual Azure AD identity in the `impersonatedUser` field. This
rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this
proxy path. Read operations (`get`, `list`) are particularly important to detect as they represent the most common
adversary action: exfiltrating secrets without leaving obvious modification traces.

This rule uses a new terms approach keyed on `kubernetes.audit.impersonatedUser.username`, so it fires the first time a
given impersonated identity performs this activity within the 5-day history window.

### Possible investigation steps

- Check the `kubernetes.audit.impersonatedUser.username` field — this contains the Azure AD object ID of the actual
  caller. Cross-reference with Azure AD to identify the service principal or user.
- Review the `kubernetes.audit.impersonatedUser.extra.oid` field for the Azure AD object ID.
- Examine the namespace — operations in `default` or application namespaces are more suspicious than `azure-arc` or
  `kube-system`.
- Check the `kubernetes.audit.objectRef.name` — look for suspicious secret/configmap names that don't match known
  application resources.
- Correlate with Azure Activity Logs for the same time window to find the `LISTCLUSTERUSERCREDENTIAL` operation that
  initiated the Arc proxy session.
- Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

### Response and remediation

- If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
- Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
- Rotate any Kubernetes secrets that may have been read or exfiltrated.
- Review the Arc connection and consider disconnecting it if compromised.
"""
references = [
    "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect",
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
    "https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence",
    "https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services",
    "https://www.wiz.io/blog/lateral-movement-risks-in-the-cloud-and-how-to-prevent-them-part-3-from-compromis",
]
risk_score = 47
rule_id = "220d92c6-479d-4a49-9cc0-3a29756dad0c"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Data Source: Kubernetes API Server Audit Logs",
    "Domain: Kubernetes",
    "Platform: Kubernetes",
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-kubernetes.audit_logs-* metadata _id, _version, _index
| WHERE STARTS_WITH(kubernetes.audit.user.username, "system:serviceaccount:azure-arc:")
    AND kubernetes.audit.objectRef.resource IN ("secrets", "configmaps")
    AND kubernetes.audit.verb IN ("get", "list", "create", "update", "patch", "delete")
    AND kubernetes.audit.objectRef.namespace NOT IN ("azure-arc", "azure-arc-release", "kube-system")
    AND NOT STARTS_WITH(kubernetes.audit.objectRef.name, "sh.helm.release.v1")

| STATS
    Esql.verb_values = VALUES(kubernetes.audit.verb),
    Esql.resource_type_values = VALUES(kubernetes.audit.objectRef.resource),
    Esql.resource_name_values = VALUES(kubernetes.audit.objectRef.name),
    Esql.namespace_values = VALUES(kubernetes.audit.objectRef.namespace),
    Esql.data_stream_namespace_values = VALUES(data_stream.namespace),
    Esql.acting_user_values = VALUES(kubernetes.audit.user.username),
    Esql.user_agent_values = VALUES(kubernetes.audit.userAgent),
    Esql.source_ips_values = VALUES(kubernetes.audit.sourceIPs),
    Esql.response_code_values = VALUES(kubernetes.audit.responseStatus.code),
    Esql.timestamp_first_seen = MIN(@timestamp),
    Esql.timestamp_last_seen = MAX(@timestamp),
    Esql.event_count = COUNT(*)
    BY kubernetes.audit.impersonatedUser.username

| WHERE Esql.timestamp_first_seen >= NOW() - 9 minutes
| KEEP kubernetes.audit.impersonatedUser.username, Esql.*
'''


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

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

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

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

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

[[rule.threat.technique]]
id = "T1213"
name = "Data from Information Repositories"
reference = "https://attack.mitre.org/techniques/T1213/"

[[rule.threat.technique]]
id = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

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

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

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

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

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

[rule]
description = """
Identifies the execution of an executable file written or modified by Microsoft Office processes and via a Windows Shell
process.
"""
id = "54aabea0-3687-4ef1-b70c-015ca588e563"
license = "Elastic License v2"
name = "Microsoft Office File Execution via Script Interpreter"
os_list = ["windows"]
version = "1.0.32"

query = '''
sequence by user.id with maxspan=1m
  [file where event.action != "deletion" and
    (file.extension : ("exe", "com", "pif", "scr") or
      // Match Windows PE files by header data (MZ)
      file.Ext.header_bytes : "4d5a*") and
    process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE")] by file.path
  [process where event.action == "start" and
    process.parent.name : ("powershell.exe", "pwsh.exe", "cmd.exe", "cscript.exe", "wscript.exe") and
    not process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe")] by process.executable
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"



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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Detects when a new member is added to a GitHub organization as an owner. This role provides admin level privileges. Any
new owner roles should be investigated to determine it's validity. Unauthorized owner roles could indicate compromise
within your organization and provide unlimited access to data and settings.
"""
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "New GitHub Owner Added"
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 New GitHub Owner Added

GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation.

### Possible investigation steps

- Review the GitHub audit logs to identify the specific user account that was added as an owner, focusing on the event.action "org.add_member" and github.permission "admin".
- Verify the identity and role of the newly added owner by cross-referencing with internal HR or user management systems to confirm if the addition was authorized.
- Check the activity history of the newly added owner account for any suspicious actions or changes made to repositories or settings since their addition.
- Contact the individual or team responsible for managing GitHub organization permissions to confirm if they were aware of and approved the new owner addition.
- Investigate any recent changes in the organization's membership or access policies that might explain the addition of a new owner.
- Assess the potential impact of the new owner's access by reviewing the repositories and sensitive data they now have administrative control over.

### False positive analysis

- Legitimate organizational changes: New owners may be added during legitimate restructuring or team expansions. Regularly review and document organizational changes to differentiate between authorized and unauthorized additions.
- Automated processes: Some organizations use automated scripts or tools to manage GitHub permissions, which might trigger this rule. Identify and whitelist these processes to prevent unnecessary alerts.
- Temporary access requirements: Occasionally, temporary owner access might be granted for specific projects or tasks. Implement a process to track and review these temporary changes, ensuring they are reverted once the task is completed.
- Onboarding of new senior staff: When new senior staff members join, they might be added as owners. Establish a clear onboarding process that includes notifying the security team to avoid false positives.
- Cross-functional team collaborations: In some cases, cross-functional teams may require owner-level access for collaboration. Maintain a list of such collaborations and review them periodically to ensure they remain necessary and authorized.

### Response and remediation

- Immediately revoke the admin privileges of the newly added GitHub owner to prevent further unauthorized access.
- Conduct a thorough review of recent changes and activities performed by the unauthorized owner to identify any potential data breaches or malicious actions.
- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
- Reset credentials and enforce multi-factor authentication for all existing GitHub organization owners to enhance security.
- Review and update access control policies to ensure that owner roles are granted only to verified and necessary personnel.
- Implement additional monitoring and alerting for any future changes to GitHub organization roles to detect similar threats promptly.
- If evidence of compromise is found, consider engaging with a digital forensics team to assess the full impact and scope of the breach."""
risk_score = 47
rule_id = "24401eca-ad0b-4ff9-9431-487a8e183af9"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Persistence",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
iam where data_stream.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin"
'''


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

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

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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects nsenter executions from inside a monitored Linux container that include a namespace target flag (-t or
--target). Adversaries abuse nsenter to attach to host or sibling namespaces and escape container isolation when
combined with privileged mounts, exposed PIDs, or shared namespaces.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Nsenter Execution with Target Flag Inside Container"
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 Nsenter Execution with Target Flag Inside Container

This alert flags `nsenter` (by process name or as a process argument) launched from a workload with a non-empty
`container.id`, with `-t` or `--target` present on the command line. That pattern is consistent with entering another
process or namespace context and is a common building block for container escape and host pivoting when prerequisites
such as host PID mounts or excessive capabilities exist.

### Possible investigation steps

- Review the full command line and parent process to see which PID or path was passed to `-t` / `--target`, and whether
  additional flags such as `-m`, `-n`, `-p`, `-U`, or `-i` indicate mount, network, PID, user, or IPC namespace joins.
- Map the container image, pod, namespace, and node; confirm whether the workload should ever invoke nsenter or share
  namespaces with the host.
- Correlate with file, network, and authentication telemetry from the same container for follow-on access to the
  container runtime socket, kubelet paths, SSH material, or cloud instance metadata.

### False positive analysis

- Some troubleshooting images or platform agents may wrap nsenter for diagnostics; verify image provenance, scheduled
  maintenance, and approved break-glass procedures before treating as malicious.

### Response and remediation

- If the activity is unauthorized, isolate the pod or node, preserve runtime artifacts, rotate any credentials exposed to
  the container, and re-image or replace the node when host integrity is in doubt.
- Reduce recurrence by enforcing least privilege, avoiding host namespace sharing, restricting hostPath and sensitive
  mounts, and blocking unnecessary capabilities.
"""
references = [
    "https://attack.mitre.org/techniques/T1611/",
    "https://man7.org/linux/man-pages/man1/nsenter.1.html",
]
risk_score = 73
rule_id = "39029450-8e2d-4034-81b0-15af8e4e3a4e"
severity = "high"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "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 == "nsenter" or process.args == "nsenter") and
  container.id like "?*" and process.args like ("-t", "--target*")
'''

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

[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

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

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

[rule]
author = ["Elastic"]
description = """
An adversary can use the Background Intelligent Transfer Service (BITS) SetNotifyCmdLine method to execute a program
that runs after a job finishes transferring data or after a job enters a specified state in order to persist on a
system.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process-*",
    "winlogbeat-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-m365_defender.event-*",
]
language = "eql"
license = "Elastic License v2"
name = "Persistence via BITS Job Notify Cmdline"
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 Persistence via BITS Job Notify Cmdline

Background Intelligent Transfer Service (BITS) is a Windows service that facilitates asynchronous, prioritized, and throttled transfer of files between machines. Adversaries exploit BITS by using the SetNotifyCmdLine method to execute malicious programs post-transfer, achieving persistence. The detection rule identifies suspicious processes initiated by BITS, excluding known legitimate executables, to flag potential abuse.

### Possible investigation steps

- Review the process details to confirm the parent process is "svchost.exe" with arguments containing "BITS" to ensure the alert is not a false positive.
- Examine the process executable path to verify it is not one of the known legitimate executables listed in the exclusion criteria.
- Investigate the command line arguments of the suspicious process to identify any potentially malicious or unusual commands being executed.
- Check the file hash and signature of the suspicious executable to determine if it is known malware or a legitimate application.
- Analyze the network activity associated with the process to identify any suspicious connections or data transfers that may indicate malicious behavior.
- Review the system's event logs for any additional context or related events that could provide insight into the persistence mechanism or the adversary's actions.
- Assess the affected system for any other signs of compromise or persistence mechanisms that may have been employed by the adversary.

### False positive analysis

- Legitimate system processes or updates may occasionally trigger the rule if they are not included in the exclusion list. Regularly review and update the exclusion list to include any new legitimate executables that are identified.
- Some third-party software may use BITS for legitimate purposes, such as software updates or data synchronization. Identify these applications and consider adding their executables to the exclusion list to prevent false positives.
- Scheduled tasks or scripts that utilize BITS for file transfers might be flagged. Verify the legitimacy of these tasks and, if deemed safe, exclude their associated executables from the detection rule.
- In environments where custom scripts or administrative tools are used, ensure that these are documented and, if necessary, excluded from the rule to avoid unnecessary alerts.
- Monitor the frequency and context of alerts to identify patterns that may indicate benign activity. Use this information to refine the rule and reduce false positives without compromising security.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified as being initiated by BITS that are not part of the known legitimate executables list.
- Conduct a thorough review of the BITS job configurations on the affected system to identify and remove any unauthorized or suspicious jobs.
- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised.
- Update and run a full antivirus and anti-malware scan on the affected system to ensure no additional threats are present.
- Review and enhance endpoint protection policies to prevent unauthorized use of BITS for persistence, ensuring that only trusted applications can create or modify BITS jobs.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
references = [
    "https://pentestlab.blog/2019/10/30/persistence-bits-jobs/",
    "https://docs.microsoft.com/en-us/windows/win32/api/bits1_5/nf-bits1_5-ibackgroundcopyjob2-setnotifycmdline",
    "https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin-setnotifycmdline",
    "https://www.elastic.co/blog/hunting-for-persistence-using-elastic-security-part-2",
]
risk_score = 47
rule_id = "c3b915e0-22f3-4bf7-991d-b643513c722f"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "svchost.exe" and process.parent.args : "BITS" and
  not process.executable :
              ("?:\\Windows\\System32\\WerFaultSecure.exe",
               "?:\\Windows\\System32\\WerFault.exe",
               "?:\\Windows\\System32\\wermgr.exe",
               "?:\\WINDOWS\\system32\\directxdatabaseupdater.exe")
'''

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:

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


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


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

[rule]
description = """
Detects when a hidden executable creates and then immediately deletes a temporary file within a temporary directory like
/tmp. We have observed threat actors doing this for data collection, exfiltration and prompt deletion.
"""
id = "a6994646-d314-4ee0-be1f-1d694dc969e7"
license = "Elastic License v2"
name = "Potential Data Collection in Temporary Directory by Hidden Executable"
os_list = ["macos"]
version = "1.0.8"

query = '''
sequence by process.entity_id, file.path with maxspan=30s
  [file where event.action == "modification" and process.name like~ ".*" and
   file.path like ("/private/tmp/*", "/tmp/*", "/var/tmp/*") and
   not process.executable like "/nix/store/*" and
   not Effective_process.executable == "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Code - Insiders"]
  [file where event.action == "deletion" and process.name like~ ".*" and
   file.path like ("/private/tmp/*", "/tmp/*", "/var/tmp/*") and
   not process.executable like "/nix/store/*" and
   not Effective_process.executable == "/Applications/Visual Studio Code - Insiders.app/Contents/MacOS/Code - Insiders"]
'''

min_endpoint_version = "8.11.1"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.executable"
state = 0

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1560"
name = "Archive Collected Data"
reference = "https://attack.mitre.org/techniques/T1560/"
[[threat.technique.subtechnique]]
id = "T1560.003"
name = "Archive via Custom Method"
reference = "https://attack.mitre.org/techniques/T1560/003/"



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

[internal]
min_endpoint_version = "8.11.1"

[rule]
description = """
Identifies attempts to change the memory page permissions of Event Tracing for Windows (ETW) functions in ntdll.dll to
make them writable from an unsigned or suspicious module. This is a precursor to patching those functions via a raw
pointer write, which can disable ETW-based telemetry and evade security tooling that relies on it.
"""
id = "a26e8618-136d-4988-a8a7-eb45d5f1d468"
license = "Elastic License v2"
name = "Potential ETW Bypass via VirtualProtect"
os_list = ["windows"]
reference = [
    "https://blog.xpnsec.com/hiding-your-dotnet-etw/",
    "https://www.elastic.co/security-labs/doubling-down-etw-callstacks",
]
version = "1.0.3"

query = '''
api where process.Ext.api.name in ("VirtualProtect", "VirtualProtectEx") and
 process.Ext.api.metadata.target_address_name like ("ntdll.dll!Etw*", "ntdll.dll!NtTrace*") and
 process.Ext.api.parameters.protection like "?W*" and
 process.executable != null and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 != null and 
 not process.thread.Ext.call_stack_final_user_module.name in ("Unknown", "Undetermined") and
 not (process.executable : "?:\\Program Files\\Microsoft Visual Studio\\*\\IDE\\devenv.exe" and 
      process.Ext.api.metadata.target_address_name like ("ntdll.dll!EtwUnregisterTraceGuid*", "ntdll.dll!EtwRegisterTraceGuids*")) and 
 not _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info like ("c:\\windows\\system32\\ntdll.dll!Ldr*", "c:\\program files\\microsoft sql server management studio*\\ide\\ssms.exe!SetOnAssertCallback*")) and 
 not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true and
                  $entry.subject_name in ("Microsoft Windows Hardware Compatibility Publisher",
                                          "Microsoft Windows Software Compatibility Publisher",
                                          "Palo Alto Networks", "Sentinel Labs, Inc.",
                                          "Microsoft Corporation", 
                                          "Check Point Software Technologies Ltd.", 
                                          "ESET, spol. s r.o.",
                                          "Promon AS",
                                          "SAP",
                                          "NOVASYNC LABS PTE. LTD.",
                                          "Tonalio GmbH",
                                          "SentinelOne Inc.",
                                          "JetBrains s.r.o.",
                                          "Safetica a.s.",
                                          "ModuleWorks GmbH",
                                          "Star Finanz-Software Entwicklung und Vertriebs GmbH", 
                                          "TRACKER SOFTWARE PRODUCTS (CANADA) LIMITED, TRACKER SOFTWARE PRODUCTS (CANADA) LIMITED")) and 
  not (process.executable like "C:\\Program Files (x86)\\SFirmV*\\SFEbicsWorker.exe" and process.thread.Ext.call_stack_final_user_module.protection_provenance_path == "c:\\windows\\system32\\rundll32.exe") and 
  not (process.parent.executable like "C:\\Program Files (x86)\\StarMoney*\\app\\StarMoney.exe" and process.thread.Ext.call_stack_final_user_module.protection_provenance_path == "c:\\windows\\system32\\rundll32.exe") and 
  process.thread.Ext.call_stack_final_user_module.protection_provenance_path != "c:\\windows\\syswow64\\icu.dll" and 
  not (process.thread.Ext.call_stack_final_user_module.path == "c:\\windows\\syswow64\\combase.dll" and process.Ext.api.summary == "VirtualProtect( ntdll.dll!EtwEventRegister, 0x5, RWX, R-X )")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[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.16.3"

[rule]
description = """
Identifies the execution of commands via Windows PowerShell with a pattern specific to the Sliver pentesting framework.
Sliver is an open source cross-platform adversary emulation and red team framework.
"""
id = "14626cac-eb09-4e52-81f1-f87975e8f5ae"
license = "Elastic License v2"
name = "Potential Execution via Sliver Framework"
os_list = ["windows"]
reference = [
    "https://github.com/BishopFox/sliver/blob/master/implant/sliver/shell/shell_windows.go#L39",
    "https://github.com/BishopFox/sliver",
]
version = "1.0.19"

query = '''
process where event.action == "start" and

(
  /* Silver default shell cmd */
 (process.name : "powershell.exe" and
  process.command_line : "?:\\Windows\\System32\\WindowsPowerShell\\*\\powershell.exe -NoExit -Command [Console]::OutputEncoding=[Text.UTF8Encoding]::UTF8") or

 (process.parent.name : "powershell.exe" and
  process.parent.command_line : "?:\\Windows\\System32\\WindowsPowerShell\\*\\powershell.exe -NoExit -Command [Console]::OutputEncoding=[Text.UTF8Encoding]::UTF8") or

  descendant of [process where event.action == "start" and
                 process.name : "powershell.exe" and
                 process.command_line : "?:\\Windows\\System32\\WindowsPowerShell\\*\\powershell.exe -NoExit -Command [Console]::OutputEncoding=[Text.UTF8Encoding]::UTF8"] or

   /* getsystem default to injecting spoolsv.exe and for diverse cmds default to spawn a notepad.exe instance */
  (process.executable : "?:\\Windows\\System32\\notepad.exe" and process.parent.executable : "?:\\Windows\\system32\\spoolsv.exe") or

   /* Silver spawns_as a child process with extra quotes after the process image */
  (process.args_count == 2 and process.command_line : "?:\\*.exe \"\"" and process.args : "?:\\Windows\\*.exe")
) and
not (process.code_signature.subject_name : "Chocolatey Software, Inc." and process.code_signature.trusted == true) and
not (process.parent.executable : "?:\\ProgramData\\chocolatey\\choco.exe" and process.parent.args : "install") and
not  descendant of [process where event.action == "start" and
                    process.code_signature.subject_name : "Chocolatey Software, Inc." and process.code_signature.trusted == true] and
not (process.executable : "?:\\Windows\\System32\\setx.exe" and
      process.args : "ChocolateyLastPathUpdate" and process.parent.name : "powershell.exe") and 
not process.parent.executable : "?:\\Program Files (x86)\\Microsoft Office\\root\\Office*\\protocolhandler.exe"
'''

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

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

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

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



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

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

[internal]
min_endpoint_version = "7.16.0"

[metadata]
creation_date = "2023/09/05"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This detection rule monitors for the execution of a system command with setuid or setgid capabilities via Python,
followed by a uid or gid change to the root user. This sequence of events may indicate successful privilege escalation.
Setuid (Set User ID) and setgid (Set Group ID) are Unix-like OS features that enable processes to run with elevated
privileges, based on the file owner or group. Threat actors can exploit these attributes to escalate privileges to the
privileges that are set on the binary that is being executed.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Privilege Escalation via Python cap_setuid"
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 Privilege Escalation via Python cap_setuid

In Unix-like systems, setuid and setgid allow processes to execute with elevated privileges, often exploited by adversaries to gain unauthorized root access. Attackers may use Python scripts to invoke system commands with these capabilities, followed by changing user or group IDs to root. The detection rule identifies this sequence by monitoring Python processes executing system commands with setuid/setgid, followed by a root user or group ID change, signaling potential privilege escalation attempts.

### Possible investigation steps

- Review the process details, including process.entity_id and process.args, to confirm the execution of a Python script with setuid or setgid capabilities.
- Check the user.id and group.id fields to verify if there was an unauthorized change to root (user.id == "0" or group.id == "0").
- Investigate the host.id to determine if other suspicious activities or alerts have been associated with the same host.
- Examine the timeline of events to see if the uid_change or gid_change occurred immediately after the Python process execution, indicating a potential privilege escalation attempt.
- Look into the source of the Python script or command executed to identify if it was a known or unknown script, and assess its legitimacy.
- Analyze any related network activity or connections from the host around the time of the alert to identify potential lateral movement or data exfiltration attempts.

### False positive analysis

- Development and testing environments may trigger this rule when developers use Python scripts to test setuid or setgid functionalities. To manage this, exclude specific user accounts or host IDs associated with development activities.
- Automated scripts or maintenance tasks that require temporary privilege escalation might be flagged. Identify and whitelist these scripts by their process names or paths to prevent false positives.
- System administrators using Python scripts for legitimate administrative tasks could inadvertently trigger the rule. Consider excluding known administrator accounts or specific scripts used for routine maintenance.
- Security tools or monitoring solutions that simulate attacks for testing purposes may cause alerts. Exclude these tools by their process signatures or host IDs to avoid unnecessary alerts.
- Custom applications that use Python for legitimate privilege management should be reviewed and, if safe, added to an exception list based on their unique process identifiers or execution paths.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious Python processes identified by the detection rule to halt potential privilege escalation activities.
- Review and revoke any unauthorized setuid or setgid permissions on binaries or scripts to prevent exploitation.
- Conduct a thorough investigation of the affected system to identify any additional signs of compromise or persistence mechanisms.
- Reset credentials and review access permissions for any accounts that may have been affected or used in the attack.
- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected."""
risk_score = 73
rule_id = "a0ddb77b-0318-41f0-91e4-8c1b5528834f"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### 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 to select "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).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
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.args : "import os;os.set?id(0);os.system(*)" and process.args : "*python*" and user.id != "0"]
  [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and
   (user.id == "0" or group.id == "0")]
'''

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

[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

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

[[rule.threat.technique.subtechnique]]
id = "T1548.001"
name = "Setuid and Setgid"
reference = "https://attack.mitre.org/techniques/T1548/001/"

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

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

[rule]
author = ["Elastic"]
description = """
This rule detects the configuration of a GitHub Actions self-hosted runner using the Runner.Listener binary.
When a machine is registered to a remote repository, its owner gains the ability to execute arbitrary workflow commands on that host.
Unexpected or unauthorized runner registration may indicate adversarial activity aimed at establishing remote code execution
via malicious GitHub workflows.
"""
false_positives = [
    "Authorized github repository with no malicious workflow actions.",
]
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*"
]
language = "eql"
license = "Elastic License v2"
name = "Remote GitHub Actions Runner Registration"
note = """## Triage and analysis

### Investigating Remote GitHub Actions Runner Registration

Unexpected or unauthorized Github actions runner registration may indicate adversarial activity aimed at establishing remote code execution via malicious GitHub workflows.

### Possible investigation steps

- Review the remote repository details and reputation.
- Examine the remote repository for any suspicious workflows run commands in the `.github/workflows` folder.
- Examine the execution context like process tree, associated network and file activities.
- Verify if there is adjascent any sensitive file access or collection.
- Correlate with other alerts and investiguate if this activity is related to a supply chain attack.

### False positive analysis

- Authorized configuration changes.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement.
- Terminate any suspicious child processes that were initiated by the registered Github actions runner.
- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise.
- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed.
- Implement application whitelisting to prevent unauthorized execution.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
references = [
    "https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise",
    "https://socket.dev/blog/shai-hulud-strikes-again-v2",
]
risk_score = 47
rule_id = "57e118c1-19eb-4c20-93a6-8a6c30a5b48b"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: Windows",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Initial Access",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 process.name in ("Runner.Listener", "Runner.Listener.exe") and
 process.args == "configure" and process.args == "--url" and process.args == "--token"
'''


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

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

[[rule.threat.technique]]
id = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"

[[rule.threat.technique.subtechnique]]
id = "T1195.002"
name = "Compromise Software Supply Chain"
reference = "https://attack.mitre.org/techniques/T1195/002/"

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

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

[[rule.threat.technique]]
id = "T1219"
name = "Remote Access Tools"
reference = "https://attack.mitre.org/techniques/T1219/"

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