Elastic rules: 2o

[rule]
description = """
Detects when Perl spawns a shell interpreter to execute an abnormally large script, indicated by a null command line
despite having the expected argument count. This technique is commonly observed in npm typosquatting attacks where
malicious packages use Perl as an intermediary to execute large embedded payloads that exceed normal command line size
limits. Adversaries leverage Perl's trusted status to execute obfuscated or encoded shell scripts that perform
credential harvesting, data exfiltration, or deploy additional malware stages.
"""
id = "484593e7-3996-49e7-97ce-452408a30f10"
license = "Elastic License v2"
name = "Abnormally Large Shell Script Execution via Perl"
os_list = ["macos"]
reference = ["https://socket.dev/blog/10-npm-typosquatted-packages-deploy-credential-harvester"]
version = "1.0.1"

query = '''
process where event.type == "start" and event.action == "exec" and process.name in ("bash", "zsh", "sh") and process.command_line == null and process.args_count == 3 and
  process.parent.name == "perl" and process.Ext.effective_parent.name in ("bash", "zsh", "sh")
'''

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

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

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

[internal]
min_endpoint_version = "8.16.0"

[metadata]
creation_date = "2026/07/27"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/27"

[rule]
author = ["Elastic"]
description = """
Detects a principal account creating or replacing - or attempts to create or replace - an AWS Network 
Access Control List (NACL) entry using protocol -1 (all traffic). Both successful and failed outcomes 
are included. A NACL entry with protocol -1 passes all traffic regardless of port, which would disable 
network-layer controls for the affected subnets. Monitoring for new identities performing this change 
helps surface freshly compromised credentials or unauthorized principals removing a defense-in-depth 
layer to facilitate lateral movement or data exfiltration. This signal only flags if this behavior was 
not observed historically in a specific time window.
"""
false_positives = [
    """
    Some legitimate architectures use permissive NACLs as a passthrough layer while relying
    on security groups for access control. Validate that the modified NACL is associated with
    subnets where this design pattern is expected and that the change was authorized through
    a change management process.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
interval = "5m"
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity"
note = """## Triage and analysis

### Investigating AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity

This rule fires when a NACL entry specifying all ports (0–65535) and all protocols is created or replaced. While NACLs are stateless and secondary to security groups, a permissive NACL entry can neutralize a defense-in-depth layer and may indicate an adversary attempting to ensure unrestricted connectivity for their tools or exfiltration channels.

### Possible investigation steps

- Identify the creating principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are authorized to modify network ACLs.
- Review `aws.cloudtrail.request_parameters` to identify the NACL ID, rule number, egress/ingress direction, and CIDR block (`0.0.0.0/0` for any-source rules are highest severity).
- Determine which subnets are associated with the modified NACL and assess the sensitivity of workloads in those subnets.
- Check for accompanying security group modifications that also expand access.
- Review VPC flow logs for unusual traffic to or from the affected subnets following the NACL change.
- Review `event.outcome` — `success` means the permissive entry was applied and the subnet's network-layer controls are weakened now; `failure` means the change was blocked, which from a new identity often indicates credential probing or permission reconnaissance.

### False positive analysis

- Architectures that use NACLs as a stateless passthrough while relying on security groups for granular control may legitimately create permissive NACL entries.
- Development environments sometimes use open NACLs for convenience.

### Response and remediation

- If unauthorized, immediately delete the permissive NACL entry and replace it with an appropriately restrictive rule.
- Review VPC flow logs for evidence of network activity that exploited the open rule.
"""
references = [
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAclEntry.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceNetworkAclEntry.html",
]
risk_score = 47
rule_id = "5d9a3c71-2b84-4e58-f693-1c7f0a4e8b26"
setup = "The AWS CloudTrail integration must be enabled and configured to collect EC2 management events."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS EC2",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ec2.amazonaws.com"
    and event.action: ("CreateNetworkAclEntry" or "ReplaceNetworkAclEntry")
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and event.outcome: ("success" or "failure")
    and aws.cloudtrail.flattened.request_parameters.aclProtocol: "-1"
    and aws.cloudtrail.flattened.request_parameters.ruleAction: "allow"
    and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi*)
'''

[[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.007"
name = "Disable or Modify Cloud Firewall"
reference = "https://attack.mitre.org/techniques/T1562/007/"

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

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

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

[metadata]
creation_date = "2021/08/27"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Austin Songer", "Elastic"]
description = """
Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file
system permanently removes all stored data and cannot be reversed. This action is rare in most environments and
typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to
destroy evidence, disrupt workloads, or impede recovery efforts.
"""
false_positives = [
    """
    Legitimate teardown or environment decommissioning processes may delete EFS file systems. Verify whether the calling
    user, role, automation system, or CI/CD workflow is expected to perform destructive actions in the affected account.
    File system deletions by unfamiliar identities, from unusual IP addresses, or occurring outside approved change
    windows should be carefully reviewed. If known automation routinely deletes ephemeral test file systems, consider
    adding scoped exceptions.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EFS File System Deleted"
note = """## Triage and analysis

### Investigating AWS EFS File System Deleted

Amazon Elastic File System (EFS) provides scalable, shared file storage used by EC2, container workloads, analytics jobs, and other persistent applications. Deleting an EFS file system (`DeleteFileSystem`) permanently removes all stored data and cannot be recovered. Mount targets must already be deleted, but those operations are common and do not themselves indicate malicious behavior. This rule focuses exclusively on the irreversible destructive event, which may signal intentional data destruction, ransomware preparation, or a post-compromise cleanup effort.

#### Possible investigation steps

- **Identify the actor and calling context**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
  - Check `source.ip`, `user_agent.original`, and whether the call originated via console, IAM role, STS session, or long-lived IAM key.
  - Verify whether this principal typically manages EFS resources or teardown activities.

- **Determine what was deleted**
  - Inspect `aws.cloudtrail.request_parameters` to identify the deleted file system ID.
  - Map the resource to:
    - Application or owner team
    - Environment classification (prod / dev / test)
    - Dependency surfaces (EC2 instances, ECS tasks, Lambda, analytics pipelines)

- **Reconstruct timeline and intent**
  - Use `@timestamp` to correlate with:
    - Recent `UpdateFileSystem` events (e.g., deletion protection, lifecycle policies)
    - IAM policy or trust policy changes
    - EC2 or container runtime disruption shortly before deletion
    - Unexpected regional activity or off-hours execution
  - Determine if mount target deletions occurred immediately beforehand (expected lifecycle) or unexpectedly earlier (possibly suspicious when paired with other anomalies).

- **Correlate with broader account activity**
  - Pivot in CloudTrail on:
    - The same access key or session
    - The same EFS file system ID
  - Look for:
    - Privilege escalation (new policy attachments, role assumptions)
    - Lateral movement (SSM sessions, unusual EC2 access)
    - Signs of cleanup or anti-forensics (CloudWatch log group deletions, RDS snapshot deletions)
    - Network isolation actions (security-group or NACL updates)

- **Validate with owners**
  - Confirm with application or infrastructure teams:
    - Whether the deletion was planned, approved, or part of an environment teardown
    - Whether a migration or infrastructure rotation is in progress
    - Whether the deleted file system contained production or sensitive workloads

### False positive analysis

- **Expected teardown activity**
  - Some pipelines (Terraform, CloudFormation, CDK, custom IaC) delete file systems as part of environment rotation or decommissioning.
  - Add exceptions for known automation roles or environment tags (e.g., `Environment=Dev`).

- **Ephemeral test environments**
  - Development, QA, or integration test accounts may routinely create and destroy EFS file systems.
  - Suppress events for non-production accounts where destructive operations are normal.

- **Automated housekeeping**
  - Internal tooling or lifecycle processes may remove unused EFS resources.
  - Identify automation roles and use exceptions based on `aws.cloudtrail.user_identity.arn` or `user_agent.original`.

### Response and remediation

- **Contain and secure**
  - If unauthorized, revoke or disable the credentials used for the deletion.
  - Review CloudTrail for additional destructive or privilege-escalating operations from the same actor.
  - Validate whether any associated compute workloads (EC2, ECS, Lambda) show compromise indicators.

- **Assess impact**
  - Identify workloads impacted by the file system deletion.
  - Determine whether alternate backups exist (EFS-to-EFS Backup, AWS Backup vaults).
  - Evaluate operational disruption and data-loss implications, especially for compliance-bound data.

- **Recover (if possible)**
  - Restore from AWS Backup if a protected resource existed.
  - Rebuild infrastructure dependencies that relied on the deleted file system.

- **Hardening and prevention**
  - Restrict use of `elasticfilesystem:DeleteFileSystem` to tightly controlled IAM roles.
  - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:SourceIp`, `aws:RequestedRegion`) to limit destructive operations.
  - Ensure AWS Backup policies include EFS resources with sufficient retention.
  - Use AWS Config or Security Hub controls to detect:
    - EFS file systems without backup plans
    - Unexpected changes to file system policies

### 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/efs/latest/ug/API_DeleteFileSystem.html",
    "https://docs.aws.amazon.com/efs/latest/ug/API_DeleteMountTarget.html",
]
risk_score = 47
rule_id = "536997f7-ae73-447d-a12d-bff1e8f5f0a0"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EFS",
    "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: "elasticfilesystem.amazonaws.com" 
    and event.action: "DeleteFileSystem" 
    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.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",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters"
]

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

[rule]
author = ["Elastic"]
description = """
Identifies the creation or modification of a local trusted root certificate in Windows. The install of a malicious root
certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity
(for example, Microsoft). It could also allow an attacker to decrypt SSL traffic.
"""
false_positives = ["Certain applications may install root certificates for the purpose of inspecting SSL traffic."]
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.registry-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Creation or Modification of Root Certificate"
note = """## Triage and analysis

### Investigating Creation or Modification of Root Certificate

Root certificates are the primary level of certifications that tell a browser that the communication is trusted and legitimate. This verification is based upon the identification of a certification authority. Windows adds several trusted root certificates so browsers can use them to communicate with websites.

[Check out this post](https://www.thewindowsclub.com/what-are-root-certificates-windows) for more details on root certificates and the involved cryptography.

This rule identifies the creation or modification of a root certificate by monitoring registry modifications. The installation of a malicious root certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity (for example, Microsoft). It could also allow an attacker to decrypt SSL traffic.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate abnormal behaviors observed by the subject process such as network connections, other registry or file modifications, and any spawned child processes.
- If one of the processes is suspicious, retrieve it and determine if it is malicious:
  - Use a private sandboxed malware analysis system to perform analysis.
    - Observe and collect information about the following activities:
      - Attempts to contact external domains and addresses.
      - File and registry access, modification, and creation activities.
      - Service creation and launch activities.
      - Scheduled task creation.
  - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values.
    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.

### False positive analysis

- This detection may be triggered by certain applications that install root certificates for the purpose of inspecting SSL traffic. Benign true positives (B-TPs) can be added as exceptions if necessary.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove the malicious certificate from the root certificate store.
- Remove and block malicious artifacts identified during triage.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- 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 = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

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

references = [
    "https://posts.specterops.io/code-signing-certificate-cloning-attacks-and-defenses-6f98657fc6ec",
    "https://www.ired.team/offensive-security/persistence/t1130-install-root-certificate",
]
risk_score = 21
rule_id = "203ab79b-239b-4aa5-8e54-fc50623ee8e4"
severity = "low"
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",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type == "change" and registry.value : "Blob" and
  registry.path :
    (
      "HKLM\\Software\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob",
      "HKLM\\Software\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob",
      "HKLM\\Software\\Policies\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob",
      "HKLM\\Software\\Policies\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob",
      "\\REGISTRY\\MACHINE\\Software\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob",
      "\\REGISTRY\\MACHINE\\Software\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob",
      "\\REGISTRY\\MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob",
      "\\REGISTRY\\MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob",
      "MACHINE\\Software\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob",
      "MACHINE\\Software\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob",
      "MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob",
      "MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob"
    ) and
  not process.executable : (
          "?:\\Program Files (x86)\\*.exe",
          "?:\\Program Files\\*.exe",
          "?:\\ProgramData\\bomgar-*\\*\\sra-pin.exe",
          "?:\\ProgramData\\bomgar-*\\*\\bomgar-scc.exe",
          "?:\\ProgramData\\CTES\\Ctes.exe",
          "?:\\ProgramData\\CTES\\Components\\SNG\\AbtSngSvc.exe",
          "?:\\ProgramData\\CTES\\Components\\SVC\\CtesHostSvc.exe",
          "?:\\ProgramData\\Lenovo\\Vantage\\Addins\\LenovoHardwareScanAddin\\*\\LdeApi.Server.exe",
          "?:\\ProgramData\\Logishrd\\LogiOptionsPlus\\Plugins\\64\\certmgr.exe",
          "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\*.exe",
          "?:\\ProgramData\\Quest\\KACE\\modules\\clientidentifier\\clientidentifier.exe",
          "?:\\ProgramData\\Sophos\\AutoUpdate\\Cache\\sophos_autoupdate1.dir\\*.exe",
          "?:\\ProgramData\\tychoncloud\\bin\\OVAL\\tvs.exe",
          "?:\\Windows\\CCM\\CcmEval.exe",
          "?:\\Windows\\CCM\\CcmExec.exe",
          "?:\\Windows\\ccmsetup\\autoupgrade\\ccmsetup*.exe",
          "?:\\Windows\\ccmsetup\\cache\\ccmsetup.exe",
          "?:\\Windows\\ccmsetup\\ccmsetup.exe",
          "?:\\Windows\\Cluster\\clussvc.exe",
          "?:\\Windows\\ImmersiveControlPanel\\SystemSettings.exe",
          "?:\\Windows\\Lenovo\\ImController\\PluginHost86\\Lenovo.Modern.ImController.PluginHost.Device.exe",
          "?:\\Windows\\Lenovo\\ImController\\Service\\Lenovo.Modern.ImController.exe",
          "?:\\Windows\\Sysmon.exe",
          "?:\\Windows\\Sysmon64.exe",
          "?:\\Windows\\UUS\\amd64\\MoUsoCoreWorker.exe",
          "?:\\Windows\\UUS\\amd64\\WaaSMedicAgent.exe",
          "?:\\Windows\\UUS\\Packages\\Preview\\amd64\\MoUsoCoreWorker.exe",
          "?:\\Windows\\WinSxS\\*.exe"
  ) and
  not
  (
    process.executable : (
      "?:\\Windows\\System32\\*.exe",
      "?:\\Windows\\SysWOW64\\*.exe"
    ) and
    not process.name : (
        "rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "expand.exe",
        "regsvr32.exe", "cscript.exe", "wscript.exe", "wmiprvse.exe", "certutil.exe", "xcopy.exe"
    )
  )
'''


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

[[rule.threat.technique]]
id = "T1553"
name = "Subvert Trust Controls"
reference = "https://attack.mitre.org/techniques/T1553/"

[[rule.threat.technique.subtechnique]]
id = "T1553.004"
name = "Install Root Certificate"
reference = "https://attack.mitre.org/techniques/T1553/004/"

[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 = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"

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

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

[rule]
author = ["Elastic"]
description = """
LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature
provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry
and wait or initiate a system restart to enable Lsass credentials access.
"""
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 = "Disabling Lsa Protection via Registry Modification"
references = ["https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection"]
risk_score = 73
rule_id = "37cb6756-8892-4af3-a6bd-ddc56db0069d"
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 == "change" and
  registry.data.strings != null and process.name != null and
  registry.value : "RunAsPPL" and
  registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL" and
  not registry.data.strings : ("1", "0x00000001", "2", "0x00000002") and
  not process.executable : "?:\\Windows\\System32\\SecurityHealthService.exe"
'''

note = """## Triage and analysis

### Investigating Disabling Lsa Protection via Registry Modification

#### Possible investigation steps

- Does the alert-local registry write attempt to lower LSA protection?
  - Why: RunAsPPL values 1 and 2 enable protected LSASS modes; a non-enabling value under the LSA control path weakens credential protection even when live-state effect is unresolved.
  - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`, confirming the RunAsPPL LSA control path and non-enabling data.
  - Implication: escalate or keep investigating when RunAsPPL receives a non-enabling value; treat numbered-ControlSet effect as unresolved, not benign. Lower suspicion only when verified as controlled compatibility testing on a non-production host.

- Which process and parent made the RunAsPPL change?
  - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`.
  - Implication: escalate when a user-writable binary, script host, renamed tool, unexpected signer, or unexplained parent changed RunAsPPL; lower suspicion when writer identity and parent workflow match a recognized validation, image-engineering, or compatibility toolchain. Identity alone does not clear the weakening change.

- Does the account and session context fit a controlled LSA protection change?
  - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.token.elevation_level`.
  - Implication: escalate when the change comes from an unexpected administrator, service account, remote shell, Office lineage, or token/session context that does not fit the expected task; lower suspicion only when account, session type, and privilege context fit the same recognized host-management workflow.

- Did the same process modify adjacent credential-protection or authentication settings?
  - Focus: registry events on the same `host.id` and `process.entity_id`, especially `registry.path`, `registry.value`, and `registry.data.strings` under LSA, WDigest, security provider, or Credential Guard families. $investigate_2
  - Hint: filter surrounding registry events by `host.id` plus `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight event-time window.
  - Implication: escalate when the writer also touches RunAsPPLBoot, LsaCfgFlags, UseLogonCredential, security packages, or similar credential-protection settings; keep scope narrower when the RunAsPPL write is isolated and registry context fits the same recognized test or build workflow.

- Did process activity prepare to exploit the weakened setting?
  - Why: a registry-only disable generally matters after reboot, so restart staging and LSASS-access preparation change urgency.
  - Focus: registry-writer and child process activity on the same `host.id`, checking `process.name`, `process.executable`, and `process.command_line`; broaden to the same `user.id` only if writer-scoped activity is unresolved. $investigate_3
  - Implication: escalate when the same lineage or user queues a reboot, launches LSASS dump tooling, invokes memory-access utilities, or stages archive commands; absence of follow-on process evidence does not close the alert because the weakened setting can be used after a later reboot.

- If local findings remain suspicious or unresolved, does the same host show broader defense weakening or credential-access activity?
  - Focus: related alerts for the same `host.id`, especially LSA-protection, LSASS-access, reboot, persistence, privilege-escalation, or credential-access alerts. $investigate_0
  - Hint: review related alerts for the same `user.id` to see whether the account is changing LSA protection or staging credential access elsewhere. $investigate_1
  - Implication: broaden scope when the same host has aligned defense-evasion or credential-access alerts; keep handling local when related host alerts are absent and registry, writer, session, and follow-on process evidence all support one recognized workflow.

- Escalate when registry meaning plus writer, session, adjacent-registry, reboot/LSASS-prep, or related-alert evidence shows unauthorized LSA-protection weakening; close only when telemetry proves one verified compatibility, validation, or image-engineering workflow with no contradictions; preserve evidence and escalate when telemetry is mixed or incomplete.

### False positive analysis

- Controlled compatibility testing, security validation, image engineering, or break-fix work can lower RunAsPPL on lab, pre-production, build, or troubleshooting systems. Confirm the exact expected test value in `registry.path`, `registry.value`, and `registry.data.strings`; a matching validation or build toolchain in `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.parent.executable`, and `user.id`; and a bounded `host.id` / `host.name` cohort. If registry meaning, writer context, session context, or host pattern is missing or contradictory, do not close as benign.
- Before creating an exception, validate recurrence of the same `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `user.id`, `host.id`, and specific `registry.path` family across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern; avoid exceptions on RunAsPPL alone, `user.name` alone, or a host alone.

### Response and remediation

- If confirmed benign, record which evidence proved the workflow: `registry.path`, `registry.data.strings`, writer identity, parent context, `user.id`, `host.id`, host cohort, and change window. Then reverse any temporary containment. Create an exception only when the same narrow pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert, registry timeline, modified RunAsPPL value (`registry.path`, `registry.data.strings`), writer command context (`process.entity_id`, `process.command_line`), parent context, account context, and any reboot or LSASS-prep command evidence before containment or cleanup. Apply reversible containment first: heightened monitoring, temporary access restrictions for the affected `user.id`, or host isolation only when dump or reboot evidence raises risk and isolation will not disrupt critical service.
- If confirmed malicious, record process and registry evidence first, then isolate the host through endpoint response when registry, writer, session, and follow-on evidence establish unauthorized protection weakening. Restore RunAsPPL to the expected enabled value, usually 1 or 2, verify adjacent LSA and security-provider settings, and confirm LSASS starts protected after the required reboot.
- If reboot or LSASS-access preparation occurred, treat resident credentials as potentially exposed, scope privileged or service accounts active on the host, and perform credential hygiene based on their exposure.
- Eradicate only the scripts, binaries, persistence changes, registry values, and dump or archive artifacts identified during the investigation, then remediate the access path that allowed the protection change.
- Retain registry and process telemetry, the final RunAsPPL state, and reboot timing so future cases can separate recurring controlled testing from repeated abuse.
"""

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.id",
    "user.id",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.parent.executable",
    "process.parent.command_line",
    "process.code_signature.subject_name",
    "process.Ext.session_info.logon_type",
    "process.Ext.token.elevation_level",
    "registry.path",
    "registry.value",
    "registry.data.type",
    "registry.data.strings",
]

[transform]

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

[[transform.investigate]]
label = "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 = "Registry activity by the same 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 = "Process activity for the registry 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" }
  ],
  [
    { 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"

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

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

[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID
Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or
sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be
investigated immediately.
"""
false_positives = [
    """
    Administrators may mark accounts as compromised during security testing or incident response exercises. If this is
    expected behavior in your environment, consider adjusting the rule or adding exceptions for specific test accounts.
    """,
]
from = "now-9m"
index = ["logs-azure.identity_protection-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Protection Admin Confirmed Compromise"
note = """## Triage and analysis

This rule detects when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This is a critical security event that requires immediate investigation and response.

### Possible investigation steps

- Review the `azure.identityprotection.properties.risk_detail` field to determine if the compromise was confirmed at the sign-in level (`adminConfirmedSigninCompromised`) or user level (`adminConfirmedUserCompromised`).
- Check the `azure.identityprotection.properties.user_principal_name` field to identify the compromised user account.
- Review the `azure.identityprotection.properties.user_display_name` field for additional user identification information.
- Examine the `azure.identityprotection.properties.risk_level` field to understand the severity level assigned to the risk event.
- Check the `azure.identityprotection.properties.risk_state` field to verify the current state of the risk (should be confirmed as compromised).
- Review the `azure.correlation_id` field to correlate this event with other related security events, including the original risk detections that led to the admin confirmation.
- Investigate the timeline of events leading up to the admin confirmation by reviewing Entra ID sign-in logs and audit logs for the affected user.
- Check for any suspicious activities associated with the user account, including:
    - Unusual sign-in locations or IP addresses
    - Access to sensitive resources or applications
    - Changes to user profile, permissions, or MFA settings
    - Bulk email sending or data exfiltration activities
- Review the `azure.identityprotection.properties.additional_info` field for any additional context provided by the administrator or Entra ID Protection.
- Identify which administrator confirmed the compromise by reviewing Entra ID audit logs for risk state changes.

### False positive analysis

- Security testing or penetration testing exercises may result in administrators confirming test accounts as compromised. If this is expected behavior, consider excluding specific test accounts or implementing a testing account naming convention to filter.
- Incident response drills or tabletop exercises may involve marking accounts as compromised for training purposes. Coordinate with security teams to identify planned exercises.

### Response and remediation

- Immediately reset the password for the compromised user account and require the user to set a new password upon next sign-in.
- Revoke all active sessions and authentication tokens for the compromised account, including:
    - Primary refresh tokens (PRTs)
    - OAuth tokens
    - Session cookies
    - Application-specific passwords
- Review and revoke any suspicious OAuth consent grants or application permissions added by the compromised account.
- Enable or enforce multi-factor authentication (MFA) for the affected user account if not already enabled.
- Review all activities performed by the compromised account, including:
    - Email forwarding rules or inbox rules
    - File access and downloads
    - Changes to security settings or permissions
    - Creation of new users or service principals
- Assess the scope of the compromise by identifying any lateral movement or privilege escalation activities.
- Consider disabling the account temporarily until the investigation is complete and all remediation steps are verified.
- Implement conditional access policies to prevent future compromises, such as requiring MFA from untrusted locations or blocking legacy authentication.
- Review and strengthen identity protection policies and risk-based conditional access rules.
- Document the incident, including the timeline, scope of compromise, and remediation actions taken.
- Conduct a post-incident review to identify gaps in security controls and implement improvements to prevent similar incidents.
"""
references = [
    "https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-investigate-risk",
    "https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks",
    "https://learn.microsoft.com/en-us/graph/api/resources/riskdetection",
]
risk_score = 99
rule_id = "a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890"
setup = """#### Required Microsoft Entra ID Protection Logs
To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration.
"""
severity = "critical"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Entra ID",
    "Data Source: Entra ID Protection Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: azure.identity_protection and
    azure.identityprotection.properties.risk_detail: (
        "adminConfirmedSigninCompromised" or
        "adminConfirmedUserCompromised"
    )
'''


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

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

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

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

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

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

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

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

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

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

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

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "azure.identityprotection.properties.risk_detail",
    "azure.identityprotection.properties.risk_level",
    "azure.identityprotection.properties.risk_state",
    "azure.identityprotection.properties.risk_event_type",
    "azure.identityprotection.properties.risk_type",
    "azure.identityprotection.properties.user_principal_name",
    "azure.identityprotection.properties.user_display_name",
    "azure.identityprotection.properties.user_id",
    "azure.identityprotection.properties.ip_address",
    "azure.identityprotection.properties.activity",
    "azure.identityprotection.properties.additional_info",
    "azure.identityprotection.properties.correlation_id",
    "azure.correlation_id",
    "source.ip",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint tsclient on the target host. This may
indicate a lateral movement attempt.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Execution via TSClient Mountpoint"
references = [
    "https://specterops.io/blog/2020/01/22/revisiting-remote-desktop-lateral-movement/",
    "https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language",
]
risk_score = 73
rule_id = "4fe9d835-40e1-452d-8230-17c147cafad8"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and process.executable : "\\Device\\Mup\\tsclient\\*.exe"
'''

note = """## Triage and analysis

### Investigating Execution via TSClient Mountpoint

#### Possible investigation steps

- What exact TSClient launch did the alert capture?
  - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`.
  - Implication: escalate when the redirected-drive executable is unsigned, untrusted, renamed, script-capable, or launched with command intent outside a recognized RDP support or deployment workflow; lower concern only when a vendor-signed installer or utility from the RDP client drive matches that exact session purpose.
- What launcher and Windows session produced the TSClient process?
  - Focus: `process.parent.name`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.id`.
  - Implication: escalate when the parent is "cmd.exe", "powershell.exe", "taskmgr.exe", or another remote-session launcher, when the session is remote-interactive for an unusual user, or when children show another TSClient-launched payload; lower concern when parent and session match a recognized support launcher or deployment tool.
- Which RDP source created the session, when authentication telemetry is available?
  - Focus: bridge `process.Ext.authentication_id` to same-host authentication events through `winlog.event_data.TargetLogonId`; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`. $investigate_0
  - Implication: escalate when the recovered source or authentication package conflicts with recognized jump hosts, support workstations, or deployment sources. Missing authentication telemetry is unresolved, not benign.
- Did the TSClient process spawn shells, tools, or persistence helpers on the target?
  - Focus: child starts from `process.entity_id` on `host.id`, especially `process.executable`, `process.command_line`, `process.parent.entity_id`. $investigate_1
  - Hint: if `process.entity_id` is absent, recover descendants with `host.id` + `process.pid` + a tight alert-time window and confirm the parent command line before interpreting results.
  - Implication: escalate when descendants include shells, script hosts, remote-access tools, credential utilities, or persistence helpers; an isolated installer-like launch lowers urgency only if session and identity evidence also align.
- If local evidence remains suspicious or incomplete, do related alerts show the same user or host attempting RDP or remote execution elsewhere?
  - Focus: same-user `user.id` and same-host `host.id` alerts sharing RDP, credential, remote-service, or execution patterns.
  - Hint: user alert pivot. $investigate_2
  - Hint: host alert pivot. $investigate_3
  - Implication: expand scope only when related alerts reuse the same user, host, session pattern, or command family; unrelated alert noise does not change disposition.
- Escalate when suspicious identity, lineage, source, descendants, or related alerts support unauthorized redirected-drive execution; close only when process identity, parent/session, source when available, and descendants all match one recognized RDP support or deployment activity; preserve artifacts and escalate when authentication visibility is missing or evidence remains mixed.

### False positive analysis

- RDP helpdesk, break-fix, or software deployment workflows can legitimately run installers or utilities from a client drive redirected into the target session. Confirm all evidence converges on one exact activity: identity and intent (`process.executable`, `process.command_line`, signature), launch/session (`process.parent.name`, `user.id`, `host.id`, recovered `source.ip` when available), and outcome (no suspicious descendants or related alerts). Contradictory evidence keeps the case open.
- Use recurrence only to support a narrow exception candidate, not to close the current case by itself. Require the same stable executable path or signer, parent/session pattern, `user.id`, `host.id`, recovered source when available, and descendant-clean outcome across prior alerts from this rule; keep the case open when current telemetry is incomplete or contradictory.
- Before creating an exception, anchor it on the minimum confirmed pattern: specific `process.executable`, stable `process.command_line` or signer, `process.parent.name`, `user.id`, `host.id`, and recovered `source.ip` only when it was part of the confirmation. Avoid exceptions on the TSClient path wildcard or `process.name` alone.

### Response and remediation

- Preserve evidence before changing state: case export of the alert, process tree, command line, binary hash or sample when available, child-process events, and authentication-bridge records.
- If confirmed benign after preservation, reverse temporary containment and document the exact process identity, parent/session context, `user.id`, `host.id`, and recovered `source.ip` that established the redirected-drive workflow. Create an exception only after the same narrowly scoped pattern is stable across prior alerts.
- If suspicious but unconfirmed after preservation, use reversible containment only: terminate the active RDP session, restrict new RDP connections from the recovered source when available, disable drive redirection for the affected access path, or heighten monitoring on the affected `host.id`. Do not isolate the host, terminate processes, or suspend accounts unless follow-on execution or related alerts confirm broader abuse.
- If confirmed malicious, isolate the target host when feasible, terminate the TSClient-launched process and malicious descendants after evidence capture, and disable or suspend the account or RDP access path used for the session.
- Scope before cleanup by reviewing other hosts and users tied to the same recovered source, `user.id`, distinctive `process.command_line`, signer, or hash.
- Eradicate only the staged payloads, persistence artifacts, or tooling identified during the investigation, then review whether credentials exposed in the RDP session need reset or reissue.
- Post-incident hardening: limit RDP drive redirection, restrict RDP access to managed jump hosts, retain endpoint process and Windows Security telemetry for session bridging, and document any TSClient execution patterns that should become narrow exceptions."""

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.parent.name",
    "process.parent.command_line",
    "process.Ext.session_info.logon_type",
    "process.Ext.authentication_id",
    "process.hash.sha256",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
]

[transform]

[[transform.investigate]]
label = "Authentication events for the linked session"
description = ""
providers = [
  [
    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{process.Ext.authentication_id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Child processes spawned by the TSClient launch"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", 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 = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"

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

[[rule.threat.technique]]
id = "T1570"
name = "Lateral Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1570/"

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

[rule]
description = """
Identifies the execution of a Windows Installer via transforms from unusual parent process. Adversaries may abuse
Windows installer transforms to hijack the normal execution of a legit installer for initial access and execution.
"""
id = "4b2f842b-8a9e-4e9d-91ae-0ef875efd561"
license = "Elastic License v2"
name = "Execution via Windows Installer Transforms"
os_list = ["windows"]
reference = ["https://learn.microsoft.com/en-us/windows/win32/msi/about-transforms"]
version = "1.0.6"

query = '''
sequence with maxspan=1m
[process where event.action == "start" and user.id != "S-1-5-18" and
 (process.pe.original_file_name == "msiexec.exe" or process.name : "msiexec.exe") and
 process.args : ("/i*", "-i*") and process.args : ("/q*", "-q*") and
 process.command_line : "*transforms*=*" and
 (process.parent.code_signature.subject_name in ("Microsoft Corporation", "Microsoft Windows") or process.parent.name : "python*.exe") and
 not process.args : ("TRANSFORMS=C:\\Windows\\*.MST", "\\\\*.msi") and
 not process.working_directory : "?:\\Windows\\AdminArsenal\\PDQDeployRunner\\*"]
[process where event.action in ("start", "already_running") and
 (
  (process.name : "msiexec.exe" and process.args == "/V") or

  (process.parent.name : "msiexec.exe" and process.parent.args == "/V")
  )]
'''

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

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[threat.technique.subtechnique]]
id = "T1218.007"
name = "Msiexec"
reference = "https://attack.mitre.org/techniques/T1218/007/"



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

[internal]
min_endpoint_version = "8.14.0"

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

[rule]
author = ["Elastic"]
description = """
Detects a single authenticated GKE identity from one source IP issuing a burst of API calls across many distinct
actions and resources with a mix of successful and failed outcomes. That pattern is consistent with automated RBAC
permission enumeration rather than steady-state controller traffic. Anonymous probing is covered by a separate rule.
"""
false_positives = [
    """
    Administrators troubleshooting RBAC from a workstation or VPN may generate mixed allow/deny results across many
    APIs in a short window; tune by identity or source IP after validation.
    """,
    """
    Newly deployed workloads with incomplete RoleBindings can probe several APIs during startup and encounter
    intermittent denials; exclude known service accounts if documented.
    """,
]
from = "now-6m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "GKE Endpoint Permission Enumeration"
note = """## Triage and analysis

### Investigating GKE Endpoint Permission Enumeration

The rule aggregates GKE audit events per `client.user.email` and `source.ip` over the rule lookback. It alerts when
the actor hits more than five distinct `event.action` values and more than three distinct `gcp.audit.resource_name`
values, produces both success and failure outcomes, and stays under 75 total events. Use
`Esql.earliest_timestamp` and `Esql.latest_timestamp` to bound the burst in Discover.

### Possible investigation steps

- Review `Esql.event_action_values`, `Esql.gcp_audit_resource_name_values`, and `Esql.event_outcome_values` for targeted APIs
  (secrets, RBAC, pods/exec) and which calls succeeded.
- Confirm whether `source.ip` and `Esql.user_agent_original_values` match expected admin or automation clients.
- Hunt for follow-on activity from the same identity: RoleBinding changes, secret reads, privileged pod creates, or
  exec.

### False positive analysis

- Platform engineers validating least-privilege RBAC can look like enumeration; correlate with change tickets.
- Chatty operators that occasionally fail authorization may approach the thresholds; raise exclusions only after
  confirming the identity is expected.

### Response and remediation

- If malicious, revoke or rotate the credential, tighten RBAC, and inspect for data access or persistence after the
  burst.
"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access",
]
risk_score = 47
rule_id = "65985cd5-e654-40fe-8bc7-de26cb95309f"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-gcp.audit-* metadata _id, _index, _version
| where data_stream.dataset == "gcp.audit"
    and service.name == "k8s.io"
    and client.user.email is not null
    and source.ip is not null
    and to_string(source.ip) != "127.0.0.1"
    and to_string(source.ip) != "::1"
    and client.user.email != "system:anonymous"
    and client.user.email != "system:unauthenticated"
    and gcp.audit.resource_name != "readyz"
    and gcp.audit.resource_name != "livez"
    and gcp.audit.resource_name != "healthz"
    and gcp.audit.resource_name != "version"
| stats
    Esql.document_count = count(),
    Esql.event_outcome_count_distinct = count_distinct(event.outcome),
    Esql.event_action_count_distinct = count_distinct(event.action),
    Esql.gcp_audit_resource_name_count_distinct = count_distinct(gcp.audit.resource_name),
    Esql.earliest_timestamp = min(@timestamp),
    Esql.latest_timestamp = max(@timestamp),
    Esql.event_action_values = values(event.action),
    Esql.event_outcome_values = values(event.outcome),
    Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name),
    Esql.user_agent_original_values = values(user_agent.original)
  by client.user.email, source.ip
| where Esql.event_outcome_count_distinct == 2
    and Esql.event_action_count_distinct > 5
    and Esql.gcp_audit_resource_name_count_distinct > 3
    and Esql.document_count < 75
| keep Esql.*, client.user.email, source.ip
'''

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

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

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

[metadata]
creation_date = "2020/02/18"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/08/03"

[rule]
author = ["Elastic"]
description = """
Indicates the creation of a scheduled task. Adversaries can use these to establish persistence, move laterally, and/or
escalate privileges.
"""
false_positives = ["Legitimate scheduled tasks may be created during installation of new software."]
from = "now-9m"
index = ["winlogbeat-*", "logs-endpoint.events.process-*", "logs-windows.sysmon_operational-*"]
language = "eql"
license = "Elastic License v2"
name = "Local Scheduled Task 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 Local Scheduled Task Creation

Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, or privilege escalation. They may use command-line tools like `schtasks.exe` to create tasks under non-system accounts. The detection rule identifies suspicious task creation by monitoring specific processes and command-line arguments, excluding those initiated by system-level users, to flag potential misuse.

### Possible investigation steps

- Review the process entity ID to identify the parent process that initiated the scheduled task creation. This can provide context on whether the task was created by a legitimate application or a potentially malicious one.
- Examine the command-line arguments used with schtasks.exe, specifically looking for unusual or suspicious parameters that might indicate malicious intent, such as unexpected task names or execution paths.
- Check the user account associated with the task creation to determine if it is a non-system account and assess whether this account should have the capability to create scheduled tasks.
- Investigate the integrity level of the process to confirm it is not running with elevated privileges, which could indicate an attempt to bypass security controls.
- Correlate the event with other recent activities on the host, such as file modifications or network connections, to identify any patterns or additional indicators of compromise.
- Review the code signature of the initiating process to determine if it is trusted or untrusted, which can help assess the legitimacy of the process creating the task.

### False positive analysis

- Scheduled tasks created by legitimate administrative tools or scripts may trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts.
- Routine maintenance tasks initiated by IT departments, such as software updates or system checks, can be mistaken for suspicious activity. Exclude these tasks by specifying their unique process names or command-line arguments.
- Tasks created by trusted third-party applications for legitimate purposes might be flagged. Review and exclude these applications by verifying their code signatures and adding them to an exception list.
- Automated tasks set up by non-system accounts for regular operations, like backups or monitoring, can be misinterpreted. Document these tasks and exclude them based on their specific parameters or user accounts involved.
- Consider excluding tasks with a consistent and verified schedule that aligns with organizational policies, as these are less likely to be malicious.

### Response and remediation

- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
- Terminate any suspicious scheduled tasks identified by the alert using Task Scheduler or command-line tools like schtasks.exe to stop further execution.
- Review and remove any unauthorized scheduled tasks created by non-system accounts to eliminate persistence mechanisms.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious artifacts.
- Analyze the user account involved in the task creation for signs of compromise, and reset credentials if necessary to prevent further unauthorized access.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for scheduled task creation events to detect similar threats in the future, ensuring alerts are configured to notify the appropriate teams promptly."""
references = [
    "https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1",
    "https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-2",
    "https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine",
    "https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper",
]
risk_score = 21
rule_id = "afcce5ad-65de-4ed2-8516-5e093d3ac99a"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence with maxspan=1m
  [process where host.os.type == "windows" and event.type == "start" and
    ((process.name : ("cmd.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "mshta.exe",
                      "powershell.exe", "pwsh.exe", "powershell_ise.exe", "WmiPrvSe.exe", "wsmprovhost.exe", "winrshost.exe") or
    process.pe.original_file_name : ("cmd.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "mshta.exe",
                                     "powershell.exe", "pwsh.dll", "powershell_ise.exe", "WmiPrvSe.exe", "wsmprovhost.exe",
                                     "winrshost.exe")) or
    ?process.code_signature.trusted == false) and
    /* exclude legitimate software creating its own scheduled tasks */
    not (
      process.name : "cmd.exe" and
      (
        (
          process.parent.executable : "?:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\libs\\node.exe" and
          process.command_line : "*?:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\CCXProcess.exe*"
        ) or
        (
          process.parent.executable : "?:\\Program Files (x86)\\LG Software\\LG App Count\\LGAppCountObserver.exe" and
          process.command_line : "*?:\\Program Files (x86)\\LG Software\\LG App Count\\*"
        ) or
        (
          process.parent.executable : "?:\\Program Files (x86)\\LG Software\\LG Update & Recovery\\URAlarm.exe" and
          process.command_line : "*?:\\Program Files (x86)\\LG Software\\LG Update & Recovery\\Support\\*"
        )
      )
    )
  ] by process.entity_id
  [process where host.os.type == "windows" and event.type == "start" and
    (process.name : "schtasks.exe" or process.pe.original_file_name == "schtasks.exe") and
    process.args : ("/create", "-create") and process.args : ("/RU", "/SC", "/TN", "/TR", "/F", "/XML") and
    /* exclude SYSTEM Integrity Level - look for task creations by non-SYSTEM user */
    not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System")
  ] by process.parent.entity_id
'''

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:

- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
"""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"
[[rule.threat.technique.subtechnique]]
id = "T1053.005"
name = "Scheduled Task"
reference = "https://attack.mitre.org/techniques/T1053/005/"



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

[rule]
description = """
This rule detects when a process creates an in-memory file descriptor (memfd_create) followed by an egress network
connection from an unusual executable. This sequence of events may indicate malicious activity, such as fileless malware
execution and command and control communication.
"""
id = "387aa854-d2ce-425f-be4a-c17f67bc2e41"
license = "Elastic License v2"
name = "Memory File Descriptor Execution from Suspicious Process"
os_list = ["linux"]
reference = ["https://man7.org/linux/man-pages/man2/memfd_create.2.html"]
version = "1.0.11"

query = '''
sequence by process.entity_id with maxspan=30s
  [process where event.type == "start" and event.action == "memfd_create" and process.parent.executable != null and (
    process.executable like (
      "memfd:*", "?memfd:*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/user/*", "/var/run/user/*",
      "/boot/*", "/sys/*", "/lost+found/*", "/proc/*", "/var/mail/*", "/var/www/*", "/root/*", "/home/*/*"
    ) or
     process.name like ".*"
   ) and
  not (
    process.parent.command_line == "buildah-chroot-runtime" or
    process.command_line == "buildah-chroot-runtime" or
    process.parent.args == "/usr/bin/crun" or
    process.parent.executable like (
      "/usr/bin/nvidia-ctk", "/home/*/.local/share/Steam/*", "./usr/bin/qemu-aarch64", "/dev/.buildkit_qemu_emulator",
      "/snap/docker/*/usr/bin/nvidia-ctk", "/usr/bin/nvidia-cdi-hook", "./usr/local/nvidia/toolkit/nvidia-cdi-hook.real",
      "./usr/bin/qemu-s390x", "/usr/bin/cosmic-files", "/nix/store/*-rofi-unwrapped-*/bin/rofi", "/usr/bin/minecraft-launcher",
      "/usr/local/nvidia/toolkit/nvidia-cdi-hook.real", "/home/*/.steam/*"
    ) or
    process.executable like (
      "./usr/bin/qemu-aarch64", ".", "/home/*/bin/firefox/firefox-bin", "/home/*/bin/firefox/updater",
      "/home/*/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/updater", "/home/*/.local/opt/tor-browser/app/Browser/updater",
      "/home/*/.local/opt/tor-browser/app/Browser/firefox.real", "/home/*/snap/steam/common/.local/share/Steam/steamapps/common/*/bin/pressure-vessel-wrap",
      "/home/*/.local/share/zen/zen", "/home/*/.local/share/zen/updater", "/home/*/.local/share/umu/steamrt4/pressure-vessel/bin/pressure-vessel-wrap",
      "/home/*/.local/share/Steam/steamapps/common/*/pressure-vessel-wrap", "/home/*/tor-browser-linux-*/tor-browser/Browser/updater",
      "/home/*/.local/share/claude/versions/*", "/home/*/Downloads/*/firefox/*", "/home/*/.local/share/umu/steamrt3/pressure-vessel/bin/steam-runtime-launch-client",
      "/home/*/Desktop/crun/crun-src/crun/crun",
      "/home/*/Zotero_linux-x86_64/*"
    )
  )]
  [process where event.type == "start" and event.action == "exec"]
'''

min_endpoint_version = "9.1.4"
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 = "T1106"
name = "Native API"
reference = "https://attack.mitre.org/techniques/T1106/"


[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.technique.subtechnique]]
id = "T1055.009"
name = "Proc Memory"
reference = "https://attack.mitre.org/techniques/T1055/009/"


[[threat.technique]]
id = "T1620"
name = "Reflective Code Loading"
reference = "https://attack.mitre.org/techniques/T1620/"


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

[internal]
min_endpoint_version = "9.1.4"

[rule]
description = """
Identifies the load of a library that was recently copied and with a unusual memory allocation properties. This may be
the result of a code injection using module stomping or DLL hollowing via overwriting the content of legit DLL with
malicious code.
"""
id = "c3758f2c-66d5-4cbe-820f-1c6207c6e341"
license = "Elastic License v2"
name = "Module Stomping from a Copied Library"
os_list = ["windows"]
version = "1.0.22"

query = '''
sequence by user.id with maxspan=3m

[file where event.action != "deletion" and
 not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and

  /* PE file dropped via CopyFile API calls  */
  file.Ext.header_bytes : "4d5a*" and
 _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: ("*CopyFileEx*", "*MoveFileExW*")) and

 not process.executable : ("?:\\Program Files (x86)\\Citrix\\ICA Client\\concentr.exe",  
                           "?:\\Program Files (x86)\\InstallShield Installation Information\\*\\setup.exe") and
 not file.path : ("?:\\Program Files (x86)\\Web Components\\NetStream.dll", "C:\\WINDOWS\\system32\\myah0.cpl")] as event0

[library where

  /* common networing and recon system modules */
  dll.name : ("ws2_32.dll", "dnsapi.dll", "wininet.dll", "psapi.dll", "vaultcli.dll") and

  /* stack starts from the recently dropped PE */
  endswith~(process.thread.Ext.call_stack_summary, event0.file.name) and

  /* Process name is different from the dropped PE */
  process.name != event0.file.name and

  /* Abnormal private bytes allocation for the dropped PE when loaded in memory */
 _arraysearch(process.thread.Ext.call_stack, $entry,
              $entry.allocation_private_bytes >= 100000 and startswith~($entry.symbol_info, event0.file.path))]
'''

min_endpoint_version = "8.7.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 = "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.7.0"

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

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

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

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

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

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

[[transform.osquery]]
label = "Osquery - Retrieve Process Info"
query = "SELECT name, cmdline, parent, path, uid FROM processes"

[rule]
author = ["Elastic"]
description = """
This rule monitors for the execution of the cat command, followed by a connection attempt by the same process. Cat is
capable of transfering data via tcp/udp channels by redirecting its read output to a /dev/tcp or /dev/udp channel. This
activity is highly suspicious, and should be investigated. Attackers may leverage this capability to transfer tools or
files to another host in the network or exfiltrate data while attempting to evade detection in the process.
"""
from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Network Activity Detected via cat"
note = """## Triage and analysis

### Investigating Network Activity Detected via cat

Attackers may leverage the `cat` utility in conjunction with a listener to read all bytes of a file, and output the content to a `/dev/tcp` or `/dev/udp` channel to transfer/exfiltrate file contents to a remote system. 

This rule looks for a sequence of a `cat` execution event followed by a network connection attempt by the same `cat` process. 

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

#### Possible investigation steps

- Identify any signs of suspicious network activity or anomalies that may indicate command and control activity or data exfiltration. This could include unexpected traffic patterns or unusual network behavior.
  - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration.
    - $osquery_0
    - $osquery_1
- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action.
  - $osquery_2
- Investigate whether the user is currently logged in and active.
  - $osquery_3
- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
  - $osquery_4
  - $osquery_5
- Investigate other alerts associated with the user/host during the past 48 hours.
  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
    - Use a private sandboxed malware analysis system to perform analysis.
      - Observe and collect information about the following activities:
        - Attempts to contact external domains and addresses.
          - Check if the domain is newly registered or unexpected.
          - Check the reputation of the domain or IP address.
        - File access, modification, and creation activities.

### Related rules

- Suspicious Network Activity to the Internet by Previously Unknown Executable - 53617418-17b4-4e9c-8a2c-8deb8086ca4b

### False positive analysis

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

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
risk_score = 47
rule_id = "afd04601-12fc-4149-9b78-9c3f8fe45d39"
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: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id, process.entity_id with maxspan=3s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
   process.name == "cat" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")]
  [network where host.os.type == "linux" and event.action in ("connection_attempted", "disconnect_received") and
   process.name == "cat" 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"
     )
   )]
'''

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

[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 = "T1048"
name = "Exfiltration Over Alternative Protocol"
reference = "https://attack.mitre.org/techniques/T1048/"

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