Elastic rules: 13

[rule]
description = """
Identifies access attempt to the Windows Passwords Vault via Powershell commands. Adversaries may acquire credentials
from Vault files.
"""
id = "7a4d1be2-db47-4545-a08c-9d4b20bad0d0"
license = "Elastic License v2"
name = "Access to Windows Passwords Vault via Powershell"
os_list = ["windows"]
reference = [
    "https://docs.microsoft.com/en-us/uwp/api/windows.security.credentials.passwordvault.retrieve?view=winrt-22000",
]
version = "1.0.29"

query = '''
process where event.action == "start" and
 process.pe.original_file_name == "PowerShell.EXE" and
 process.command_line : ("*Credentials.PasswordVault*", "*RetrievePassword*", "*Credentials*RetrieveAll*") and
 not process.parent.executable :
          ("?:\\Program Files\\WindowsApps\\KeeperSecurityInc.KeeperPasswordManager_*\\app\\keeperpasswordmanager.exe",
           "?:\\Program Files (x86)\\WindowsApps\\KeeperSecurityInc.KeeperPasswordManager_*\\app\\keeperpasswordmanager.exe") and
 not (process.parent.code_signature.subject_name == "Keeper Security Inc." and process.parent.code_signature.trusted == true)
'''

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

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

[[optional_actions]]
action = "rollback"
field = "process.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.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[threat.technique.subtechnique]]
id = "T1555.004"
name = "Windows Credential Manager"
reference = "https://attack.mitre.org/techniques/T1555/004/"



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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2024/03/14"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies the creation of an Alternate Data Stream (ADS) at a volume root directory, which can indicate the attempt to
hide tools and malware, as ADSs created in this directory are not displayed by system utilities.
"""
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 = "Alternate Data Stream Creation/Execution at Volume Root Directory"
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 Alternate Data Stream Creation/Execution at Volume Root Directory

Alternate Data Streams (ADS) in Windows allow files to contain multiple streams of data, which can be exploited by adversaries to conceal malicious tools or data. By creating or executing ADS at the root of a volume, attackers can evade detection by standard system utilities. The detection rule identifies suspicious ADS activity by monitoring file creation and process execution patterns at the volume root, flagging potential defense evasion attempts.

### Possible investigation steps

- Review the alert details to identify the specific file path or process executable that triggered the alert, focusing on the volume root directory pattern [A-Z]:\\\\:.
- Check the file or process creation timestamp to determine when the suspicious activity occurred and correlate it with other events or activities on the system around the same time.
- Investigate the file or process owner and the user account associated with the activity to assess if it aligns with expected behavior or if it indicates potential unauthorized access.
- Examine the file or process for known indicators of compromise (IOCs) or signatures of malicious activity using threat intelligence sources or antivirus tools.
- Analyze the system for additional signs of compromise, such as unexpected network connections, registry changes, or other suspicious files, to determine if the ADS activity is part of a larger attack.
- Review system logs and security tools for any related alerts or anomalies that could provide further context or evidence of malicious intent.

### False positive analysis

- System utilities or legitimate applications may create ADS at the volume root for benign purposes, such as storing metadata or configuration data. Review the source of the ADS creation to determine if it is associated with known safe applications.
- Backup or disk management software might use ADS to store additional information about files. Verify if the detected activity aligns with scheduled backup operations or disk management tasks.
- Some security tools or system monitoring applications may use ADS for logging or tracking purposes. Cross-reference the process or file path with known security tools to rule out false positives.
- If a specific application is consistently triggering alerts due to its use of ADS, consider creating an exception for that application's process or file path in your monitoring solution to reduce noise.
- Regularly update your list of known safe applications and processes that interact with ADS to ensure that legitimate activities are not flagged as suspicious.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the identified ADS activity.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any hidden malicious files or tools.
- Review and delete any unauthorized or suspicious ADS found at the volume root directory to eliminate potential hiding places for malware.
- Restore affected files from a known good backup to ensure system integrity and remove any compromised data.
- Monitor network traffic for unusual patterns or connections that may indicate ongoing malicious activity or data exfiltration attempts.
- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures."""
references = ["https://www.crowdstrike.com/blog/anatomy-of-alpha-spider-ransomware/"]
risk_score = 47
rule_id = "ff6cf8b9-b76c-4cc1-ac1b-4935164d1029"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "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 regex~ """[A-Z]:\\:.+""") or
    (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""")
  )
'''

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 = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[rule.threat.technique.subtechnique]]
id = "T1564.004"
name = "NTFS File Attributes"
reference = "https://attack.mitre.org/techniques/T1564/004/"



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

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

[rule]
author = ["Elastic", "@BenB196", "Austin Songer"]
description = """
Identifies when an Okta user account is locked out 3 times within a 3 hour window. An adversary may attempt a brute
force or password spraying attack to obtain unauthorized access to user accounts. The default Okta authentication policy
ensures that a user account is locked out after 10 failed authentication attempts.
"""
from = "now-180m"
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Attempts to Brute Force an Okta User Account"
note = """## Triage and analysis

### Investigating Attempts to Brute Force an Okta User Account

Brute force attacks aim to guess user credentials through exhaustive trial-and-error attempts. In this context, Okta accounts are targeted.

This rule fires when an Okta user account has been locked out 3 times within a 3-hour window. This could indicate an attempted brute force or password spraying attack to gain unauthorized access to the user account. Okta's default authentication policy locks a user account after 10 failed authentication attempts.

#### Possible investigation steps:

- Identify the actor related to the alert by reviewing `okta.actor.alternate_id` field in the alert. This should give the username of the account being targeted.
- Review the `okta.event_type` field to understand the nature of the events that led to the account lockout.
- Check the `okta.severity` and `okta.display_message` fields for more context around the lockout events.
- Look for correlation of events from the same IP address. Multiple lockouts from the same IP address might indicate a single source for the attack.
- If the IP is not familiar, investigate it. The IP could be a proxy, VPN, Tor node, cloud datacenter, or a legitimate IP turned malicious.
- Determine if the lockout events occurred during the user's regular activity hours. Unusual timing may indicate malicious activity.
- Examine the authentication methods used during the lockout events by checking the `okta.authentication_context.credential_type` field.

### False positive analysis:

- Determine whether the account owner or an internal user made repeated mistakes in entering their credentials, leading to the account lockout.
- Ensure there are no known network or application issues that might cause these events.

### Response and remediation:

- Alert the user and your IT department immediately.
- If unauthorized access is confirmed, initiate your incident response process.
- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.
- Require the affected user to change their password.
- If the attack is ongoing, consider blocking the IP address initiating the brute force attack.
- Implement account lockout policies to limit the impact of brute force attacks.
- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.
- Check if the compromised account was used to access or alter any sensitive data or systems.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 47
rule_id = "e08ccd49-0380-4b2b-8d71-8000377d6e49"
severity = "medium"
tags = [
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Data Source: Okta",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset:okta.system and event.action:user.account.lock
'''


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

[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"

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

[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[rule.threshold]
field = ["okta.actor.alternate_id"]
value = 3

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

[rule]
author = ["Elastic"]
description = """
Identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may
use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects
unusual user activity by monitoring for the Scan action in CloudTrail logs. This is a New Terms rule that only flags
when this behavior is observed by a user or role for the first time.
"""
false_positives = [
    """
    Legitimate users may scan DynamoDB tables for various reasons, such as data analysis or application functionality.
    Ensure that the user has the necessary permissions and that the Scan operation is authorized before taking action.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS DynamoDB Scan by Unusual User"
note = """## Triage and analysis

### Investigating AWS DynamoDB Scan by Unusual User

This rule identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs.

This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags when this behavior is observed for the first time.

#### Possible Investigation Steps

- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the subscription. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user.
- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access.
- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the Scan request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being scanned.
- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key is associated with a legitimate user or if it has been compromised.


### False Positive Analysis

- Historical User Actions: If the user has a history of scanning DynamoDB tables for legitimate purposes, this may not be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions.
- Automated Processes: Some automated processes or applications may perform scans on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may not be a false positive.

### Response and Remediation

- Immediate Review and Reversal: If the Scan action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's account or removing their permissions.
- Investigate Compromise: If the Scan action is determined to be malicious, investigate the source of the request and any potential compromise of the user's account. This may involve reviewing access logs, resetting passwords, and enabling multi-factor authentication (MFA) for the affected user. If export options were used with the CLI or SDK, they may have been saved locally or to a remote location.
- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources.
- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts.

### Additional Information

For further guidance on managing and securing DynamoDB in AWS environments, refer to the [AWS DynamoDB documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html) and AWS best practices for security.
"""
references = ["https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html"]
risk_score = 21
rule_id = "96b2a03e-003b-11f0-8541-f661ea17fbcd"
setup = "DynamoDB data events must be enabled in CloudTrail to capture the Scan action. Ensure that the AWS CloudTrail service is configured to log data events for DynamoDB tables."
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS DynamoDB",
    "Resources: Investigation Guide",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "dynamodb.amazonaws.com"
    and event.action: "Scan"
    and event.outcome: "success"
'''


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

[[rule.threat.technique]]
id = "T1567"
name = "Exfiltration Over Web Service"
reference = "https://attack.mitre.org/techniques/T1567/"

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are
critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data
recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive
attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery
capabilities.
"""
false_positives = [
    """
    Storage administrators may legitimately delete snapshots during routine maintenance, storage optimization, or
    cleanup of old backup data. Verify that the deletion was expected and follows organizational data retention
    policies. Consider exceptions for approved maintenance windows or automated retention management tools.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Compute Snapshot Deletion by Unusual User and Resource Group"
note = """## Triage and analysis

### Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group

Azure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days.

### Possible investigation steps

- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields.
- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities.
- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions.
- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal.
- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization.
- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time.
- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion.
- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations.

### False positive analysis

- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities.
- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows.
- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows.
- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods.

### Response and remediation

- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders.
- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled.
- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy.
- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities.
- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion.
- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators.
- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted.
- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots.
- Document the incident and update security policies and procedures to prevent similar incidents in the future.
"""
references = [
    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
]
risk_score = 21
rule_id = "c3d4e5f6-7a8b-9c0d-1e2f-3a4b5c6d7e8f"
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Storage",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: azure.activitylogs and
    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
    azure.activitylogs.properties.status_code: "Accepted" and
    azure.activitylogs.identity.claims_initiated_by_user.name: *
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "azure.activitylogs.identity.claims_initiated_by_user.name",
    "azure.activitylogs.identity.authorization.evidence.principal_id",
    "azure.activitylogs.identity.claims.appid",
    "azure.activitylogs.identity.claims.sid",
    "azure.resource.name",
    "azure.resource.group",
    "azure.activitylogs.operation_name",
    "azure.subscription_id",
    "azure.activitylogs.tenant_id",
    "source.ip",
]


[[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 = "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.new_terms]
field = "new_terms_fields"
value = ["azure.activitylogs.identity.claims_initiated_by_user.name", "azure.resource.group"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2023/06/09"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/22"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve File Listing Information"
query = """
SELECT * FROM file WHERE (path LIKE '/etc/cron.allow.d/%' OR path LIKE '/etc/cron.d/%' OR path LIKE '/etc/cron.hourly/%'
OR path LIKE '/etc/cron.daily/%' OR path LIKE '/etc/cron.weekly/%' OR path LIKE '/etc/cron.monthly/%' OR path LIKE
'/var/spool/cron/crontabs/%')
"""

[[transform.osquery]]
label = "Osquery - Retrieve Cron File Information"
query = "SELECT * FROM file WHERE (path = '/etc/cron.allow' OR path = '/etc/cron.deny' OR path = '/etc/crontab')\n"

[[transform.osquery]]
label = "Osquery - Retrieve Additional File Listing Information"
query = """
SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS
file_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS
file_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT
JOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/cron.allow.d/%' OR path LIKE
'/etc/cron.d/%' OR path LIKE '/etc/cron.hourly/%' OR path LIKE '/etc/cron.daily/%' OR path LIKE '/etc/cron.weekly/%' OR
path LIKE '/etc/cron.monthly/%' OR path LIKE '/var/spool/cron/crontabs/%')
"""

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

[[transform.osquery]]
label = "Osquery - Retrieve Listening Ports"
query = "SELECT pid, address, port, socket, protocol, path FROM listening_ports"

[[transform.osquery]]
label = "Osquery - Retrieve Open Sockets"
query = "SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"

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

[rule]
author = ["Elastic"]
description = """
This rule monitors for (ana)cron jobs being created or renamed. Linux cron jobs are scheduled tasks that can be
leveraged by system administrators to set up scheduled tasks, but may be abused by malicious actors for persistence,
privilege escalation and command execution. By creating or modifying cron job configurations, attackers can execute
malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized
activities.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Cron Job Created or Modified"
note = """## Triage and analysis

### Investigating Cron Job Created or Modified
Linux cron jobs are scheduled tasks that run at specified intervals or times, managed by the cron daemon. 

By creating or modifying cron job configurations, attackers can execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities.

This rule monitors the creation of cron jobs by monitoring for file creation and rename events in the most common cron job task location directories.

> **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 the cron job file that was created or modified.
- Investigate whether any other files in any of the available cron job directories have been altered through OSQuery.
  - $osquery_0
  - $osquery_1
  - $osquery_2
- Investigate the script 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.
- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. 
  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
    - Use a private sandboxed malware analysis system to perform analysis.
      - Observe and collect information about the following activities:
        - Attempts to contact external domains and addresses.
          - Check if the domain is newly registered or unexpected.
          - Check the reputation of the domain or IP address.
        - File access, modification, and creation activities.
- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes.
  - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration.
    - $osquery_4
    - $osquery_5
  - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.
    - $osquery_6
- Investigate whether the user is currently logged in and active.
    - $osquery_7

### False Positive Analysis

- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. 
- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.

### Related Rules

- Suspicious File Creation in /etc for Persistence - 1c84dd64-7e6c-4bad-ac73-a5014ee37042
- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f
- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b
- Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c
- Systemd Service Created - 17b0a495-4d9f-414c-8ad0-92f018b8e001

### 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.
- 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.
- Delete the service/timer or restore its original configuration.
- 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.
- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
    "https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-cron/",
    "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
]
risk_score = 47
rule_id = "ff10d4d8-fea7-422d-afb1-e5a2702369a9"
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: Persistence",
    "Tactic: Privilege Escalation",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action in ("rename", "creation") and file.path like (
  "/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*", "/etc/cron.hourly/*", "/etc/cron.daily/*", "/etc/cron.weekly/*",
  "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*", "/var/spool/anacron/*"
) and not (
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon",
    "/bin/pamac-daemon", "/usr/local/bin/dockerd", "/opt/elasticbeanstalk/bin/platform-engine",
    "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/opt/imunify360/venv/bin/python3",
    "/opt/eset/efs/lib/utild", "/usr/sbin/anacron", "/usr/bin/podman", "/kaniko/kaniko-executor",
    "/usr/bin/pvedaemon", "./usr/bin/podman", "/usr/lib/systemd/systemd", "./usr/bin/podman", "/usr/bin/coreutils",
    "/usr/sbin/univention-config-registry", "/usr/bin/dnf5", "./usr/lib/snapd/snap-update-ns"
  ) or
  file.path like ("/var/spool/cron/crontabs/tmp.*", "/etc/cron.d/jumpcloud-updater") or
  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
  file.Ext.original.extension == "dpkg-new" or
  process.executable like (
    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/libexec/platform-python*",
    "/var/lib/waagent/Microsoft*"
  ) or
  process.executable == null or
  process.name in (
    "crond", "executor", "puppet", "droplet-agent.postinst", "cf-agent", "schedd", "imunify-notifier",
    "jumpcloud-agent", "crio", "dnf_install", "utild"
  ) or
  (process.name == "sed" and file.name like "sed*") or
  (process.name == "perl" and file.name like "e2scrub_all.tmp*")  or
  (process.name in ("vi", "vim") and file.name like "*~")
)
'''

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

[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"

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

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

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

[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"

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

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

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

[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"

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

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

[metadata]
bypass_bbr_timing = true
creation_date = "2023/10/11"
integration = "endpoint"
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Detects files being compressed or archived into common formats by unsigned processes. This is a common technique used to
obfuscate files to evade detection or to staging data for exfiltration.
"""
from = "now-9m"
index = ["logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "File Compressed or Archived into Common Format by Unsigned Process"
references = ["https://en.wikipedia.org/wiki/List_of_file_signatures"]
risk_score = 21
rule_id = "79124edf-30a8-4d48-95c4-11522cad94b1"
severity = "low"
tags = [
    "Data Source: Elastic Defend",
    "Domain: Endpoint",
    "OS: macOS",
    "OS: Windows",
    "Tactic: Collection",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.type in ("creation", "change") and
 process.executable != null and process.code_signature.trusted != true and
 file.Ext.header_bytes : (
                          /* compression formats */
                          "1F9D*",             /* tar zip, tar.z (Lempel-Ziv-Welch algorithm) */
                          "1FA0*",             /* tar zip, tar.z (LZH algorithm) */
                          "425A68*",           /* Bzip2 */
                          "524E4301*",         /* Rob Northen Compression */
                          "524E4302*",         /* Rob Northen Compression */
                          "4C5A4950*",         /* LZIP */
                          "504B0*",            /* ZIP */
                          "526172211A07*",     /* RAR compressed */
                          "44434D0150413330*", /* Windows Update Binary Delta Compression file */
                          "50413330*",         /* Windows Update Binary Delta Compression file */
                          "377ABCAF271C*",     /* 7-Zip */
                          "1F8B*",             /* GZIP */
                          "FD377A585A00*",     /* XZ, tar.xz */
                          "7801*",	           /* zlib: No Compression (no preset dictionary) */
                          "785E*",	           /* zlib: Best speed (no preset dictionary) */
                          "789C*",	           /* zlib: Default Compression (no preset dictionary) */
                          "78DA*", 	           /* zlib: Best Compression (no preset dictionary) */
                          "7820*",	           /* zlib: No Compression (with preset dictionary) */
                          "787D*",	           /* zlib: Best speed (with preset dictionary) */
                          "78BB*",	           /* zlib: Default Compression (with preset dictionary) */
                          "78F9*",	           /* zlib: Best Compression (with preset dictionary) */
                          "62767832*",         /* LZFSE */
                          "28B52FFD*",         /* Zstandard, zst */
                          "5253564B44415441*", /* QuickZip rs compressed archive */
                          "2A2A4143452A2A*",   /* ACE */

                          /* archive formats */
                          "2D686C302D*",       /* lzh */
                          "2D686C352D*",       /* lzh */
                          "303730373037*",     /* cpio */
                          "78617221*",         /* xar */
                          "4F4152*",           /* oar */
                          "49536328*"          /* cab archive */
 )
'''


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

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

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

[[rule.threat.technique]]
id = "T1560"
name = "Archive Collected Data"
reference = "https://attack.mitre.org/techniques/T1560/"

[[rule.threat.technique.subtechnique]]
id = "T1560.001"
name = "Archive via Utility"
reference = "https://attack.mitre.org/techniques/T1560/001/"

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

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

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

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

[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 = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

[[rule.threat.technique.subtechnique]]
id = "T1027.015"
name = "Compression"
reference = "https://attack.mitre.org/techniques/T1027/015/"

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

[metadata]
creation_date = "2025/12/16"
integration = ["github"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when GitHub Secret Scanning is disabled for a repository. Adversaries may disable secret scanning to
evade detection of hardcoded secrets, such as API keys or credentials, that could be used for further
compromise or data exfiltration.
"""
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "GitHub Secret Scanning Disabled"
note = """ ## Triage and analysis

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

### Investigating GitHub Secret Scanning Disabled

This rule triggers when secret scanning is disabled on a repository, signaling an attempt to hide exposed tokens, keys, or passwords that can enable lateral movement, persistence, and data exfiltration. An attacker who gains admin or bot access may disable scanning, push a commit embedding plaintext credentials, and modify a workflow to export them via CI jobs, then use those secrets to authenticate to external services or cloud accounts and expand control.

### Possible investigation steps

- Identify the actor (user, bot, or GitHub App), their auth method and source IP, confirm admin privileges, and validate whether the change was planned and approved.
- Immediately re-enable Secret Scanning and Push Protection on the repository and, if possible, enforce them via an organization policy, recording change control and justification.
- Review commits, pull requests, and workflow file changes near the disable timestamp to detect added plaintext credentials, secret files, or code paths that read or export secrets.
- Examine recent GitHub Actions runs, artifacts, and logs for secrets printed, unusual network egress, or jobs using elevated token scopes, and check for newly added or modified repo/org secrets.
- Correlate IdP, cloud, and third-party service logs for authentication or API activity shortly after the disable event, revoking and rotating any credentials suspected to be exposed.

### False positive analysis

- A repository admin temporarily disables Secret Scanning during a planned maintenance or configuration test to address noisy detections or performance issues, then re-enables it, generating a benign disable event.
- Organization-managed templates or automation enforce a settings baseline that disables Secret Scanning for non-code or ephemeral repos (e.g., mirrors, docs, or test sandboxes), causing the event as part of expected governance.

### Response and remediation

- Immediately re-enable Secret Scanning and Push Protection on the affected repository, lock the default branch with "Require pull request reviews" and "Restrict who can push," and temporarily pause GitHub Actions workflows that access repo or org secrets.
- Revert or rewrite commits made while scanning was disabled to remove credentials from files like .env, config.yml, and .github/workflows/*.yml, and delete build artifacts and caches that may contain sensitive values.
- Revoke and rotate exposed credentials by disabling compromised PATs, rotating cloud API keys and service tokens, and updating organization and repository secrets in Settings > Secrets and variables.
- Validate recovery by confirming Secret Scanning and Push Protection are enabled in repository settings, re-running a full secret scan across HEAD, tags, and protected branches, and restoring merges and deployments only after clean results.
- Escalate to incident response if the actor is unknown or unauthorized, if plaintext secrets appear in commits or workflow logs, or if external authentications use repo-linked credentials within 24 hours of the disable event.
- Harden by enforcing org-wide policies requiring Secret Scanning and Push Protection for all repositories, adding repository rulesets to require status checks and pull request reviews before merging, and limiting Actions token permissions with protected environments and branch protections.
"""
references = [
    "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
    "https://trigger.dev/blog/shai-hulud-postmortem",
    "https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem",
]
risk_score = 21
rule_id = "21c3536f-b674-43db-9bfc-dcf4cf9dcc37"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
configuration where data_stream.dataset == "github.audit" and event.type == "change" and event.action == "repository_secret_scanning.disable"
'''

[[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]
description = """
Detects when a hidden process is executed, and initiates an outbound network connection. Threat actors may drop hidden
payloads that will later be used to download additional payload stages or tools.
"""
id = "04ec0ec4-86c4-47e3-8c7b-8dad5f97532c"
license = "Elastic License v2"
name = "Hidden Process Execution followed by Network Connection"
os_list = ["linux"]
version = "1.0.8"

query = '''
sequence by process.entity_id with maxspan=30s
  [process where event.type == "start" and event.action == "exec" and
   process.executable like ("/tmp/.*", "/var/tmp/.*", "/dev/shm/.*") and
   not process.executable like ("/tmp/.ryeinstall*", "/tmp/.sentry*")]
  [network where event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and
   process.name like ".*"]
'''

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

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

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


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


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Detects when the find command is used to search for files followed by the creation or modification of text files,
indicating potential automated collection of sensitive information. This technique is commonly observed in npm
typosquatting attacks and information stealers where adversaries use find to locate specific files and then aggregate
the results into text files for staging before exfiltration. The find command with file type filters allows attackers to
efficiently enumerate and collect target files across the filesystem.
"""
id = "406b2b26-bfaa-4a20-9551-cc4a95635a9e"
license = "Elastic License v2"
name = "Information Stealer Collection via Find"
os_list = ["macos"]
reference = ["https://socket.dev/blog/10-npm-typosquatted-packages-deploy-credential-harvester"]
version = "1.0.4"

query = '''
sequence by process.entity_id with maxspan=10s
  [process where event.type == "start" and event.action == "exec" and process.name == "find" and
    process.args like "/Users/*/Library/Application Support/*" and process.args == "-type" and process.args == "f"]
  [file where file.extension == "txt" and Effective_process.executable != "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint"]
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1074"
name = "Data Staged"
reference = "https://attack.mitre.org/techniques/T1074/"
[[threat.technique.subtechnique]]
id = "T1074.001"
name = "Local Data Staging"
reference = "https://attack.mitre.org/techniques/T1074/001/"


[[threat.technique]]
id = "T1119"
name = "Automated Collection"
reference = "https://attack.mitre.org/techniques/T1119/"


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

[internal]
min_endpoint_version = "8.16.0"

[metadata]
creation_date = "2025/06/17"
integration = ["endpoint", "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/24"

[rule]
author = ["Elastic"]
description = """
The kubeconfig file is a critical component in Kubernetes environments, containing configuration
details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to,
create or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or
move laterally within the cluster.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-cloud_defend.file*"]
language = "eql"
license = "Elastic License v2"
name = "Kubeconfig File Creation or 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 Kubeconfig File Creation or Modification
Kubeconfig files are essential in Kubernetes environments, storing configurations for cluster access and management. Adversaries may target these files to gain unauthorized access or move laterally within clusters. The detection rule identifies suspicious creation or modification of kubeconfig files, excluding legitimate processes like kubeadm and minikube, to flag potential threats and mitigate risks associated with unauthorized access.

### Possible investigation steps

- Review the alert details to identify the specific file path involved in the creation or modification event, focusing on paths like "/root/.kube/config" or "/etc/kubernetes/admin.conf".
- Examine the process responsible for the file creation or modification, ensuring it is not one of the excluded legitimate processes such as "kubeadm", "kubelet", "vcluster", or "minikube".
- Check the user account associated with the process to determine if it has legitimate access to modify kubeconfig files and assess if the activity aligns with typical user behavior.
- Investigate the timing of the event to see if it coincides with any scheduled maintenance or deployment activities that could explain the modification.
- Look for any related alerts or logs that might indicate lateral movement or unauthorized access attempts within the Kubernetes cluster.
- Assess the network activity from the host where the modification occurred to identify any suspicious connections or data transfers that could suggest unauthorized access or exfiltration.

### False positive analysis

- Legitimate administrative tools like kubeadm, kubelet, vcluster, and minikube may create or modify kubeconfig files as part of normal operations. Ensure these processes are excluded from triggering alerts by maintaining the exclusion list in the detection rule.
- Automated scripts or configuration management tools that use sed to modify kubeconfig files might be flagged. Consider adding specific script names or paths to the exclusion list if they are verified as non-threatening.
- User-initiated changes to kubeconfig files for legitimate access or configuration updates can trigger alerts. Implement a process to verify and document such changes, allowing for quick exclusion of known user actions.
- Regular updates or maintenance activities that involve kubeconfig file modifications should be documented and excluded from detection. Coordinate with the operations team to identify and whitelist these activities.
- Development environments where frequent kubeconfig changes occur, such as in testing or staging, may generate false positives. Establish a separate monitoring policy for these environments to reduce noise while maintaining security oversight.

### Response and remediation

- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the Kubernetes cluster.
- Revoke any potentially compromised credentials associated with the kubeconfig files and issue new credentials to ensure secure access.
- Conduct a thorough review of recent access logs and audit trails to identify any unauthorized access or suspicious activity related to the kubeconfig files.
- Restore the kubeconfig files from a known good backup to ensure the integrity of the configuration and access settings.
- Implement additional monitoring and alerting for any future modifications to kubeconfig files, focusing on processes not typically involved in legitimate changes.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader Kubernetes environment.
- Review and update Kubernetes access policies to ensure they align with best practices for security and least privilege, reducing the risk of unauthorized access.
"""
references = [
    "https://kubernetes-threat-matrix.redguard.ch/initial-access/kubeconfig-file/",
    "https://kubenomicon.com/Initial_access/Kubeconfig_file.html",
    ]
risk_score = 47
rule_id = "b11116fd-023c-4718-aeb8-fa9d283fc53b"
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",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Tactic: Defense Evasion",
    "Tactic: Initial Access",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Defend for Containers",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type != "deletion" and file.path like (
  "/root/.kube/config",
  "/home/*/.kube/config",
  "/etc/kubernetes/admin.conf",
  "/etc/kubernetes/super-admin.conf",
  "/etc/kubernetes/kubelet.conf",
  "/etc/kubernetes/controller-manager.conf",
  "/etc/kubernetes/scheduler.conf",
  "/var/lib/*/kubeconfig"
) and not (
  process.name in ("kubeadm", "kubelet", "vcluster", "minikube", "kind") or
  (process.name == "sed" and ?file.Ext.original.name like "sed*") or
  process.executable like (
    "/usr/local/bin/k3d", "/usr/local/aws-cli/*/dist/aws", "/usr/local/bin/ks", "/usr/local/bin/aws",
    "/usr/local/bin/kubectl"
  )
)
'''

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

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

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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic", "Austin Songer"]
description = """
Identifies suspicious files being written by the Microsoft Exchange Server Unified Messaging (UM) service. This activity
has been observed exploiting CVE-2021-26858.
"""
false_positives = [
    """
    Files generated during installation will generate a lot of noise, so the rule should only be enabled after the fact.
    """,
    """
    This rule was tuned using the following baseline:
    https://raw.githubusercontent.com/microsoft/CSS-Exchange/main/Security/Baselines/baseline_15.2.792.5.csv from
    Microsoft. Depending on version, consult https://github.com/microsoft/CSS-Exchange/tree/main/Security/Baselines to
    help determine normalcy.
    """,
]
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 = "Microsoft Exchange Server UM Writing Suspicious Files"
note = """## Triage and analysis

Positive hits can be checked against the established Microsoft [baselines](https://github.com/microsoft/CSS-Exchange/tree/main/Security/Baselines).

Microsoft highly recommends that the best course of action is patching, but this may not protect already compromised systems
from existing intrusions. Other tools for detecting and mitigating can be found within their Exchange support
[repository](https://github.com/microsoft/CSS-Exchange/tree/main/Security)
"""

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

references = [
    "https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers",
    "https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities",
]
risk_score = 47
rule_id = "6cd1779c-560f-4b68-a8f1-11009b27fe63"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Endgame",
    "Use Case: Vulnerability",
    "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 = '''
file where host.os.type == "windows" and event.type == "creation" and
  process.name : ("UMWorkerProcess.exe", "umservice.exe") and
  file.extension : ("php", "jsp", "js", "aspx", "asmx", "asax", "cfm", "shtml") and
  (
    file.path : "?:\\inetpub\\wwwroot\\aspnet_client\\*" or

    (file.path : "?:\\*\\Microsoft\\Exchange Server*\\FrontEnd\\HttpProxy\\owa\\auth\\*" and
       not (file.path : "?:\\*\\Microsoft\\Exchange Server*\\FrontEnd\\HttpProxy\\owa\\auth\\version\\*" or
            file.name : ("errorFE.aspx", "expiredpassword.aspx", "frowny.aspx", "GetIdToken.htm", "logoff.aspx",
                        "logon.aspx", "OutlookCN.aspx", "RedirSuiteServiceProxy.aspx", "signout.aspx"))) or

    (file.path : "?:\\*\\Microsoft\\Exchange Server*\\FrontEnd\\HttpProxy\\ecp\\auth\\*" and
       not file.name : "TimeoutLogoff.aspx")
  )
'''


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

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

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

[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 = "T1505"
name = "Server Software Component"
reference = "https://attack.mitre.org/techniques/T1505/"

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

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

[metadata]
creation_date = "2020/08/17"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system"]
maturity = "production"
updated_date = "2026/05/03"

[rule]
author = ["Elastic"]
description = """
Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity
level of SYSTEM.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Persistence via Update Orchestrator Service Hijack"
references = ["https://github.com/irsl/CVE-2020-1313"]
risk_score = 73
rule_id = "265db8f5-fc73-4d0d-b434-6483b56372e2"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Use Case: Vulnerability",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: Windows Security Event Logs",
    "Data Source: SentinelOne",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and
  process.parent.args : "UsoSvc" and
  not process.executable :
          ("?:\\ProgramData\\Microsoft\\Windows\\UUS\\Packages\\*\\amd64\\MoUsoCoreWorker.exe",
          "?:\\Windows\\System32\\UsoClient.exe",
          "?:\\Windows\\System32\\MusNotification.exe",
          "?:\\Windows\\System32\\MusNotificationUx.exe",
          "?:\\Windows\\System32\\MusNotifyIcon.exe",
          "?:\\Windows\\System32\\WerFault.exe",
          "?:\\Windows\\System32\\WerMgr.exe",
          "?:\\Windows\\UUS\\amd64\\MoUsoCoreWorker.exe",
          "?:\\Windows\\System32\\MoUsoCoreWorker.exe",
          "?:\\Windows\\UUS\\amd64\\UsoCoreWorker.exe",
          "?:\\Windows\\System32\\UsoCoreWorker.exe",
          "?:\\Program Files\\Common Files\\microsoft shared\\ClickToRun\\OfficeC2RClient.exe") and
  not process.name : ("MoUsoCoreWorker.exe", "OfficeC2RClient.exe")
'''

note = """## Triage and analysis

### Investigating Persistence via Update Orchestrator Service Hijack

#### Possible investigation steps

- What did UsoSvc actually launch, and does the child identity fit Windows or Office servicing?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
  - Hint: use `process.parent.command_line` to confirm svchost is hosting UsoSvc, not just sharing the name.
  - Implication: escalate when UsoSvc launches a renamed, user-writable, unsigned, rare, or non-servicing child; lower concern only when path, signer, and parent service context match a recognized Windows Update or Click-to-Run component. Identity alone does not clear it.

- Does the command line show attacker-controlled work running with service-level privilege?
  - Why: on unpatched hosts, CVE-2020-1313 ScheduleWork can queue signed System32 or Common Files binaries with attacker-controlled arguments.
  - Focus: `process.command_line`, `process.Ext.token.integrity_level_name`, and `user.id`.
  - Implication: escalate when "cmd.exe", "rundll32.exe", "regsvr32.exe", a scripting host, or another signed binary runs shell, download, staging, redirection, or persistence arguments under SYSTEM or high integrity; lower concern when arguments fit the exact servicing binary workflow.

- If registry telemetry is available, was matching work queued under the Update Orchestrator UScheduler path?
  - Focus: same `host.id` registry events for `registry.path` under "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\WindowsUpdate\\Orchestrator\\UScheduler", with `registry.value`, `registry.data.strings`, and writer `process.executable`.
  - Range: search several days before the alert; queued work can run overnight or after a multi-day service window.
  - Hint: interpret queued strings with `registry.data.type`, then compare them to `process.command_line` and `process.executable`; missing registry telemetry is unresolved, not benign.
  - Implication: escalate when the queue names the same unusual child or arguments, especially from a non-servicing writer; absent queue history only limits this corroborator.

- Did the child stage artifacts or spawn follow-on processes that extend the abuse?
  - Focus: child starts from `process.entity_id`; if file telemetry exists, same-process `file.path`, `file.Ext.original.path`, and `file.origin_url`.
    - $investigate_0
    - $investigate_1
  - Hint: scope file pivots with `host.id` plus `process.entity_id`; use `host.id` plus `process.pid` and a tight alert window only when entity ID is absent. Missing file telemetry limits artifact review, but child-process and command evidence can justify escalation.
  - Implication: escalate when the child writes executable or scriptable content to user-writable or deceptive paths, renames staged content, or launches written artifacts; lower concern when activity stays inside the recognized servicing path with no follow-on execution.

- If network telemetry is available, does the child contact destinations consistent with servicing?
  - Focus: process-scoped DNS `dns.question.name` and `dns.resolved_ip`, then connections by `destination.ip`, `destination.port`, and `destination.as.organization.name`. $investigate_2
  - Hint: use "lookup_result" DNS events for populated `dns.resolved_ip`; scope with `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` and a tight alert window. Infrastructure ownership is context, not a verdict; missing network telemetry is unresolved, not benign.
  - Implication: escalate when the child reaches rare or public infrastructure unrelated to Microsoft servicing, the signer, or recovered queue; lower concern when destinations fit the signed binary's normal update or repair endpoints.

- If local evidence remains suspicious or unresolved, do related alerts change scope?
  - Focus: compare recent alerts for the same `process.executable`. $investigate_3
  - Hint: review same `host.id` alerts only when child identity, command, queue, artifact, or destination evidence needs scope. $investigate_4
  - Implication: broaden scope when the same child path or host shows repeated privilege-escalation, persistence, staging, or follow-on alerts; keep urgency local when isolated and no corroborating alert history appears.

- Escalate on attacker-controlled UsoSvc child identity or command intent, using queue, artifact, destination, or related-alert evidence as corroboration; close only when alert-local and recovered evidence tie to one exact servicing or authorized validation workflow without contradictions; preserve artifacts and escalate when evidence is mixed, incomplete, or unavailable.

### False positive analysis

- Windows Update, repair, or Office Click-to-Run servicing can trigger this rule when UsoSvc queues a servicing component outside the exclusions. Close from telemetry first: child path, signer, command line, parent service context, UScheduler queue content when available, artifacts, destinations, and `host.id` cohort must align with one recognized servicing workflow. Patch-window or change records may corroborate; prior alerts only prove exception stability after current evidence fits.
- Authorized exploit-validation or adversary-emulation tests can exercise Update Orchestrator abuse. Confirm stable payload identity such as `process.hash.sha256`, `process.command_line`, expected `host.id` or `user.id` test scope, matching queue content when available, and no spread to unrelated production hosts. Use engagement records or prior test alerts only as corroboration, and do not exception on `process.parent.executable`, "UsoSvc", or `process.name` alone.

### Response and remediation

- If confirmed benign:
  - Record the exact evidence that proved the servicing or test workflow: child identity, command line, parent service context, queue content when available, same-process artifacts or destinations, and recurrence or records. Then reverse temporary containment and build any exception from that minimum pattern plus `host.id`, not from UsoSvc or a generic signed-binary condition.
- If suspicious but unconfirmed:
  - Preserve a case export with the alert process instance, process tree, command line, UScheduler queue values when available, writer-process details, written artifacts, destination indicators, and related-alert context before cleanup.
  - Apply reversible containment tied to the finding, such as blocking the child hash or destination, temporarily disabling the queued work after preservation, or increasing host monitoring. Escalate to host isolation only when host criticality allows it and artifacts, destinations, or related alerts show active follow-on behavior.
- If confirmed malicious:
  - Preserve the case export first: child `process.entity_id` or `process.pid`, command line, queue values, writer lineage, payload hashes, artifact paths, and destination indicators. Then isolate the host when the identity, command, queue, artifact, or destination evidence confirms unauthorized UsoSvc execution.
  - Remove the malicious queued work or restore the Update Orchestrator registry state to known-good, eradicate only payloads and persistence artifacts identified during triage, validate that UsoSvc returns to recognized servicing children, and review other hosts for the same child path or queue pattern before deleting preserved evidence.
- Post-incident hardening:
  - Apply the June 2020 or later Windows security updates where still applicable because the fix blocks untrusted caller queuing, retire unsupported builds, restrict write paths that can feed Update Orchestrator abuse, and retain registry/process telemetry for UScheduler queue changes.
"""

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)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.pid",
    "process.executable",
    "process.command_line",
    "process.args",
    "process.hash.sha256",
    "process.pe.original_file_name",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
    "process.Ext.token.integrity_level_name",
    "process.parent.executable",
    "process.parent.command_line",
]

[transform]

[[transform.investigate]]
label = "Child process starts from the launched child"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { 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" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "File events for the launched child"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", 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 = "event.category", queryType = "phrase", value = "file", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Network events for the launched child"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", 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 = "event.category", queryType = "phrase", value = "network", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts involving the same child executable"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "process.executable", queryType = "phrase", value = "{{process.executable}}", 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 = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

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

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

[[rule.threat.technique.subtechnique]]
id = "T1574.011"
name = "Services Registry Permissions Weakness"
reference = "https://attack.mitre.org/techniques/T1574/011/"

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

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

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

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

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

[metadata]
creation_date = "2023/12/11"
maturity = "production"
updated_date = "2025/01/15"

[rule]
author = ["Elastic"]
description = """
Detects potential buffer overflow attacks by querying the "Segfault Detected" pre-built rule signal index, through a
threshold rule, with a minimum number of 100 segfault alerts in a short timespan. A large amount of segfaults in a short
time interval could indicate application exploitation attempts.
"""
from = "now-9m"
index = [".alerts-security.*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential Buffer Overflow Attack Detected"
risk_score = 21
rule_id = "b7c05aaf-78c2-4558-b069-87fa25973489"
setup = """## Setup


This rule leverages alert data from other prebuilt detection rules to function correctly.

### Dependent Elastic Detection Rule Enablement
As a higher-order rule (based on other detections), this rule also requires the following prerequisite Elastic detection rule to be installed and enabled:
- Segfault Detected (5c81fc9d-1eae-437f-ba07-268472967013)
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Initial Access",
    "Use Case: Vulnerability",
    "Rule Type: Higher-Order Rule",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.type:linux and event.kind:signal
'''
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 Buffer Overflow Attack Detected

Buffer overflow attacks exploit vulnerabilities in software to execute arbitrary code, often leading to privilege escalation. Adversaries may trigger numerous segmentation faults (segfaults) on Linux systems as they attempt to exploit these vulnerabilities. The detection rule identifies potential attacks by monitoring for a surge in segfault alerts, indicating possible exploitation attempts, and correlates them with known threat tactics.

### Possible investigation steps

- Review the alert details to confirm the presence of a surge in segfault alerts, focusing on the host.os.type:linux field to ensure the affected systems are Linux-based.
- Correlate the timestamps of the segfault alerts to identify any patterns or specific timeframes when the surge occurred, which might indicate the start of an exploitation attempt.
- Investigate the affected host(s) by examining system logs and application logs around the time of the segfault alerts to identify any suspicious activities or anomalies.
- Check for any recent changes or updates to the software running on the affected host(s) that might have introduced vulnerabilities.
- Look for any known vulnerabilities or exploits associated with the software or services running on the affected host(s) that could be targeted by a buffer overflow attack.
- Assess the network traffic to and from the affected host(s) during the time of the alerts to identify any unusual or unauthorized connections that could indicate an attack vector.
- Consult threat intelligence sources to determine if there are any ongoing campaigns or known threat actors targeting similar vulnerabilities or systems.

### False positive analysis

- High-volume legitimate application crashes can trigger false positives, especially during software testing or development phases. Users should identify and exclude these applications from the rule by creating exceptions for specific processes known to cause frequent segfaults without malicious intent.
- System updates or patches may cause temporary spikes in segfault alerts as applications restart or reconfigure. Users can mitigate this by setting a temporary exception during scheduled maintenance windows.
- Custom scripts or automated tasks that interact with system memory in non-standard ways might generate segfaults. Review these scripts and, if verified as safe, exclude them from the rule to prevent false alerts.
- Certain security tools or monitoring software may intentionally cause segfaults as part of their operation. Identify these tools and add them to the exception list to avoid unnecessary alerts.
- Legacy applications with known stability issues might frequently cause segfaults. Consider updating or replacing these applications, or create exceptions if updates are not feasible.

### Response and remediation

- Isolate the affected Linux host immediately to prevent further exploitation and lateral movement within the network.
- Terminate any suspicious processes identified on the affected host that are associated with the segfault alerts to halt potential malicious activity.
- Conduct a thorough analysis of the affected application or service to identify and patch the specific vulnerability being exploited, ensuring all software is updated to the latest secure versions.
- Review and enhance system and application logging to capture detailed information on segfault occurrences and related activities for future analysis and detection.
- Implement additional security controls such as application whitelisting and memory protection mechanisms (e.g., DEP, ASLR) to mitigate the risk of buffer overflow attacks.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Document the incident, including all actions taken and findings, to improve future response efforts and update incident response plans accordingly."""


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


[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[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.threshold]
field = ["event.kind", "host.id"]
value = 100

[rule]
description = """
Identifies an unelevated attempt to create a BLF file using the Common Log File System (CLFS) API. This may indicate an
attempt to exploit a CLFS vulnerability for privilege escalation.
"""
id = "4fd4edfd-3bb4-4eac-82f2-8d4ebcbed0f3"
license = "Elastic License v2"
name = "Potential Common Log File System Exploit"
os_list = ["windows"]
reference = [
    "https://securelist.com/windows-clfs-exploits-ransomware/111560/",
    "https://www.elastic.co/security-labs/itw-windows-lpe-0days-insights-and-detection-strategies",
]
version = "1.0.3"

query = '''
file where event.action != "deletion" and user.id != "S-1-5-18" and user.id != null and process.pid != 4 and
  _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: ("*clfsw32.dll!CreateLogFile*", "*clfsw32.dll!AddLogContainerSet*"))
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"


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

[internal]
min_endpoint_version = "8.7.0"

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

[rule]
author = ["Elastic"]
description = """
This rule detects potential direct Kubelet access via process arguments. An adversary may need to access the
Kubelet API to gain access to the Kubernetes API server or other resources within the cluster. These requests
are often used to enumerate or execute commands on the Kubernetes API server or other resources within the
cluster, and may indicate an attempt to move laterally within the cluster.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Potential Direct Kubelet Access via Process Arguments Detected via Defend for Containers"
note = """ ## Triage and analysis

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

### Investigating Potential Direct Kubelet Access via Process Arguments Detected via Defend for Containers

This detection flags an interactive process started inside a Linux container that includes an HTTP request targeting the Kubelet API on port 10250, a common pivot point for gaining execution and visibility across nodes. Attackers use direct Kubelet access to enumerate pods, fetch logs, or run commands that can lead to broader cluster access and lateral movement. A typical pattern is invoking curl or wget from a container shell against `https://<node-ip>:10250/` endpoints to probe or execute actions.

### Possible investigation steps

- Identify the originating pod/workload and container image for the interactive session, then determine whether the container was expected to provide diagnostic tooling or shell access and whether it recently changed.  
- Extract the full command line and reconstruct the requested Kubelet endpoint path (for example `/pods`, `/exec`, `/run`, `/logs`) to infer intent (enumeration vs remote execution) and capture any embedded tokens or client cert usage.  
- Correlate the process start time with Kubernetes audit logs and API server events to see if there were concurrent pod exec/attach, secret reads, or workload modifications suggesting follow-on activity.  
- Verify whether the destination node IP/hostname is the local node or a remote node and review network flow logs/egress policies to confirm the container could reach port 10250 and whether other nodes were contacted.  
- Check node and Kubelet configuration for exposure and auth bypass risk (anonymous auth, webhook mode, client certs), and inspect Kubelet logs around the timestamp for the corresponding request and response status codes.

### False positive analysis

- A cluster operator or SRE opens an interactive shell in a troubleshooting container and manually curls `https://<node-ip>:10250/` (or `/pods`/`/metrics`) to validate Kubelet reachability, authentication behavior, or node health during incident triage.
- A legitimate in-container diagnostic workflow uses an interactive session to probe the local node’s Kubelet port 10250 for environment verification (e.g., confirming node IP mapping or TLS/cert configuration), embedding the URL in process arguments without any intent to enumerate or execute actions across the cluster.

### Response and remediation

- Isolate the affected pod by removing service exposure and applying a temporary egress deny rule to block traffic to node port 10250 from that namespace/pod label, then terminate the interactive shell session and restart the workload from a known-good image.  
- Capture and preserve the full command line, container filesystem changes, and relevant Kubelet and Kubernetes audit log entries around the timestamp, then hunt for additional in-cluster attempts to reach `https://<node>:10250/` from other pods or namespaces.  
- Rotate any credentials that may have been exposed or used (service account tokens, client certificates, kubeconfig files) and revoke or redeploy affected service accounts, then validate no unauthorized `exec/attach`, secret reads, or workload changes occurred after the access attempt.  
- Escalate to the platform security/on-call incident commander immediately if the Kubelet request targeted sensitive endpoints like `/exec`, `/run`, `/containerLogs`, or returned successful responses (2xx/3xx) or if similar commands are seen across multiple nodes.  
- Harden by enforcing Kubelet authentication/authorization (disable anonymous access, require webhook authz, restrict client cert issuance), and implement network controls that prevent pods from reaching node Kubelet ports except from approved node-local agents.  
- Reduce recurrence by removing shell and HTTP tooling from application images, limiting interactive access (disable `kubectl exec` for non-admins), and tightening RBAC and admission policies to block privileged pods/host networking that increase node API reachability.
"""
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 = "b4bd186b-69c6-45ad-8bef-5c35bbadeaef"
severity = "high"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.args like ("http*:10250*", "http*:10255*", "wss:*:10250*", "wss:*:10255*") and container.id like "?*"
'''

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

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

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

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

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

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

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

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