Elastic rules: 3f

[metadata]
creation_date = "2023/08/23"
integration = ["endpoint", "windows", "system"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Attackers may abuse cmd.exe commands to reassemble binary fragments into a malicious payload.\n"
from = "now-119m"
index = [
    "endgame-*",
    "logs-endpoint.events.process-*",
    "logs-system.security*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Binary Content Copy via Cmd.exe"
risk_score = 21
rule_id = "53dedd83-1be7-430f-8026-363256395c8b"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Rule Type: BBR",
    "Data Source: Sysmon",
    "Data Source: Elastic Endgame",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.name : "cmd.exe" and (
    (process.args : "type" and process.args : (">", ">>")) or
    (process.args : "copy" and process.args : "/b"))
'''


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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to
bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and
sensitive resources by using bring-your-own IdP (BYOIDP) methods.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.graphactivitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID External Authentication Methods (EAM) Modified"
note = """## Triage and analysis

### Investigating Entra ID External Authentication Methods (EAM) Modified

This rule detects suspicious modifications to external authentication methods (EAMs) in Microsoft Entra ID via Microsoft Graph API. Adversaries may abuse this capability to bypass multi-factor authentication (MFA), enabling persistence or unauthorized access through bring-your-own identity provider (BYOIDP) methods.

### Possible investigation steps
- Validate that `event.action` is `"Microsoft Graph Activity"` and that `http.request.method` is `"PATCH"`, indicating a configuration change was made.
- Confirm that `url.path` contains the string `authenticationMethodsPolicy`, which is associated with external authentication settings in Entra ID.
- Review `user.id` to identify the Azure AD object ID of the user or service principal that initiated the change.
- Examine `azure.graphactivitylogs.properties.app_id` to determine the application ID that performed the action.
- Analyze `azure.graphactivitylogs.properties.scopes[]` to assess whether the request used privileged scopes such as `AuthenticationMethod.ReadWrite.All`.
- Review the geographic origin of the request using `source.geo.*` and the `source.ip` field to identify anomalous locations.
- Examine `user_agent.original` to determine whether the request was made through a browser or automation (e.g., scripted activity).
- Correlate `azure.graphactivitylogs.properties.token_issued_at` and `azure.graphactivitylogs.properties.time_generated` to assess whether the change occurred shortly after token issuance.
- Investigate additional activity by the same `user.id` or `app_id` within a short timeframe (e.g., 30 minutes) to detect related suspicious behavior.
- Use the `operation_id` or `correlation_id` to pivot across related Graph API or Entra ID activity logs, if available.

### False positive analysis
- Legitimate administrative activity may trigger this rule, such as configuring FIDO2 or enabling passwordless sign-in methods during onboarding or security upgrades.
- Some enterprise integrations or federated identity providers may programmatically update EAM settings as part of legitimate operations.
- Routine security assessments or red team exercises may include changes to authentication policies. Validate with internal teams when in doubt.
- If appropriate, filter or suppress alerts originating from known trusted service principals or administrative accounts.

### Response and remediation
- Confirm whether the user or application that made the change was authorized to do so. If not, immediately revoke access and reset credentials as needed.
- Review the application or automation that triggered the change to ensure it is legitimate. If unauthorized, disable or remove it and rotate secrets or tokens it may have accessed.
- Audit current external authentication configurations and conditional access policies to ensure no persistent backdoors were introduced.
- Revoke session tokens associated with the change using Entra ID's portal or Microsoft Graph API, and enforce reauthentication where appropriate.
- Implement stricter RBAC or conditional access policies to prevent unauthorized EAM changes in the future.
- Monitor for repeat or similar activity from the same source or identity as part of an ongoing compromise assessment.
"""
references = ["https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/"]
risk_score = 47
rule_id = "42c97e6e-60c3-11f0-832a-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Graph",
    "Data Source: Microsoft Graph Activity Logs",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: azure.graphactivitylogs and
    url.path: *authenticationMethodsPolicy* and
    http.request.method: "PATCH" and
    http.response.status_code: 200
'''


[[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.009"
name = "Conditional Access Policies"
reference = "https://attack.mitre.org/techniques/T1556/009/"

[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.009"
name = "Conditional Access Policies"
reference = "https://attack.mitre.org/techniques/T1556/009/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.new_terms]
field = "new_terms_fields"
value = ["azure.graphactivitylogs.properties.user_principal_object_id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2025/01/20"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies the creation or execution of files or processes with names containing the Right-to-Left Override (RTLO)
character, which can be used to disguise the file extension and trick users into executing malicious files.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "endgame-*",
]
language = "eql"
license = "Elastic License v2"
name = "File with Right-to-Left Override Character (RTLO) Created/Executed"
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 File with Right-to-Left Override Character (RTLO) Created/Executed

The RTLO character reverses text direction, often used to disguise file extensions, making malicious files appear benign. Adversaries exploit this to trick users into executing harmful files. The detection rule identifies suspicious file or process activities on Windows systems by scanning for RTLO characters in file paths or process names, helping to uncover potential masquerading attempts.

### Possible investigation steps

- Review the alert details to identify the specific file path or process name containing the RTLO character by examining the file.path or process.name fields.
- Check the event.type field to determine whether the alert was triggered by a file creation or process start event, which can help prioritize the investigation focus.
- Investigate the origin of the file or process by examining the file's creation time, user account involved, and any associated network activity to identify potential sources or delivery methods.
- Analyze the file or process for malicious behavior by using endpoint detection tools or sandbox environments to execute and monitor its actions.
- Cross-reference the file or process with threat intelligence databases to check for known malicious indicators or similar attack patterns.
- Review system logs and other security alerts around the same timeframe to identify any additional suspicious activities or related incidents.

### False positive analysis

- Legitimate software installations or updates may use RTLO characters in file names to manage versioning or localization, which can trigger false positives. Users can create exceptions for known software vendors or specific installation directories to reduce these alerts.
- Some file management or backup applications might use RTLO characters in temporary file names for internal processing. Identifying these applications and excluding their specific file paths from monitoring can help minimize false positives.
- Custom scripts or tools developed in-house might inadvertently use RTLO characters for legitimate purposes. Reviewing these scripts and excluding their execution paths or file names from the detection rule can prevent unnecessary alerts.
- Certain international or multilingual applications may use RTLO characters as part of their normal operation. Users should identify these applications and configure exceptions based on their file paths or process names to avoid false positives.
- In environments where file names are dynamically generated and may include RTLO characters, consider implementing a whitelist of trusted file paths or process names to reduce the likelihood of false alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
- Terminate any suspicious processes identified with the RTLO character in their names to halt any ongoing malicious activity.
- Quarantine the files containing the RTLO character to prevent execution and further analysis.
- Conduct a thorough scan of the isolated system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants.
- Review and analyze system logs and security alerts to determine the extent of the compromise and identify any lateral movement or additional affected systems.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary.
- Implement enhanced monitoring and detection rules to identify future attempts to use RTLO characters for masquerading, ensuring that similar threats are detected promptly."""
risk_score = 47
rule_id = "7e763fd1-228a-4d43-be88-3ffc14cd7de1"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where host.os.type == "windows" and event.category in ("file", "process") and 
  (
    (event.type == "creation" and file.path : "*\u{202E}*") or 
    (event.type == "start" and process.name : "*\u{202E}*")
  )
'''

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)
- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
"""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[rule.threat.technique.subtechnique]]
id = "T1036.002"
name = "Right-to-Left Override"
reference = "https://attack.mitre.org/techniques/T1036/002/"



[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 = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



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

[metadata]
creation_date = "2026/08/21"
integration = ["sonicwall_firewall"]
maturity = "production"
updated_date = "2026/08/21"

[rule]
author = ["Elastic"]
description = """
Identifies a successful SonicWall VPN- or WAN-zone administrator or remote-user login from a source IP that was not
previously observed with the same user on the same appliance during the prior 14 days. This may indicate stolen
credentials, compromised administrator access, or unauthorized remote access.
"""
false_positives = [
    """
    New administrators or VPN users, travel, mobile networks, ISP address rotation, managed service providers, and first
    observations after integration onboarding or retention loss can trigger this rule.
    """,
]
from = "now-9m"
index = ["logs-sonicwall_firewall.log-*"]
interval = "5m"
language = "kuery"
license = "Elastic License v2"
name = "First Seen SonicWall Remote Access Login by User and Source"
note = """## Triage and analysis

### Investigating First Seen SonicWall Remote Access Login by User and Source

This rule detects a newly observed combination of SonicWall appliance serial number, user name, and source IP for a
successful VPN- or WAN-zone login. Event IDs `235` and `236` are administrator logins from VPN and WAN zones, `237` and
`238` are remote-user logins from VPN and WAN zones, and `1080` is a successful SSL VPN user login.

### Possible investigation steps

- Confirm the user, source IP, appliance, login type, VPN policy, MFA result, and assigned tunnel address.
- Review the source geolocation, reputation, and prior authentication activity.
- Correlate with failed logins, configuration changes, internal reconnaissance, and endpoint activity.
- Prefer exceptions scoped to the appliance, user, and expected source rather than globally excluding an identity.

### False positive analysis

- Validate new users, travel, ISP address changes, managed service provider activity, and integration onboarding before
  treating the alert as unauthorized access.

### Response and remediation

- If unauthorized access is suspected, terminate active sessions, disable the affected account, rotate credentials and
  tokens, verify MFA, and review downstream activity from the assigned tunnel address.
- Preserve SonicWall authentication, VPN session, and configuration audit logs before making broad changes.
"""
references = [
    "https://www.elastic.co/docs/reference/integrations/sonicwall_firewall",
    "https://www.sonicwall.com/support/knowledge-base/monitoring-sslvpn-user-logins/kA1VN0000000JQz0AM",
    "https://www.huntress.com/blog/sonicwall-credential-stuffing-campaign",
]
risk_score = 47
rule_id = "7df97e5b-1722-4305-80c7-7a203f2ff36e"
setup = """## Setup

This rule requires the Elastic SonicWall Firewall integration and SonicWall Enhanced Syslog authentication events.
Configure the appliance to forward **Users > Authentication Access** events, including event IDs `235`, `236`, `237`,
`238`, and `1080`. Verify that the integration populates `data_stream.dataset`, `event.action`, `event.code`,
`source.ip`, `user.name`, and `observer.serial_number`.

The new-terms key requires `observer.serial_number`. Events without that field do not match. Ensure serial numbers are
stable and unique across tenants in a shared Kibana space.
"""
severity = "medium"
tags = [
    "Domain: Network",
    "Domain: Identity",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Data Source: SonicWall Firewall Logs",
    "Rule Type: New Terms",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:"sonicwall_firewall.log" and
  event.action:"login-success" and
  event.code:("235" or "236" or "237" or "238" or "1080") and
  source.ip:* and user.name:* and observer.serial_number:*
'''


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

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


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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "message",
    "event.code",
    "event.action",
    "event.outcome",
    "source.ip",
    "source.port",
    "source.geo.country_iso_code",
    "user.name",
    "observer.serial_number",
    "observer.name",
    "observer.ip",
    "sonicwall.firewall.vpnpolicy",
    "sonicwall.firewall.vpnpolicyDst",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["observer.serial_number", "user.name", "source.ip"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"

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

[rule]
author = ["Elastic"]
description = """
Identifies the first client IP observed issuing MongoDB commands that can drop databases, collections, indexes, users,
or roles within a five-day history window. Adversaries with access to an exposed or compromised MongoDB service may use
these commands to destroy data, disrupt applications, or prepare a wipe-and-extort attack.
"""
false_positives = [
    """
    Database administrators, deployment automation, test teardown jobs, and schema migration tools may issue destructive
    commands legitimately. Validate the client address, target resource, change window, and associated administrator
    activity before escalating.
    """,
]
from = "now-9m"
index = ["logs-network_traffic.mongodb-*"]
language = "kuery"
license = "Elastic License v2"
name = "First-Time Destructive MongoDB Command from a Client IP"
note = """## Triage and analysis

### Investigating First-Time Destructive MongoDB Command from a Client IP

MongoDB wipe-and-extort campaigns commonly enumerate databases before dropping databases or collections and inserting a ransom note. This rule detects the first client IP observed issuing decoded MongoDB commands capable of destructive schema, data, identity, or access changes within a five-day history window.

### Possible investigation steps

- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.mongodb.method`, `network_traffic.mongodb.query`, `network_traffic.mongodb.resource`, and `network_traffic.mongodb.fullCollectionName`.
- Determine whether the client is an approved application, DBA workstation, migration host, or automation service.
- Search earlier events on the same `network.community_id` for `listDatabases`, `listCollections`, `usersInfo`, or `rolesInfo`, which may indicate reconnaissance before destruction.
- Search subsequent activity for database or collection creation and ransom-related strings such as `README`, `RECOVER`, `bitcoin`, or `meow`.
- Confirm the operation and affected resources in MongoDB audit logs and assess whether data was deleted.

### False positive analysis

- Schema migrations and test cleanup can legitimately drop collections or indexes.
- Authorized identity lifecycle operations can drop users or roles.
- Scope exceptions to approved clients and maintenance windows rather than excluding command names globally.

### Response and remediation

- Block the client and isolate the MongoDB service if the activity is unauthorized.
- Preserve MongoDB audit logs and packet evidence, identify affected databases, and begin recovery from immutable backups.
- Rotate database credentials, remove unauthorized users or roles, and restrict MongoDB network access to approved application and administration hosts.
"""
references = [
    "https://www.bleepingcomputer.com/news/security/mongo-lock-attack-ransoming-deleted-mongodb-databases/",
    "https://flare.io/learn/resources/blog/mongodb-ransom",
    "https://attack.mitre.org/techniques/T1485/",
]
risk_score = 73
rule_id = "0d8a33be-5595-400c-a677-c4474829ed55"
setup = """## Setup

This rule requires the Elastic Network Packet Capture integration with the MongoDB protocol analyzer enabled and
cleartext visibility into MongoDB transactions. TLS-encrypted or compressed MongoDB wire traffic may not expose
`network_traffic.mongodb.query`. Modern OP_MSG traffic often reports `network_traffic.mongodb.method` as `msg`, so the
query-text branch is required. Use MongoDB audit logs for authoritative user attribution and operation outcomes.
"""
severity = "high"
tags = [
    "Domain: Network",
    "Use Case: Network Security Monitoring",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Data Source: Network Packet Capture",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:network_traffic.mongodb and
(
  network_traffic.mongodb.method:(
    "dropDatabase" or "drop" or "dropIndexes" or
    "dropAllUsersFromDatabase" or "dropAllRolesFromDatabase"
  ) or
  (
    network_traffic.mongodb.method:"msg" and
    network_traffic.mongodb.query:(
      *dropDatabase* or *dropIndexes* or
      *dropAllUsersFromDatabase* or *dropAllRolesFromDatabase* or
      *\"drop\"*
    )
  )
)
'''


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

[rule.new_terms]
field = "new_terms_fields"
value = ["client.ip"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

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

[rule]
author = ["Elastic"]
description = """
Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may
indicate privilege delegation or RBAC misconfiguration leading to elevated access.
"""
false_positives = [
    """
    GitOps, namespace onboarding, and workload deployment commonly create RoleBindings for service accounts. Default
    bootstrap bindings from `system:apiserver` and GKE node bootstrap from `gcp:kube-bootstrap` are excluded.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Creation of a RoleBinding Referencing a ServiceAccount"
note = """## Triage and analysis

### Investigating GKE Creation of a RoleBinding Referencing a ServiceAccount

This rule detects creation of a RoleBinding or ClusterRoleBinding whose subject is a ServiceAccount. Attackers often bind
over-privileged roles to an existing workload service account to operate with elevated rights.

### Possible investigation steps

- Review `client.user.email`, `source.ip`, `gcp.audit.request.roleRef`, and `gcp.audit.request.subjects`.
- Determine which workloads run under the bound service account and whether the referenced role is cluster-scoped.
- Correlate with secret access, exec, or additional RBAC changes from the same actor.

### False positive analysis

- Legitimate deployments and operators create service account bindings during routine releases.

### Response and remediation

- Remove unauthorized bindings, rotate the service account credentials, and tighten who can create RoleBindings.

"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
]
risk_score = 47
rule_id = "1e58e0a0-7674-4aa9-9409-f72f100a8b5e"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:(
  "io.k8s.authorization.rbac.v1.rolebindings.create" or
  "io.k8s.authorization.rbac.v1.clusterrolebindings.create"
) and gcp.audit.request.subjects.kind:"ServiceAccount" and not client.user.email:(
  "system:apiserver" or
  "gcp:kube-bootstrap"
)
'''

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

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2025/06/19"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "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/30"

[rule]
author = ["Elastic"]
description = """
This rule detects potential kubectl network configuration modification activity by monitoring for process events
where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in
Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as
establishing unauthorized access or exfiltrating data.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-cloud_defend.process*",
]
language = "eql"
license = "Elastic License v2"
name = "Kubectl Network Configuration Modification"
note = """ ## Triage and analysis

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

### Investigating Kubectl Network Configuration Modification

Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and network settings. Adversaries may exploit kubectl to alter network configurations, potentially establishing unauthorized access or data exfiltration channels. The detection rule identifies suspicious kubectl usage patterns, such as port-forwarding or proxy commands, especially when executed from atypical parent processes or directories, indicating possible malicious intent.

### Possible investigation steps

- Review the process command line to confirm the specific kubectl command and arguments used, focusing on "port-forward", "proxy", or "expose" to understand the intended network configuration change.
- Examine the parent process details, including the name and executable path, to determine if the kubectl command was initiated from an unusual or suspicious location, such as "/tmp/*" or "/var/tmp/*".
- Investigate the user account associated with the kubectl process to verify if the activity aligns with their typical behavior or if it indicates potential compromise.
- Check for any recent changes or anomalies in the Kubernetes cluster's network settings or configurations that could correlate with the detected kubectl activity.
- Look for additional related alerts or logs that might indicate a broader pattern of suspicious activity, such as other command and control tactics or protocol tunneling attempts.

### False positive analysis

- Legitimate administrative tasks using kubectl port-forward or proxy commands can trigger the rule. To manage this, create exceptions for known administrative scripts or users who frequently perform these tasks.
- Automated scripts or cron jobs that use kubectl for network configuration changes may cause false positives. Identify these scripts and exclude their specific command patterns or parent processes from the rule.
- Development environments where developers frequently use kubectl for testing purposes might generate alerts. Consider excluding specific user accounts or directories associated with development activities.
- Continuous integration/continuous deployment (CI/CD) pipelines that utilize kubectl for deployment processes can be a source of false positives. Exclude the CI/CD tool's process names or execution paths from the rule.
- Temporary directories like /tmp or /var/tmp used by legitimate applications for kubectl operations can trigger alerts. Review and whitelist these specific applications or their execution contexts.

### Response and remediation

- Immediately isolate the affected host to prevent further unauthorized access or data exfiltration. This can be done by removing the host from the network or applying network segmentation rules.
- Terminate any suspicious kubectl processes identified by the detection rule to halt any ongoing malicious activity.
- Review and revoke any unauthorized access credentials or tokens that may have been compromised or used in the attack.
- Conduct a thorough audit of Kubernetes network configurations and access controls to identify and rectify any unauthorized changes or vulnerabilities.
- Restore any altered network configurations to their original state using backups or configuration management tools.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
- Implement enhanced monitoring and logging for kubectl activities and network configuration changes to detect and respond to similar threats more effectively in the future.
"""
risk_score = 21
rule_id = "877cc04a-3320-411d-bbe9-53266fa5e107"
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 or macOS 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 = "low"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Elastic Defend for Containers",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type in ("linux", "macos") and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
process.name == "kubectl" and (
  process.args == "port-forward" and process.args like "*:*" or
  process.args in ("proxy", "expose")
) and (
  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
  (
    process.parent.executable like (
      "/tmp/*", "/private/tmp/*", "/var/tmp/*", "/private/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*", "/Users/*"
    ) or
    process.parent.name like (".*", "*.sh", "python*")
  )
)
'''

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

[[rule.threat.technique]]
id = "T1090"
name = "Proxy"
reference = "https://attack.mitre.org/techniques/T1090/"

[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"

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

[metadata]
creation_date = "2026/02/02"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects potential endpoint enumeration attempts by an anonymous user. An anonymous user is a user that
is not authenticated or authorized to access the Kubernetes API server. By looking for a series of failed API requests,
on multiple endpoints, and a limited number of documents, this rule can detect automated permission enumeration attempts.
This behavior is uncommon for regular Kubernetes clusters.
"""
language = "esql"
license = "Elastic License v2"
name = "Kubernetes Potential Endpoint Permission Enumeration Attempt by Anonymous User Detected"
note = """ ## Triage and analysis

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

### Investigating Kubernetes Potential Endpoint Permission Enumeration Attempt by Anonymous User Detected

This detects a burst of Kubernetes API requests from an unauthenticated identity that probes many different endpoints and resource types, producing mostly forbidden/unauthorized/not found responses within a small window. It matters because this pattern maps the cluster’s exposed surface and reveals which APIs might be reachable before an attacker commits to credential theft or exploitation. A common usage pattern is scripted GET/LIST sweeps across core and custom resources (for example pods, secrets, namespaces, and CRDs) from one source IP and user agent.

### Possible investigation steps

- Review the specific request URIs and resource types queried and their sequence to fingerprint common reconnaissance tooling and whether high-value endpoints (e.g., secrets, tokenreviews, subjectaccessreviews, CRDs) were probed.  
- Determine whether the apparent source IP is internal or Internet-routable and confirm the true originating client by correlating load balancer/ingress/firewall logs (including X-Forwarded-For) with the audit event timestamps.  
- Validate Kubernetes API server authentication/authorization posture during the window to identify misconfiguration that permits anonymous access and confirm whether any requests returned successful responses that indicate real data exposure.  
- Hunt for follow-on activity from the same origin or user agent such as authenticated requests, service account token usage, RBAC/ClusterRoleBinding changes, pod exec, or secret/configmap reads to assess escalation beyond discovery.  
- If the API endpoint is publicly reachable, apply immediate containment by restricting network access to the API server (allowlisting, VPN/private endpoint, temporary IP blocks) while preserving relevant audit and network logs for forensics.

### False positive analysis

- Misconfigured or transitional API server authentication (e.g., anonymous auth briefly enabled or a failing authn proxy/fronting component) can cause legitimate clients to appear as `system:anonymous` and generate multiple 401/403/404 responses across several endpoints during normal cluster access attempts.
- Internal cluster health checks or component discovery behavior that hits multiple API paths without presenting credentials (or uses requests that the audit log records with empty/null usernames) can resemble enumeration when it produces a short burst of failed requests across diverse resources from a single source IP and user agent.

### Response and remediation

- Immediately restrict Kubernetes API server network exposure by allowlisting known admin/VPN IPs and temporarily blocking the observed source IP(s) and user agent at the load balancer/firewall while preserving audit logs and reverse-proxy access logs for the timeframe.  
- Eradicate the anonymous access path by disabling anonymous authentication on the API server, fixing any misconfigured auth proxy that forwards unauthenticated traffic, and removing any RBAC bindings that grant permissions to `system:anonymous` or `system:unauthenticated`.  
- Validate whether any requests from the same source returned successful responses (especially reads of secrets/configmaps, tokenreviews/subjectaccessreviews, or CRDs) and, if so, rotate impacted service account tokens and credentials and perform a targeted review of recently issued tokens and new ClusterRoleBindings.  
- Recover by re-enabling API access in a controlled manner (private endpoint/VPN, bastion, or mTLS), confirming expected kubectl and controller functionality, and monitoring for renewed bursts of failed requests across many request URIs from unauthenticated identities.  
- Escalate to the incident response lead and platform security team if any anonymous request succeeded, if the probing repeats from multiple external IPs, or if follow-on activity appears (new privileged RBAC, pod exec, or secret reads) within 24 hours of the enumeration attempt.  
- Harden by enforcing least-privilege RBAC, enabling and retaining full audit logging for authn/authz failures, applying API server rate limits/WAF rules for repeated 401/403/404 sweeps, and continuously validating that the API endpoint is not publicly reachable.
"""
references = [
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access"
]
risk_score = 47
rule_id = "2dd0d4fd-0cc9-4d18-8b46-1a507e28bbc0"
severity = "medium"
tags = [
  "Data Source: Kubernetes",
  "Domain: Kubernetes",
  "Use Case: Threat Detection",
  "Tactic: Discovery",
  "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-kubernetes.audit_logs-* metadata _id, _index, _version
| where (
    kubernetes.audit.user.username in ("system:anonymous", "system:unauthenticated") or
    kubernetes.audit.user.username is null or
    kubernetes.audit.user.username == ""
  ) and
  kubernetes.audit.level in ("RequestResponse", "ResponseComplete", "Request")

| eval Esql.decision = `kubernetes.audit.annotations.authorization_k8s_io/decision`
| eval Esql.code = kubernetes.audit.responseStatus.code

| eval Esql.outcome = case(
    Esql.decision == "allow", "authz_allow",
    Esql.decision == "forbid", "authz_forbid",

    // fallback: infer from status when decision is missing
    Esql.code in (401, 403), "authn_authz_failed",
    (Esql.code >= 200 and Esql.code < 300), "success",
    Esql.code == 404, "not_found",
    Esql.code is null, "unknown",
    true, "other_error"
  )

| stats
    Esql.document_count = count(),

    Esql.authz_allow_count = sum(case(Esql.outcome == "authz_allow", 1, 0)),
    Esql.authz_forbid_count = sum(case(Esql.outcome == "authz_forbid", 1, 0)),

    Esql.status_fail_count = sum(case(Esql.outcome == "authn_authz_failed", 1, 0)),
    Esql.success_count = sum(case(Esql.outcome == "success", 1, 0)),
    Esql.not_found_count = sum(case(Esql.outcome == "not_found", 1, 0)),
    Esql.other_error_count = sum(case(Esql.outcome == "other_error", 1, 0)),
    Esql.unknown_count = sum(case(Esql.outcome == "unknown", 1, 0)),

    Esql.kubernetes_audit_verb_count_distinct = count_distinct(kubernetes.audit.verb),
    Esql.kubernetes_audit_requestURI_count_distinct = count_distinct(kubernetes.audit.requestURI),
    Esql.kubernetes_audit_objectRef_resource_count_distinct = count_distinct(kubernetes.audit.objectRef.resource),

    Esql.kubernetes_audit_outcome_values = values(Esql.outcome),
    Esql.kubernetes_audit_decision_values = values(Esql.decision),
    Esql.kubernetes_audit_responseStatus_code_values = values(Esql.code),
    Esql.kubernetes_audit_responseStatus_message_values = values(kubernetes.audit.responseStatus.message),

    Esql.kubernetes_audit_verb_values = values(kubernetes.audit.verb),
    Esql.kubernetes_audit_objectRef_resource_values = values(kubernetes.audit.objectRef.resource),
    Esql.kubernetes_audit_objectRef_namespace_values = values(kubernetes.audit.objectRef.namespace),
    Esql.kubernetes_audit_user_username_values = values(kubernetes.audit.user.username),
    Esql.kubernetes_audit_user_groups_values = values(kubernetes.audit.user.groups),
    Esql.kubernetes_audit_requestURI_values = values(kubernetes.audit.requestURI),
    Esql.data_stream_namespace_values = values(data_stream.namespace)

  BY kubernetes.audit.sourceIPs, user_agent.original

| where
    Esql.kubernetes_audit_requestURI_count_distinct > 5 and
    Esql.kubernetes_audit_objectRef_resource_count_distinct > 3 and
    Esql.document_count < 50 and
    (Esql.authz_forbid_count >= 1 or Esql.status_fail_count >= 1 or Esql.not_found_count >= 3)

| keep Esql.*, kubernetes.audit.sourceIPs, user_agent.original
'''

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

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

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

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

[[rule.threat.technique]]
id = "T1595"
name = "Active Scanning"
reference = "https://attack.mitre.org/techniques/T1595/"

[[rule.threat.technique.subtechnique]]
id = "T1595.003"
name = "Wordlist Scanning"
reference = "https://attack.mitre.org/techniques/T1595/003/"

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

[metadata]
creation_date = "2023/02/13"
integration = ["system"]
maturity = "production"
updated_date = "2026/03/24"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve Information for a Specific Group"
query = "SELECT * FROM groups WHERE groupname = {{group.name}}"

[[transform.osquery]]
label = "Osquery - Retrieve Information for a Specific User"
query = "SELECT * FROM users WHERE username = {{user.name}}"

[[transform.osquery]]
label = "Osquery - Investigate the Account Authentication Status"
query = "SELECT * FROM logged_in_users WHERE user = {{user.name}}"

[[transform.osquery]]
label = "Osquery - Retrieve Running Processes by User"
query = "SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"


[rule]
author = ["Elastic"]
description = """
Identifies attempts to create a new group. Attackers may create new groups to establish persistence on a system.
"""
from = "now-9m"
index = ["filebeat-*", "logs-system.auth-*"]
language = "eql"
license = "Elastic License v2"
name = "Linux Group Creation"
note = """## Triage and analysis

### Investigating Linux Group Creation

The `groupadd` and `addgroup` commands are used to create new user groups in Linux-based operating systems.

Attackers may create new groups to maintain access to victim systems or escalate privileges by assigning a compromised account to a privileged group.

This rule identifies the usages of `groupadd` and `addgroup` to create new groups.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.

#### Possible investigation steps

- Investigate whether the group was created succesfully.
  - $osquery_0
- Identify if a user account was added to this group after creation.
  - $osquery_1
- Investigate whether the user is currently logged in and active.
  - $osquery_2
- Identify the user account that performed the action and whether it should perform this kind of action.
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
  - $osquery_3
- Investigate other alerts associated with the user/host during the past 48 hours.

### False positive analysis

- Group creation is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.
- Delete the created group and, in case an account was added to this group, delete the account.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"]
risk_score = 21
rule_id = "a1c2589e-0c8c-4ca8-9eb6-f83c4bbdbe8f"
setup = """## Setup

This rule requires data coming in from Filebeat.

### Filebeat Setup
Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.

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

#### Rule Specific Setup Note
- This rule requires the “Filebeat System Module” to be enabled.
- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
iam where host.os.type == "linux" and event.type == "group" and event.type == "creation" and event.outcome == "success"
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.007"
name = "Additional Local or Domain Groups"
reference = "https://attack.mitre.org/techniques/T1098/007/"

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

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

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

[rule]
description = """
Identifies the usage of Rubeus using known malicious command line arguments. Rubeus is a toolset used for a diverse set
of Kerberos Abuses and Manipulations like renew, ask, extract, and forge Kerberos Tickets.
"""
id = "0783f666-75ad-4015-9dd5-d39baec8f6b0"
license = "Elastic License v2"
name = "Potential Credential Access via Rubeus"
os_list = ["windows"]
reference = [
    "https://github.com/GhostPack/Rubeus",
    "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_hack_rubeus.yml",
]
version = "1.0.28"

query = '''
process where event.action == "start" and
  process.command_line : (
    "* asreproast *",
    "* dump /service:krbtgt*",
    "* dump /luid:*",
    "* kerberoast *",
    "* createnetonly /program:*",
    "* ptt /ticket:*",
    "* /impersonateuser:*",
    "* renew /ticket:*",
    "* asktgt /user:*",
    "* asktgs /ticket:*",
    "* harvest /interval:*",
    "* s4u /user:*",
    "* s4u /ticket:*",
    "* hash /password:*",
    "* tgtdeleg",
    "* tgtdeleg /target:*",
    "* golden /des:*",
    "* golden /rc4:*",
    "* golden /aes128:*",
    "* golden /aes256:*",
    "* changpw /ticket:*"
  )
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1558"
name = "Steal or Forge Kerberos Tickets"
reference = "https://attack.mitre.org/techniques/T1558/"


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2026/04/28"
integration = ["endpoint", "auditd_manager"]
maturity = "production"
updated_date = "2026/04/28"

[rule]
author = ["Elastic"]
description = """
Detects potential direct Kubelet API access attempts on Linux by identifying process executions whose arguments contain
URLs targeting Kubelet ports (10250/10255). Adversaries may probe or access Kubelet endpoints to enumerate pods, fetch
logs, or attempt remote execution, which can enable discovery and lateral movement in Kubernetes environments.
"""
false_positives = [
    """
    Cluster operators and node diagnostics may legitimately probe Kubelet endpoints (for example /pods or /metrics) during
    troubleshooting. Validate the initiating user, session, and whether the target node/IP is expected for the host.
    """,
]
from = "now-9m"
index = ["auditbeat-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Direct Kubelet Access via Process Arguments"
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 Direct Kubelet Access via Process Arguments

This detection flags a process on a Linux host whose arguments include a URL targeting the Kubelet API ports 10250/10255.
Attackers often use `curl`, `wget`, or scripting runtimes to access endpoints such as `/pods`, `/runningpods`,
`/metrics`, `/exec`, or `/containerLogs`. Successful access can provide node and workload visibility, and in some cases
enable actions that facilitate lateral movement within the cluster.

### Possible investigation steps

- Extract and reconstruct the full URL from `process.args` / `process.command_line`, including the hostname/IP, port, and
  path, and determine whether the request intent was discovery or execution.
- Identify the user and session that launched the process and whether it originated from an interactive shell, scheduled
  task, or automation.
- Correlate the timestamp with Kubernetes audit logs and node/Kubelet logs to confirm whether the request was
  authenticated and whether it returned success.
- If the destination is a node IP, check whether this host should be allowed to reach node Kubelet ports and whether
  other nodes were contacted in a scanning pattern.

### False positive analysis

- SRE/operator troubleshooting sessions validating Kubelet reachability or TLS/auth behavior.
- Approved health checks, debugging scripts, or node agents that query Kubelet endpoints.

### Response and remediation

- Restrict access to Kubelet ports 10250/10255 at the network layer; block pod-to-node or host-to-node traffic except for
  approved agents.
- Rotate any potentially exposed credentials (service account tokens, client certs, kubeconfigs) and assess for follow-on
  activity such as `exec/attach` and secret reads.
- Harden Kubelet configuration (disable anonymous auth, enforce webhook authn/authz) and review RBAC/admission controls.
"""
references = [
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#kubelet-api",
    "https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
    "https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/",
]
risk_score = 73
rule_id = "6aa52f86-18f1-4a5a-a0ac-e2b5db8af589"
severity = "high"
tags = [
    "Domain: Endpoint",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "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", "executed") and
(
  /* direct utility execution */
  process.name like ("curl", "wget", "python*", "perl*", "php*", "node*", "java", "ruby*", "lua*", ".*") or
  
  process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/run/*", "/home/*", "/run/user/*", "/busybox/*")
) and
process.args like ("http*:10250/*", "http*:10255/*", "wss:*:10250/*", "wss:*:10255/*")
'''

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

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

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

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

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

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

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

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

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

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

[rule]
description = """
Identifies attempts to load a recently created unsigned DLL file by an already existing signed process. This may
indicate an attempt to load a malicious module via DLL search order hijacking.
"""
id = "bf189c50-de24-471f-8e9e-01c9cfb5e05b"
license = "Elastic License v2"
name = "Potential DLL Search Order Hijacking of an Existing Program"
os_list = ["windows"]
reference = [
    "https://posts.specterops.io/automating-dll-hijack-discovery-81c4295904b0",
    "https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion",
]
version = "1.0.31"

query = '''
sequence by process.entity_id with maxspan=1m

   [process where event.action == "start" and
    process.code_signature.trusted == true and
    process.executable : ("?:\\ProgramData\\*.exe", "?:\\Users\\*.exe") and

    /* creation time is at least 30 days old */
    process.Ext.relative_file_creation_time >= 2592000 and

    /* not modified in the last 24 hours */
    process.Ext.relative_file_name_modify_time > 86400 and

    not process.code_signature.subject_name :
              ("IFS World Operations AB", "TEAMDEV LTD.", "philandro Software GmbH", "Autodesk, Inc.", "Loom, Inc.",
               "SystemServer", "Kramer Electronics LTD.", "WILLIAM HENSHAW (Affiliate)", "Oracle America, Inc.",
               "Voicebrook Inc")
    ]

   [library where
    /* creation time equal or less than 24 hrs*/
    dll.Ext.relative_file_creation_time <= 86400 and
    not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*") and
    process.executable : ("?:\\ProgramData\\*.exe", "?:\\Users\\*.exe") and
    dll.path : ("?:\\ProgramData\\*.dll", "?:\\Users\\*.dll") and

    /* DLL loaded from the process.executable current directory */
	 endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1))) and

	 not dll.hash.sha256 :
	         ("73170761d6776c0debacfbbc61b6988cb8270a20174bf5c049768a264bb8ffaf",
	          "76f19b52423774932831dcba0596989ec56213f9b217a0432fbc122f99704a2a",
	          "0da7803bdd72de8f635336057d3d672b645d4da963e5c61544a4c5a2e8289fd8",
	          "d78adc29ea8fd4f180a3eaaa5713874af42cb79509aef6509af299b895b8dd77",
	          "822dae5c53e148cad6a789fb5f6fb759fab740e2d34d07f3ddbed5cbe226a785",
	          "3871034ebb72b5700722526ce15a67030a9d42ec9329dd878d979ed680dc9424",
	          "8740c64aaeba10108c4384eb6723407b8e9bed4f57c79c0f279ab9f28cb6287e",
	          "db00672e1b66559684e66c4c92aa39230ee75234a2580b0730c39dc171db632a")]
'''

min_endpoint_version = "8.10.0"
reputation = true
[[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 = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"
[[threat.technique.subtechnique]]
id = "T1574.001"
name = "DLL"
reference = "https://attack.mitre.org/techniques/T1574/001/"



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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2021/10/14"
integration = ["windows"]
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
Identifies suspicious access to an LSASS handle via PssCaptureSnapShot where two successive process accesses are
performed by the same process and target two different instances of LSASS. This may indicate an attempt to evade
detection and dump LSASS memory for credential access.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential LSASS Memory Dump via PssCaptureSnapShot"
references = [
    "https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/",
    "https://twitter.com/sbousseaden/status/1280619931516747777?lang=en",
]
risk_score = 73
rule_id = "0f93cb9a-1931-48c2-8cd0-f173fd3e5283"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
event.category:process and host.os.type:windows and event.code:10 and
 winlog.event_data.TargetImage:("C:\\Windows\\system32\\lsass.exe" or
                                 "c:\\Windows\\system32\\lsass.exe" or
                                 "c:\\Windows\\System32\\lsass.exe")
'''

note = """## Triage and analysis

### Investigating Potential LSASS Memory Dump via PssCaptureSnapShot

#### Possible investigation steps

- What do the threshold summary and recovered members prove about the LSASS access pattern?
  - Why: grouped threshold alerts require member recovery before the count proves a snapshot or repeated-access pattern.
  - Focus: `process.entity_id`, `kibana.alert.threshold_result.count`, and Sysmon Event 10 members for `winlog.event_data.TargetProcessId`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`. $investigate_0
  - Implication: escalate when one process entity touched two distinct LSASS target PIDs and access or call-trace evidence fits snapshot or dump collection; lower concern only when members form one recognized debugger, EDR, or IR memory-acquisition pattern. If members cannot be recovered, the grouped alert stays unresolved, not benign.

- Which caller and stack evidence identify the snapshot or dump path?
  - Focus: caller path, access mask, and call trace from recovered members on the same `host.id`.
  - Implication: escalate when the caller is user-writable, renamed, unrelated to endpoint security, or the stack shows PssCaptureSnapshot, PssNtCaptureSnapshot, dbghelp, or MiniDumpWriteDump-style dumping; lower concern when caller, access mask, and stack match a recognized EDR, debugger, or forensic collector.

- Does the user-host context fit deliberate LSASS memory acquisition?
  - Focus: `host.id`, `user.id`, `user.name`, and recovered caller.
  - Implication: escalate when activity runs under a normal user, service account, workstation, domain controller, or jump host with no matching IR or security-collection purpose; lower concern only when the same host, user, and caller map to one recognized memory-acquisition workflow.

- If Windows Security logs are available, did authentication or source evidence show credential use after the LSASS access?
  - Why: PssCaptureSnapshot-based LSASS access commonly precedes credential dumping, so post-access identity use changes urgency.
  - Focus: `host.id` and `user.id`; if Windows Security logs exist for this host/window, recover authentication records before interpretation and use `source.*` only from those records, especially `event.code`, `winlog.event_data.TargetLogonId`, and `source.ip`.
  - Implication: escalate when the same user or host shows new 4624 logons, 4648 explicit-credential use, rare `source.ip`, or remote access after LSASS events; use `winlog.event_data.TargetLogonId` to group logon records, not claim process-session continuity. Missing authentication telemetry is unresolved, not benign.

- If local evidence remains suspicious or unresolved, do related alerts change scope?
  - Focus: credential-access, archive, lateral-movement, or clone-related alerts for the same `process.entity_id`, `user.id`, or `host.id`. $investigate_1 $investigate_2 $investigate_3
  - Implication: broaden response when the same process entity also shows dumping, archive staging, suspicious authentication, lateral movement, or clone-related alerts; keep scope local when related alerts are absent, but do not use alert absence to clear recovered LSASS access evidence.

- Escalate when member pattern, caller or stack evidence, user-host context, authentication/source evidence, or related-alert scope supports unauthorized LSASS access or credential use; close only when member events and host/user context bind the alert to one recognized debugger, EDR, forensic, IR, or lab workflow with no contradictory evidence; preserve evidence and escalate when recovery is incomplete or findings conflict.

### False positive analysis

- Authorized debugger, EDR, forensic, IR memory-acquisition, or lab validation tooling can trigger this rule. Confirm from telemetry first: member-event pattern, caller or stack, `host.id`, and `user.id` must converge on the same workflow. Use case records or tool inventory only to corroborate that telemetry-bound workflow. If members are unavailable or any anchor contradicts it, do not close as benign.
- Before creating an exception, validate that the same stable caller, recovered target-PID/access/call-trace pattern, `host.id`, and `user.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on `process.entity_id`, `kibana.alert.threshold_result.count`, or LSASS targeting alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and document the alert summary, grouped `process.entity_id`, recovered member-event pattern, caller or stack evidence, `host.id`, `user.id`, and the corroborating case, tool, or lab record. Create an exception only for the recurring workflow pattern.
- If suspicious but unconfirmed, preserve the alert, Timeline member records, target-PID/access/call-trace evidence, recovered caller, `process.entity_id`, `host.id`, `user.id`, and any recovered authentication or source records before containment.
- If suspicious but unconfirmed, apply reversible containment first, such as heightened monitoring or temporary network isolation for the affected `host.id`; weigh host criticality before isolating domain controllers, jump hosts, or production servers.
- If confirmed malicious, isolate the affected host when recovered member events and caller or stack evidence confirm unauthorized LSASS access. Disable or reset accounts only when recovered authentication or source evidence indicates credential use or likely exposure.
- If confirmed malicious, collect the suspicious binary, dump outputs, scripts, archives, and memory-acquisition tooling identified during investigation before terminating processes or deleting files.
- If confirmed malicious, block confirmed remote sources or transfer paths identified during investigation, then eradicate the collected dump tooling and remediate the execution or privilege path that enabled LSASS access.
- Post-incident hardening: restrict LSASS snapshot and dump tooling to controlled security workflows, enable LSASS protection controls where compatible, retain Sysmon Event 10 and Windows Security logs, and document PssCaptureSnapshot or clone-based variants surfaced during triage.
"""

setup = """## Setup

This rule requires Sysmon telemetry to be enabled and ingested.

Setup instructions: https://ela.st/sysmon-event-10-setup
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "host.id",
    "user.name",
    "user.id",
    "user.domain",
    "process.entity_id",
    "kibana.alert.threshold_result.count",
]

[transform]

[[transform.investigate]]
label = "Sysmon process access events for the grouped process entity"
description = ""
providers = [
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "C:\\Windows\\system32\\lsass.exe", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "c:\\Windows\\system32\\lsass.exe", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "10", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.TargetImage", queryType = "phrase", value = "C:\\Windows\\System32\\lsass.exe", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the grouped process entity"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"
[[rule.threat.technique.subtechnique]]
id = "T1003.001"
name = "LSASS Memory"
reference = "https://attack.mitre.org/techniques/T1003/001/"

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

[rule.threshold]
field = ["process.entity_id"]
value = 2

[[rule.threshold.cardinality]]
field = "winlog.event_data.TargetProcessId"
value = 2

[metadata]
creation_date = "2024/05/02"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a file with a name similar to ransomware note files by the Windows System process (PID 4). This may indicate a remote ransomware attack via the SMB protocol.
"""
from = "now-5m"
index = ["logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Ransomware Note File Dropped via SMB"
risk_score = 73
rule_id = "02bab13d-fb14-4d7c-b6fe-4a28874d37c5"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by host.id, file.name with maxspan=1m
 [file where host.os.type == "windows" and event.action == "creation" and
  process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and file.extension : ("hta", "txt", "readme", "htm*") and
   /* ransom file name keywords */
    file.name : ("*read*me*", "*lock*", "*@*", "*RECOVER*", "*decrypt*", "*restore*file*", "*FILES_BACK*", "*how*to*") and 
    (file.path : ("C:\\Users\\*", "C:\\aaAntiRansom*") or (file.path : "C:\\*" and not file.path : "C:\\*\\*"))] with runs=3
'''

note = """## Triage and analysis

### Investigating Potential Ransomware Note File Dropped via SMB

#### Possible investigation steps

- What do the sequence member events show about the accepted SMB session and note-file burst?
  - Why: this sequence can omit stage-specific values from the combined alert; disposition depends on recovered source events.
  - Focus: Timeline member events: network-stage `source.ip`, then file-stage `user.id`, `file.path`, `file.name`, and `file.extension`.
  - Implication: escalate when one remote source is followed within one second by repeated note-like creations under user-profile paths; lower concern only when recovered source, identity, names, and paths form one bounded, neutral file-copy pattern for validation.
  - Hint: `process.pid` value "4" is target-side kernel SMB I/O, not the remote executable; use `user.name` only as a readable label for the file-stage identity.

- Do recovered `source.ip` and writing identity match a stable SMB pattern for this host?
  - Why: the target-side kernel process does not identify the remote operator; source and SMB identity carry attribution value.
  - Focus: surrounding and historical SMB "connection_accepted" events for `host.id` and recovered `source.ip`, plus file-stage `user.id` and `user.name`. $investigate_0
  - Implication: escalate when the source is new for this host, appears only in a short burst, or pairs with an unusual SMB identity; lower concern when the same source and identity recur as one bounded backup, migration, or maintenance pattern. Missing SMB history is unresolved, not benign.

- Do created files indicate broad ransom-note staging rather than routine instructions?
  - Focus: recovered `file.path`, `file.name`, `file.extension`, `file.size`, and `file.Ext.header_bytes`; repeated names across multiple "C:\\Users\\" profile paths.
  - Implication: escalate when identical or near-identical note files land in multiple profiles, use ".hta" or HTML variants, or are small text/HTML artifacts meant for user visibility; lower concern when files stay in one bounded application or migration folder and match stable instruction-file naming for the same source.

- Does same-window SMB file activity show broader destructive or staging behavior?
  - Why: note drops often accompany remote rename, delete, or other drop activity that this rule does not capture directly.
  - Focus: file events in the same SMB window: `event.action`, `file.path`, `file.extension`, `file.Ext.original.path`, and `file.Ext.original.extension`. $investigate_1
  - Implication: escalate when the same window shows mass rename, delete, extension-change, or extra drop behavior in user or shared paths; lower concern when activity stays limited to the small note set with no follow-on churn.

- If local SMB evidence remains suspicious or unresolved, does impact context stay local or show source fan-out?
  - Why: ransomware may place notes apart from encryption or recovery inhibition, and SMB ransomware can fan out with valid accounts or admin shares.
  - Focus: same-host impact alerts over 48 hours, then other SMB events keyed by recovered `source.ip` with matching note-like `file.name`, `file.path`, or impact `event.action`. $investigate_2
  - Implication: escalate when the host shows rename, shadow-copy, backup-tamper, or destructive alerts, or when one source fans out to multiple hosts with matching note-drop or impact signals; keep the case local only when the source is confined to one bounded file-copy pattern. Missing cross-host SMB telemetry is unresolved, not benign.
  - Hint: start with `source.ip` plus `destination.port` 445, then join returned hosts to note-like file creations by time.

- What disposition do the recovered SMB source, identity, note pattern, file churn, and scope support?
  - Escalate for remote note staging plus unexpected SMB identity, destructive file activity, recovery inhibition, or multi-host spread; close only for one stable bounded file-copy pattern with neutral names and no contradictory impact evidence; if purpose still depends on records, preserve artifacts until telemetry resolves it.

### False positive analysis

- Bulk backup, migration, or endpoint-management jobs can place repeated text or HTML instruction files over SMB. Confirm the same recovered `source.ip`, `user.id`, `user.name`, neutral `file.name` family, and bounded `file.path` recurs for this `host.id` without rename, delete, shadow-copy, backup-tamper, or cross-host note-drop spread. Change records can corroborate, not replace, telemetry alignment.
- Case-driven incident response, legal-hold, or notification activity can write readme-style files remotely. Confirm recovered `source.ip`, `user.id`, `user.name`, `file.path`, and `file.extension` stay bounded to intended case or communication folders, use neutral notice/readme naming rather than decrypt, recover, lock, or payment language, and do not coincide with broader rename or delete activity from `process.pid` value "4". If case records are unavailable, require recurrence of the same source, identity, and path family without spread.
- Before creating an exception, validate recurrence across prior alerts from this rule. Build the exception from the minimum pattern: recovered `source.ip`, `user.id` or `user.name`, representative `file.name`, bounded `file.path` family, and affected host cohort. Avoid exceptions on `file.name`, `host.id`, or `process.pid` alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and record the confirmed `source.ip`, `user.id` or `user.name`, representative `file.name`, and bounded `file.path` pattern. Create an exception only after that same pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert, Timeline member-event export, copies or hashes of representative note files, recovered source and user identifiers, surrounding file-action evidence, and same-host alert identifiers before containment. Apply reversible containment first, such as temporarily blocking SMB from the recovered source to the target or restricting the recovered user for SMB access. Use host isolation only if note drops continue, spread to additional hosts, or the target role can tolerate interruption.
- If confirmed malicious, isolate the recovered source host when it is managed and the source, SMB identity, note-file pattern, and impact evidence confirm active ransomware behavior. If direct endpoint response is unavailable on the source, hand off the preserved artifacts to the team that can block the SMB path or contain the source system. Before deleting files, terminating processes, or restoring data, export the member events, related impact alerts, note files, and affected host list.
- After confirmed malicious scoping identifies affected hosts and accounts, rotate or reset the SMB credentials that were used or exposed, review other hosts touched by the same recovered `source.ip`, then remove dropped notes and restore affected data from known-good backups.
- Post-incident hardening: restrict unnecessary SMB administrative access, protect backup and shadow-copy workflows, retain endpoint network and file telemetry needed to reconstruct remote file activity, and record the confirmed benign workflow or malicious source-and-path pattern for future cases.
"""

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "host.name",
    "process.pid",
]

[transform]

[[transform.investigate]]
label = "SMB connection events on the host"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
    { excluded = false, field = "event.action", queryType = "phrase", value = "connection_accepted", valueType = "string" },
    { excluded = false, field = "destination.port", queryType = "phrase", value = "445", valueType = "string" },
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "File events for SMB server writes on this host"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

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

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

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

[[rule.threat.technique]]
id = "T1490"
name = "Inhibit System Recovery"
reference = "https://attack.mitre.org/techniques/T1490/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1021.002"
name = "SMB/Windows Admin Shares"
reference = "https://attack.mitre.org/techniques/T1021/002/"

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

[rule]
description = """
Identifies the execution of a process in an hidden desktop within the default interactive window station. This may
indicate an attempt to conceal malicious activity from the plain sight of users.
"""
id = "b90e3fdf-b525-4e27-914a-920f1afd1b4e"
license = "Elastic License v2"
name = "Process Started in a Hidden Desktop"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1564/003/",
    "https://www.elastic.co/security-labs/elastic-security-labs-discovers-lobshot-malware",
]
version = "1.0.5"

query = '''
process where event.type == "start" and process.Ext.desktop_name like "WinSta0\\*" and
not process.Ext.desktop_name : ("WinSta0\\Winlogon", "WinSta0\\Screen-saver", "WinSta0\\ScreenConnectDesktop", "WinSta0\\InstallerDesktop") and 
not (process.parent.executable : "C:\\Program Files (x86)\\SnapComms\\App\\*\\SnapClientHelper.exe" and 
     process.Ext.desktop_name : ("WinSta0\\DummyDesktopForInstantResume", "WinSta0\\ScreenConnectDesktop", "WinSta0\\Disconnect", "WinSta0\\sbox_alternate_desktop_local_winstation_*"))
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[threat.technique.subtechnique]]
id = "T1564.003"
name = "Hidden Window"
reference = "https://attack.mitre.org/techniques/T1564/003/"



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

[internal]
min_endpoint_version = "9.1.0"