Elastic rules: 2q

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

[rule]
author = ["Elastic"]
description = """
Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or
CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows
however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it
off-account for exfiltration of data.
"""
false_positives = [
    """
    VM export and EC2 image creation may be done by system administrators, DevOps or migration teams as part of planned
    maintenance, disaster-recovery or known backup methods. Verify whether the user identity, user agent, and/or
    hostname should be making changes in your environment. Exports from unfamiliar users or hosts 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 EC2 Export Task"
note = """## Triage and analysis

### Investigating AWS EC2 Export Task

The APIs `CreateInstanceExportTask`, `ExportImage`, and `CreateStoreImageTask` allow the export of a running or stopped EC2 instance (or its AMI/image) to external storage (e.g., S3) or image formats. While often used for migration, cloning or backup, adversaries can leverage these actions to copy full VM state or images out of the environment for exfiltration.

#### Possible investigation steps

**Identify the actor and context**  
   - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id` to identify who made the call.  
   - Verify `user_agent.original`, `source.ip` and `@timestamp` to determine whether the action is by known automation, trusted operator, or an unexpected identity or location.  
   - Confirm `cloud.account.id` and `cloud.region` match the expected account/region for export tasks.

**Examine the specific export/image task details**  
   - Review `aws.cloudtrail.request_parameters` for details such as the `InstanceId`, `TargetEnvironment`, `S3Bucket`, `S3Key`, `DiskImageFormat`, `ContainerFormat`. 
   - Check `aws.cloudtrail.response_elements` for the resulting export task ID and status.  
   - Determine whether the exported instance or image contained sensitive workloads (e.g., production databases, critical systems) via instance tags or asset inventory.

**Pivot to related API calls/events**  
   - Look for follow-on tasks such as:  
     - S3 bucket writes or cross-account bucket ACL changes (`PutBucketAcl`/`PutBucketPolicy`) referencing the export S3 bucket or key.  
     - `CopyImage`, `ModifyImageAttribute`, or `ShareImage` events if the exported image is copied or shared.  
     - Network or usage anomalies in the region or from the S3 bucket (large downloads from the exported object).  
   - Check for preceding suspicious actions that could indicate compromise: `AssumeRole`, `CreateAccessKey`, `AttachUserPolicy`, or unusual `Describe*` operations.

**Assess legitimacy and risk**  
   - Confirm whether this export was authorized (via change ticket or migration workflow) and whether the principal has a documented justification for VM export.  
   - If unauthorized, assess what was exported, where it is stored, how it may be transferred or used externally, and the data risk exposure.

### False positive analysis

- Legitimate migration or backup workflows may trigger these export/image APIs.  
- Development/test environments may export VM images or instances for sandbox cloning.  
- Known automation tools may create exports at scheduled times.  

### Response and remediation

- Immediately identify and disable or isolate any object/resource created by the export (e.g., the S3 bucket/object, image ID) that is suspected of unauthorized use.  
- Revoke the access credentials (`aws.cloudtrail.user_identity.access_key_id`) used if they show unusual activity.  
- Rotate keys, enforce MFA, and review IAM permissions for the principal.  
- Audit the exported VM/image: review its contents if possible, check whether it has been moved off-account.  
- Strengthen monitoring: set alerts for subsequent large data transfers from the S3 export location, cross-account sharing of exported images, or anomalous AMI imports.  
- Update policy: restrict who can perform exports, monitor export actions via AWS Config or CloudTrail, tag and track export tasks and their destinations.
"""
references = [
    "https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html",
    "https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport_image.html",
    "https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.html,",
]
risk_score = 47
rule_id = "deee5856-25ba-438d-ae53-09d66f41b127"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS EC2",
    "Use Case: Asset Visibility",
    "Tactic: Exfiltration",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail" and 
    event.provider: "ec2.amazonaws.com" and 
    event.action: ("CreateInstanceExportTask" or "ExportImage" or "CreateStoreImageTask") and 
    event.outcome: "success"
'''


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

[[rule.threat.technique]]
id = "T1537"
name = "Transfer Data to Cloud Account"
reference = "https://attack.mitre.org/techniques/T1537/"

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

[[rule.threat.technique.subtechnique]]
id = "T1567.002"
name = "Exfiltration to Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1567/002/"

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

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

[[rule.threat.technique]]
id = "T1005"
name = "Data from Local System"
reference = "https://attack.mitre.org/techniques/T1005/"

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

[[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",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements"
]

[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2025/03/21"

[rule]
author = ["Elastic"]
description = """
Elastic Endgame detected Credential Manipulation. Click the Elastic Endgame icon in the event.module column or the link
in the rule.reference column for additional information.
"""
from = "now-2m"
index = ["endgame-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Credential Manipulation - Detected - Elastic Endgame"
risk_score = 73
rule_id = "c0be5f31-e180-48ed-aa08-96b36899d48f"
setup = """## Setup

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "high"
tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event)
'''
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 Credential Manipulation - Detected - Elastic Endgame

Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential manipulation, which adversaries exploit to escalate privileges by altering access tokens. This detection rule identifies such threats by analyzing alerts for token manipulation events, leveraging its high-risk score and severity to prioritize investigation. The rule aligns with MITRE ATT&CK's framework, focusing on privilege escalation tactics.

### Possible investigation steps

- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to Elastic Endgame's detection capabilities.
- Examine the event.action and endgame.event_subtype_full fields for token_manipulation_event to understand the specific type of credential manipulation detected.
- Check the associated user account and system involved in the alert to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
- Investigate the timeline of events leading up to and following the token manipulation event to identify any additional suspicious activities or patterns.
- Correlate the alert with other security events or logs to assess if this incident is part of a broader attack or isolated.
- Evaluate the risk score and severity to prioritize the response and determine if immediate action is required to mitigate potential threats.

### False positive analysis

- Routine administrative tasks involving token manipulation can trigger alerts. Review the context of the event to determine if it aligns with expected administrative behavior.
- Automated scripts or software updates that require token changes might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for operations.
- Security tools or monitoring solutions that interact with access tokens for legitimate purposes may cause false positives. Ensure these tools are recognized and excluded from triggering alerts.
- User behavior analytics might misinterpret legitimate user actions as suspicious. Regularly update user profiles and behavior baselines to minimize these occurrences.
- Scheduled maintenance activities that involve access token modifications should be documented and excluded from detection rules during their execution time.

### Response and remediation

- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network.
- Revoke and reset any compromised credentials or access tokens identified in the alert to prevent further misuse.
- Conduct a thorough review of recent access logs and token usage to identify any unauthorized access or actions taken by the adversary.
- Apply security patches and updates to the affected system and any related systems to close vulnerabilities that may have been exploited.
- Implement enhanced monitoring on the affected system and related accounts to detect any further suspicious activity or attempts at credential manipulation.
- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, and escalate to higher management if the threat level increases.
- Review and update access control policies and token management practices to prevent similar incidents in the future, ensuring that least privilege principles are enforced."""


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


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

[rule]
description = """
Identifies a list of LDAP search queries to enumerate domain policies and trusts. Adversaries attempt to enumerate
information on the Active Directory structure by using various LDAP-based discovery queries to identify targets for
attack.
"""
id = "9c928393-2aeb-4143-8ed6-c9704c094f76"
license = "Elastic License v2"
name = "Domain Trust and Schema Enumeration via LDAP"
os_list = ["windows"]
reference = ["https://attack.mitre.org/techniques/T1482/"]
version = "1.0.3"

query = '''
api where process.Ext.api.name == "ldap_search" and not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and
 not process.executable :
             ("?:\\Program Files\\Azure Advanced Threat Protection Sensor\\*\\Microsoft.Tri.Sensor.exe",
              "?:\\Windows\\System32\\lsass.exe",
              "?:\\Windows\\ADWS\\Microsoft.ActiveDirectory.WebServices.exe",
              "?:\\Windows\\ADFS\\Microsoft.IdentityServer.ServiceHost.exe", 
              "?:\\Program Files\\Fortinet\\FortiAuthenticator Agent\\FAC_Agent.Configuration.exe") and
 (
  (process.Ext.api.parameters.search_filter : "(objectclass=trusteddomain)" and process.Ext.api.parameters.distinguished_name like "dc=*") or

  (process.Ext.api.parameters.search_filter : "(schemaIDGUID=?)" and process.Ext.api.parameters.distinguished_name like "cn=schema,cn=configuration,dc=*")
  ) and 
  not (process.code_signature.subject_name == "Fortinet, Inc." and process.code_signature.trusted == true)
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"
[[threat.technique.subtechnique]]
id = "T1069.002"
name = "Domain Groups"
reference = "https://attack.mitre.org/techniques/T1069/002/"


[[threat.technique]]
id = "T1087"
name = "Account Discovery"
reference = "https://attack.mitre.org/techniques/T1087/"
[[threat.technique.subtechnique]]
id = "T1087.002"
name = "Domain Account"
reference = "https://attack.mitre.org/techniques/T1087/002/"


[[threat.technique]]
id = "T1482"
name = "Domain Trust Discovery"
reference = "https://attack.mitre.org/techniques/T1482/"


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

[internal]
min_endpoint_version = "9.1.0"

[rule]
description = """
Identifies unlevated attempt to create a BLF file using the Common Log File System (CLFS) API followed by spawning a
child process with System privileges. This may indicate a successful CLFS vulnerability exploitation for privilege
escalation.
"""
id = "54cff348-106e-42bf-bf94-ce8e3ed68440"
license = "Elastic License v2"
name = "Elevation via Common Log File System Exploitation"
os_list = ["windows"]
reference = ["https://securelist.com/windows-clfs-exploits-ransomware/111560/"]
version = "1.0.2"

query = '''
sequence with maxspan=2m
 [file where event.action != "deletion" and not user.id : "S-1-5-18" and user.id != null and 
  _arraysearch(process.thread.Ext.call_stack, $entry, 
               $entry.symbol_info: ("*clfsw32.dll!CreateLogFile*", "*clfsw32.dll!AddLogContainerSet*"))] by process.entity_id
 [process where event.action == "start" and user.id : "S-1-5-18"] by process.parent.entity_id
'''

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

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

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

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

[rule]
description = """
Detects when a executable file is accessed or modified by Osascript on macOS. This activity should be considered
malicious or highly suspicious and is indicative of initial access or tool ingress.
"""
id = "cb3fe671-de31-41f4-bf71-3a39b024fd0e"
license = "Elastic License v2"
name = "Executable File Access or Modification via Osascript"
os_list = ["macos"]
version = "1.0.8"

query = '''
file where event.action != "deletion" and 
 file.Ext.header_bytes like~ ("cffaedfe*", "cafebabe*") and
 process.name == "osascript"
'''

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

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



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


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

[internal]
min_endpoint_version = "8.10.2"

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

[rule]
author = ["Elastic"]
description = """
Detects the first time a Python process accesses sensitive credential files on a given host. This behavior may indicate
post-exploitation credential theft via a malicious Python script, compromised dependency, or malicious model file
deserialization. Legitimate Python processes do not typically access credential files such as SSH keys, AWS credentials,
browser cookies, Kerberos tickets, or keychain databases, so a first occurrence is a strong indicator of compromise.
"""
from = "now-9m"
index = ["logs-endpoint.events.file-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Time Python Accessed Sensitive Credential Files"
note = """## Triage and analysis

### Investigating First Time Python Accessed Sensitive Credential Files

Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — often target sensitive credential files such as SSH keys, cloud provider credentials, browser session cookies, and macOS keychain data. Since legitimate Python processes do not typically access these files, a first occurrence from a Python process is highly suspicious.

This rule leverages the Elastic Defend sensitive file `open` event, which is only collected for known sensitive file paths, combined with the New Terms rule type to alert on the first time a specific credential file is accessed by Python on a given host within a 7-day window.

### Possible investigation steps

- Examine the Python process command line and arguments to identify the script or command that triggered the file access.
- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency.
- Review the specific credential file that was accessed and assess the potential impact (SSH keys enable lateral movement, AWS credentials enable cloud access, browser cookies enable session hijacking).
- Check for outbound network connections from the same process tree that may indicate credential exfiltration.
- Investigate the origin of any recently downloaded scripts, packages, or model files on the host.
- Look for file creation events in `/tmp/` or other staging directories that may contain copies of the stolen credentials.

### False positive analysis

- Python-based secret management tools (e.g., `aws-cli`, `gcloud`) legitimately access credential files. Consider excluding known trusted executables by process path.
- SSH automation scripts using `paramiko` or `fabric` may read SSH keys. Evaluate whether the access pattern matches known automation workflows.
- Security scanning tools running Python may enumerate credential files as part of their assessment.

### Response and remediation

- Immediately rotate any credentials that were potentially accessed (SSH keys, AWS access keys, cloud tokens).
- Quarantine the Python process and investigate the source script, package, or model file that triggered the access.
- If a malicious file is confirmed, identify all hosts where it may have been distributed.
- Review outbound network connections from the host around the time of the credential access to check for exfiltration.
- Consider implementing `weights_only=True` enforcement for PyTorch model loading across the environment.
"""
references = [
    "https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/",
    "https://github.com/trailofbits/fickling",
]
risk_score = 47
rule_id = "03b150d9-9280-4eb8-9906-38cfb6184666"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
    "Domain: LLM",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:file and host.os.type:macos and event.action:open and
process.name:python*
'''

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

[[rule.threat.technique]]
id = "T1539"
name = "Steal Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1539/"

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

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

[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"

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

[[rule.threat.technique]]
id = "T1558"
name = "Steal or Forge Kerberos Tickets"
reference = "https://attack.mitre.org/techniques/T1558/"

[[rule.threat.technique.subtechnique]]
id = "T1558.005"
name = "Ccache Files"
reference = "https://attack.mitre.org/techniques/T1558/005/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[rule.new_terms]
field = "new_terms_fields"
value = ["host.id", "file.path"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2023/09/27"
integration = ["endpoint"]
maturity = "production"
updated_date = "2024/05/21"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies binaries that are loaded and with an invalid code signature. This may indicate an attempt to masquerade as a
signed binary.
"""
from = "now-119m"
index = ["logs-endpoint.events.library-*"]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Image Loaded with Invalid Signature"
risk_score = 21
rule_id = "fd9484f2-1c56-44ae-8b28-dc1354e3a0e8"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Rule Type: BBR",
    "Data Source: Elastic Defend",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
library where host.os.type == "windows" and event.action == "load" and
  dll.code_signature.status : ("errorUntrustedRoot", "errorBadDigest", "errorUntrustedRoot") and
  (dll.Ext.relative_file_creation_time <= 500 or dll.Ext.relative_file_name_modify_time <= 500) and
  not startswith~(dll.name, process.name) and
  not dll.path : (
    "?:\\Windows\\System32\\DriverStore\\FileRepository\\*"
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[rule.threat.technique.subtechnique]]
id = "T1036.001"
name = "Invalid Code Signature"
reference = "https://attack.mitre.org/techniques/T1036/001/"



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

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

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Identifies indirect command execution via Program Compatibility Assistant (pcalua.exe) or forfiles.exe.\n"
from = "now-119m"
index = [
    "endgame-*",
    "logs-endpoint.events.process-*",
    "logs-system.security*",
    "logs-windows.*",
    "winlogbeat-*",
]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Indirect Command Execution via Forfiles/Pcalua"
risk_score = 21
rule_id = "98843d35-645e-4e66-9d6a-5049acd96ce1"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Rule Type: BBR",
    "Data Source: Elastic Endgame",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : ("pcalua.exe", "forfiles.exe")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1202"
name = "Indirect Command Execution"
reference = "https://attack.mitre.org/techniques/T1202/"


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

[rule]
description = """
Identifies attempts to execute commands with long base64 encoded command lines via an interactive shell. Adversaries may
abuse this technique to execute malicious commands.
"""
id = "e7b95c3e-9640-4836-85f9-2aaf6c14cebc"
license = "Elastic License v2"
name = "Long Base64 Command Execution via Interactive Shell"
os_list = ["linux"]
version = "1.0.6"

query = '''
process where event.type == "start" and event.action == "exec" and
process.parent.interactive == true and process.interactive == true and
(
  (
    process.name like~ "python*" and
    (
      process.command_line like~ "*b64decode*" or
      (
        process.command_line like "*-c *" and
        process.command_line like~ "*base64*"
      )
    )
  ) or
  (
    process.name like~ ("powershell*", "pwsh*") and
    process.command_line like~ (
      "* -e *", "* -en *", "* -enc *", "* -enco *", "* -encod *", "* -encode *", "* -encoded *",
      "* -encodedcommand *", "*frombase64string*"
    )
  ) or
  (
    process.name like~ ("node*", "deno*") and
    (
      process.command_line like~ ("*atob(*", "*eval(*") or
      (
        process.command_line like~ "*buffer.from*" and
        process.command_line like~ "*base64*"
      )
    )
  ) or
  (
    process.name like~ "php*" and
    process.command_line like~ ("*base64_decode(*", "*convert.base64-decode*")
  ) or
  (
    process.name like~ "perl*" and
    process.command_line like~ ("*MIME::Base64*", "*decode_base64(*")
  ) or
  (
    process.name like~ "ruby*" and
    process.command_line like~ ("*require*base64*", "*Base64.decode64(*")
  ) or
  (
    process.name like~ "java*" and
    process.command_line like~ "*base64*decode(*"
  ) or
  (
    process.name like~ "lua*" and
    process.command_line like~ ("*mime.decode(*base64*", "*mime.unb64(*")
  ) or
  (
    process.name like~ "openssl*" and
    process.command_line like~ ("*base64 -d*", "*-base64*")
  ) or
  (
    process.name in ("base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16") and
    process.command_line like~ ("* -d*", "* --decode*")
  ) or
  (
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
    process.command_line like~ ("*base64 -d*", "*base64 --decode*")
  )
) and length(process.command_line) >= 4000 and
not (
  process.parent.executable like (
  "/usr/bin/claude-bin", "/home/*/.local/share/claude/versions/*", "/opt/tm/gemini/node/bin/node",
  "/home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/*/bin/ruby",
  "/usr/bin/sudo", "/usr/local/xars/standalone-tools/claude/*", "/usr/bin/su", "/mnt/fast/nobackup/users/*",
  "/opt/local/share/claude/versions/*", "/home/*/.nvm/versions/node/*", "/usr/share/devin-desktop/devin-desktop",
  "/opt/linuxbrew/.linuxbrew/Homebrew/*", "/usr/bin/bwrap", "/root/.local/share/claude/versions/*",
  "/tmp/.mount_*/usr/share/cursor/cursor", "/home/*/.local/share/cursor-agent/versions/*/node",
  "/usr/local/lib/claude-code/claude-bin", "/opt/local/*/dotfolders/.local/share/claude/versions/*",
  "/scratch/user/*/.local/bin/claude-science", "/usr/bin/make", "/home/*/.cache/JetBrains/*/dist-package/node",
  "/home/*/.aimee-code/bin/*", "/opt/*/.local/share/claude/versions/*", "*/.codex/packages/standalone/releases/*/bin/codex",
  "/home/linuxbrew/.linuxbrew/Caskroom/codex/*/bin/codex", "*/node_modules/@openai/codex-linux-x64/vendor/*/bin/codex",
  "*/.local/share/claude/versions/*"
  ) or
  process.parent.name in ("claude", "claude.exe", "cursor") or
  process.parent.args like (
    "/root/.ansible/tmp/ansible-tmp-*/AnsiballZ_command.py", "source /home/*/.claude/shell-snapshots/snapshot-*", "claude",
    "/home/*/.ansible/tmp/ansible-tmp-*/AnsiballZ_command.py", "/tmp/cmdickens/tmp/eb-*", "/tmp/thangha/tmp/eb-*"
  ) or
  process.parent.command_line like "*mitogen:ansible*" or
  (process.parent.executable == "/usr/bin/timeout" and process.working_directory == "/workspace") or
  (
    process.parent.executable like "/tools/eb/build/*/bazel-root/install/*/process-wrapper" and
    process.executable like "/cvmfs/*/software/Python/*/bin/python3*"
  ) or
  process.working_directory in ("/workspace/race/codex", "/workspace/race/claude")
)
'''

min_endpoint_version = "8.3.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.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"

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

[[threat.technique.subtechnique]]
id = "T1059.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"

[[threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"

[[threat.technique.subtechnique]]
id = "T1059.011"
name = "Lua"
reference = "https://attack.mitre.org/techniques/T1059/011/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

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


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

[internal]
min_endpoint_version = "8.3.0"

[metadata]
creation_date = "2021/06/01"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
Identifies modifications of the AmsiEnable registry key to 0, which disables Windows Script AMSI scanning for the
affected user. Adversaries can modify this key to bypass AMSI protections for Windows Script Host or JScript execution.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.registry-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Modification of AmsiEnable Registry Key"
references = [
    "https://hackinparis.com/data/slides/2019/talks/HIP2019-Dominic_Chell-Cracking_The_Perimeter_With_Sharpshooter.pdf",
    "https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal",
]
risk_score = 73
rule_id = "f874315d-5188-4b4a-8521-d1c73093a7e4"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type in ("creation", "change") and
  registry.value : "AmsiEnable" and registry.data.strings: ("0", "0x00000000")

  /*
    Full registry key path omitted due to data source variations:
    HKEY_USERS\\*\\Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable"
  */
'''

note = """## Triage and analysis

### Investigating Modification of AmsiEnable Registry Key

#### Possible investigation steps

- Does the registry event prove Windows Script AMSI was disabled for a user hive?
  - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings` for "Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable" under "HKEY_USERS\\<SID>".
  - Implication: escalate true disablement when `registry.path` resolves to that user-hive value and `registry.data.strings` is "0" or "0x00000000"; lower suspicion only when the path or data does not disable AMSI, or same-host evidence proves controlled validation or image-build deliberately toggled Windows Script AMSI.

- Is the writing process a recognized validation tool or an abuse launcher?
  - Focus: writer identity: `process.entity_id`, `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0
  - Hint: reconstruct activity with `host.id` plus `process.entity_id`; if missing, use `host.id`, `process.pid`, and a tight time window.
  - Implication: escalate when the writer is unsigned, untrusted, user-writable, renamed, script-launched, or writes "AmsiEnable" outside a recognized validation or image-build command line. Identity alone never clears the registry change.

- Does lineage and session explain the AMSI disablement?
  - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`.
  - Implication: escalate when lineage involves Office, a browser, script host, remote shell, scheduled task, unexpected service account, or a standard user context that does not fit script-control testing; lower suspicion only when parent, session, and `user.id` match controlled validation or image-build launch context.

- Did follow-on process activity use the disablement path?
  - Focus: post-write process activity in the recovered process scope, especially `process.executable`, `process.command_line`, and `process.parent.command_line`. $investigate_1
  - Implication: escalate when the same lineage later launches or reopens "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "wmic.exe", "regsvr32.exe", or Office-child script execution. A write followed by a second script open matches SharpShooter-style AMSI-stub behavior; activity confined to recognized validation is lower risk.

- Did the same process change related registry state for evasion, persistence, or cleanup?
  - Focus: same-process registry activity in the recovered process scope, with `registry.path`, `registry.value`, and `registry.data.strings`. $investigate_2
  - Implication: escalate when the process also weakens script policy, security-control, Run, Startup, COM, or other persistence-relevant keys, or quickly restores `registry.path` after script execution. Risk is narrower when surrounding registry writes stay limited to the Windows Script validation task and return to baseline.

- If local evidence stays suspicious or unresolved, do related alerts broaden scope?
  - Focus: related alerts for the same `user.id` that show execution, persistence, delivery, or defense evasion. $investigate_3
  - Hint: query related alerts for the same `host.id` to find adjacent script execution, persistence, related registry tampering, or other AMSI-bypass alerts. $investigate_4
  - Implication: broaden scope and urgency when either pivot shows related execution, persistence, or defense evasion; quiet related-alert pivots only lower urgency when local registry, process, and user evidence already supports one exact benign workflow.

- Escalate when true AMSI disablement combines with suspicious writer, lineage, script follow-on, related registry weakening, or related alerts; close only when same-host registry and process evidence proves one controlled workflow, with outside confirmation when telemetry cannot prove legitimacy; preserve and escalate mixed or incomplete evidence.

### False positive analysis

- Controlled security validation or golden-image build validation can legitimately toggle AMSI on lab, build, or pre-production assets. Confirm `registry.path`, `registry.value`, and `registry.data.strings` match the intended user hive; `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.command_line`, `process.parent.command_line`, `user.id`, and `host.id` align with that workflow; and surrounding process plus registry activity stays inside the task. Use change records, testing plans, owner confirmation, or toolchain confirmation only to verify telemetry-proven workflow, not override unresolved telemetry.
- Base exceptions on the minimum confirmed workflow pattern: `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, `registry.path`, `user.id`, and `host.id`. Use prior alerts, when available, to validate stability. Avoid exceptions on the AmsiEnable value alone, on `user.name` alone, or on a host alone.

### Response and remediation

- If confirmed benign, reverse any temporary containment and document the exact registry, process, parent, user, and host evidence that justified closure. Create an exception only when that confirmed pattern is specific enough to avoid suppressing lookalike AMSI tampering; use recurrence as supporting evidence when it exists.
- If suspicious but unconfirmed, preserve the registry event, same-host process timeline, parent command line, related registry changes, and affected user and host before containment. Apply reversible containment first, such as heightened monitoring, temporary network restriction, or carefully scoped endpoint isolation based on host role; escalate to account action or stronger host isolation only if follow-on execution, related registry tampering, or broader alert scope is confirmed.
- If confirmed malicious, preserve the registry, process, user, host, and related-alert evidence plus any recovered script or payload identifiers before destructive action. Use endpoint isolation to stop follow-on execution while retaining telemetry, then terminate malicious processes or suspend accounts only after recording the process and user evidence needed for follow-up.
- After scoping related `host.id`, `user.id`, `process.executable`, and `registry.path` evidence across affected assets, restore `registry.value` to the expected baseline and remove only the scripts, binaries, Run keys, COM changes, scheduled tasks, or other persistence artifacts identified during the investigation.
- Post-incident hardening: restrict who can modify the Windows Script settings path, review controls around script hosts and Office macro execution, and retain the registry and process telemetry that proved the case.
"""

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:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "host.id",
    "user.name",
    "user.id",
    "process.executable",
    "process.command_line",
    "process.entity_id",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
    "process.parent.executable",
    "process.parent.command_line",
    "registry.path",
    "registry.value",
    "registry.data.strings",
]

[transform]

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

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

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

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

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

[[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/11/07"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when a user has started multiple Okta sessions with the same user account and different session IDs. This may
indicate that an attacker has stolen the user's session cookie and is using it to access the user's account from a
different location.
"""
false_positives = ["A user may have multiple sessions open at the same time, such as on a mobile device and a laptop."]
from = "now-35m"
index = ["filebeat-*", "logs-okta*"]
interval = "30m"
language = "kuery"
license = "Elastic License v2"
name = "Multiple Okta Sessions Detected for a Single User"
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 Multiple Okta Sessions Detected for a Single User

Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by hijacking session cookies, allowing unauthorized access to user accounts from different locations. The detection rule identifies anomalies by flagging multiple session initiations with distinct session IDs for the same user, excluding legitimate Okta system actors, thus highlighting potential unauthorized access attempts.

### Possible investigation steps

- Review the Okta logs to identify the specific user account associated with the multiple session initiations and note the distinct session IDs.
- Check the geographic locations and IP addresses associated with each session initiation to determine if there are any unusual or unexpected locations.
- Investigate the timestamps of the session initiations to see if they align with the user's typical login patterns or if they suggest simultaneous logins from different locations.
- Examine the okta.actor.id and okta.actor.display_name fields to ensure that the sessions were not initiated by legitimate Okta system actors.
- Contact the user to verify if they recognize the session activity and if they have recently logged in from multiple devices or locations.
- Assess if there are any other related security alerts or incidents involving the same user account that could indicate a broader compromise.

### False positive analysis

- Legitimate multiple device usage: Users may legitimately access their accounts from multiple devices, leading to multiple session initiations. To handle this, create exceptions for users who frequently use multiple devices for work.
- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing Okta from various locations. Consider setting up location-based exceptions for these users.
- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Implement policies to discourage account sharing or create exceptions for known shared accounts.
- Automated scripts or integrations: Some users may have automated processes that initiate multiple sessions. Identify these scripts and exclude them from the rule by their specific session patterns.
- Testing and development environments: Users involved in testing or development may generate multiple sessions as part of their work. Exclude these environments from the rule to prevent false positives.

### Response and remediation

- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access.
- Reset the user's password and invalidate any existing session cookies to ensure that any stolen session cookies are rendered useless.
- Conduct a thorough review of recent login activity and session logs for the affected user to identify any suspicious or unauthorized access patterns.
- Notify the user of the potential compromise and advise them to verify any recent account activity for unauthorized actions.
- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems may be affected.
- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security against unauthorized access.
- Update and enhance monitoring rules to detect similar anomalies in the future, focusing on unusual session patterns and access from unexpected locations.

## 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://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
    "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 = "621e92b6-7e54-11ee-bdc0-f661ea17fbcd"
severity = "medium"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset:okta.system
    and okta.event_type:user.session.start
    and okta.authentication_context.external_session_id:*
    and not (okta.actor.id: okta* or okta.actor.display_name: okta*)
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1550.004"
name = "Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1550/004/"

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

[rule.threshold]
field = ["okta.actor.id"]
value = 1
[[rule.threshold.cardinality]]
field = "okta.authentication_context.external_session_id"
value = 3

[rule]
description = """
This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this
technique to download and execute payloads for various malicious purposes, such as establishing persistence or
exfiltrating data.
"""
id = "0369a845-9383-4be6-8102-5e5688b8253b"
license = "Elastic License v2"
name = "Payload Downloaded and Piped to Interpreter"
os_list = ["linux"]
version = "1.0.4"

query = '''
sequence by process.parent.entity_id with maxspan=1s
  [network where event.type == "start" and event.action == "connection_attempted" and (
    process.name like (
      "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish",
      "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin",
      "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2",
      "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno",
      "env", "timeout", "nice", "stdbuf", "setsid", "setarch", "unshare", "nsenter", "flock",
      "runuser", "sudo", "snap"
    ) or
    process.name like ("python*", "perl*", "ruby*", "lua*", "php*", "qemu-*-static")
  ) and 
   not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
     destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
     "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
     "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
     "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
     "FF00::/8"
     )
   )]
  [process where event.type == "start" and event.action == "exec" and process.interactive == true and (
    process.name like (
      "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish",
      "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin",
      "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2",
      "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno"
    ) or
    process.name like ("python*", "perl*", "ruby*", "lua*", "php*")
  ) and (
    stringcontains(process.executable, process.command_line) or
    stringcontains(process.name, process.command_line)
  ) and
  process.args_count == 1 and
  /* Prevent FPs from long single argument strings due to parsing */
  length(process.command_line) < 50 and
  not (
    process.parent.executable like (
      "/usr/sbin/univention-directory-listener", "/home/*/.local/zed.app/libexec/zed-editor",
      "/home/*/nvim-linux-x86_64/bin/nvim"
    ) or
    process.executable like (
      "/usr/local/php*/bin/php-cgi", "/opt/plesk/php/*/bin/php-cgi", "/opt/cpanel/ea-php*/root/usr/bin/php-cgi", "/usr/bin/php-cgi",
      "/opt/universal/python/bin/python3*", "/opt/remi/php*/root/usr/bin/php-cgi", "/oracle/app/oracle/*/perl/bin/perl",
      "/mnt/Xilinx/PetaLinux/*/usr/bin/python3.*.real", "/usr/bin/php-cgi*", "/oracle_agent/*/agent/*/perl/bin/perl",
      "/home/*/anaconda3/envs/pnid_env/bin/python*", "/tmp/newroot/home/*/.nvm/versions/node/*/bin/node"
    ) or
    (
      process.name like "python*" and
      process.args in ("/usr/bin/pip", "/usr/local/bin/pip")
    )
  )]
'''

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

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

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

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

[[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.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"



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

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


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

[internal]
min_endpoint_version = "8.6.0"

[rule]
description = """
Detects suspicious creation of the nsswitch.conf file, outside of the regular /etc/nsswitch.conf path, consistent with
attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using
attacker-controlled NSS files or libraries to gain root.
"""
id = "cc81a704-da59-4baf-9b93-c9d893f17ab0"
license = "Elastic License v2"
name = "Potential CVE-2025-32463 Nsswitch File Creation"
os_list = ["linux"]
reference = [
    "https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot",
    "https://github.com/kh4sh3i/CVE-2025-32463",
]
version = "1.0.6"

query = '''
file where event.type == "creation" and file.path like "/*/etc/nsswitch.conf" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not 
(
  process.name in ("bash", "dash") and file.path like (
    "/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*", "/tmp/petalinux*/etc/nsswitch.conf",
    "/tmp/selfextract.*/mkinitramfs_*/etc/nsswitch.conf", "/var/tmp/dracut.*/initramfs/etc/nsswitch.conf",
    "/tmp/user/0/mkinitramfs_*/etc/nsswitch.conf", "/opt/mkinitramfs_*/etc/nsswitch.conf",
    "/opt/dumpling-nxp/*/etc/nsswitch.conf", "/tmp/store/vfs/dir/*", "/opt/tmp/mkinitramfs_*",
    "/opt/nvidia_tmpfs/mkinitramfs*"
  )
)
'''

min_endpoint_version = "7.15.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 = "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 = "7.15.0"

[rule]
description = """
Identifies suspicious memory allocations by a browser process. This may indicate an attempt to exploit a vulnerability
for initial access and execution.
"""
id = "d5fb2972-bf70-42a8-ad42-4db62491f2ad"
license = "Elastic License v2"
name = "Potential Shellcode Injection by a Browser Process"
os_list = ["windows"]
version = "1.0.3"

query = '''
api where process.Ext.api.name == "VirtualProtect" and
 process.Ext.api.name == "VirtualAlloc" and process.Ext.api.parameters.size >= 10000 and
 process.Ext.api.summary like "*COMMIT*" and process.thread.Ext.call_stack_final_user_module.name == "Unbacked" and
 process.name in~ ("iexplore.exe", "chrome.exe", "msedge.exe") and
 not _arraysearch(process.thread.Ext.call_stack, $entry, $entry.protection_provenance like ("Kernel", "Kernel|*")) and
 not process.thread.Ext.call_stack_final_user_module.protection_provenance like ("Kernel", "Kernel|*", "chrome.exe", "chrome.exe|*",  "msedge.exe",  "msedge.exe|*") and
 not process.thread.Ext.call_stack_final_user_module.hash.sha256 in
                                  ("1a9ca25a7d7f11f6be10dee684505ee4b3340a0d3cbc22d959e69322e7cf0848",
                                   "d09f0ed19b426b1f78de9b736f6c1f667b3e689c1927e6a3466423ddf88fd4a4") and
 not process.thread.Ext.call_stack_final_user_module.protection_provenance like ("chrome.exe", "chrome.exe|*", "msedge.exe", "msedge.exe|*") and
 not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true)
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1189"
name = "Drive-by Compromise"
reference = "https://attack.mitre.org/techniques/T1189/"


[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"


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


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

[internal]
min_endpoint_version = "8.10.0"

[rule]
description = """
Adversaries can abuse Electron default configuration which allows executing code in the context of those Electron apps
and thus inherit their TCC permissions. It’s a technique that doesn’t touch files of those apps so it also bypasses the
new macOS Ventura App Protection mechanism.
"""
id = "f150809c-5f4b-4715-b4a6-4bc8b9929d65"
license = "Elastic License v2"
name = "Potential TCC Bypass via Electron Web Inspector API"
os_list = ["macos"]
reference = [
    "https://infocondb.org/con/def-con/def-con-31/electronizing-macos-privacy-a-new-weapon-in-your-red-teaming-armory",
    "https://github.com/r3ggi/electroniz3r",
]
version = "1.0.7"

query = '''
process where event.type == "start" and event.action == "exec" and
 (
  (process.executable like ("/Applications/*", "/Volumes/*") and process.command_line like~ "*--inspect=13337*") or
  (process.parent.executable like ("/Applications/*", "/Volumes/*") and process.command_line like~ "*--inspect=13337*")
 )
'''

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


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

[internal]
min_endpoint_version = "8.6.0"

[metadata]
creation_date = "2024/01/09"
integration = ["endpoint", "crowdstrike"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies recursive process capability enumeration of the entire filesystem through the getcap command. Malicious users
may manipulate identified capabilities to gain root privileges.
"""
from = "now-9m"
index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Process Capability Enumeration"
risk_score = 47
rule_id = "5c351f54-4187-4ad8-abc8-29b0cfbef8b1"
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: Discovery",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "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", "ProcessRollup2") and
  process.name == "getcap" and process.args == "-r" and process.args == "/" and
  process.args_count == 3 and user.id != "0"
'''
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 Process Capability Enumeration

In Linux environments, the `getcap` command is used to list file capabilities, which define specific privileges for executables. Adversaries may exploit this by recursively scanning the filesystem to identify and manipulate capabilities, potentially escalating privileges. The detection rule identifies suspicious use of `getcap` by monitoring for its execution with specific arguments, especially by non-root users, indicating potential misuse.

### Possible investigation steps

- Review the alert details to confirm the execution of the `getcap` command with the arguments `-r` and `/`, ensuring the process was initiated by a non-root user (user.id != "0").
- Identify the user account associated with the process execution to determine if the user has a legitimate reason to perform such actions.
- Examine the process execution history for the identified user to check for any other suspicious activities or commands executed around the same time.
- Investigate the system logs for any signs of privilege escalation attempts or unauthorized access following the execution of the `getcap` command.
- Check for any recent changes to file capabilities on the system that could indicate manipulation by the adversary.
- Assess the system for any other indicators of compromise or related alerts that might suggest a broader attack campaign.

### False positive analysis

- System administrators or automated scripts may use the getcap command for legitimate auditing purposes. To handle this, create exceptions for known administrative accounts or scripts that regularly perform capability checks.
- Security tools or monitoring solutions might trigger the rule during routine scans. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
- Developers or testing environments may execute getcap as part of software testing or development processes. Exclude specific user IDs or groups associated with these environments to prevent unnecessary alerts.
- Scheduled maintenance tasks might involve capability enumeration. Document and exclude these tasks by specifying the time frames or user accounts involved in the maintenance activities.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
- Terminate any unauthorized or suspicious processes associated with the `getcap` command to halt potential privilege escalation activities.
- Conduct a thorough review of the system's file capabilities using a trusted method to identify any unauthorized changes or suspicious capabilities that may have been set.
- Revert any unauthorized capability changes to their original state to ensure that no elevated privileges are retained by malicious users.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement monitoring for similar `getcap` command executions across the environment to detect and respond to future attempts promptly.
- Review and update access controls and user permissions to ensure that only authorized users have the necessary privileges to execute potentially sensitive commands like `getcap`."""

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

[[rule.threat.technique]]
id = "T1057"
name = "Process Discovery"
reference = "https://attack.mitre.org/techniques/T1057/"

[[rule.threat.technique]]
id = "T1083"
name = "File and Directory Discovery"
reference = "https://attack.mitre.org/techniques/T1083/"

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

[metadata]
creation_date = "2026/01/21"
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/07/29"

[rule]
author = ["Elastic"]
description = """
This rule detects the reading of the service account namespace file inside a container. The service account namespace file
is used to identify the namespace of the container in which it is running, and may be used by an adversary to get a better
understanding of the container and the services running inside it.
"""
false_positives = [
    """
    There is a potential for false positives if the reading of the service account namespace file is used for legitimate purposes,
    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
    if they are indicative of malicious activity or part of legitimate container activity.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Service Account Namespace Read 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 Service Account Namespace Read Detected via Defend for Containers

This rule flags a process inside a container opening /var/run/secrets/kubernetes.io/serviceaccount/namespace, which reveals the pod’s Kubernetes namespace; adversaries use this quick check to orient themselves and scope discovery. A common pattern is: after landing a shell in a pod, the attacker reads the namespace file, then issues namespace-scoped kubectl or direct API calls to list Deployments, Secrets, and ServiceAccounts, map privileges and service endpoints, and plan targeted lateral movement within that namespace.

### Possible investigation steps

- Build the process tree and shell session timeline around the event to identify the parent and child processes, interactive TTY, and exact commands executed before and after.
- Map the container to its pod, namespace, node, image, owner, and service account, and verify whether any kubectl exec/attach or debug container activity targeting this pod is expected at that time.
- Correlate Kubernetes audit logs for that service account and pod around the timestamp to spot list/get calls, Secrets or ServiceAccounts enumeration, and the user/IP that initiated any exec/attach.
- Inspect network flows and DNS from the container to the Kubernetes API server immediately after the event to confirm follow-on API access or token validation attempts.
- Review the service account’s RBAC bindings and search the container for reads of the token/ca.crt or the presence of kubectl/kubeconfig or scripts that could leverage the token.

### False positive analysis

- During legitimate troubleshooting, a user opens an interactive shell in the container and the shell’s profile or prompt customization reads /var/run/secrets/kubernetes.io/serviceaccount/namespace to display the current namespace.
- A documented operational check or training exercise instructs staff to manually open the service account namespace file inside a container to confirm the environment before changes, producing a benign detection.

### Response and remediation

- Immediately kill the interactive shell process inside the container (e.g., bash/sh attached via kubectl exec) and quarantine the pod/namespace by applying a deny-all NetworkPolicy and pausing the owning Deployment/StatefulSet.
- Escalate to a major incident and page the on-call cluster security team if you observe subsequent reads of /var/run/secrets/kubernetes.io/serviceaccount/token or ca.crt or API calls from the pod to the Kubernetes API (443) that list Secrets or ServiceAccounts.
- Rotate the service account credentials by deleting the pod to force a new projected token, set automountServiceAccountToken: false on the workload if not needed, and remove pods/exec and pods/attach privileges from users or roles that accessed this pod.
- Redeploy the workload from a trusted, signed image without embedded shells/kubectl, verify image digest on rollout, and only lift quarantine after confirming no unauthorized containers, cronjobs, or startup scripts were added.
- Enforce least-privilege RBAC for the service account (deny list/get on Secrets, ConfigMaps, and Pods in the namespace), enable Pod Security Admission restricted with readOnlyRootFilesystem and dropped Linux capabilities, and require approvals for kubectl exec using ephemeral containers for debugging.
"""
risk_score = 21
rule_id = "f7c64a1b-9d00-4b92-9042-d3bb4196899a"
severity = "low"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
any where host.os.type == "linux" and container.id like "*" and (
  (event.category == "file" and event.type == "change" and event.action == "open" and
  file.path in (
    "/var/run/secrets/kubernetes.io/serviceaccount/namespace",
    "/run/secrets/kubernetes.io/serviceaccount/namespace"
  )) or
  (event.category == "process" and event.type == "start" and event.action == "exec" and
  (
    process.name in ("cat", "head", "tail", "more", "less", "sed", "awk") or
    process.args in (
      "cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
      "head", "/bin/head", "/usr/bin/head", "/usr/local/bin/head",
      "tail", "/bin/tail", "/usr/bin/tail", "/usr/local/bin/tail",
      "more", "/bin/more", "/usr/bin/more", "/usr/local/bin/more",
      "less", "/bin/less", "/usr/bin/less", "/usr/local/bin/less",
      "sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
      "awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
    )
  ) and process.args like "*/run/secrets/kubernetes.io/serviceaccount/namespace*"
    )
)
'''

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

[[rule.threat.technique]]
id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"

[[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 = "T1005"
name = "Data from Local System"
reference = "https://attack.mitre.org/techniques/T1005/"

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