Elastic rules: 36

[metadata]
creation_date = "2020/02/18"
integration = ["network_traffic", "panw", "fortinet_fortigate", "pfsense", "sonicwall_firewall", "suricata"]
maturity = "production"
updated_date = "2026/09/03"

[rule]
author = ["Elastic"]
description = """
This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system
administrators to remotely control older or embedded systems using the command line shell. It should almost never be
directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or
backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the
traffic.
"""
false_positives = [
    """
    IoT (Internet of Things) devices and networks may use telnet and can be excluded if desired. Some business
    work-flows may use Telnet for administration of older devices. These often have a predictable behavior. Telnet
    activity involving an unusual source or destination may be more suspicious. Telnet activity involving a production
    server that has no known associated Telnet work-flow or business requirement is often suspicious.
    """,
]
from = "now-9m"
index = [
    "packetbeat-*",
    "auditbeat-*",
    "filebeat-*",
    "logs-network_traffic.*",
    "logs-panw.panos*",
    "logs-fortinet_fortigate.log-*",
    "logs-pfsense.log-*",
    "logs-sonicwall_firewall.log-*",
    "logs-suricata.*",
]
language = "kuery"
license = "Elastic License v2"
name = "Accepted Default Telnet Port Connection"
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 Accepted Default Telnet Port Connection

Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts.

### Possible investigation steps

- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization.
- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes.
- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack.
- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access.
- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers.
- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access.
- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts.

### False positive analysis

- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems.
- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts.
- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise.
- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities.
- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred.
- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges.
- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet.
- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures."""
risk_score = 47
rule_id = "34fde489-94b0-4500-a76f-b8a157cf9269"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Tactic: Lateral Movement",
    "Tactic: Initial Access",
    "Data Source: Fortinet",
    "Data Source: PAN-OS",
    "Data Source: pfSense",
    "Data Source: SonicWall",
    "Data Source: Suricata",
    "Resources: Investigation Guide",
]
timeline_id = "300afc76-072d-4261-864d-4149714bf3f1"
timeline_title = "Comprehensive Network Timeline"
timestamp_override = "event.ingested"
type = "query"

query = '''
(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow
        or panw.panos or pfsense.log or sonicwall_firewall.log or suricata.eve)
    or event.category:(network or network_traffic))
    and event.type:(connection and not (denied or end))
    and not event.action:(Reject or client-rst or connection-denied or
        connection-end or denied or deny or flow_denied or flow_dropped or
        flow_terminated or network_flow or server-rst or timeout)
    and not (event.action:netflow_flow and not network.packets > 1)
    and not network.application:(stretchoid-scanning or traceroute)
    and destination.port:23
    and (network.protocol:(telnet or not *) or data_stream.dataset:fortinet_fortigate.log)
'''


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


[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "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 = "T1133"
name = "External Remote Services"
reference = "https://attack.mitre.org/techniques/T1133/"

[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"


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

[rule.alert_suppression]
group_by = ["source.ip", "destination.ip"]
missing_fields_strategy = "doNotSuppress"

[rule.alert_suppression.duration]
unit = "h"
value = 1

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

[rule]
author = ["Elastic"]
description = """
Detects the creation of an Amazon EKS access entry followed by its deletion by the same
identity within a short time window. EKS access entries define Kubernetes RBAC-level
permissions for IAM principals in an EKS cluster. An adversary with EKS administrative
access may temporarily grant themselves cluster access, use those permissions to create
Kubernetes RBAC resources (ClusterRoleBindings, ServiceAccounts with privileged roles),
and then delete the access entry to hide the evidence of the initial grant while retaining
access through the Kubernetes-level backdoor.
"""
false_positives = [
    """
    Automated infrastructure tests that create and immediately tear down EKS access entries
    as part of CI/CD validation may trigger this rule. Validate that the sequence corresponds
    to a documented test pipeline.
    """,
]
from = "now-15m"
index = ["logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS EKS Access Entry Created Then Deleted by Same Identity"
note = """## Triage and analysis

### Investigating AWS EKS Access Entry Created Then Deleted by Same Identity

EKS access entries (introduced in EKS API mode) map IAM principals to Kubernetes access policies or allow associating Kubernetes groups to IAM principals. An adversary who obtains `eks:CreateAccessEntry` and `eks:DeleteAccessEntry` permissions can:

1. Create an access entry for their own IAM principal with cluster-admin level access.
2. Use that access to create persistent Kubernetes RBAC resources (ClusterRoleBindings, privileged ServiceAccounts, rogue DaemonSets).
3. Delete the access entry, removing the CloudTrail evidence of the initial grant while retaining Kubernetes-level access.

This sequence is analogous to adding a backdoor user, using it, then deleting it to cover tracks. The deletion within a short window of creation is the key behavioral indicator.

### Possible investigation steps

- Identify the calling identity from `aws.cloudtrail.user_identity.arn` and the targeted cluster from `aws.cloudtrail.request_parameters`.
- Review Kubernetes audit logs for the affected cluster in the time window between the `CreateAccessEntry` and `DeleteAccessEntry` events. Look for `create` verbs on ClusterRoleBindings, RoleBindings, ServiceAccounts, or DaemonSets.
- Check the cluster's current RBAC configuration for persistent backdoor resources.
- Determine whether the identity had a legitimate reason to create an access entry for the targeted cluster.

### False positive analysis

- Infrastructure-as-code and CI/CD pipelines that create and tear down EKS access entries as part of cluster validation — Terraform or eksctl apply/destroy cycles, ephemeral test clusters — will produce this exact sequence. Correlate with the pipeline identity and change records before triaging further.
- Short-lived break-glass or just-in-time administrative access that is granted and revoked by the same operator within minutes is legitimate; confirm against access-request tickets or change approvals.
- Migration tooling that switches clusters between authentication modes may churn access entries in bulk under a single automation role.
- The sequence correlates on the calling identity only, so confirm the `CreateAccessEntry` and `DeleteAccessEntry` events reference the same cluster and principal ARN in the request parameters before treating them as one grant-and-revoke cycle.
- Scope any exceptions by the calling ARN or automation role rather than excluding the behavior globally.

### Response and remediation

- Audit all Kubernetes RBAC resources for unauthorized ClusterRoleBindings or privileged ServiceAccounts created in the suspect window.
- Rotate credentials for the calling identity.
- Apply IAM policies restricting `eks:CreateAccessEntry` and `eks:DeleteAccessEntry` to designated EKS administrative roles.
"""
references = [
    "https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateAccessEntry.html",
    "https://docs.aws.amazon.com/eks/latest/APIReference/API_DeleteAccessEntry.html",
    "https://www.wiz.io/blog/new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features",
    "https://securitylabs.datadoghq.com/articles/eks-cluster-access-management-deep-dive/",
]
risk_score = 47
rule_id = "2b60fb61-d0c7-405e-9f33-a66d8729628d"
setup = "The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. EKS management events are logged by default."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Platform: AWS",
    "Platform: Kubernetes",
    "Data Source: AWS CloudTrail",
    "Service: AWS EKS",
    "Rule Type: Event Correlation (EQL)",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by aws.cloudtrail.user_identity.arn with maxspan=5m
  [any where data_stream.dataset == "aws.cloudtrail" and event.provider == "eks.amazonaws.com" and event.action == "CreateAccessEntry" and event.outcome == "success" and aws.cloudtrail.user_identity.arn != null]
  [any where data_stream.dataset == "aws.cloudtrail" and event.provider == "eks.amazonaws.com" and event.action == "DeleteAccessEntry" and event.outcome == "success" and aws.cloudtrail.user_identity.arn != null]
'''

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

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

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

[rule]
description = """
Identifies the execution of a binary via the Pester PowerShell module. Adversaries may bypass process and
signature-based defenses by proxying execution of malicious content with signed, or otherwise trusted, binaries.
"""
id = "bbc7e649-dc8e-401f-a6e4-d2d668aef4ac"
license = "Elastic License v2"
name = "Binary Proxy Execution via Pester"
os_list = ["windows"]
reference = ["https://lolbas-project.github.io/lolbas/Scripts/pester/"]
version = "1.0.5"

query = '''
process where event.action == "start" and
(
 (process.parent.name : "powershell.exe" and
  process.parent.command_line : "powershell*WindowsPowerShell\\Modules*\\Pester.psm1*;*" and
 not process.executable : ("?:\\Windows\\Microsoft.NET\\Framework*\\csc.exe", "?:\\Windows\\Sys*\\conhost.exe")) or

 (process.name : "powershell.exe" and process.command_line : "*\\Pester.psm1*;*http*")
)
'''

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 = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Detects osascript spawning curl followed by creation of hidden binary files with Mach-O headers within 30 seconds. This
indicates malicious AppleScript workflows downloading and staging executable payloads.
"""
id = "3c3aaa63-d213-486f-b157-e4b1a45d9913"
license = "Elastic License v2"
name = "Curl Hidden Binary Modification via Osascript"
os_list = ["macos"]
version = "1.0.3"

query = '''
sequence by process.entity_id with maxspan=30s
[process where event.type == "start" and event.action == "exec" and process.name == "curl" and process.parent.name == "osascript"]
[file where event.action == "modification" and file.Ext.header_bytes like~ ("cffaedfe*", "cafebabe*") and file.name like~ ".*"]
'''

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

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



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


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

[internal]
min_endpoint_version = "8.16.0"

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

[rule]
author = ["Elastic"]
description = """
Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC
is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This
method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor
authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when
user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or
unusual activity.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID OAuth ROPC Grant Login Detected"
note = """## Triage and analysis

### Investigating Entra ID OAuth ROPC Grant Login Detected

This rule detects unusual login attempts using the Resource Owner Password Credentials (ROPC) flow in Microsoft Entra ID. ROPC allows applications to obtain tokens by directly providing user credentials, bypassing multi-factor authentication (MFA). This method is less secure and can be exploited by adversaries to gain access to user accounts, especially during enumeration or password spraying.

### Possible investigation steps
- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the ROPC login attempt. Check if this user is expected to use ROPC or if it is an unusual account for this type of authentication.
- Analyze the `azure.signinlogs.properties.authentication_protocol` field to confirm that the authentication protocol is indeed ROPC. This protocol is typically used in legacy applications or scripts that do not support modern authentication methods.
- Check the `user_agent.original` field to identify potentially abused open-source tools or scripts that may be using ROPC for unauthorized access such as TeamFiltration or other enumeration tools.
- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to determine which application is attempting the ROPC login. FOCI applications are commonly used for enumeration and password spraying.
- Investigate the `azure.signinlogs.properties.client_ip` to identify the source of the login attempt. Check if the IP address is associated with known malicious activity or if it is a legitimate user location.
- Review the `azure.signinlogs.properties.authentication_details` field for any additional context on the authentication attempt, such as whether it was successful or if there were any errors.
- Examine the `azure.signinlogs.properties.applied_conditional_access_policies` to see if any conditional access policies were applied during the login attempt. If no policies were applied, this could indicate a potential bypass of security controls.
- Identify the resource requested access to by checking the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id`. This can help determine if the login attempt was targeting sensitive resources or applications such as Exchange Online, SharePoint, or Teams.

### False positive analysis
- Legitimate applications or scripts that use ROPC for automation purposes may trigger this rule.
- Some legacy applications may still rely on ROPC for authentication, especially in environments where modern authentication methods are not fully implemented.
- Internal security tools or scripts that perform automated tasks using ROPC may generate false positives if they are not properly whitelisted or excluded from the rule.

### Response and remediation
- If the ROPC login attempt is confirmed to be malicious, immediately block the user account and reset the password to prevent further unauthorized access.
- Consider enforcing multi-factor authentication (MFA) for the user account to enhance security and prevent future unauthorized access attempts.
- Review and update conditional access policies to restrict the use of ROPC for sensitive accounts or applications, ensuring that MFA is required for all login attempts.
- Investigate the source of the ROPC login attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity.
- Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified.
- Educate users about the risks associated with ROPC and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible.
"""
references = [
    "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign",
    "https://dirkjanm.io/assets/raw/Finding%20Entra%20ID%20CA%20Bypasses%20-%20the%20structured%20way.pdf",
    "https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc",
    "https://redcanary.com/blog/threat-detection/bav2ropc/",
    "https://www.huntress.com/blog/lshiy-password-spray-attack"
]
risk_score = 47
rule_id = "8d696bd0-5756-11f0-8e3b-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-In Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs" and
    (
        azure.signinlogs.properties.authentication_protocol: "ropc" or
        user_agent.original: "BAV2ROPC"
    ) and
    azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and
    azure.signinlogs.properties.user_type: "Member" 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 = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of
service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client
fingerprint; a new user agent or source for that service account could indicate a stolen token used outside
the workload (for example curl, a custom script, or kubectl from an unexpected host).
"""
false_positives = [
    """
    Controller upgrades, sidecar replacements, or client library version bumps change user agents and can produce
    a first-seen alert for known service accounts. Confirm the new client is expected before treating as compromise.
    """,
    """
    Newly deployed operators or workloads that change egress IP will alert once while the history window learns
    their client fingerprint.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Unusual Service Account Secret Access via New User Agent"
note = """## Triage and analysis

### Investigating GKE Unusual Service Account Secret Access via New User Agent

This new-terms rule alerts when a `system:serviceaccount:*` identity successfully calls `secrets.get` with a
`client.user.email` + `user_agent.original` + `source.ip` combination not seen in the history window.

### Possible investigation steps

- Confirm whether the service account normally uses this user agent or whether the client looks like an interactive
  or scripting tool (`curl`, `python`, `kubectl`, generic HTTP libraries).
- Review `gcp.audit.resource_name` and namespace scope against the workload's expected secret mounts and RBAC.
- Pivot on the same `client.user.email` or `source.ip` for secret list/get bursts, exec, or RBAC changes.
- Compare to recent deployments or operator upgrades that would legitimately introduce a new client string.

### False positive analysis

- Operator or library upgrades that change the user-agent string for an otherwise unchanged service account.
- First enablement of the rule will surface baseline controller clients until the history window fills.

### Response and remediation

- If malicious, revoke the service-account token, rotate exposed secrets, isolate the originating workload or
  host, and tighten RBAC so the identity can only read required secrets.
"""
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/authentication/#service-account-tokens",
]
risk_score = 21
rule_id = "5dd3358c-4664-4b4c-aca1-b3fa4a4c83c9"
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and
event.action:"io.k8s.core.v1.secrets.get" and
client.user.email:system\:serviceaccount\:* and
user_agent.original:(* and not *kubernetes/$Format*) and
source.ip:(* and not (127.0.0.1 or "::1"))
'''

[rule.new_terms]
field = "new_terms_fields"
value = ["client.user.email", "user_agent.original", "source.ip"]

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

[[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.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "gcp.audit.resource_name",
    "data_stream.namespace",
]

[metadata]
creation_date = "2022/07/27"
integration = ["endpoint", "auditd_manager", "crowdstrike"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = "This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period.\n"
from = "now-9m"
index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*"]
language = "kuery"
license = "Elastic License v2"
name = "High Number of Process Terminations"
note = """## Triage and analysis

### Investigating High Number of Process Terminations

Attackers can kill processes for a variety of purposes. For example, they can kill process associated with business applications and databases to release the lock on files used by these applications so they may be encrypted,or stop security and backup solutions, etc.

This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period.

#### Possible investigation steps

- Examine the entry point to the host and user in action via the Analyse View.
  - Identify the session entry leader and session user.
- Examine the contents of session leading to the process termination(s) via the Session View.
  - Examine the command execution pattern in the session, which may lead to suspricous activities.
- Examine the process killed during the malicious execution
  - Identify imment threat to the system from the process killed.
  - Take necessary incident response actions to respawn necessary process.

### False positive analysis

- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity.
- 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.
- Reimage the host operating system or restore it to the operational state.
- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through 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).
"""
risk_score = 47
rule_id = "67f8443a-4ff3-4a70-916d-3cfa3ae9f02b"
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: Impact",
  "Resources: Investigation Guide",
  "Data Source: Elastic Endgame",
  "Data Source: Elastic Defend",
  "Data Source: Auditd Manager",
  "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "threshold"
query = '''
event.category:process and host.os.type:linux and event.type:start and (
  (process.name:"pkill" and process.args:"-f") or
  (process.name:kill and process.args:"-9") or
  (process.name:killall)
)
'''

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

[[rule.threat.technique]]
id = "T1489"
name = "Service Stop"
reference = "https://attack.mitre.org/techniques/T1489/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1562.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/"
[rule.threshold]
field = ["host.id", "process.executable", "user.name"]
value = 15

[metadata]
creation_date = "2020/04/16"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a simple reverse shell to a fully
interactive tty after obtaining initial access to a host.
"""
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 = "Interactive Terminal Spawned via Perl"
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 Interactive Terminal Spawned via Perl

Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse.

### Possible investigation steps

- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as "exec \\"/bin/sh\\";", "exec \\"/bin/dash\\";", or "exec \\"/bin/bash\\";".
- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access.
- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise.
- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers.
- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity.
- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign.

### False positive analysis

- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments.
- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule.
- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories.
- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity.
- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity.
- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack.
- Restore the affected system from a known good backup to ensure any malicious changes are removed.
- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""
risk_score = 73
rule_id = "05e5a668-7b51-4a67-93ab-e9af405c9ef3"
setup = """## Setup

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

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

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

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

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

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
"""
severity = "high"
tags = [
  "Domain: Endpoint",
  "OS: Linux",
  "Use Case: Threat Detection",
  "Tactic: Execution",
  "Data Source: Elastic Defend",
  "Data Source: Elastic Endgame",
  "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 == "perl" and process.args == "exec" and
process.args in (
  "\"sh\";", "\"dash\";", "\"bash\";", "\"zsh\";",
  "\"/bin/sh\";", "\"/bin/dash\";", "\"/bin/bash\";", "\"/bin/zsh\";",
  "\"/usr/bin/sh\";", "\"/usr/bin/dash\";", "\"/usr/bin/bash\";", "\"/usr/bin/zsh\";",
  "\"/usr/local/bin/sh\";", "\"/usr/local/bin/dash\";", "\"/usr/local/bin/bash\";", "\"/usr/local/bin/zsh\";"
)
'''

[[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 enumerate the state of keyboard keys and the call is coming from a suspicious call stack.
Adversaries may log user keystrokes to intercept credentials or other information from the user as the user types them.
"""
id = "6ef43c9a-25af-449c-8416-20349780a146"
license = "Elastic License v2"
name = "Keystrokes Input Capture from Suspicious CallStack"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1056/001/",
    "https://www.elastic.co/security-labs/protecting-your-devices-from-information-theft-keylogger-protection",
]
version = "1.0.22"

query = '''
api where
 process.thread.Ext.call_stack_final_user_module.hash.sha256 != null and
 (
  process.Ext.api.name == "GetAsyncKeyState" or
  (process.Ext.api.name == "RegisterRawInputDevices" and
   process.Ext.api.parameters.usage == "KEYBOARD" and process.Ext.api.parameters.flags like "*INPUTSINK*") or
  (process.Ext.api.name == "SetWindowsHookEx" and process.Ext.api.parameters.hook_type == "WH_KEYBOARD_LL" and
   process.Ext.api.parameters.hook_module == "null")
  ) and

  process.thread.Ext.call_stack_final_user_module.name != null and process.executable != null and 
  process.thread.Ext.call_stack_summary :
           ("win32u.dll|Unknown|*",
            "*win32u.dll|user32.dll|Unknown|*",
            "win32u.dll|Unbacked|*",
            "*win32u.dll|user32.dll|Unbacked|*",
            "win32u.dll|user32.dll|Unbacked",
            "*|python*.dll*",
            "Unknown",
            "Unbacked") and 
  not (process.thread.Ext.call_stack_summary : "*clr.dll*" and process.thread.Ext.call_stack_final_user_module.name : "Unbacked") and 
  not process.thread.Ext.call_stack_final_user_module.path : 
                              ("?:\\Program Files\\*",
                               "?:\\Program Files (x86)\\*",
                               "?:\\Windows\\*", 
                               "\\Program Files\\*",
                               "\\Program Files (x86)\\*",
                               "\\Windows\\*") and 
  not process.thread.Ext.call_stack_final_user_module.name : ("Unknown", "Undetermined") and
  not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true and
                   $entry.subject_name in (".NET", "Microsoft Corporation", "Microsoft Windows", "Sophos Limited", "EOG Resources, Inc.")) and
  not process.executable : 
                   ("?:\\Program Files (x86)\\Image Express\\ixDrill\\ixDrill.exe", 
                    "?:\\Windows\\System32\\DellTPad\\ApMsgFwd.exe", 
                    "?:\\Windows\\System32\\FMAPP.exe",
                    "?:\\Program Files (x86)\\Power Automate Desktop\\PAD.Console.Host.exe",
                    "?:\\Program Files (x86)\\SuperPuTTY\\SuperPutty.exe",
                    "?:\\Program Files\\SuperPuTTY*\\SuperPutty.exe",
                    "C:\\Program Files\\Four Winds Interactive\\Content Player\\Signage.exe",
                    "C:\\Program Files\\WindowsApps\\Microsoft.PowerAutomateDesktop_*\\dotnet\\PAD.Console.Host.exe",
                    "C:\\Program Files (x86)\\Hyland\\OCR for AnyDoc\\OCRforAnyDoc.exe",
                    "C:\\Program Files\\Dell\\Dell Display and Peripheral Manager\\Plugins\\DDPM.Subagent.User\\DDPM.Subagent.User.exe") and
  not (process.code_signature.trusted == true and
       process.code_signature.subject_name in ("Grammarly, Inc.", "HP Inc.", "Proofpoint, Inc.", "ETH Zürich", "Learnpulse",
        "Qisda Corporation", "ONELAUNCH TECHNOLOGIES INC.", "Laserfiche", "ARTICULATE GLOBAL, LLC",
        "Connectwise, LLC", "Carl Zeiss Microscopy GmbH", "Articulate Global, Inc.", "JItbit LP", "Dell Inc.",
        "Roblox Corporation", "Colony Labs, Inc.", "Devolutions Inc", "Wispr AI, Inc.", "Adobe Inc.", "Activision Publishing Inc")) and
  not process.thread.Ext.call_stack_final_user_module.hash.sha256 in ("120446e2c7729a7ae15e08bcc5cdb95c35151aa0f7e803e53dc7e92a1579783d",
                                                                      "46327ac3d7979cfc254ba0e76cd17b3a72128034f3618e8247bdcc9f6d84aea2",
                                                                      "557ae751c11dfb2a9a976c3312f469a4f0b776c1088aeeefdee99b5327aa2fed",
                                                                      "a57b437a7fe4eb285830564839f37a6704fa1f9dfe4a9a631cd28db43a83320c",
                                                                      "604d2cddc32d62da41c9553f35eb9aac442574db219cb63caae25205bbff88f8")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1056"
name = "Input Capture"
reference = "https://attack.mitre.org/techniques/T1056/"
[[threat.technique.subtechnique]]
id = "T1056.001"
name = "Keylogging"
reference = "https://attack.mitre.org/techniques/T1056/001/"



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

[internal]
min_endpoint_version = "8.12.0"

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

[rule]
author = ["Elastic"]
description = """
Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or
node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. 
Useful for spotting in-cluster and hybrid credential theft early.
"""
false_positives = [
    """
    Legitimate backup, compliance scanners, or admin scripts that enumerate paths under /home or /var/run/secrets may
    match. Tune by parent process, image, or automation identity.
    """,
]
from = "now-9m"
index = ["auditbeat-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*"]
language = "kuery"
license = "Elastic License v2"
name = "Kubernetes and Cloud Credential Path Access via Process Arguments"
note = """## Triage and analysis

### Investigating Kubernetes and Cloud Credential Path Access via Process Arguments

Confirm whether the process user and parent chain are expected to read the matched path (for example a CI job,
bootstrap script, or kubelet). Reconstruct the full command line and check for piping, encoding, or exfiltration
patterns immediately after the read.

### Possible investigation steps

- Map the workload or login session to an identity; prioritize events from nodes, jump hosts, or pods with mounted
  service account tokens.
- Correlate with file, network, and Kubernetes audit telemetry for secret reads, token minting, or API calls using
  harvested material.

### Response and remediation

- Rotate affected service account tokens, kubeconfigs, and cloud keys when access was unauthorized; review RBAC and
  secret mount policy for the workload.
"""
references = [
    "https://attack.mitre.org/techniques/T1552/",
    "https://kubernetes.io/docs/concepts/security/service-accounts/",
]
risk_score = 73
rule_id = "5f0fff18-f340-444b-9a98-c49ade766ff4"
setup = """## Setup

Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`,
`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events.

### Elastic Defend
Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with
arguments.

### Auditd Manager
Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and
`process.executable` populate for monitored binaries.

See https://docs.elastic.co/integrations/auditd_manager
"""
severity = "high"
tags = [
    "Data Source: Auditd Manager",
    "Data Source: Elastic Defend",
    "Domain: Endpoint",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
host.os.type:linux and event.category:process and event.action:(exec or executed) and 
(
  process.name:(
    busybox or cat or head or tail or more or less or sed or awk or 
    find or grep or ls or whereis or cp or mv or ln or
    curl or wget or scp or rsync or tar or zip or gzip or
    base64 or xxd or od or dd or tee or strings or xargs or jq or yq or
    openssl or ssh or sftp or nc or ncat or netcat or socat or
    python* or perl* or ruby* or node or php* or lua* or .*
  ) or
  process.args:(
    cat or head or tail or more or less or sed or awk or 
    find or grep or cp or mv or curl or wget or base64 or 
    tar or scp or dd or strings or xargs
  ) or
  process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /home/* or /run/user/*)
) and process.args:(
  "/var/run/secrets/kubernetes.io/serviceaccount/token" or
  "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" or
  "/var/run/secrets/eks.amazonaws.com/serviceaccount/token" or
  "/var/run/secrets/azure/tokens/azure-identity-token" or
  "/var/run/secrets/tokens/azure-identity-token" or
  "/var/lib/kubelet/kubeconfig" or
  "/etc/kubernetes/admin.conf" or
  "/etc/kubernetes/pki/ca.key" or
  "/etc/kubernetes/pki/apiserver-kubelet-client.key" or
  "/var/lib/kubelet/pki/kubelet-client-current.pem" or
  "/etc/rancher/k3s/k3s.yaml" or
  */.aws/credentials or
  */.aws/cli/cache/*.json or
  */.aws/sso/cache/*.json or
  */.azure/accessTokens.json or
  */.azure/azureProfile.json or
  */.azure/msal_token_cache.json or
  */confluence/confluence.cfg.xml or 
  *confluence/conf/server.xml
  */.config/gcloud/application_default_credentials.json or
  */.config/gcloud/credentials.db or
  */.config/gcloud/access_tokens.db or
  */.config/gcloud/legacy_credentials or
  */.kube/config or
  */.docker/config.json
) 
'''

[[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.001"
name = "Credentials In Files"
reference = "https://attack.mitre.org/techniques/T1552/001/"


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

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

[metadata]
creation_date = "2020/11/24"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/04/24"

[rule]
author = ["Elastic"]
description = """
Identifies creation of LSASS memory dump artifacts with filenames matching LSASS dumps or common dumping-tool outputs,
including dumpert.dmp, Andrew.dmp, SQLDmpr*.mdmp, and Coredump.dmp. This can indicate credential access through
trusted utilities such as Task Manager or SQLDumper, or known tooling such as Dumpert and AndrewSpecial.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "LSASS Memory Dump Creation"
references = ["https://github.com/outflanknl/Dumpert", "https://github.com/hoangprod/AndrewSpecial"]
risk_score = 73
rule_id = "f2f46686-6f3c-4724-bd7d-24e31c70f98f"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.action != "deletion" and
  file.name : ("lsass*.dmp", "dumpert.dmp", "Andrew.dmp", "SQLDmpr*.mdmp", "Coredump.dmp") and

  not (
        process.executable : (
          "?:\\Program Files\\Microsoft SQL Server\\*\\Shared\\SqlDumper.exe",
          "?:\\Program Files\\Microsoft SQL Server Reporting Services\\SSRS\\ReportServer\\bin\\SqlDumper.exe",
          "?:\\Windows\\System32\\dllhost.exe"
        ) and
        file.path : (
          "?:\\*\\Reporting Services\\Logfiles\\SQLDmpr*.mdmp",
          "?:\\Program Files\\Microsoft SQL Server Reporting Services\\SSRS\\Logfiles\\SQLDmpr*.mdmp",
          "?:\\Program Files\\Microsoft SQL Server\\*\\Shared\\ErrorDumps\\SQLDmpr*.mdmp",
          "?:\\Program Files\\Microsoft SQL Server\\*\\MSSQL\\LOG\\SQLDmpr*.mdmp"
        )
      ) and

  not (
        process.executable : (
          "?:\\Windows\\system32\\WerFault.exe",
          "?:\\Windows\\System32\\WerFaultSecure.exe"
          ) and
        file.path : (
          "?:\\Windows\\System32\\config\\systemprofile\\AppData\\Local\\CrashDumps\\lsass.exe.*.dmp",
          "?:\\Windows\\System32\\%LOCALAPPDATA%\\CrashDumps\\lsass.exe.*.dmp"
        )
  )
'''

note = """## Triage and analysis

### Investigating LSASS Memory Dump Creation

#### Possible investigation steps

- What dump artifact did the alert record, and does it look like crash handling or credential collection?
  - Focus: `file.path`, `file.name`, `file.extension`, `file.size`, and the alerting `process.entity_id`.
  - Implication: escalate when the path is user-writable, remote, hidden, or deceptive, or when `file.name` is "dumpert.dmp", "Andrew.dmp", "Coredump.dmp", or an LSASS-named dump outside a recognized crash location; lower suspicion only when the artifact fits a known crash-analysis, vendor support, or IR acquisition path for this `host.id`.
  - Hint: the rule already filters common WER LSASS crash paths and expected SQLDumper dump locations, so a remaining SQLDmpr or LSASS dump path needs its own workflow explanation.

- Is the writer an expected dump utility in an expected execution context?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.command_line`. $investigate_4
  - Implication: escalate when the writer is unsigned, renamed, user-writable, launched with dump-specific arguments, or matches a "rundll32.exe" Dumpert DLL chain; reduce concern only when signer, path, arguments, and parent context all fit the same recognized diagnostic or IR workflow. Identity alone does not clear LSASS dumping.

- Does the parent chain and user context explain why this account created an LSASS dump?
  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, `user.id`, and `user.name`.
  - Implication: escalate when shells, script hosts, Office, browsers, remote-admin tooling, or an unexpected user launch the writer; lower suspicion only when lineage and `user.id` match the same recognized support, vendor, or forensic collection workflow.

- Did the same writer hide, move, archive, or copy the dump after creation?
  - Focus: same-writer file events for `host.id` and `process.entity_id`, especially `file.path`, `file.Ext.original.path`, `file.name`, and `file.size`. $investigate_0
  - Implication: escalate when the dump is renamed, compressed, copied to a share, moved into hidden or user-controlled paths, or removed after staging; unresolved when same-writer file telemetry does not explain the dump's handling.
  - Hint: use `file.Ext.original.path` on rename events to connect a detected dump name to a later archive, deceptive extension, or alternate staging path.

- Did child processes use or clean up the dump?
  - Focus: child process events on `host.id` where `process.parent.entity_id` equals the writer `process.entity_id`, with `process.executable`, `process.command_line`, and `@timestamp`. $investigate_1
  - Implication: escalate when archivers, copy tools, PowerShell, "rundll32.exe", dump parsers such as Mimikatz, or deletion commands follow the dump write; no child follow-on only narrows this path and does not rule out in-process or remote retrieval.

- Does the host or session make the exposed credential material high impact?
  - Focus: `host.id`, `host.name`, `user.domain`, `user.id`, and `process.Ext.session_info.logon_type`; asset or host-role context when available.
  - Implication: raise urgency when the dump is on a server, jump host, domain controller, privileged admin workstation, or from an unexpected administrative session; a lab or diagnostics host lowers urgency only after artifact, writer, lineage, and handling evidence fit one recognized workflow.

- If local evidence is suspicious or unresolved, do related alerts change scope?
  - Focus: related credential-access, staging, privilege, or lateral-movement alerts for `user.id`. $investigate_2
  - Hint: compare related alerts for `host.id` separately to determine whether activity is isolated to this host or part of broader compromise. $investigate_3
  - Implication: broaden containment when the same user or host has related credential-access or post-compromise alerts; keep scope local when related alerts are quiet, but do not use quiet scoping to close unresolved dump evidence.

- Escalate when artifact, writer, lineage, staging, child-process, host-role, or related-alert evidence shows deliberate LSASS collection or broader compromise; close only when those categories bind to one recognized troubleshooting, vendor support, or IR workflow for this host; preserve artifacts and escalate when evidence is mixed or incomplete.

### False positive analysis

- Recognized crash analysis, vendor support, Task Manager troubleshooting, SQL Server diagnostics outside filtered paths, or IR/forensic acquisition can legitimately create LSASS dumps. Confirm by aligning identity (`process.executable`, `process.code_signature.subject_name`, `process.pe.original_file_name`), artifact (`file.path`, `file.name`, `file.size`, rename history), lineage (`process.parent.executable`, `process.parent.command_line`), actor (`user.id`, `user.domain`), and host (`host.id`, role) to the same exact workflow. If any dimension contradicts the workflow or telemetry cannot explain why LSASS was dumped, do not close on owner or change-record claims alone.
- If workflow records or owner confirmation are unavailable, require telemetry-only stability for the same workflow pattern on the same `host.id` and `user.id` across prior alerts before considering closure; a first-time or one-off LSASS dump remains suspicious unless artifact, writer, lineage, and handling evidence are clean.
- Build exceptions from the minimum confirmed pattern: `process.executable`, `process.code_signature.subject_name`, `process.pe.original_file_name`, parent workflow, `file.path` pattern, `user.id`, and `host.id`. Avoid exceptions on `file.name`, `process.name`, LSASS naming, or host alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and document the dump path, writer identity, signer, parent workflow, user, host role, and confirming workflow evidence. Create an exception only when the same workflow recurs consistently for the same scope.
- If suspicious but unconfirmed, preserve the dump or case-safe copy, `file.path`, rename/archive paths, writer `process.entity_id`, `process.command_line`, parent chain, child-process records, `user.id`, and `host.id` before containment or cleanup. Apply reversible containment first, such as restricting outbound administrative access or suspending the writer when operationally safe. Escalate to host isolation or account containment only when staging, transfer, parsing, or related-alert evidence shows likely credential theft.
- If confirmed malicious, isolate the host when host role permits, or escalate with the preserved artifact set to the team that can contain it. Record artifacts before terminating processes or deleting dumps, archives, or tools.
- Treat confirmed LSASS dump exposure on servers, jump hosts, domain controllers, or privileged administration assets as credential compromise risk. Scope which local, cached, service, or administrative credentials may have been present and begin credential hygiene for implicated accounts and systems.
- Eradicate unauthorized dump utilities, scripts, archives, copied dumps, and persistence mechanisms found during the investigation, then remediate the privilege path or initial access route that allowed dump creation.
- After containment, hunt for the same writer paths, dump-file naming patterns, "rundll32.exe" Dumpert launch chains, and archive or copy commands across other hosts.
"""

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.pe.original_file_name",
    "process.parent.executable",
    "process.parent.command_line",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
    "process.Ext.session_info.logon_type",
    "file.path",
    "file.Ext.original.path",
]

[[transform.investigate]]
label = "File events by dump writer"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Child processes by dump writer"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
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"

[[transform.investigate]]
label = "Process events by dump writer"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
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/"

[metadata]
creation_date = "2022/01/10"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the occurrence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers
can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access.
Users can inadvertently share these files without knowing their maliciousness, giving adversaries an opportunity to gain
initial access to other endpoints in the environment.
"""
false_positives = ["Benign files can trigger signatures in the built-in virus protection"]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 OneDrive Malware File Upload"
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 M365 OneDrive Malware File Upload

OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement within a network. The detection rule identifies such threats by monitoring OneDrive activities for malware detection events, focusing on file operations flagged by Microsoft's security engine. This proactive approach helps in identifying and mitigating potential breaches.

### Possible investigation steps

- Review the alert details to confirm the event dataset is 'o365.audit' and the event provider is 'OneDrive' to ensure the alert is relevant to OneDrive activities.
- Examine the specific file operation flagged by the event code 'SharePointFileOperation' and action 'FileMalwareDetected' to identify the file in question and understand the nature of the detected malware.
- Identify the user account associated with the file upload to determine if the account has been compromised or if the user inadvertently uploaded the malicious file.
- Check the sharing settings of the affected file to assess the extent of exposure and identify any other users or systems that may have accessed the file.
- Investigate the file's origin and history within the organization to trace how it was introduced into the environment and whether it has been shared or accessed by other users.
- Review any additional security alerts or logs related to the user account or file to identify potential patterns of malicious activity or further compromise.
- Coordinate with IT and security teams to isolate the affected file and user account, and initiate remediation steps to prevent further spread of the malware.

### False positive analysis

- Legitimate software updates or patches may be flagged as malware if they are not yet recognized by the security engine. Users should verify the source and integrity of the file and consider adding it to an exception list if confirmed safe.
- Files containing scripts or macros used for automation within the organization might trigger false positives. Review the file's purpose and origin, and whitelist it if it is a known and trusted internal tool.
- Shared files from trusted partners or vendors could be mistakenly identified as threats. Establish a process to verify these files with the sender and use exceptions for recurring, verified files.
- Archived or compressed files that contain known safe content might be flagged due to their format. Decompress and scan the contents separately to confirm their safety before adding exceptions.
- Files with unusual or encrypted content used for legitimate business purposes may be misclassified. Ensure these files are documented and approved by IT security before excluding them from alerts.

### Response and remediation

- Immediately isolate the affected OneDrive account to prevent further file sharing and potential spread of malware within the organization.
- Notify the user associated with the account about the detected malware and instruct them to cease any file sharing activities until further notice.
- Conduct a thorough scan of the affected files using an updated antivirus or endpoint detection and response (EDR) solution to confirm the presence of malware and identify any additional infected files.
- Remove or quarantine the identified malicious files from OneDrive and any other locations they may have been shared to prevent further access or execution.
- Review and revoke any shared links or permissions associated with the infected files to ensure no unauthorized access is possible.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if any lateral movement or additional compromise has occurred.
- Implement enhanced monitoring and alerting for similar OneDrive activities to quickly detect and respond to any future malware uploads or related threats.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/virus-detection-in-spo?view=o365-worldwide",
]
risk_score = 73
rule_id = "bba1b212-b85c-41c6-9b28-be0e5cdfc9b1"
severity = "high"
tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Lateral Movement", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:OneDrive and event.code:SharePointFileOperation and event.action:FileMalwareDetected
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1080"
name = "Taint Shared Content"
reference = "https://attack.mitre.org/techniques/T1080/"


[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 = "T1608"
name = "Stage Capabilities"
reference = "https://attack.mitre.org/techniques/T1608/"
[[rule.threat.technique.subtechnique]]
id = "T1608.001"
name = "Upload Malware"
reference = "https://attack.mitre.org/techniques/T1608/001/"


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

[metadata]
creation_date = "2026/02/24"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies search queries in SharePoint containing sensitive terms related to credentials, financial data,
PII, legal matters, or infrastructure information. Adversaries who compromise user accounts often search for high-value
files before exfiltration. This rule detects searches containing terms across multiple sensitivity categories,
regardless of the access method (browser, PowerShell, or API). The actual search query text is analyzed against a
curated list of sensitive terms to identify potential reconnaissance activity.
"""
false_positives = [
    "Security or compliance teams using eDiscovery or Content Search for legitimate investigations.",
    "HR or finance personnel legitimately searching for employee or financial records.",
    "IT administrators searching for configuration or infrastructure documentation.",
    "Legal teams searching for contract or privileged documents.",
]
from = "now-9m"
index = ["filebeat-*", "logs-o365.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "M365 SharePoint Search for Sensitive Content"
note = """## Triage and Analysis

### Investigating M365 SharePoint Search for Sensitive Content

This rule detects search queries in SharePoint or OneDrive that contain sensitive terms. The Microsoft 365 Unified Audit Log captures the actual search query text in the `SearchQueryText` field, allowing detection of reconnaissance activity targeting credentials, financial data, PII, legal documents, or infrastructure information.

#### Possible Investigation Steps

- Identify who performed the search and determine if this user has a legitimate business need to search for this type of content.
- Review the exact search terms used. Multiple sensitive terms in one query are more suspicious.
- Determine if the search was via browser, automation tool (PnP PowerShell), or API.
- Review the source IP and correlate with the user's typical access patterns.
- Look for subsequent file download or access events from the same user/session within minutes of the search.
- Determine if the user is a member of roles that would legitimately search for sensitive content (HR, Finance, Legal, Security, Compliance).
- Check Azure AD sign-in logs for authentication anomalies (device code flow, unusual location).

### Response and Remediation

- If unauthorized search activity is confirmed, immediately review what files were accessed or downloaded following the search.
- Revoke the user's session tokens and require reauthentication with MFA.
- If the account was compromised, reset credentials and investigate the compromise vector.
- Review Data Loss Prevention (DLP) policies to ensure sensitive content is properly protected.
- Consider implementing sensitivity labels and access restrictions on high-value content.
"""
references = ["https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft"]
risk_score = 21
rule_id = "4f2654e4-125b-11f1-af7d-f661ea17fbce"
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
web where data_stream.dataset == "o365.audit" and
    event.provider == "SharePoint" and
    event.action == "SearchQueryPerformed" and
    event.outcome == "success" and
    o365.audit.SearchQueryText != null and
    o365.audit.SearchQueryText != "" and
    o365.audit.SearchQueryText like~ (
        /* Credentials and Secrets */
        "*password*", "*credential*", "*secret*", "*api key*", "*apikey*",
        "*token*", "*private key*", "*certificate*", "*ssh*", "*aws*",
        "*azure*", "*gcp*", "*oauth*", "*bearer*", "*connection string*",
        "*access key*", "*secret key*",
        /* Financial */
        "*salary*", "*payroll*", "*compensation*", "*budget*", "*revenue*",
        "*financial*", "*banking*", "*invoice*", "*wire transfer*", "*account number*",
        "*credit card*", "*routing number*", "*profit*", "*expense*", "*1099*",
        /* Legal and Compliance */
        "*confidential*", "*privileged*", "*attorney*", "*legal hold*", "*settlement*",
        "*contract*", "*nda*", "*merger*", "*acquisition*", "*litigation*",
        "*subpoena*", "*trade secret*", "*intellectual property*", "*proprietary*",
        "*internal*", "*proposal*", "*poc*",
        /* HR and PII */
        "*ssn*", "*social security*", "*employee*", "*personnel*", "*performance review*",
        "*termination*", "*tax*", "*w2*", "*benefits*", "*background check*",
        "*medical*", "*hipaa*", "*passport*", "*driver license*", "*dob*",
        /* Infrastructure and IT */
        "*admin*", "*root*", "*vpn*", "*firewall*", "*network diagram*",
        "*architecture*", "*topology*", "*production*", "*database*", "*config*",
        "*backup*", "*disaster recovery*", "*vulnerability*", "*pentest*", "*security audit*",
        "*salesforce*"
    )
'''

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1619"
name = "Cloud Storage Object Discovery"
reference = "https://attack.mitre.org/techniques/T1619/"

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

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

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

[metadata]
creation_date = "2026/04/29"
integration = ["endpoint", "windows", "system"]
maturity = "production"
updated_date = "2026/04/29"

[rule]
author = ["Elastic"]
description = """
Correlates process telemetry for shells and major cloud/Kubernetes CLIs when command lines match token or credential
material access patterns (GCP, Azure, AWS, GitHub, kubectl, DigitalOcean, OCI). Flags hosts where multiple cloud
targets appear within a five-minute window.
"""
false_positives = [
    """
    Automation, CI runners, and platform engineering scripts may legitimately print tokens or dump kubeconfig across
    providers in one session. Baseline approved identities and runner images before tuning thresholds.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "Multi-Cloud CLI Token and Credential Access Commands"
note = """## Triage and analysis

### Investigating Multi-Cloud CLI Token and Credential Access Commands

Each result row summarizes activity for one host, user, and five-minute time bucket. Review `Esql.process_command_line_values` for the
exact invocations and confirm whether the session was interactive, automated, or tied to a known pipeline.

### Possible investigation steps

- Map `Esql.cloud_targets` and `Esql.unique_clouds` to the underlying `process.command_line` values and parent
  executables.
- Correlate with authentication, Kubernetes audit, and cloud API logs for misuse of printed tokens.
- Identify whether the parent chain indicates a remote shell, RMM, or scheduled task.

### Response and remediation

- If unauthorized, isolate the host, invalidate any printed material at the identity provider, and hunt for lateral
  movement using the same time window as the alert.

**GCP (gcloud / application-default credentials)**

- Sign the user or build identity out of local gcloud sessions on the affected machine (example host session):

  `gcloud auth revoke --all`

- Remove leaked Application Default Credentials on that host (often used by client libraries):

  `gcloud auth application-default revoke`

- If a user OAuth refresh token or service account key was exposed, revoke or rotate it in Google Cloud Console (IAM
  and admin: delete compromised keys; for end users, revoke OAuth tokens under Security or Workspace admin tools as
  applicable).

**Azure (`az` / `azd`)**

- Clear cached CLI sessions on the host so new tokens are not silently reusable from disk:

  `az logout`

  `az account clear`

- If `az account get-access-token`, `Get-AzAccessToken`, or `azd auth token` output was captured, treat the bearer as
  compromised: rotate the underlying secret (for example app registration client secret or federated credential),
  revoke sessions in Microsoft Entra ID where supported, and enforce re-authentication with Conditional Access.

**GitHub (`gh` / PATs)**

- Remove the GitHub CLI session from the affected profile:

  `gh auth logout`

- If a personal access token or fine-grained token was printed, revoke it under GitHub user or organization settings
  (Developer settings → Personal access tokens), and rotate any secrets or deploy keys that were readable with that
  token.

For all providers, prefer provider-console revocation and rotation when a token string left the trust boundary; local
`logout`/`revoke` alone does not invalidate tokens that were already copied off-host.
"""
references = [
    "https://attack.mitre.org/techniques/T1528/",
    "https://attack.mitre.org/techniques/T1552/",
]
risk_score = 73
rule_id = "2b9a3b7a-0891-4a89-abbe-dca753c403cd"
severity = "high"
tags = [
    "Domain: Endpoint",
    "Domain: Cloud",
    "OS: Windows",
    "OS: Linux",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Sysmon",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
FROM logs-endpoint.events.process-*, logs-system.security-*, logs-windows.sysmon_operational-* METADATA _id, _index, _version
| WHERE event.category == "process" AND KQL(""" event.type : "start" and not event.action : "fork" """)
  AND process.command_line IS NOT NULL 
  AND (
    TO_LOWER(process.name) IN (
      "cmd.exe", "powershell.exe", "pwsh.exe", 
      "sh", "bash", "zsh", "dash", "fish", "ksh",
      "gcloud", "gcloud.cmd", "az", "az.cmd", "azd", "azd.exe",
      "gh", "gh.exe", "aws", "aws.exe",
      "kubectl", "kubectl.exe",
      "doctl", "doctl.exe",
      "oci", "oci.exe"
    ) OR
    TO_LOWER(process.parent.name) IN (
      "cmd.exe", "powershell.exe", "pwsh.exe",
      "sh", "bash", "zsh", "dash", "fish", "ksh", "bun", "bun.exe", 
      "node", "node.exe", "java", "java.exe"
    )
  )
  AND process.command_line RLIKE """.*(config-helper\s.*--format|auth\s+print-access-token|auth\s+print-identity-token|auth\s+application-default\s+print|get-access-token\s.*--output|Get-AzAccessToken|azd\s+auth\s+token|az\s+account\s+get-access-token|gh\s+auth\s+(token|status)|aws\s+sts\s+(get-session-token|get-caller-identity|assume-role)|aws\s+configure\s+(export-credentials|list)|kubectl\s+config\s+view\s.*--raw|kubectl\s+get\s+secret|doctl\s+auth\s+(list|init)|oci\s+session\s+authenticate|oci\s+iam\s.*token).*"""
| EVAL cloud_target = CASE(
    process.command_line RLIKE ".*(gcloud|config-helper|print-access-token|print-identity-token).*", "GCP",
    process.command_line RLIKE ".*(azd auth|az account|Get-AzAccessToken).*", "AZURE",
    process.command_line RLIKE ".*(aws sts|aws configure).*", "AWS",
    process.command_line RLIKE ".*(gh auth).*", "GITHUB",
    process.command_line RLIKE ".*(kubectl config|kubectl get secret).*", "KUBERNETES",
    process.command_line RLIKE ".*(doctl).*", "DIGITALOCEAN",
    process.command_line RLIKE ".*(oci session|oci iam).*", "ORACLE"
  )
| WHERE cloud_target IS NOT NULL // drop unclassified events before aggregation
| STATS
    Esql.cloud_targets = VALUES(cloud_target),
    Esql.unique_clouds = COUNT_DISTINCT(cloud_target),
    Esql.process_command_line_values = VALUES(process.command_line),
    Esql.process_parent_executable_values = VALUES(process.parent.executable),
    Esql.first_seen = MIN(@timestamp),
    Esql.last_seen = MAX(@timestamp),
    Esql.event_count = COUNT(*)
  BY host.name, host.id, user.name
| WHERE Esql.unique_clouds >= 2
| KEEP Esql.*, user.name, host.name, host.id
'''

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

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

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

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

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