Elastic rules: 0j

[rule]
description = """
Detects when an abnormally large amount of JavaScript is supplied to Node.js for execution via the evaluate flag. This
behavior has been observed in DPRK-attributed malware campaigns.
"""
id = "76259650-ed25-4d48-9cb2-e4a32073f945"
license = "Elastic License v2"
name = "Abnormally Large Javascript Evaluation via Nodejs"
os_list = ["macos"]
reference = ["https://kl4r10n.tech/blog/dprk-new-malware"]
version = "1.0.1"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "node" and process.args == "node" and
 process.args == "-e" and process.args_count == 3 and process.command_line == null and process.parent.name == "node"
'''

min_endpoint_version = "8.10.2"
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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



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

[internal]
min_endpoint_version = "8.10.2"

[metadata]
creation_date = "2025/12/15"
maturity = "production"
updated_date = "2026/02/16"

[rule]
author = ["Elastic"]
description = """
This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving 
the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely 
to be related to a compromise.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Alerts From Multiple Integrations by Destination Address"
risk_score = 73
rule_id = "08933236-b27a-49f6-b04a-a616983f04b9"
severity = "high"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from .alerts-security.*

// any alerts excluding low severity, threat_match and machine_learning rules 
| where kibana.alert.rule.name is not null and destination.ip is not null and kibana.alert.risk_score > 21 and not kibana.alert.rule.type in ("threat_match", "machine_learning") and
        not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)

// group alerts by destination.ip and extract values of interest for alert triage
| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
        Esql.event_module_values = VALUES(event.module),
        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.message_values = VALUES(message),
        Esql.event_category_values = VALUES(event.category),
        Esql.event_action_values = VALUES(event.action),
        Esql.source_ip_values = VALUES(source.ip),
        Esql.host_id_values = VALUES(host.id),
        Esql.agent_id_values = VALUES(agent.id),
        Esql.user_name_values = VALUES(user.name),
        Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by destination.ip

// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels or presence of high severity alerts
| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99)
| keep destination.ip, Esql.*
'''
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 Alerts From Multiple Integrations by Destination Address

The detection rule uses alert data to determine when multiple alerts from different integrations involving the same destination.ip are triggered.

### Possible investigation steps

- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.

### False positive analysis

- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance.
- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.

### Response and remediation

- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""

[rule]
description = """
Identifies attempts to modify the permissions or write to Microsoft Anti Malware Scan Interface or Windows Lock Down
Policy related DLLs from memory. This may indicate an attempt to tamper with certain Windows native protections.
"""
id = "586bf106-b208-45fc-9401-727664175ca0"
license = "Elastic License v2"
name = "AMSI or WLDP Bypass via Memory Patching"
os_list = ["windows"]
reference = [
    "https://aidenpearce369.github.io/offsec/AMSI-Memory-Bypass/",
    "https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell/blob/master/README.md#Patch-the-providers-DLL-of-Microsoft-MpOav.dll",
    "https://modexp.wordpress.com/2019/06/03/disable-amsi-wldp-dotnet/",
    "https://www.elastic.co/security-labs/doubling-down-etw-callstacks",
]
version = "1.0.30"

query = '''
api where

 ((process.Ext.api.name in ("VirtualProtect", "VirtualProtectEx") and process.Ext.api.parameters.protection like "?W*") or
  process.Ext.api.name == "WriteProcessMemory") and

 process.Ext.api.summary : ("* amsi.dll*", "* mpoav.dll*", "* wldp.dll*") and 
 process.executable != null and process.parent.executable != null and process.thread.Ext.call_stack_summary : "?*" and
 not process.thread.Ext.call_stack_final_user_module.name in ("Kernel", "Unknown") and
 (
  process.thread.Ext.call_stack_summary like
                    ("ntdll.dll|kernelbase.dll|Unbacked",
                     "ntdll.dll|kernelbase.dll|Unknown",
                     "ntdll.dll|kernelbase.dll|kernel32.dll|Unbacked",
                     "ntdll.dll|wow64.dll|wow64cpu.dll|wow64.dll|ntdll.dll|kernelbase.dll|Unbacked",
                     "ntdll.dll|wow64.dll|wow64cpu.dll|wow64.dll|ntdll.dll|kernelbase.dll|Unbacked|kernel32.dll|ntdll.dll", 
                     "ntdll.dll|kernelbase.dll|*|_ctypes.pyd|python*.dll|Unknown|kernel32.dll|ntdll.dll",
                     "ntdll.dll|*|vbe?.dll|*",
                     "ntdll.dll|Unknown") or

  endswith~(process.thread.Ext.call_stack_summary, concat("ntdll.dll|kernelbase.dll|Unbacked|", process.name)) or

  endswith~(process.thread.Ext.call_stack_summary, concat(concat("ntdll.dll|kernelbase.dll|Unbacked|", process.name), "|kernel32.dll|ntdll.dll"))
 ) and
 not (process.code_signature.subject_name in
              ("TPZ SOLUCOES DIGITAIS LTDA", "NedGraphics Software B.V.", "Gerber Technology LLC", "Rocscience Inc.", 
               "Wilcom International Pty Limited", "Code Systems Corporation", "Wilcom Pty Ltd", "Galooli Ltd",
               "MECH-MIND ROBOTICS TECHNOLOGIES LTD.", "COJALI SL") and
      process.code_signature.trusted == true) and
 not process.parent.executable : "?:\\Program Files\\PC SOFT\\WINDEV*\\Programmes\\windev64local.exe" and 
 not process.executable : ("?:\\Program Files\\GRAPHISOFT\\ArchiCAD ??\\ArchiCAD.exe", 
                           "?:\\Program Files\\nQueue\\iAPrintManager\\iAPrintManager.exe", 
                           "?:\\Program Files\\PC SOFT\\WINDEV*\\Programmes\\windev64local.exe", 
                           "?:\\Program Files\\PC SOFT\\WINDEV*\\Programmes\\windev64local.exe",
                           "?:\\Program Files\\Sophos\\Endpoint Defense\\SSPService.exe") and
 not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.subject_name in ("Bitdefender SRL", "Parallels International GmbH") and $entry.status == "trusted") and
 not process.thread.Ext.call_stack_final_user_module.path like
                                                            ("c:\\windows\\sys?????\\apphelp.dll",
                                                             "c:\\windows\\syswow64\\esensordbi.dll",
                                                             "c:\\program files\\bitdefender\\endpoint security\\bdhkm\\*\\bdhkm64.dll",
                                                             "c:\\program files (x86)\\internet explorer\\ieshims.dll") and
 not _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info like ("c:\\windows\\sys?????\\ntdll.dll!LdrLoadDll*", "c:\\windows\\sys?????\\kernelbase.dll!LoadLibrary*"))
'''

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

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



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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2022/09/21"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Xavier Pich"]
description = """
Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a
KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to
critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations,
impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated
data, any modification to their lifecycle should be considered highly sensitive and investigated promptly.
"""
false_positives = [
    """
    A customer managed KMS key may be disabled or scheduled for deletion by a system administrator. Verify whether the
    user identity, user agent, and/or hostname should be making changes in your environment. Key deletions by unfamiliar
    users should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion"
note = """## Triage and analysis

### Investigating AWS KMS Customer Managed Key Disabled or Scheduled for Deletion

AWS KMS keys underpin encryption for S3, EBS, RDS, Secrets Manager, Lambda, and numerous other AWS services. Disabling a KMS key or scheduling its deletion immediately disrupts encryption and decryption workflows, and, once deleted, renders all data encrypted with that key unrecoverable.

Because these operations are rare, highly privileged, and tightly controlled in mature environments, they should be treated as high-risk, destructive actions when performed unexpectedly. Adversaries may disable or delete KMS keys to sabotage recovery, impede forensic analysis, or destroy evidence after exfiltration.


#### Possible investigation steps

- **Identify the actor and authentication context**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the caller.
  - Check `source.ip`, `source.geo` fields, and `user_agent.original` to determine whether the action originated from an expected network path or automation platform.
  - Compare the actor and access key to historical usage patterns.

- **Determine what key was affected and its criticality**
  - Inspect `aws.cloudtrail.resources.arn` to identify the KMS key.
  - Determine:
    - The services and data protected by the key (e.g., RDS, EBS, S3, Secrets Manager).
    - The environment (prod vs. dev).
    - Owner or application team.

- **Understand the scope and intent of the change**
  - For `DisableKey`, determine whether a dependent service immediately began failing or experienced decryption errors.
  - For `ScheduleKeyDeletion`, examine the `PendingWindowInDays` value within `aws.cloudtrail.request_parameters`.
  - Check whether the key was previously rotated, enabled/disabled, or had its policy recently modified.

- **Correlate with surrounding events**
  - Look for:
    - IAM policy changes granting new KMS privileges.
    - Access anomalies involving the same principal.
    - File system, database, or backup deletions near the same timeframe.
    - S3, EBS, or RDS resources showing encryption failures.
  - Determine whether other keys were modified in the same window (possible broader sabotage attempt).

- **Validate intent with owners**
  - Confirm with the application, data, or security owners:
    - Whether deactivation or scheduled deletion was requested.
    - Whether the key was being replaced, migrated, or retired.

### False positive analysis

- **Planned key lifecycle activities**
  - Some organizations disable KMS keys before rotation, migration, or decommissioning.
  - Scheduled deletion during infrastructure teardown may be expected in CI/CD-driven ephemeral environments.

- **Configuration errors**
  - Misapplied tags or incorrect CloudFormation teardown workflows can unintentionally disable or schedule deletion of KMS keys.

If any of the above conditions apply, consider adjusting rule exceptions based on IAM principal, environment tag, or automation role.

### Response and remediation

- **Contain and validate**
  - Immediately confirm whether the key disablement or deletion schedule was intentional.
  - If unauthorized, cancel scheduled deletion (`CancelKeyDeletion`) and re-enable the key (`EnableKey`) as appropriate.
  - Rotate credentials or access keys used by the actor if compromise is suspected.

- **Assess impact**
  - Identify all AWS services and data encrypted with the affected KMS key.
  - Review logs and service metrics for failures involving:
    - EBS volume attachments
    - RDS instance decryption
    - S3 object access
    - Secrets Manager retrieval
    - Lambda environment variable decryption

- **Investigate for compromise**
  - Review CloudTrail activity for the principal:
    - Permission escalations
    - Unusual STS role assumptions
    - S3, EC2, RDS destructive behavior
  - Look for preceding data access or exfiltration attempts.

- **Strengthen controls**
  - Restrict AWS KMS lifecycle permissions (`kms:DisableKey`, `kms:ScheduleKeyDeletion`) to a very small privileged set.
  - Use AWS Organizations SCPs to prevent KMS key deletion in production accounts.
  - Enable AWS Config rules for KMS key state monitoring.
  - Require MFA for administrators capable of key management.

- **Post-incident improvement**
  - Update runbooks to include KMS lifecycle change approvals.
  - Implement tagging standards to designate high-risk keys.
  - Enhance monitoring for key policy modifications or changes to principal permissions.

### Additional information
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/cli/latest/reference/kms/disable-key.html",
    "https://docs.aws.amazon.com/cli/latest/reference/kms/schedule-key-deletion.html",
]
risk_score = 47
rule_id = "6951f15e-533c-4a60-8014-a3c3ab851a1b"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS KMS",
    "Tactic: Impact",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "kms.amazonaws.com" 
    and event.action: ("DisableKey" or "ScheduleKeyDeletion") 
    and event.outcome: "success"
    and not user_agent.original: (*Terraform* or *Pulumi*)
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1485.001"
name = "Lifecycle-Triggered Deletion"
reference = "https://attack.mitre.org/techniques/T1485/001/"

[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"
[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",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies the execution of a binary by root in Linux shared memory directories: (/dev/shm/, /run/shm/, /var/run/,
/var/lock/). This activity is to be considered highly abnormal and should be investigated. Threat actors have placed
executables used for persistence on high-uptime servers in these directories as system backdoors.
"""
false_positives = [
    """
    Directories /dev/shm and /run/shm are temporary file storage directories in Linux. They are intended to appear as a
    mounted file system, but uses virtual memory instead of a persistent storage device and thus are used for mounting
    file systems in legitimate purposes.
    """,
]
from = "now-9m"
index = ["endgame-*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Binary Executed from Shared Memory Directory"
references = [
    "https://linuxsecurity.com/features/fileless-malware-on-linux",
    "https://twitter.com/GossiTheDog/status/1522964028284411907",
    "https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor",
]
risk_score = 73
rule_id = "3f3f9fe2-d095-11ec-95dc-f661ea17fbce"
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 = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Threat: BPFDoor",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and
user.id == "0" and process.executable like ("/dev/shm/*", "/run/shm/*", "/var/run/*", "/var/lock/*") and
not (
  process.executable : (
    "/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*",
    "/var/run/argo/argoexec", "/dev/shm/*.*/sandfly"
  ) or
  process.parent.command_line == "/usr/bin/runc init"
)
'''
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 Binary Executed from Shared Memory Directory

Shared memory directories in Linux, such as /dev/shm and /run/shm, are designed for efficient inter-process communication. However, adversaries exploit these directories to execute binaries stealthily, often as root, bypassing traditional security measures. The detection rule identifies such anomalies by monitoring for root-executed binaries in these directories, excluding known legitimate processes, thus flagging potential backdoor activities.

### Possible investigation steps

- Review the process executable path to confirm it resides in a shared memory directory such as /dev/shm, /run/shm, /var/run, or /var/lock, and verify it is not part of the known exclusions like /var/run/docker or /var/run/utsns.
- Investigate the parent process of the suspicious executable to understand the context of its execution, focusing on the command line used, especially if it does not match the exclusion pattern /usr/bin/runc init.
- Check the process's creation time and correlate it with any other suspicious activities or alerts around the same timeframe to identify potential patterns or related incidents.
- Analyze the binary file in question for any known malicious signatures or unusual characteristics using tools like file integrity checkers or antivirus solutions.
- Review system logs and audit logs for any unauthorized access or privilege escalation attempts that might have led to the execution of the binary as root.
- Investigate the user account activity associated with user.id "0" to ensure there are no signs of compromise or misuse of root privileges.
- If possible, isolate the affected system to prevent further potential malicious activity while the investigation is ongoing.

### False positive analysis

- Docker-related processes can trigger false positives when binaries are executed from shared memory directories. To mitigate this, exclude paths like /var/run/docker/* from the detection rule.
- Processes related to container orchestration tools such as Kubernetes might also cause false positives. Exclude paths like /var/run/utsns/* and /var/run/s6/* to prevent these.
- Cloudera services may execute binaries from shared memory directories as part of their normal operations. Exclude /var/run/cloudera-scm-agent/* to avoid false alerts.
- Argo workflows might execute binaries in these directories. Exclude /var/run/argo/argoexec to reduce false positives.
- Legitimate use of /usr/bin/runc init as a parent process can be excluded to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the threat actor.
- Terminate any suspicious processes running from the shared memory directories (/dev/shm, /run/shm, /var/run, /var/lock) to halt potential malicious activity.
- Conduct a thorough review of the system's process tree and logs to identify any additional malicious binaries or scripts that may have been executed or are scheduled to run.
- Remove any unauthorized binaries or scripts found in the shared memory directories and other critical system paths to eliminate persistence mechanisms.
- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation.
- Implement enhanced monitoring and alerting for any future execution of binaries from shared memory directories, ensuring that legitimate processes are whitelisted appropriately.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects when the tc (transmission control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network
interface. Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic.
A threat actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic.
This technique is not at all common and should indicate abnormal, suspicious or malicious activity.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "BPF filter applied using TC"
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 BPF filter applied using TC

BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.

### Possible investigation steps

- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive.
- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`.
- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior.
- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity.
- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat.
- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context.

### False positive analysis

- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule.
- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities.
- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule.
- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary.
- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application.
- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses.
- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist.
- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters."""
references = [
    "https://github.com/h3xduck/TripleCross/blob/master/src/helpers/deployer.sh",
    "https://man7.org/linux/man-pages/man8/tc.8.html",
]
risk_score = 73
rule_id = "ef04a476-07ec-48fc-8f3d-5e1742de76d3"
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 = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Threat: TripleCross",
    "Data Source: Auditd Manager",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.executable == "/usr/sbin/tc" and process.args == "filter" and process.args == "add" and process.args == "bpf" and
not ?process.parent.executable == "/usr/sbin/libvirtd"
'''

[[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 = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

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

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

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

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the image load of a compression DLL. Adversaries will often compress and encrypt data in preparation for
exfiltration.
"""
from = "now-119m"
index = ["logs-endpoint.events.library-*"]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Compression DLL Loaded by Unusual Process"
risk_score = 21
rule_id = "d197478e-39f0-4347-a22f-ba654718b148"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Collection",
    "Data Source: Elastic Defend",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
library where host.os.type == "windows" and event.action == "load" and
  dll.name : ("System.IO.Compression.FileSystem.ni.dll", "System.IO.Compression.ni.dll") and
  not 
  (
    (
      process.executable : (
        "?:\\Program Files\\*",
        "?:\\Program Files (x86)\\*",
        "?:\\Windows\\Microsoft.NET\\Framework*\\mscorsvw.exe",
        "?:\\Windows\\System32\\sdiagnhost.exe",
        "?:\\Windows\\System32\\inetsrv\\w3wp.exe",
        "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe",
        "?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\DataCollection\\*\\OpenHandleCollector.exe"
      ) and process.code_signature.trusted == true
    ) or
    (
      process.name : "NuGet.exe" and process.code_signature.trusted == true and user.id : ("S-1-5-18", "S-1-5-20")
    )
  )
'''


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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects file creation events in the plugin directories for the Yum package manager. In Linux, DNF (Dandified YUM) is a
command-line utility used for handling packages on Fedora-based systems, providing functions for installing, updating,
upgrading, and removing software along with managing package repositories. Attackers can backdoor DNF to gain
persistence by injecting malicious code into plugins that DNF runs, thereby ensuring continued unauthorized access or
control each time DNF is used for package management.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
language = "eql"
license = "Elastic License v2"
name = "DNF Package Manager Plugin File Creation"
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 DNF Package Manager Plugin File Creation

DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities.

### Possible investigation steps

- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*".
- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria.
- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx".
- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior.
- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates.
- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise.
- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat.

### False positive analysis

- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule.
- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list.
- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria.
- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives.
- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes.
- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager.
- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots.
- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker.
- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms.
- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation."""
references = [
    "https://pwnshift.github.io/2020/10/01/persistence.html",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 21
rule_id = "3fe4e20c-a600-4a86-9d98-3ecb1ef23550"
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 = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "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 ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*") and not (
  process.executable in (
    "/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", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/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/lib/snapd/snapd", "/usr/local/bin/dockerd",
    "/usr/libexec/netplan/generate", "./usr/bin/podman", "/usr/bin/dnf5", "/bin/needs-restarting",
    "/usr/bin/crio", "/usr/bin/insights-client", "/kaniko/executor"
  ) or
  file.extension in ("swp", "swpx", "swx") or
  process.executable : (
    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*",
    "/etc/kernel/*"
  ) or
  process.executable == null or
  (process.name == "sed" and file.name : "sed*") or
  (process.name == "perl" and file.name : "e2scrub_all.tmp*") or
  file.path like~ "/etc/dnf/plugins/.ansible_tmp*" or
  process.name like~ ("ssm-agent-worker, NinjaOrbit", "python*")
)
'''

[[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]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

[[rule.threat.technique.subtechnique]]
id = "T1546.016"
name = "Installer Packages"
reference = "https://attack.mitre.org/techniques/T1546/016/"

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

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

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

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

[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 = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

[[rule.threat.technique.subtechnique]]
id = "T1546.016"
name = "Installer Packages"
reference = "https://attack.mitre.org/techniques/T1546/016/"

[[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 = "2025/11/18"
integration = ["endpoint", "panw", "fortinet_fortigate", "suricata"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto
Networks (PANW) and Fortinet Fortigate by host.ip and source.ip. This may indicate that this host is compromised and
triggering multi-datasource alerts.
"""
from = "now-60m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "Elastic Defend and Network Security Alerts Correlation"
risk_score = 73
rule_id = "0bca7e73-e1b5-4fb2-801b-9b5f5be20dfe"
setup = """## Setup

This rule requires the `host.ip` field to be populated.
For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.

If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).
"""
severity = "high"
tags = [
    "Use Case: Threat Detection",
    "Rule Type: Higher-Order Rule",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Fortinet",
    "Data Source: PAN-OS"
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-* metadata _id
| WHERE
        // Elastic Defend Alerts
        (event.module == "endpoint" and data_stream.dataset == "endpoint.alerts") or

        // PANW suspicious events
        (data_stream.dataset == "panw.panos" and
         event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", "spyware_detected", "large_upload", "denied", "exploit_detected")) or

        // Fortigate suspicious events
        (data_stream.dataset == "fortinet_fortigate.log" and
         (event.action in ("outbreak-prevention", "infected", "blocked") or message like "backdoor*" or message like "Proxy*" or message like "anomaly*" or message like "P2P*" or message like "misc*" or message like "DNS.Over.HTTPS" or message like "Remote.Access")) or

        // Suricata
        (data_stream.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", "A Network Trojan was detected", "Detection of a Network Scan", "Domain Observed Used for C2 Detected", "Malware Command and Control Activity Detected"))

// extract source.ip from PANW or Fortigate events and host.ip from Elastic Defend alert
|eval fw_alert_source_ip = CASE(data_stream.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
      elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", host.ip, null)
| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
| where Esql.source_ip is not null

// group by host_source_ip shared between FG/PANW and Elastic Defend
| stats Esql.alerts_count = COUNT(*),
        Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.message_values_distinct_count = COUNT_DISTINCT(message),
        Esql.event_module_values = VALUES(event.module),
        Esql.message_values = VALUES(message),
        Esql.event_action_values = VALUES(event.action),
        Esql.process_executable_values = VALUES(process.executable),
        Esql.process_hash_sha256_values = VALUES(process.hash.sha256),
        Esql.process_cmdline_values = VALUES(process.command_line),
        Esql.file_path_values = VALUES(file.path),
        Esql.file_hash_sha256_values = VALUES(file.hash.sha256),
        Esql.host_id_values = VALUES(host.id),
        Esql.user_name_values = VALUES(user.name),
        Esql.destination_ip_values = VALUES(destination.ip)
        by Esql.source_ip
| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2
| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",")
// Make sure an endpoint alert is present along one of the network ones
| where concat_module_values like "*endpoint*"

// Move single values to their corresponding ECS fields for alerts exclusion
| eval source.ip = mv_min(Esql.source_ip),
       host.id = mv_min(Esql.host_id_values),
       user.name = mv_min(Esql.user_name_values)

| keep source.ip, host.id, user.name, Esql.*
'''
note = """## Triage and analysis

### Investigating Elastic Defend and Network Security Alerts Correlation

This rule correlate any Elastic Defend alert with suspicious events from Network Security datasources like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip.

### Possible investigation steps

- Review the alert details to identify the specific host and users involved.
- Investiguate the network alerts by destination.ip and message.
- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.

### False positive analysis

- IP address ranges overlap where the host.ip value from the Elastic Defend alert is unrelated to the source.ip value from the Network Security alert.
- Alerts from routine administrative tasks may trigger multiple alerts. Review and exclude known benign activities such as scheduled software updates or system maintenance.
- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise.
- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening.
- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score.
- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities.

### Response and remediation

- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""

[rule]
description = """
Identifies when Python spawns the native Osascript binary to execute a Javascript payload. An adversary may use this
technique to execute their malicious payload and obtain initial access to an endpoint.
"""
id = "36536aab-671a-4f3f-aad2-8d113bedec8a"
license = "Elastic License v2"
name = "Execution of JavaScript Payload via Python"
os_list = ["macos"]
reference = ["https://github.com/MythicAgents/medusa"]
version = "1.0.10"

query = '''
process where event.action == "exec" and process.name == "osascript" and
 process.parent.name like~ "python*" and
 process.args == "-l" and process.args : "JavaScript*" and
 not process.command_line == "osascript -l JavaScript -e ObjC.import('Foundation'); ObjC.unwrap($.NSUserDefaults.alloc.initWithSuiteName('ManagedInstalls').objectForKey('ManagedInstallDir'))" and
 not process.Ext.effective_parent.executable in ("/usr/local/jamf/bin/jamf",
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon", 
                                                 "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService")
'''

min_endpoint_version = "8.5.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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



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

[internal]
min_endpoint_version = "8.5.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a service account is disabled in Google Cloud Platform (GCP). A service account is a special type of
account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to
make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users
through domain-wide delegation. An adversary may disable a service account in order to disrupt to disrupt their target's
business operations.
"""
false_positives = [
    """
    Service accounts may be disabled by system administrators. Verify that the behavior was expected. Exceptions can be
    added to this rule to filter expected behavior.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Service Account 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 GCP Service Account Disabled

In Google Cloud Platform, service accounts are crucial for applications and VMs to perform authorized actions without user intervention. Adversaries may disable these accounts to disrupt services, impacting business operations. The detection rule identifies successful disablement actions in audit logs, signaling potential malicious activity by correlating specific event actions and outcomes, thus enabling timely investigation and response.

### Possible investigation steps

- Review the audit logs for the specific event.action:google.iam.admin.v*.DisableServiceAccount to identify the exact time and source of the disablement action.
- Identify the user or service account that performed the disablement by examining the actor information in the audit logs.
- Check for any recent changes or unusual activities associated with the disabled service account, such as modifications to permissions or roles.
- Investigate any related events or actions in the audit logs around the same timeframe to identify potential patterns or additional suspicious activities.
- Assess the impact of the disabled service account on business operations by determining which applications or services were using the account.
- Contact relevant stakeholders or application owners to verify if the disablement was authorized or if it was an unexpected action.

### False positive analysis

- Routine maintenance activities by administrators may involve disabling service accounts temporarily. To manage this, create exceptions for known maintenance periods or specific administrator actions.
- Automated scripts or tools used for testing or deployment might disable service accounts as part of their process. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
- Organizational policy changes or restructuring might lead to intentional service account disablement. Document these changes and update the detection rule to recognize these legitimate actions.
- Service accounts associated with deprecated or retired applications may be disabled as part of cleanup efforts. Maintain an updated list of such applications and exclude related disablement actions from alerts.

### Response and remediation

- Immediately isolate the affected service account by revoking its permissions to prevent further unauthorized actions.
- Review the audit logs to identify any other suspicious activities associated with the disabled service account and assess the potential impact on business operations.
- Re-enable the service account if it is determined to be legitimate and necessary for business functions, ensuring that it is secured with appropriate permissions and monitoring.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Implement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly.
- Conduct a root cause analysis to understand how the service account was disabled and address any security gaps or misconfigurations that allowed the incident to occur.
- Consider implementing additional security measures such as multi-factor authentication and least privilege access to enhance the protection of service accounts.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/iam/docs/service-accounts"]
risk_score = 47
rule_id = "bca7d28e-4a48-47b1-adb7-5074310e9a61"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DisableServiceAccount and event.outcome:success
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1531"
name = "Account Access Removal"
reference = "https://attack.mitre.org/techniques/T1531/"


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

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

[rule]
author = ["Elastic"]
description = """
Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns,
including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and
common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these
patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check
ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is
passed to exec.
"""
false_positives = [
    """
    Security training, CTF-style images, or vendor diagnostics may include bash redirection or /dev/tcp examples.
    Baseline approved images then expand exclusions as needed.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Pod Exec Potential Reverse Shell"
note = """## Triage and analysis

### Investigating GKE Pod Exec Potential Reverse Shell

This alert fires when a successful pods/exec API call includes a command matching reverse/bind-shell idioms.
Review `gcp.audit.labels.command.gke.io/command` for the reconstructed payload.

### Possible investigation steps

- Identify the actor (`client.user.email`), source IP, and user agent (human kubectl vs automation).
- Resolve the target namespace and pod from `gcp.audit.resource_name` and correlate with workload ownership.
- Hunt nearby events from the same identity: secret reads, pods/exec to other workloads, RoleBinding changes.
- Do not replay the command against live infrastructure unless policy explicitly allows a sandboxed recreation.

### False positive analysis

- Security training or CTF images may include reverse-shell examples; scope exceptions to those namespaces/images.
- Some observability or mesh sidecars use socat or sockets in overlapping ways; validate image and command lineage.

### Response and remediation

- If malicious, terminate the exec session, isolate the workload or node, rotate credentials reachable from the pod,
  and revoke pods/exec for the abused principal unless strictly required.
"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://attack.mitre.org/techniques/T1609/",
    "https://attack.mitre.org/techniques/T1059/",
]
risk_score = 73
rule_id = "b5974c88-d584-451c-8ce3-6b19d7456199"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: GCP Audit Logs",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.type:start and
event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
gcp.audit.labels.command.gke.io/command:(
  (
    */dev/tcp/* or */dev/udp/* or */inet/tcp/* or
    *0\\\>&1* or
    *IO*Socket*INET* or *TCPSocket.new* or *bash*-i* or *fsockopen* or
    *import*pty* or *import*socket* or *mkfifo* or
    *nc*-c* or *nc*-e* or *netcat*-e* or
    *socat*exec* or *socat*pty* or *socket.socket* or
    *zsh/net/tcp* or *zsh/net/udp*
  ) and not (
    *127.0.0.1* or *localhost*
  )
)
'''

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

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

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

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

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

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "event.type",
    "gcp.audit.labels.command.gke.io/command",
    "gcp.audit.resource_name",
    "data_stream.namespace",
]

[metadata]
creation_date = "2022/09/06"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/27"

[rule]
author = ["Elastic"]
description = """
Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable
BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid
account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device
management.
"""
false_positives = [
    """
    Administrators may temporarily disabled Bitlocker on managed devices for maintenance, testing or to resolve
    potential endpoint conflicts.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Bitlocker Setting Disabled"
note = """## Triage and analysis

### Investigating Google Workspace Bitlocker Setting Disabled

BitLocker Drive Encryption is a data protection feature that integrates with the Windows operating system to address the data theft or exposure threats from lost, stolen, or inappropriately decommissioned computers. BitLocker helps mitigate unauthorized data access by enhancing file and system protections, such as data encryption and rendering data inaccessible. Google Workspace can sync with Windows endpoints that are registered in inventory, where BitLocker can be enabled and disabled.

Disabling Bitlocker on an endpoint decrypts data at rest and makes it accessible, which raises the risk of exposing sensitive endpoint data.

This rule identifies a user with administrative privileges and access to the admin console, disabling BitLocker for Windows endpoints.

### Possible investigation steps

- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert.
- Review `google_workspace.admin.org_unit.name`, `google_workspace.admin.setting.name`, and `google_workspace.admin.old_value` / `new_value` to confirm BitLocker was disabled and for which OU.
- After identifying the user, verify if the user should have administrative privileges to disable BitLocker on Windows endpoints.
- Review Admin and Device logs, filtering on the user email identified from the alert.
- Confirm the policy change under `Devices` (Windows device management) or the relevant Chrome/Windows endpoint settings area for the affected OU.

### False positive analysis

- An administrator may have intentionally disabled BitLocker for routine maintenance or endpoint updates.
   - Verify with the user that they intended to disable BitLocker on Windows endpoints.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/9176657?hl=en",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
]
risk_score = 47
rule_id = "7caa8e60-2df0-11ed-b814-f661ea17fbce"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING"
    and google_workspace.admin.new_value:"Disabled" and google_workspace.admin.setting.name:BitLocker*
'''

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

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

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

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

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

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

[metadata]
creation_date = "2026/01/07"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/02"

[rule]
author = ["Elastic"]
description = """
This rule monitors for the usage of the most common audio recording utilities on unix systems by an uncommon process parent.
Adversaries may collect audio data from users or systems for a variety of reasons including espionage, credential theft, or reconnaissance.
"""
from = "now-9m"
index = [
          "logs-endpoint.events.process*",
          "logs-sentinel_one_cloud_funnel.*",
          "endgame-*",
        ]
language = "kuery"
license = "Elastic License v2"
name = "Linux Audio Recording Activity Detected"
note = """ ## Triage and analysis

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

### Investigating Linux Audio Recording Activity Detected

This rule flags executions of Linux audio-recording tools (arecord, parec, pw-record, ecasound, pw-cat -r, ffmpeg) started by uncommon parent processes, signaling potential covert microphone capture. Attackers often drop a systemd service or cron job that silently invokes arecord or ffmpeg to record from default PulseAudio/PipeWire devices and stash WAV/MP3 files under user directories or stream them to a remote host. Capturing ambient audio can reveal passwords, meeting content, and sensitive conversations, aiding reconnaissance and espionage.

### Possible investigation steps

- Examine the full process tree and session context (parent/grandparent, controlling TTY, logged-in user) to determine whether launch came from an expected desktop workflow versus non-interactive origins like cron, systemd, or ssh.
- Parse the command line to identify input device and output target, then hunt for created artifacts (WAV/MP3/OGG) under common stash paths (~/.cache, ~/.local/share, /tmp, /var/tmp, hidden directories) and verify timestamps and owner.
- If the command indicates streaming or piping, inspect recent outbound network connections and DNS from the process/user for RTMP/HTTP/SFTP endpoints and correlate with firewall or EDR flow logs to detect exfiltration.
- Check for persistence mechanisms that could re-invoke the recorder, including systemd user/system units and timers, cron/anacron entries, and shell scripts in autostart paths, and disable or quarantine any suspicious items.
- Review audio subsystem and device access evidence (audit logs for open/read on /dev/snd/* and PipeWire/PulseAudio logs showing record nodes) to confirm capture and identify the device and scope.

### False positive analysis

- ffmpeg is executed with -i to read an existing media file for transcode or audio extraction, not to capture from a microphone, which satisfies the rule conditions but is routine multimedia processing.
- A legitimate systemd or cron job starts arecord/parec/pw-record/pw-cat -r to periodically sample audio for device diagnostics or content creation, resulting in an uncommon parent process yet expected outputs under user or application directories.

### Response and remediation

- Immediately terminate arecord, parec, pw-record, ecasound, pw-cat -r, or ffmpeg processes launched by cron/systemd/ssh and stop any associated systemd units/timers, then block outbound RTMP/HTTP/SFTP connections from the recording user.
- Disable and remove persistence that invokes recording, including systemd .service/.timer files under /etc/systemd/system or ~/.config/systemd/user, cron entries in /etc/cron.* or user crontabs, and autostart scripts in ~/.config/autostart or /etc/xdg/autostart, and quarantine any unknown executables or wrappers in /tmp, /var/tmp, or hidden user directories that spawn these tools.
- Before cleanup, preserve the full command line and copies of recorded artifacts (WAV/MP3/OGG) located in ~/.cache, ~/.local/share, /tmp, /var/tmp, and hidden directories, then remove remaining audio files and staging folders after evidence collection.
- Verify recovery by confirming no active record nodes in PipeWire/PulseAudio and no further opens on /dev/snd/*, and restart affected user sessions or hosts if audio subsystem settings were altered.
- Harden by restricting access to /dev/snd/* via udev group membership and AppArmor/SELinux, whitelisting approved desktop apps, and adding detections to flag non-interactive parents launching arecord/ffmpeg or pw-cat -r and creation of large audio files in cache/temp paths.
- Escalate to incident response and privacy/legal if recording is initiated by a root-owned systemd service or an unknown binary in /tmp, or if audio streaming/exfiltration to external IPs/domains is observed.
"""
risk_score = 21
rule_id = "3ee526ce-1f26-45dd-9358-c23100d1121f"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Collection",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:process and host.os.type:"linux" and event.type:"start" and event.action:("exec" or "exec_event" or "start") and (
  process.name:("arecord" or "parec" or "pw-record" or "ecasound") or
  (process.name:"pw-cat" and process.args:"-r") or
  (process.name:"ffmpeg" and process.args:"-i")
) and
not process.args:("-h" or "--help" or "--version")
'''

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

[[rule.threat.technique]]
id = "T1123"
name = "Audio Capture"
reference = "https://attack.mitre.org/techniques/T1123/"

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

[rule.new_terms]
field = "new_terms_fields"
value = ["host.id", "process.parent.executable"]

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

[rule]
description = """
Identifies the creation or modification of a Launch agent or daemon property list file that masquerades as legitimate
software such as Apple or Microsoft Plist filename but performed by an untrusted or unsigned macho executable.
"""
id = "3da48cdd-262a-42a9-af2f-c82ef639b9e3"
license = "Elastic License v2"
name = "Persistence via a Masqueraded Plist Filename"
os_list = ["macos"]
reference = [
    "https://www.virustotal.com/gui/file/68438dcb296b4aeada2be505d4907c9f6066ceb40737a99d36e35d81a8a08235",
]
version = "1.0.26"

query = '''
file where event.type != "deletion" and 
file.name like~ 
      ("*com.apple*.plist",
       "*com.microsoft*.plist", 
       "*com.google*.plist", 
       "*com.adobe*.plist", 
       "*com.java*.plist", 
       "*com.mozilla*.plist",
       "*com.dropbox*.plist") and
  file.path like
       ("/System/Library/LaunchAgents/*", 
        "/Library/LaunchAgents/*",
        "/Users/*/Library/LaunchAgents/*",
        "/System/Library/LaunchDaemons/*",
        "/Library/LaunchDaemons/*") and
(process.code_signature.trusted == false or process.code_signature.exists == false)
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"
[[threat.technique.subtechnique]]
id = "T1543.001"
name = "Launch Agent"
reference = "https://attack.mitre.org/techniques/T1543/001/"


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


[threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[threat.technique.subtechnique]]
id = "T1036.005"
name = "Match Legitimate Resource Name or Location"
reference = "https://attack.mitre.org/techniques/T1036/005/"


[[threat.technique]]
id = "T1647"
name = "Plist File Modification"
reference = "https://attack.mitre.org/techniques/T1647/"


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

[internal]
min_endpoint_version = "8.11.0"