Elastic rules: 1e

[metadata]
creation_date = "2026/02/09"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies AWS API activity originating from uncommon desktop client applications based on the user agent string. This
rule detects S3 Browser and Cyberduck, which are graphical S3 management tools that provide bulk upload/download
capabilities. While legitimate, these tools are rarely used in enterprise environments and have been observed in use by
threat actors for data exfiltration. Any activity from these clients should be validated against authorized data
transfer workflows.
"""
false_positives = [
    """
    Some organizations may have legitimate use cases for S3 Browser or Cyberduck, particularly in development, data
    migration, or backup scenarios. Verify whether the IAM principal, source network, and accessed buckets align with
    approved workflows. Unexpected activity from these clients, especially accessing sensitive buckets, should be
    investigated.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS API Activity from Uncommon S3 Client by Rare User"
note = """## Triage and Analysis

### Investigating AWS API Activity from Uncommon S3 Client by Rare User

S3 Browser and Cyberduck are graphical clients for Amazon S3 that allow users to browse, upload, download, and manage S3 objects. While legitimate tools, they are uncommonly used in enterprise environments where organizations typically standardize on AWS CLI, SDKs, or console access. The presence of these tools may indicate unauthorized data access or exfiltration activity.

This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that identifies the first time a specific user within an account makes API calls using S3 Browser or Cyberduck user agent strings. Threat actors have been observed using these tools for their intuitive interface and bulk data transfer capabilities during post-compromise data theft operations.

### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which IAM principal was used.
  - Check whether this principal normally accesses S3 and whether usage of these desktop clients is expected or authorized.

- **Review accessed resources**
  - Examine `aws.cloudtrail.resources.arn` to identify which S3 buckets and objects were accessed.
  - Determine whether the accessed data is sensitive, confidential, or subject to data protection policies.
  - Look for patterns indicating bulk downloads or systematic enumeration of bucket contents.

- **Analyze the actions performed**
  - Review `event.action` to understand what operations were performed (e.g., `GetObject`, `ListBucket`, `PutObject`).
  - High volumes of `GetObject` calls may indicate data exfiltration.
  - `PutObject` calls to external buckets could indicate data staging for exfiltration.

- **Inspect source network context**
  - Review `source.ip` and `source.geo` fields to determine the origin of the request.
  - Check whether the IP belongs to corporate infrastructure, VPN, or an unexpected external location.
  - External IPs combined with these desktop client tools are high-risk indicators.

- **Correlate with surrounding activity**
  - Search for additional CloudTrail events from the same access key or session.
  - Look for preceding credential theft indicators such as `GetSecretValue`, `CreateAccessKey`, or console logins.
  - Check for cross-account transfers or `CreateBucket` calls in external accounts.

### False positive analysis

- **Authorized data migration or backup activities** may use these tools. Confirm with data engineering or IT teams.
- **Developer testing** in non-production environments may occasionally involve these clients. Validate the environment and data sensitivity.
- **Third-party integrations** using Cyberduck libraries may generate this user agent. Verify the automation context.

### Response and remediation

- **If unauthorized**, immediately revoke or rotate the affected access keys and invalidate active sessions.
- **Assess data exposure** by reviewing which objects were accessed and determining if sensitive data was compromised.
- **Notify security operations** and initiate incident response procedures if exfiltration is confirmed.
- **Implement preventive controls** such as S3 bucket policies restricting access by user agent or requiring VPC endpoints.

### 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)**
- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
"""
references = [
    "https://s3browser.com/",
    "https://cyberduck.io/",
    "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud",
    "https://attackevals.github.io/ael/enterprise/scattered_spider/emulation_plan/scattered_spider_scenario/",
]
risk_score = 21
rule_id = "73344d2d-9cfb-4daf-b3c5-1d40a8182b86"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS S3",
    "Tactic: Exfiltration",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and user_agent.original: (*S3 Browser* or *Cyberduck*)
    and event.outcome: "success"
'''


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

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

[[rule.threat.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 = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

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

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

[metadata]
creation_date = "2020/06/05"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
description = """
Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures
that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys.
Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by
default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection
before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or
ransomware-style attacks that depend on unencrypted volumes.
"""
false_positives = [
    """
    Disabling encryption may be done by a system or network administrator. Verify whether the user identity, user agent,
    and/or hostname should be making changes in your environment. Disabling encryption by 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 Encryption Disabled"
note = """## Triage and analysis

### Investigating AWS EC2 Encryption Disabled

Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys.  
When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption.  
This action can have serious security implications as it can weaken the organization’s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls.

#### Possible investigation steps

**Identify the initiator and context**
- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action.  
  - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser).  
  - Validate whether the actor is authorized to modify account-level encryption defaults.
- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host.
- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse.

**Review the timing and scope**
- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications.  
- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign.
- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated.

**Assess data exposure risk**
- Identify newly created or modified EBS volumes after the timestamp of this change.  
  - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`.  
- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes.  
- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration.

**Correlate related security events**
- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering.  
- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely.
- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off.

### False positive analysis

- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change.  
- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded.  
- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources.

If confirmed as expected, document the change request, implementation window, and user responsible for traceability.

### Response and remediation

**Containment and restoration**
- Re-enable EBS encryption by default in the affected region to restore protection for new volumes:
  - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default.  
  - Or via CLI/API: `enable-ebs-encryption-by-default`.  
- Audit recently created EBS volumes and snapshots.  
  - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows.  
- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant.

**Investigate and scope**
- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission.  
- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role.  
- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications.

**Long-term hardening**
- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts.  
- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting.  
- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity.
- Educate administrators on data protection implications and require change approvals for encryption-related settings.

**Recovery validation**
- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines.  
- Confirm that subsequent EBS volumes are created with `Encrypted:true`.  
- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits.

### Additional information

- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: guidance for investigating unauthorized access to modify account settings.  
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services
- **AWS Documentation: [EBS Encryption at Rest](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)**
"""
references = [
    "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html",
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disable-ebs-encryption-by-default.html",
    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisableEbsEncryptionByDefault.html",
]
risk_score = 47
rule_id = "bb9b13b2-1700-48a8-a750-b43b0a72ab69"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS EC2",
    "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:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault and event.outcome:success
    and not user_agent.original: (*Terraform*)
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1565.001"
name = "Stored Data Manipulation"
reference = "https://attack.mitre.org/techniques/T1565/001/"

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

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

[[rule.threat.technique]]
id = "T1578"
name = "Modify Cloud Compute Infrastructure"
reference = "https://attack.mitre.org/techniques/T1578/"

[[rule.threat.technique.subtechnique]]
id = "T1578.005"
name = "Modify Cloud Compute Configurations"
reference = "https://attack.mitre.org/techniques/T1578/005/"

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

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

[rule]
author = ["Austin Songer", "Elastic"]
description = """
Identifies when an AWS Route 53 private hosted zone is associated with a new Virtual Private Cloud (VPC). Private hosted
zones restrict DNS resolution to specific VPCs, and associating additional VPCs expands the scope of what networks can
resolve internal DNS records. Adversaries with sufficient permissions may associate unauthorized VPCs to intercept,
observe, or reroute internal traffic, establish persistence, or expand their visibility within an AWS environment.
"""
false_positives = [
    """
    Private hosted zones may be legitimately associated with VPCs by network or infrastructure administrators. Verify
    whether the user identity, user agent, and source IP address align with expected administrative behavior. Known and
    authorized associations may be exempted to reduce noise.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Route 53 Private Hosted Zone Associated With a VPC"
note = """## Triage and analysis

### Investigating AWS Route 53 Private Hosted Zone Associated With a VPC

Route 53 private hosted zones provide internal DNS capabilities accessible only to the VPCs explicitly associated with
them. Associating a new VPC expands DNS visibility and access. If an adversary gains sufficient IAM permissions, they may
attach unauthorized VPCs to privileged hosted zones to perform internal reconnaissance, intercept service discovery,
redirect traffic, or gain persistence by manipulating internal name resolution.

This rule detects successful `AssociateVPCWithHostedZone` events where a hosted zone's visibility scope is modified.

### Possible investigation steps

- **Identify the Actor**
  - Review `aws.cloudtrail.user_identity.arn` and `access_key_id` to determine who initiated the association. Validate whether this identity is expected to manage Route 53 or VPC networking.

- **Review Request Details**
  - Examine `aws.cloudtrail.request_parameters` to confirm which hosted zone and VPC were associated. Determine if the hosted zone contains sensitive internal service records, privileged DNS, or identity service endpoints.

- **Validate the VPC**
  - Identify whether the associated VPC belongs to an authorized environment (e.g., known production, staging, or internal networks). Check for unusual VPC creation events, cross-account VPC behavior, or recently observed anomalous resource provisioning.

- **Assess Source Context**
  - Inspect `source.ip` and `user_agent.original` for geographic anomalies, automation patterns, or suspicious tooling.
  - Look for correlations with unusual IAM activity, privilege escalations, or policy modifications.

- **Correlate With Broader Activity**
  - Search for additional changes involving the same identity, including:
    - Route 53 hosted zone modifications
    - VPC peering creation
    - Network ACL or security group changes
    - IAM privilege modifications
  - Identify whether this association is part of a larger sequence suggesting lateral movement or internal reconnaissance.

- **Engage Relevant Teams**
  - If initiated by a user, confirm intent with networking or cloud infrastructure teams. Validate whether the association aligns with deployment, migration, or environment expansion activities.

### False positive analysis

- **Routine Infrastructure Updates**
  - Associations may occur during normal environment expansions (new VPC for microservices, deployments, region expansion).

- **Automated Tooling**
  - Infrastructure-as-code pipelines (Terraform, CloudFormation, CDK) may regularly modify hosted zone associations.
  - If confirmed legitimate, consider excluding specific automation IAM roles.

- **Migration or Restructuring Events**
  - Large-scale cloud migrations or VPC re-architecture work may trigger frequent legitimate associations.

### Response and remediation

- **Revoke Unauthorized Access**
  - If the association is unauthorized, review and restrict IAM permissions for the actor.
  - Remove the VPC association if it is not intended.

- **Investigate Potential Impact**
  - Review internal DNS query logs and VPC flow logs for any misuse, suspicious lookups, or unauthorized cross-VPC traffic.

- **Strengthen IAM Controls**
  - Limit `route53:AssociateVPCWithHostedZone` to specific administrative roles.
  - Require MFA for accounts with Route 53 and VPC modification permissions.

- **Monitor for Related Activity**
  - Add monitoring for other hosted zone modifications, new VPC creation, and cross-account network configurations.

- **Communicate and Document**
  - Notify cloud networking and security operations of unauthorized changes.
  - Document findings and update policy controls or automation baselines.

### 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)** 
- **[AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)**
"""
references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html"]
risk_score = 47
rule_id = "e3c27562-709a-42bd-82f2-3ed926cced19"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Route 53",
    "Tactic: Persistence",
    "Tactic: Resource Development",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

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

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

[[rule.threat.technique]]
id = "T1583"
name = "Acquire Infrastructure"
reference = "https://attack.mitre.org/techniques/T1583/"

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

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

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

[rule]
description = """
Identifies the execution of commonly abused utilities to run DLLs or scripts via the Outlook.Application COM Object.
This behavior may indicate adversarial activity to evade defenses on the system.
"""
id = "17030515-5ed0-43c8-9602-f97cbebd43c0"
license = "Elastic License v2"
name = "Execution via Outlook Application COM Object"
os_list = ["windows"]
reference = ["https://www.darkoperator.com/blog/2017/11/11/windows-defender-exploit-guard-asr-rules-for-office"]
version = "1.0.33"

query = '''
sequence with maxspan=1m
   /* Outlook started via DCOM */
 [process where event.action == "start" and
  process.name : "outlook.exe" and process. command_line : "*-Embedding*" and
  process.parent.name : "svchost.exe"] by process.entity_id
   /* Suspicious Outlook child processes */
 [process where event.action == "start" and
   process.pe.original_file_name :
               ("cscript.exe",
                "wscript.exe",
                "powershell.exe",
                "rundll32.exe",
                "cmd.exe",
                "mshta.exe",
                "msbuild.exe",
                "InstallUtil.exe",
                "Microsoft.Workflow.Compiler.exe",
                "wmic.exe",
                "regsvr32.exe",
                "pwsh.exe",
                "ScriptRunner.exe") and not
   /* Issue #330 */
   (process.name:"rundll32.exe" and process.args : ("--eoim", "--enable-speech-input")) and

   not (process.name : "rundll32.exe" and process.args : "?:\\WINDOWS\\sys*\\spool\\DRIVERS\\x64\\3\\*.dll,MonitorPrintJobStatus")] by process.parent.entity_id
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[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.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[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.005"
name = "Mshta"
reference = "https://attack.mitre.org/techniques/T1218/005/"

[[threat.technique.subtechnique]]
id = "T1218.010"
name = "Regsvr32"
reference = "https://attack.mitre.org/techniques/T1218/010/"

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



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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a
special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use
service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud
Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a
security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions
assigned to that account and evade detection.
"""
false_positives = [
    """
    Service account keys may be created by system administrators. Verify that the configuration change was expected.
    Exceptions can be added to this rule to filter expected behavior.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Service Account Key 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 GCP Service Account Key Creation

In GCP, service accounts are crucial for applications to authenticate and interact with Google services securely. They use cryptographic keys for API access, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. The detection rule monitors audit logs for new key creations, flagging potential misuse by identifying successful key generation events, thus helping to mitigate risks associated with unauthorized access.

### Possible investigation steps

- Review the audit logs for the specific event.action: google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation.
- Check the event.dataset:gcp.audit logs to determine the user or process that initiated the key creation and verify if it aligns with expected behavior or scheduled tasks.
- Investigate the permissions and roles assigned to the service account to assess the potential impact of the new key being used maliciously.
- Examine the event.outcome:success logs to confirm the successful creation of the key and cross-reference with any recent changes or deployments that might justify the key creation.
- Contact the owner or responsible team for the service account to verify if the key creation was authorized and necessary for their operations.
- Review any recent alerts or incidents related to the service account to identify patterns or repeated unauthorized activities.

### False positive analysis

- Routine key rotations by automated processes can trigger alerts. To manage this, identify and whitelist these processes by their service account names or associated metadata.
- Development and testing environments often generate new keys frequently. Exclude these environments from alerts by using environment-specific tags or labels.
- Scheduled maintenance activities by cloud administrators may involve key creation. Document these activities and create exceptions based on the timing and user accounts involved.
- Third-party integrations that require periodic key updates can cause false positives. Maintain a list of trusted third-party services and exclude their key creation events from alerts.
- Internal tools or scripts that programmatically create keys for operational purposes should be reviewed and, if deemed safe, added to an exception list based on their execution context.

### Response and remediation

- Immediately revoke the newly created service account key to prevent unauthorized access. This can be done through the GCP Console or using the gcloud command-line tool.
- Conduct a thorough review of the service account's permissions to ensure they are aligned with the principle of least privilege. Remove any unnecessary permissions that could be exploited.
- Investigate the source of the key creation event by reviewing audit logs to identify the user or process responsible for the action. Determine if the action was authorized or if it indicates a potential compromise.
- If unauthorized access is suspected, rotate all keys associated with the affected service account and any other potentially compromised accounts to mitigate further risk.
- Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future.
- Escalate the incident to the security team for further investigation and to determine if additional containment or remediation actions are necessary, including notifying affected stakeholders if a breach is confirmed.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://cloud.google.com/iam/docs/service-accounts",
    "https://cloud.google.com/iam/docs/creating-managing-service-account-keys",
]
risk_score = 73
rule_id = "0e5acaae-6a64-4bbc-adb8-27649c03f7e1"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.001"
name = "Additional Cloud Credentials"
reference = "https://attack.mitre.org/techniques/T1098/001/"

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

[metadata]
creation_date = "2023/10/12"
integration = ["lmd", "endpoint"]
maturity = "production"
updated_date = "2026/07/27"
min_stack_version = "9.4.0"
min_stack_comments = "Use EA (Entity Analytics) fields"

[rule]
anomaly_threshold = 70
author = ["Elastic"]
description = """
A machine learning job has detected unusually high mean of RDP session duration. Long RDP sessions can be used to evade
detection mechanisms via session persistence, and might be used to perform tasks such as lateral movement, that might
require uninterrupted access to a compromised machine.
"""
from = "now-12h"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = "lmd_high_mean_rdp_session_duration_ea"
name = "High Mean of RDP Session Duration"
references = [
    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
    "https://docs.elastic.co/en/integrations/lmd",
    "https://www.elastic.co/blog/detecting-lateral-movement-activity-a-new-kibana-integration",
    "https://www.elastic.co/blog/remote-desktop-protocol-connections-elastic-security",
]
risk_score = 21
rule_id = "a74c60cb-70ee-4629-a127-608ead14ebf1"
setup = """## Setup

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

If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).

The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration.

### Lateral Movement Detection Setup
The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature.

#### Prerequisite Requirements:
- Fleet is required for Lateral Movement Detection.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
- Windows RDP process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration.
- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).

#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration:
- Go to the Kibana homepage. Under Management, click Integrations.
- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it.
- Follow the instructions under the **Installation** section.
- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
"""
severity = "low"
tags = [
    "Data Source: Elastic Defend",
    "Use Case: Lateral Movement Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
type = "machine_learning"
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 High Mean of RDP Session Duration

Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity.

### Possible investigation steps

- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session lengths.
- Correlate the flagged RDP session with user activity logs to determine if the session aligns with expected user behavior or if it deviates from normal patterns.
- Check for any concurrent or subsequent suspicious activities, such as file transfers or command executions, that might indicate lateral movement or data exfiltration.
- Investigate the source and destination IP addresses involved in the RDP session to identify if they are known, trusted, or associated with any previous security incidents.
- Analyze the user account involved in the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access patterns.
- Review any recent changes in the network or system configurations that might have affected RDP session durations or security settings.

### False positive analysis

- Extended RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities.
- Scheduled maintenance or software updates often require prolonged RDP sessions. Exclude these activities by setting time-based exceptions during known maintenance windows.
- Remote support sessions from trusted third-party vendors may appear as anomalies. Create exceptions for these vendors by verifying their IP addresses and adding them to an allowlist.
- Training sessions or demonstrations using RDP can result in longer session durations. Document and exclude these events by correlating them with scheduled training times and user accounts involved.
- Automated scripts or processes that maintain RDP sessions for monitoring purposes can be mistaken for threats. Identify these scripts and exclude their associated user accounts or machine names from the detection rule.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious or unauthorized RDP sessions to cut off potential adversary access.
- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts.
- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
- Restore the system from a known good backup if any unauthorized changes or malware are detected.
- Monitor network traffic and logs for any signs of further exploitation attempts or related suspicious activity.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation."""
[[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 = "T1210"
name = "Exploitation of Remote Services"
reference = "https://attack.mitre.org/techniques/T1210/"

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

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

[rule]
author = ["Elastic"]
description = """
The Debugger and SilentProcessExit registry keys can allow an adversary to intercept the execution of files, causing a
different process to be executed. This functionality can be abused by an adversary to establish persistence.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.registry-*",
    "endgame-*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Image File Execution Options Injection"
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 Image File Execution Options Injection

Image File Execution Options (IFEO) is a Windows feature allowing developers to debug applications by specifying an alternative executable to run. Adversaries exploit this by setting a debugger to execute malicious code instead, achieving persistence or evasion. The detection rule identifies changes to specific registry keys associated with IFEO, flagging potential misuse by monitoring for unexpected executables being set as debuggers.

### Possible investigation steps

- Review the registry path and value that triggered the alert to identify the specific executable or process being targeted for debugging or monitoring.
- Check the registry.data.strings field to determine the unexpected executable set as a debugger or monitor process, and assess its legitimacy.
- Investigate the origin and purpose of the executable found in the registry.data.strings by checking its file properties, digital signature, and any associated metadata.
- Correlate the alert with recent system or user activity to identify any suspicious behavior or changes that coincide with the registry modification.
- Examine the system for additional indicators of compromise, such as unusual network connections, file modifications, or other registry changes, to assess the scope of potential malicious activity.
- Consult threat intelligence sources to determine if the identified executable or behavior is associated with known malware or threat actors.

### False positive analysis

- ThinKiosk and PSAppDeployToolkit are known to trigger false positives due to their legitimate use of the Debugger registry key. Users can mitigate this by adding exceptions for these applications in the detection rule.
- Regularly review and update the list of exceptions to include any new legitimate applications that may use the Debugger or MonitorProcess registry keys for valid purposes.
- Monitor the environment for any new software installations or updates that might interact with the IFEO registry keys and adjust the rule exceptions accordingly to prevent unnecessary alerts.
- Collaborate with IT and security teams to identify any internal tools or scripts that might be using these registry keys for legitimate reasons and ensure they are accounted for in the rule exceptions.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
- Terminate any suspicious processes identified as being executed through the IFEO mechanism to halt any ongoing malicious activity.
- Revert any unauthorized changes to the registry keys associated with Image File Execution Options and SilentProcessExit to their default or intended state.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
- Review and restore any altered or deleted system files from a known good backup to ensure system integrity.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for registry changes related to IFEO to detect and respond to similar threats in the future."""
references = [
    "https://oddvar.moe/2018/04/10/persistence-using-globalflags-in-image-file-execution-options-hidden-from-autoruns-exe/",
]
risk_score = 47
rule_id = "6839c821-011d-43bd-bd5b-acff00257226"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type == "change" and
  registry.value : ("Debugger", "MonitorProcess") and length(registry.data.strings) > 0 and
  registry.path : (
    "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger",
    "HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger",
    "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess",
    "HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess",
    "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger",
    "\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger",
    "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess",
    "\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess",
    "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger",
    "MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger",
    "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess",
    "MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess"
  ) and
    /* add FPs here */
  not registry.data.strings regex~ ("""C:\\Program Files( \(x86\))?\\ThinKiosk\\thinkiosk\.exe""", """.*\\PSAppDeployToolkit\\.*""")
'''

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.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[rule.threat.technique.subtechnique]]
id = "T1546.012"
name = "Image File Execution Options Injection"
reference = "https://attack.mitre.org/techniques/T1546/012/"



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


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

[metadata]
creation_date = "2026/02/20"
integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate
discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare
for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting,
performance analysis, or observability tooling validation.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Kernel Instrumentation Discovery via kprobes and tracefs"
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 Kernel Instrumentation Discovery via kprobes and tracefs

This rule detects common Linux utilities and shells reading kprobes and tracing locations under debugfs/tracefs, signaling discovery of kernel instrumentation hooks. Attackers use this to understand which kprobe/tracepoint interfaces are available or already in use before deploying eBPF-based collection or stealthy monitoring. A typical pattern is a script that iterates tracing directories and reads kprobe and tracepoint listings to map callable probes and active tracing state.

### Possible investigation steps

- Review the full command line and the specific tracefs/debugfs paths accessed to determine whether this was benign directory enumeration or targeted inspection of sensitive files like `available_filter_functions`, `kprobe_events`, `set_ftrace_filter`, or `trace_pipe`.  
- Identify the initiating user and process tree, then search nearby activity for follow-on steps such as writing to `kprobe_events`/`uprobe_events`, enabling tracing events, or sustained reads from `trace_pipe`.  
- Validate whether `debugfs`/`tracefs` are mounted and assess the host’s role and installed observability/performance tooling to quickly separate routine diagnostics from unexpected tracing access.  
- Hunt for adjacent signals of kernel instrumentation setup or abuse, including use of eBPF tooling (`bpftool`, `bpftrace`, BCC), `perf`, suspicious `bpf()` syscall activity, or module loading around the same time window.  
- Compare current tracing configuration and recent file modification activity under `/sys/kernel/debug/tracing` and `/sys/kernel/tracing` against baseline expectations to detect tampering or persistence.

### False positive analysis

- A system administrator or automated diagnostic script may use basic utilities like `cat`, `grep`, or `find` to enumerate `/sys/kernel/debug/tracing` or `/sys/kernel/tracing` during kernel troubleshooting or performance triage to confirm tracefs/debugfs is mounted and to review available functions/events.
- Routine validation of tracing configuration after kernel upgrades or configuration changes can involve shells running `ls`, `stat`, or `readlink` over kprobe and tracing paths to verify current settings and permissions, even when no malicious instrumentation is intended.

### Response and remediation

- Contain suspected abuse by isolating the host and immediately stopping the offending script/process tree that is enumerating `/sys/kernel/debug/kprobes/*` or `/sys/kernel/*tracing/*`, then preserve the shell history and the script/binary on disk for analysis.  
- Eradicate kernel instrumentation changes by checking for and removing any attacker-added entries in `kprobe_events`/`uprobe_events`, disabling any enabled tracing knobs, and remounting or unmounting `debugfs`/`tracefs` if they are not required for operations.  
- Recover to a known-good state by rebooting to clear transient tracing state, validating that `trace_pipe` is not being read continuously, and confirming that expected observability tooling (if any) still functions after tracing is reset.  
- Escalate to incident response immediately if you observe writes to `kprobe_events`/`uprobe_events`, sustained reads from `trace_pipe`, or nearby execution of eBPF/performance tooling (e.g., `bpftool`, `bpftrace`, `perf`) by an unexpected user or from an unusual parent process.  
- Harden to prevent recurrence by restricting access to `debugfs`/`tracefs` to administrators only, disabling unprivileged BPF where feasible, and enforcing MAC policies (SELinux/AppArmor) to deny non-approved processes from reading or writing tracing interfaces."""
risk_score = 21
rule_id = "fb542346-1624-4cf2-bcc7-c68abaab261b"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name in (
  "cat", "grep", "head", "tail", "ls",
  "less", "more",
  "awk", "sed", "cut", "tr", "xargs", "tee",
  "find", "stat", "readlink",
  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
) and
process.args like ("/sys/kernel/debug/kprobes/*", "/sys/kernel/debug/tracing/*", "/sys/kernel/tracing/*")
'''

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

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

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

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

[metadata]
creation_date = "2023/08/30"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule monitors for the potential memory dump of the init process (PID 1) through gdb. Attackers may leverage memory
dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include
"truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-auditd_manager.auditd-*",
]
language = "eql"
license = "Elastic License v2"
name = "Linux init (PID 1) Secret Dump via GDB"
note = """## Triage and analysis

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

### Investigating Linux init (PID 1) Secret Dump via GDB

In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation.

### Possible investigation steps

- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1".
- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system.
- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script.
- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack.
- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections.
- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated.

### False positive analysis

- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions.
- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe.
- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources.
- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity.
- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities.
- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts.
- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems.
- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required.
- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future."""
references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"]
risk_score = 73
rule_id = "d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1"
'''

[[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.007"
name = "Proc Filesystem"
reference = "https://attack.mitre.org/techniques/T1003/007/"

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

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

[rule]
description = """
Detects when a hidden process spawns an interactive shell. Many different types of malware will create and execute
hidden binaries in order to avoid suspicion or detection by a user. Sometimes depending on the implementation a payload
will open an interactive shell on the target system in order to execute post exploitation commands in real time.
"""
id = "8d6b1c6b-fd51-4a56-bc34-ea91f9921651"
license = "Elastic License v2"
name = "MacOS Interactive Shell Spawned via Hidden Process"
os_list = ["macos"]
version = "1.0.5"

query = '''
process where event.type == "start" and event.action == "exec" and (process.name in ("bash", "sh", "zsh", "dash", "csh", "tcsh", "ksh", "tclsh", "fish") or process.name like "tclsh*") and
 process.args == "-i" and process.args_count == 2 and
 process.parent.name like~ ".*"
'''

min_endpoint_version = "8.11.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.11.0"

[metadata]
creation_date = "2020/08/31"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/06"

[rule]
author = ["Elastic"]
description = """
Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp
module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to
the host.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-m365_defender.event-*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Mimikatz Memssp Log File Detected"
references = ["https://www.elastic.co/security-labs/detect-credential-access"]
risk_score = 73
rule_id = "ebb200e8-adf0-43f8-a0bb-4ee5b5d852c6"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and file.name : "mimilsa.log" and process.name : "lsass.exe"
'''

note = """## Triage and analysis

### Investigating Mimikatz Memssp Log File Detected

#### Possible investigation steps

- Is the alert-local event the default MemSSP credential log?
  - Focus: `file.name`, `file.path`, `file.size`, `process.name`, and `process.executable`.
  - Implication: escalate when "lsass.exe" creates "mimilsa.log", especially at "C:\\Windows\\System32\\mimilsa.log" or a staging path; lower suspicion only when the same host, path, and process evidence align with an authorized red-team, responder, malware-analysis, or isolated lab run.

- Was the log handled like credential material after creation?
  - Focus: file events on the same `host.id` around `file.path`, including `file.Ext.original.path`, `file.extension`, and the acting `process.executable`.
  - Implication: escalate when "mimilsa.log" is copied, renamed, archived, deleted, or paired with DLL/archive artifacts such as "mimilib.dll"; absence of follow-on file handling does not clear the alert because the log creation itself can mean credential capture.
  - Hint: pivot first on the exact `file.path` and rename source path, then on companion "mimilib.dll" file events on the same host. $investigate_2

- Which process activity likely enabled MemSSP before LSASS wrote the log?
  - Focus: process starts on the same `host.id`: `process.command_line`, `process.executable`, `process.parent.executable`, `process.code_signature.trusted`, and `process.Ext.token.integrity_level_name`.
  - Implication: escalate when "misc::memssp", Mimikatz/Invoke-Mimikatz, "mimilib.dll", PowerShell, rundll32, regsvr32, unsigned helpers, or high-integrity/system tooling appear before the write; a clean process search narrows the launcher only if collection covers that window.
  - Hint: search backward from alert `@timestamp` for process starts containing "memssp", "mimikatz", "mimilib", or script/LOLBIN launchers on the same `host.id`.

- Which accounts may have been exposed after the log appeared?
  - Why: MemSSP records credentials from successful authentications after injection, so exposure depends on who logged on or unlocked the host after the write.
  - Focus: if Windows Security authentication logs are available, correlate same-`host.id` events after `@timestamp` with `winlog.event_id`, `winlog.event_data.TargetUserName`, `winlog.logon.type`, `source.ip`, and `winlog.event_data.AuthenticationPackageName`. $investigate_3
  - Implication: escalate when privileged, service, machine, remote, or unexpected NTLM logons appear after creation; if policy permits secure collection, accounts visible in "mimilsa.log" are direct exposure evidence. Missing Windows Security telemetry or uncollected log content is unresolved, not benign.

- Does the host show default in-memory MemSSP only, or a persistent SSP setup?
  - Why: persistent SSP changes survive a single process-memory event and widen eradication scope beyond the observed log file.
  - Focus: companion DLL file events (`file.path`, `file.extension`) and, when registry telemetry is available, LSA Security Packages changes in `registry.path` and `registry.data.strings`.
  - Implication: escalate persistence scope when "mimilib.dll" or an unfamiliar SSP DLL is placed for loading, or when LSA Security Packages registry data names it; if registry telemetry is unavailable, persistence is unresolved and must not be used to close.

- If local evidence is suspicious or unresolved, what related alert activity changes scope?
  - Focus: related alerts for the same `host.id` in the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access. $investigate_1
  - Hint: use the `user.id` alert pivot only when a non-SYSTEM account from process or authentication evidence becomes part of scope. $investigate_0
  - Implication: broaden response when related alerts explain precursor access or follow-on use of captured credentials; keep scope local only when artifact, lineage, exposure, and persistence evidence remain bounded and no contradictory alerts appear.

- Escalate when alert-local artifact, file handling, enabling process, credential exposure, persistence, or related alerts point to hostile MemSSP use; close only when telemetry and outside confirmation align with one authorized lab, red-team, or responder workflow; preserve and escalate when evidence is mixed, missing, or credential exposure cannot be scoped.

### False positive analysis

- Normal Windows operation should not create "mimilsa.log". Authorized red-team, responder, malware-analysis, or isolated lab validation is the narrow benign path. Confirm by verifying alert-local `file.path`/`process.executable`, enabling `process.command_line`/`process.parent.executable`, file handling, asset identity, and any credential-exposure evidence all align with the same case; if any dimension contradicts it, do not close as benign.
- If exercise or case records are unavailable, do not exception a first occurrence; require a previously confirmed exercise or responder case plus the same stable pattern (`host.id`, `file.path`, `process.executable`, enabling `process.command_line`, and file-handling behavior) across prior alerts. Avoid exceptions on `file.name`, `process.name`, or host alone.

### Response and remediation

- If confirmed benign, reverse containment and document the exact exercise or responder case with `host.id`, `file.path`, `process.executable`, enabling command/parent, and file-handling evidence. Create an exception only for the recurring same pattern.
- If suspicious but unconfirmed, preserve evidence before containment: export the alert, surrounding process/file events, related alerts, any available authentication events, and securely collect "mimilsa.log" as credential material if policy permits. Capture volatile LSASS state or memory through approved IR tooling before rebooting because restart can remove in-memory evidence.
- Then apply reversible containment based on scope: restrict network access for the affected `host.id`, heighten monitoring, and scrutinize accounts identified in "mimilsa.log" or post-write logons. Avoid deleting the log, terminating suspected tooling, or rebooting until preservation is complete.
- If confirmed malicious, isolate or rebuild the host as host criticality allows; remove "mimilsa.log", companion DLLs, archives, and any persistent SSP configuration discovered; terminate tooling only after evidence capture; then reboot or rebuild to clear injected SSP state.
- Reset or rotate credentials for privileged, service, machine, and lateral-movement-relevant accounts shown in the log content or post-write authentication evidence; review related hosts/accounts before broad resets when exposure is uncertain.
- Post-incident hardening: reduce interactive logons to high-value hosts, restrict debug and LSASS access, review LSA protection and allowed SSP configuration where compatible, monitor for "mimilsa.log" and "mimilib.dll", and document telemetry gaps that limited credential-exposure or persistence scoping.
"""

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "host.id",
    "user.id",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.parent.executable",
    "process.parent.command_line",
    "process.code_signature.trusted",
    "process.Ext.token.integrity_level_name",
    "file.path",
    "file.Ext.original.path",
    "file.name",
    "file.size",
]

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

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

[[transform.investigate]]
label = "MemSSP log and companion file events"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "file.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "file.Ext.original.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
  ],
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "file.name", queryType = "phrase", value = "mimilib.dll", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Authentication events after MemSSP log creation"
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 = "event.code", queryType = "phrase", value = "4776", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-24h"
relativeTo = "now"


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

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

[[rule.threat.technique]]
id = "T1556"
name = "Modify Authentication Process"
reference = "https://attack.mitre.org/techniques/T1556/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1547.005"
name = "Security Support Provider"
reference = "https://attack.mitre.org/techniques/T1547/005/"

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

[rule]
description = """
Identifies changes to the SoftwareUpdate preferences using the built-in defaults command. Adversaries may abuse this in
an attempt to disable security updates.
"""
id = "741ad90d-e8d0-4d29-b91b-3d68108cb789"
license = "Elastic License v2"
name = "Operating System Security Updates Disabled"
os_list = ["macos"]
reference = ["https://blog.checkpoint.com/2017/07/13/osxdok-refuses-go-away-money/"]
version = "1.0.28"

query = '''
process where event.type == "start" and
 process.name == "defaults" and
 process.args like~ "write" and process.args like~ "-bool" and
 process.command_line like~ "*com.apple.SoftwareUpdate*" and process.args like~ "CriticalUpdateInstall" and process.args like~ "NO"
'''

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 = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"



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

[internal]
min_endpoint_version = "8.10.2"

[rule]
description = """
Detects the use of wget to upload collected data or files to an internet server from suspicious working directories,
including via HTTP POST options or use of cat/base64 on sensitive paths. Threat actors commonly collect data on a system
and exfiltrate it back to their C2 server, and wget has been observed being abused for this purpose. Use of wget in this
way, while not inherently malicious, should be considered highly abnormal and suspicious activity.
"""
id = "5389bdae-778e-48b6-af2e-0107327ca855"
license = "Elastic License v2"
name = "Potential Data Exfiltration Through Wget"
os_list = ["linux"]
reference = ["https://linux.die.net/man/1/wget"]
version = "1.0.3"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "wget" and
process.parent.executable != null and (
  process.args like ("--post-file*", "--post-data*", "--body-file*") or
  (
    process.command_line like ("*cat*", "*base64*") and
    process.command_line like (
      "*/etc/passwd*", "*/etc/shadow*", "*~/.ssh/*", "*.env*", "*credentials*", "*/tmp/*",
      "*/var/tmp/*", "*/dev/shm/*", "*/home/*/*", "*/root/*"
    )
  )
) and
(
  process.command_line like ("*http://*", "*https://*") or
  process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*"
) and (
  process.working_directory like (
    "/tmp*", "/var/tmp*", "/dev/shm*", "/run*", "/var/run*", "/home/*/*", "/root*",
    "/var/www*", "/boot*", "/srv*", "/mnt*", "/media*"
  ) or
  process.parent.working_directory like (
    "/tmp*", "/var/tmp*", "/dev/shm*", "/run*", "/var/run*", "/home/*/*", "/root*",
    "/var/www*", "/boot*", "/srv*", "/mnt*", "/media*"
  )
) and
not
(
  process.command_line like (
    "*://localhost*",
    "*://127.0.0.1*",
    "*://0.0.0.0*",
    "*://[::1]*",
    "*10.*.*.*",
    "*192.168.*.*",
    "*172.16.*.*",
    "*api.telegram.org*", /* already covered by another rule */
    "*https://storage.googleapis.com/detonate-prod/*",
    "*https://storage.googleapis.com/detonate-ci/*",
    "*https://artifactory.*.local/artifactory*"
  ) or
  process.working_directory like ("/home/*/*", "/root", "/opt/ft/nl/*") or
  process.parent.executable like "/opt/miniconda/bin/python*" or
  process.parent.command_line like ("*/var/spool/asterisk/wgetstderr*", "*lastaccesseduuid*")
)
'''

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


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

[internal]
min_endpoint_version = "8.2.0"

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

[rule]
author = ["Elastic"]
description = """
Windows contains accessibility features that may be launched with a key combination before a user has logged in. An
adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the
system.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Modification of Accessibility Binaries"
references = ["https://www.elastic.co/blog/practical-security-engineering-stateful-detection"]
risk_score = 73
rule_id = "7405ddf1-6c8e-41ce-818f-48bea6bcaed8"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
 process.parent.name : ("Utilman.exe", "winlogon.exe") and user.name == "SYSTEM" and
 process.pe.original_file_name : "?*" and
 process.args :
    (
    "C:\\Windows\\System32\\osk.exe",
    "C:\\Windows\\System32\\Magnify.exe",
    "C:\\Windows\\System32\\Narrator.exe",
    "C:\\Windows\\System32\\Sethc.exe",
    "utilman.exe",
    "ATBroker.exe",
    "DisplaySwitch.exe",
    "sethc.exe"
    )
 and not process.pe.original_file_name in
    (
    "osk.exe",
    "sethc.exe",
    "utilman2.exe",
    "DisplaySwitch.exe",
    "atbroker.exe",
    "ATBroker.exe",
    "ScreenMagnifier.exe",
    "SR.exe",
    "Narrator.exe",
    "magnify.exe",
    "MAGNIFY.EXE"
    )
'''

note = """## Triage and analysis

### Investigating Potential Modification of Accessibility Binaries
#### Possible investigation steps

- Does the alert show an accessibility-feature launch path running a different binary identity?
  - Focus: `process.parent.name`, `user.name`, `process.args`, and `process.pe.original_file_name`.
  - Implication: escalate when the logon accessibility path starts a SYSTEM process whose PE original name does not fit the requested feature; lower initial concern only when this exact host and binary match a narrow exception from prior verified testing. Otherwise, the mismatch stays suspicious.

- What binary actually ran from the accessibility launch?
  - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
  - Implication: escalate when the executable is a shell, scripting or administration tool, user-writable copy, unsigned or unexpectedly signed binary, or rare hash for the host; stable hash or trusted signer lowers identity concern but does not clear the SYSTEM accessibility mismatch.

- Did the launched binary create a SYSTEM follow-on process?
  - Focus: process starts on the same `host.id` where `process.parent.entity_id` matches `process.entity_id`, checking `process.executable`, `process.args`, and `user.name`. $investigate_0
  - Implication: escalate when follow-on activity opens a shell, scripting engine, remote-access tool, credential or account utility, or long-lived SYSTEM process; no children lowers follow-on severity only, not the accessibility mismatch.
  - Hint: if `process.entity_id` is missing, use `host.id`, `process.pid`, and a tight alert-time window as a weaker fallback.

- Do surrounding process starts show preparation, replacement, or cleanup?
  - Focus: same-`host.id` process starts in a tight alert-time window, prioritizing parent or child links to the alerting process, then same `user.id`; check `process.name`, `process.args`, and `process.parent.name`. $investigate_1
  - Implication: escalate when takeown, icacls, copy, robocopy, reg, PowerShell, cmd, or service-control activity surrounds the accessibility launch; absence of setup or cleanup reduces preparation evidence only, not the mismatch.
  - Why: runtime evidence may not show whether abuse used binary replacement or IFEO/debugger redirection, so surrounding process starts can expose the setup path to preserve or restore.

- If local evidence is suspicious or unresolved, is this a local one-off or repeated accessibility-hijack pattern?
  - Focus: prior alerts and process starts for the same `host.id`, then the same `process.hash.sha256`, `process.executable`, or `process.pe.original_file_name` across other hosts.
    - $investigate_2
    - $investigate_3
  - Implication: escalate scope when the same binary identity or PE mismatch appears on additional hosts, recurs after attempted cleanup, or clusters outside a recognized validation cohort; no recurrence lowers scope only. Do not close on absence or recurrence alone.

- Escalate for suspicious binary identity, SYSTEM follow-on activity, preparation or cleanup, or unexplained recurrence. Close only when process evidence matches a preexisting narrow exception for one controlled test on this host; if absent or mixed, preserve the binary, process tree, and alert records and escalate.

### False positive analysis

- Accessibility-feature hijacking is an operational anti-pattern. The main benign path is a preexisting, narrow security-test exception for this exact behavior. Compare the alert to stable exception anchors: `host.id`, `process.hash.sha256`, `process.executable`, `process.args`, `process.pe.original_file_name`, parent context, and child-process evidence; contradictions prevent benign closure.
- Without a preexisting exception, do not close from recurrence alone. Treat stable recurrence as candidate exception evidence and keep the case open or escalated until the exact activity is verified.
- Build exceptions only from stable test anchors: `process.hash.sha256`, signer identity, `process.args`, `process.pe.original_file_name`, and `host.id` or a tightly managed test cohort. Avoid exceptions on `process.name`, accessibility filenames, parent name, or `user.name` alone.

### Response and remediation

- If confirmed benign:
  - Record the exact evidence that confirmed the test: host, binary hash and signer, accessibility target, parent context, and absence of suspicious child or surrounding process activity.
  - Reverse temporary containment after the evidence record is complete.
  - Create a narrow exception only after the same test pattern is stable across prior alerts and limited to the validated cohort.
- If suspicious but unconfirmed:
  - Preserve the alert record, process tree, executable copy, hash, signature details, child-process events, and surrounding process events before containment.
  - Apply reversible containment tied to the findings, such as temporary host isolation, restricted remote access, or increased monitoring on the affected host, and avoid deleting binaries or restoring system state until evidence is preserved.
- If confirmed malicious:
  - Record `process.entity_id`, `process.pid`, command arguments, executable path, hash, signer, and any child process identifiers before containment, termination, or cleanup.
  - Contain the endpoint based on the binary identity, SYSTEM lineage, follow-on process activity, and recurrence scope that established malicious use.
  - Block confirmed malicious hashes or binaries, then terminate active shells or backdoors.
  - Restore affected accessibility binaries to known-good state, validate the accessibility launch path no longer starts the suspicious binary, and remediate the account, deployment tool, or remote-access path that allowed the change.
  - Reset credentials only when follow-on activity or separate identity evidence shows account misuse.
- Post-incident hardening:
  - Restrict local administrator paths that can replace or redirect Windows accessibility features, and enforce application control for accessibility-feature execution where feasible.
  - Ensure Remote Desktop exposure uses gateway controls and Network Level Authentication so remote users authenticate before the login screen path can be abused.
  - Document the confirmed test pattern or malicious artifact set so future analysts can separate repeat validation from repeat 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:

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

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

[transform]

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

[[transform.investigate]]
label = "Process starts on the host near the alert"
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" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

[[transform.investigate]]
label = "Process events with the same SHA-256"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "process.hash.sha256", queryType = "phrase", value = "{{process.hash.sha256}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

[[rule.threat.technique.subtechnique]]
id = "T1546.008"
name = "Accessibility Features"
reference = "https://attack.mitre.org/techniques/T1546/008/"

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

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

[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

[[rule.threat.technique.subtechnique]]
id = "T1546.008"
name = "Accessibility Features"
reference = "https://attack.mitre.org/techniques/T1546/008/"

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

[rule]
description = """
Identifies when an unsigned process or a proxy execution utility spawns a protected process. This may indicate an
attempt to bypass PPL protection and inject malicious code into a protected process or disable security software.
"""
id = "9dbdcb78-6f0c-48cd-bfb8-46078de392ad"
license = "Elastic License v2"
name = "Protected Process from Unusual Parent"
os_list = ["windows"]
reference = ["https://www.zerosalarium.com/2025/08/countering-edrs-with-backing-of-ppl-protection.html"]
version = "1.0.1"

query = '''
process where event.action == "start" and process.Ext.protection like "PsProtectedSigner*" and
 (
  process.parent.code_signature.exists == false or
  process.parent.code_signature.trusted == false or
  process.parent.name : ("rundll32.exe", "regsvr32.exe", "explorer.exe", "powershell.exe", "msbuild.exe")
  )
'''

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

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

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

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


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

[internal]
min_endpoint_version = "8.10.0"

[rule]
description = """
Identifies the execution of a script or program extracted from within a Windows shortcut (lnk) file. Adversaries may
embed malicious scripts or files in a shortcut file before delivering it to their target in order to trick them into
executing the payload.
"""
id = "1a88b997-bcae-430a-8a24-7378e8bf5cc4"
license = "Elastic License v2"
name = "Shell Execution via Windows Shortcut File"
os_list = ["windows"]
reference = ["https://docs.google.com/presentation/d/13SsBd0wI0PpyH5C8WlnE_DsJjy1KxAjZ5Dmke9FHfRE/"]
version = "1.0.35"

query = '''
sequence with maxspan=1m
  [file where event.action == "creation" and file.extension : ("lnk", "url") and
   (
    (process.name : ("winrar.exe", "7zFM.exe", "Bandizip.exe") and
     file.path : ("?:\\*\\Temp\\7z*\\*", "?:\\*\\Temp\\Rar$*\\*", "?:\\*\\Temp\\BNZ.*")) or
     /* Issue #374 */
    (process.name : "explorer.exe" and
     /* lowered file.size condition as it creates evasion opportunities */
     file.path : "?:\\*\\AppData\\Local\\Temp\\Temp?_*.lnk")
   )
  ] by process.entity_id
  [process where event.action == "start" and
   process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "wmic.exe") and
   (process.parent.name : ("winrar.exe", "7zFM.exe") or
    /* Issue #374 */
    (process.parent.name : "explorer.exe" and process.args_count >= 5))
   ] by process.parent.entity_id
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"

[[threat.technique.subtechnique]]
id = "T1566.002"
name = "Spearphishing Link"
reference = "https://attack.mitre.org/techniques/T1566/002/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[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.003"
name = "Windows Command Shell"
reference = "https://attack.mitre.org/techniques/T1059/003/"


[[threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[threat.technique.subtechnique]]
id = "T1204.001"
name = "Malicious Link"
reference = "https://attack.mitre.org/techniques/T1204/001/"

[[threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



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

[internal]
min_endpoint_version = "7.15.0"