Elastic rules: 14

[metadata]
creation_date = "2020/03/25"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/07/27"
min_stack_version = "9.4.0"
min_stack_comments = "Use EA (Entity Analytics) fields"
[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 '%LocalSyste' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""

[[transform.osquery]]
label = "Retrieve Service Unisgned 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]
anomaly_threshold = 50
author = ["Elastic"]
description = """
Searches for rare processes running on multiple hosts in an entire fleet or network. This reduces the detection of false
positives since automated maintenance processes usually only run occasionally on a single machine but are common to all
or many hosts in a fleet.
"""
false_positives = [
    """
    A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this
    alert.
    """,
]
from = "now-45m"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = ["v3_windows_anomalous_process_all_hosts_ea"]
name = "Anomalous Process For a Windows Population"
note = """## Triage and analysis

###  Investigating Anomalous Process For a Windows Population

Searching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.

This rule uses a machine learning job to detect a Windows process that is rare and unusual for all of the monitored Windows hosts in your environment.

> **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

- 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.
  - If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.
  - Investigate the process metadata — such as the digital signature, directory, etc. — to obtain more context that can indicate whether the executable is associated with an expected software vendor or package.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?
- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.
- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.
- Examine the host for derived artifacts that indicate suspicious activities:
  - Analyze the process executable using a private sandboxed analysis system.
  - Observe and collect information about the following activities in both the sandbox and 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
  - 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.

### False Positive Analysis

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

### Related Rules

- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76
- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5
- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts 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.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- 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).
"""
references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
risk_score = 21
rule_id = "6e40d56f-5c0e-4ac6-aece-bee96645b172"
setup = """## Setup

This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
- Elastic Defend
- Windows

### Anomaly Detection Setup

Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).

### 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 to your 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/current/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).

### Windows Integration Setup
The Windows integration allows you to monitor the Windows OS, services, applications, and more.

#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Windows” and select the integration to see more details about it.
- Click “Add Windows”.
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
- Click “Save and Continue”.
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Use Case: Threat Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
type = "machine_learning"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"


[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



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

[metadata]
creation_date = "2026/09/01"
integration = ["aws"]
maturity = "production"
updated_date = "2026/09/01"

[rule]
author = ["Elastic"]
description = """
Identifies failed authentication attempts against the AWS Management Console root user from the same source IP address
targeting multiple AWS accounts. Password spraying uses few attempts per target across many accounts to avoid lockout,
making per-account volume an unreliable signal. This rule detects the cross-account breadth pattern: a single source IP
generating root ConsoleLogin failures across two or more distinct AWS accounts. Requires an AWS Organizations-level
CloudTrail trail aggregating events from member accounts.
"""
false_positives = [
    """
    Administrators behind a shared egress address, such as a corporate NAT gateway or VPN
    concentrator, can trigger this rule when separate people mistype root passwords for different
    accounts within the window, since a single failure per account is sufficient. An administrator
    who legitimately holds root credentials for several accounts can also match. Verify whether the
    source IP is an expected corporate or administrator address, and whether the targeted accounts
    correspond to that person's scope, before escalating. Repeated failures against a single account
    do not trigger this rule and are covered by the separate brute-force rule.
    """,
]
from = "now-1h"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Root Console Login Password Spraying"
note = """## Triage and analysis

### Investigating AWS Root Console Login Password Spraying

Password spraying is a credential access technique where an attacker tries a small number of commonly used or leaked passwords across many accounts. Unlike brute force, the per-account attempt count is intentionally low — often 2–8 attempts — to stay below lockout thresholds and evade high-volume detections. Attackers targeting AWS root accounts typically hold a pre-enumerated list of root account email addresses and route attempts through proxy or residential IP infrastructure.

This rule fires when a single source IP generates failed root `ConsoleLogin` events against two or more distinct AWS accounts within a 1 hour window, requiring an AWS Organizations-level CloudTrail trail. The cross-account breadth is the defining spray signal; brute force against a single account is covered by a separate rule.

#### Possible investigation steps

- **Assess the source IP.**
Determine whether the IP belongs to a known corporate range, VPN, or expected admin location. Use threat intelligence tools to check if it is flagged as a proxy, Tor exit node, or residential proxy service.

- **Review the user agent string.**
Outdated browser user agents (for example, Chrome 85 or Firefox 120) are common indicators of spray-campaign tooling. Cross-reference `user_agent.original` across the contributing events in Timeline.

- **Check for a subsequent successful login.**
Query CloudTrail for a `ConsoleLogin` success for the root identity in the same timeframe. A success immediately after failures indicates the spray succeeded — escalate immediately.

- **Examine follow-on API calls.**
If a successful login did occur, review high-risk API calls that followed: `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `DeleteTrail`, or `StopLogging`.

- **Widen the scope across accounts.**
If your organization uses AWS Organizations, check whether the same source IP triggered root login failures in other member accounts during the same window.

### False positive analysis

- **Mistyped credentials.** A root credential custodian mistyping the password multiple times is the most likely benign cause. Confirm whether the source IP is a known admin location and whether a successful login followed shortly after.
- **Stale automation.** Misconfigured scripts or browser sessions with cached root credentials may retry on failure. Check whether the user agent matches known internal tooling.

### Response and remediation

- **If no successful root login is found:**
  - Rotate the root password to a strong, unique credential stored in an offline vault.
  - Confirm MFA is enabled and enforced on the root account.
  - Block the source IP at AWS WAF or network ACLs if confirmed malicious.

- **If a successful root login is found:**
  - Treat as Priority-1 account compromise and immediately follow the *AWS Management Console Root Login* investigation guide.
  - Initiate an emergency root password reset and MFA re-enrollment.
  - Preserve all CloudTrail events from ±1 hour around the login in an immutable evidence bucket.
  - Audit all API calls made during the session for persistence: new users, access keys, policy changes.

### Additional information

- [AWS root user best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
- [AWS IR Playbooks — Credential Compromise](https://github.com/aws-samples/aws-incident-response-playbooks)
"""
setup = """## Setup

This rule requires an AWS Organizations-level CloudTrail trail that aggregates management events from all member accounts into a single destination. A single-account trail will only ever contain one `cloud.account.id` value and the cross-account cardinality signal will never fire.

To configure an org-level trail: in the AWS CloudTrail console, create a trail scoped to your AWS Organization and enable it in all regions. Ensure the Elastic AWS integration is ingesting from the aggregated trail destination."""
references = [
    "https://securitylabs.datadoghq.com/articles/aws-root-user-bruteforce-campaign/",
]
risk_score = 47
rule_id = "171d3cdd-0c04-47c2-b392-65719284ae25"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Rule Type: Threshold",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset:aws.cloudtrail and
event.provider:signin.amazonaws.com and
event.action:ConsoleLogin and
aws.cloudtrail.user_identity.type:Root and
event.outcome:failure
'''

[rule.investigation_fields]
field_names = [
    "source.ip",
    "user_agent.original",
    "cloud.account.id",
    "aws.cloudtrail.user_identity.type",
    "event.outcome",
    "aws.cloudtrail.error_message",
    "@timestamp",
]

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

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

[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"

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

[rule.threshold]
field = ["source.ip"]
value = 1

[[rule.threshold.cardinality]]
field = "cloud.account.id"
value = 2

[rule.alert_suppression]
duration = {value = 1, unit = "h"}

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

[rule]
author = ["Elastic"]
description = """
Detects the first occurrence in 7 days of an AWS identity attaching the managed policy
AmazonSESFullAccess to an IAM user, role, or group. AmazonSESFullAccess grants unrestricted
permission to send email, manage identities and templates, manage suppression lists, and access
SES account-level settings. Granting this policy to an unexpected IAM entity, particularly a newly
created user or a role not previously associated with email operations, is a documented technique
used by threat actors to establish phishing infrastructure on compromised AWS accounts, enabling
them to send email on behalf of the victim organization's trusted sending domain. Using new terms
on the calling identity suppresses recurring attachments by known email automation while
surfacing identities performing this action for the first time.
"""
false_positives = [
    """
    Legitimate email service automation may attach AmazonSESFullAccess to a service account.
    Validate the target IAM entity against known email automation roles and CI/CD pipeline identities.
    Because this is a new terms rule keyed on the calling identity, recurring attachments by the
    same automation will not re-alert within the 7-day history window; first-time attachments by
    administrators performing legitimate setup may still trigger and should be validated against
    change management records.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SES Full Access Policy Attached to IAM Entity by Unusual User"
note = """## Triage and analysis

### Investigating AWS SES Full Access Policy Attached to IAM Entity by Unusual User

AWS Simple Email Service (SES) is a cost-effective bulk email platform with a reputation built on a customer's verified sending domains. Threat actors who compromise an AWS account often establish phishing infrastructure by granting SES access to a new or existing IAM identity and then using that identity's credentials to send phishing emails under the victim organization's trusted domain. Attaching the managed policy `AmazonSESFullAccess` is the simplest way to grant the full range of SES capabilities (send, manage identities, manage suppression lists, configure sending settings).

This is a new terms rule that alerts only when the calling identity (`aws.cloudtrail.user_identity.arn`) has not attached this policy within the previous 7 days, prioritizing anomalous or first-time activity over recurring automation.

### Possible investigation steps

- Identify the caller in `aws.cloudtrail.user_identity.arn` and `user.name`. Determine whether the caller is a legitimate administrator or an anomalous identity.
- Identify the target IAM entity in `user.target.name` and `aws.cloudtrail.flattened.request_parameters.userName` (or `groupName` or `roleName`). Is this a known email automation account, or an entity created recently?
- Query CloudTrail for all SES API calls (`event.provider: ses.amazonaws.com`) from the target entity in the time window after this attachment. Look for `SendEmail`, `SendRawEmail`, `VerifyEmailIdentity`, `SetIdentityMailFromDomain`, or `UpdateAccountSendingEnabled`.
- Review whether the attachment corresponds to a legitimate change management process. Check for a corresponding IAM change window ticket.
- Verify whether SES sending is enabled for the account (`ses:GetAccountSendingEnabled`) and whether there are existing or recently created SES identities.

### False positive analysis

- Legitimate email automation services (transactional email, notification services) may attach AmazonSESFullAccess. Confirm the target entity is a known service role.
- CI/CD pipelines that manage email notification infrastructure may attach this policy. Validate via pipeline execution logs and source IP.

### Response and remediation

- If unauthorized, immediately detach AmazonSESFullAccess from the target entity and review all SES calls made under that identity.
- Review SES account sending status and disable sending if any unauthorized email was sent.
- Check SES suppression list for any unauthorized modifications (attackers may add or remove entries to influence deliverability).
- Rotate all credentials associated with both the calling identity and the target entity.
- Enable SES event publishing to review any emails sent during the unauthorized period.
"""
references = [
    "https://docs.aws.amazon.com/ses/latest/dg/control-user-access.html"
]
risk_score = 47
rule_id = "d2e3f4a5-b6c7-8901-bcde-f23456789012"
setup = "The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional data event selectors are required — `iam:AttachUserPolicy`, `iam:AttachRolePolicy`, and `iam:AttachGroupPolicy` are management-plane APIs logged by default."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Service: AWS IAM",
    "Service: AWS SES",
    "Rule Type: New Terms",
    "Tactic: Persistence",
    "Tactic: Resource Development",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: ("AttachUserPolicy" or "AttachRolePolicy" or "AttachGroupPolicy")
    and event.outcome: "success"
    and aws.cloudtrail.flattened.request_parameters.policyArn: "arn:aws:iam::aws:policy/AmazonSESFullAccess"
'''


[[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.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"


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


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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage
Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities
with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts.
Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security.
This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days.
"""
from = "now-9m"
index = ["logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Storage Account Keys Accessed by Privileged User"
note = """## Triage and Analysis

### Investigating Azure Storage Account Keys Accessed by Privileged User

Azure Storage Account keys provide full administrative access to storage resources. While legitimate administrators may occasionally need to access these keys, Microsoft recommends using more granular access methods like Shared Access Signatures (SAS) or Azure AD authentication. This detection identifies when users with high-privilege roles (Owner, Contributor, Storage Account Contributor, or User Access Administrator) access storage account keys, particularly focusing on unusual patterns that may indicate compromise. This technique was notably observed in STORM-0501 ransomware campaigns where compromised identities retrieved keys for unauthorized storage operations.

### Possible investigation steps

- Review the `azure.activitylogs.identity.authorization.evidence.principal_id` to identify the specific user who accessed the storage account keys.
- Examine the `azure.resource.name` field to determine which storage account's keys were accessed and assess the sensitivity of data stored there.
- Check the `azure.activitylogs.identity.authorization.evidence.role` to confirm the user's assigned role and whether this level of access is justified for their job function.
- Investigate the timing and frequency of the key access event - multiple key retrievals in a short timeframe may indicate automated exfiltration attempts.
- Review the source IP address and geographic location of the access request to identify any anomalous access patterns or locations.
- Correlate this event with other activities by the same principal ID, looking for patterns such as permission escalations, unusual data access, or configuration changes.
- Check Azure AD sign-in logs for the user around the same timeframe to identify any suspicious authentication events or MFA bypasses.
- Examine subsequent storage account activities to determine if the retrieved keys were used for data access, modification, or exfiltration.

### False positive analysis

- DevOps and infrastructure teams may legitimately access storage keys during deployment or migration activities. Document these planned activities and consider creating exceptions for specific time windows.
- Emergency troubleshooting scenarios may require administrators to retrieve storage keys. Establish a process for documenting these emergency accesses and review them regularly.
- Automated backup or disaster recovery systems might use high-privilege service accounts that occasionally need key access. Consider using managed identities or service principals with more restricted permissions instead.
- Legacy applications that haven't been migrated to use SAS tokens or Azure AD authentication may still require key-based access. Plan to modernize these applications and track them as exceptions in the meantime.
- New storage account provisioning by administrators will often include initial key retrieval. Consider the age of the storage account when evaluating the risk level.

### Response and remediation

- Immediately rotate the storage account keys that were accessed using Azure Portal or Azure CLI.
- Review all recent activities on the affected storage account to identify any unauthorized data access, modification, or exfiltration attempts.
- If unauthorized access is confirmed, disable the compromised user account and initiate password reset procedures.
- Audit all storage accounts accessible by the compromised identity and rotate keys for any accounts that may have been accessed.
- Implement Entra ID authentication or SAS tokens for applications currently using storage account keys to reduce future risk.
- Configure Azure Policy to restrict the listKeys operation to specific roles or require additional approval workflows.
- Review and potentially restrict the assignment of high-privilege roles like Owner and Contributor, following the principle of least privilege.
- Enable diagnostic logging for all storage accounts to maintain detailed audit trails of access and operations.
- Consider implementing Privileged Identity Management (PIM) for just-in-time access to high-privilege roles that can list storage keys.
"""
references = [
    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
    "https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage"
]
risk_score = 47
rule_id = "8b4d6c3a-2e9f-4b7c-9a5d-6f8e3c1b4d2a"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Use Case: Threat Detection",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.activitylogs" and
azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION" and
azure.activitylogs.identity.authorization.evidence.principal_type: "User" and
azure.activitylogs.identity.authorization.evidence.role: (
    "Owner" or
    "Contributor" or
    "Storage Account Contributor" or
    "User Access Administrator"
) and event.outcome: "success"
'''

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.activitylogs.identity.authorization.evidence.principal_id", "azure.resource.name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[rule.threat.technique.subtechnique]]
id = "T1555.006"
name = "Cloud Secrets Management Stores"
reference = "https://attack.mitre.org/techniques/T1555/006/"


[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 = "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]
description = """
Identifies the execution of a browser process in an unusual desktop. This may indicate an attempt to conceal malicious
activity from the plain sight of users.
"""
id = "51f30ba4-ec1e-4a83-9c69-14bc8d46a6e5"
license = "Elastic License v2"
name = "Browser Process Started in a Hidden Desktop"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1564/003/",
    "https://www.elastic.co/security-labs/elastic-security-labs-discovers-lobshot-malware",
]
version = "1.0.3"

query = '''
process where event.type == "start" and
 process.Ext.desktop_name like "WinSta0\\*" and
 process.name : ("chrome.exe", "msedge.exe", "brave.exe", "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe", "opera.exe", "firefox.exe", "iexplore.exe")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[threat.technique.subtechnique]]
id = "T1564.003"
name = "Hidden Window"
reference = "https://attack.mitre.org/techniques/T1564/003/"



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

[internal]
min_endpoint_version = "9.1.0"

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

[rule]
author = ["Elastic"]
description = "Identifies PowerShell, PowerShell ISE, or Cmd execution spawned from Windows Script Host or MSHTA."
from = "now-9m"
index = [
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Command and Scripting Interpreter via Windows Scripts"
risk_score = 73
rule_id = "2d62889e-e758-4c5e-b57e-c735914ee32a"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
    "Data Source: Windows Security Event Logs",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.command_line != null and
  (
    process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe", "cmd.exe") or
    ?process.pe.original_file_name : ("powershell.exe", "pwsh.dll", "powershell_ise.exe", "Cmd.Exe")
  ) and
  process.parent.name : ("wscript.exe", "mshta.exe") and
  not (
    process.args : (
      "C:\\Program Files\\Intel\\SUR\\QUEENCREEK\\x64\\task.bat",
      "\"C:\\Program Files\\Intel\\SUR\\QUEENCREEK\\x64\\task.bat\""
    ) or
    process.command_line : (
      "\"C:\\Windows\\system32\\cmd.exe\" /c auditpol.exe /set /SUBCATEGORY:*",
      "\"C:\\Windows\\system32\\cmd.exe\" /c auditpol.exe /get*",
      "\"C:\\Windows\\system32\\cmd.exe\" /c exit\""
    ) or
    (process.args == "-File" and process.args == "-ExecutionPolicy")
  )
  and 
  not (
    ?user.id == "S-1-5-18" and
    /* Don't apply the user.id exclusion to Sysmon for compatibility */
    not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon")
  ) 
'''

note = """## Triage and analysis

### Investigating Command and Scripting Interpreter via Windows Scripts

#### Possible investigation steps

- What script-host-to-interpreter chain did the alert capture?
  - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.name`, and `process.command_line`.
  - Implication: escalate when "wscript.exe" or "mshta.exe" launches PowerShell/pwsh/ISE/cmd from user-writable script/HTA, archive, download path, or URL; lower suspicion only when parent source, child command, `user.id`, and `host.id` fit one recognized logon, deployment, or vendor workflow.

- Does the child command express staging, retrieval, persistence, or defense evasion?
  - Focus: `process.command_line`: "-EncodedCommand"/"-e", "-NoProfile", hidden windows, execution-policy bypass, Invoke-Expression/DownloadString, cmd "/c" chaining, curl/bitsadmin retrieval, or schtasks/sc.exe changes.
  - Hint: decode or reconstruct encoded or inline PowerShell before deciding intent; use script-block logs as optional corroboration.
  - Follow-on: inspect child starts from `process.entity_id`; PID-only matches are timestamp-bound candidates. $investigate_2
  - Implication: escalate when the command fetches content, decodes or executes inline script, launches another shell, or changes tasks/services; lower risk only when it runs a local script from the same logon, deployment, or vendor source without staging or unexpected egress.

- Does the child binary identity fit the observed command line and location?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
  - Implication: escalate when the child is renamed, unsigned or untrusted from a user-writable path, or mismatched to original file name; lower identity risk when signer, path, and hash history fit the expected interpreter, but identity alone never clears suspicious command intent.

- Did the alerting process stage scripts, archives, or follow-on payloads?
  - Focus: file events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, checking `file.path`, `file.Ext.original.path`, `file.Ext.original.extension`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. $investigate_0
  - Hint: for PID fallback, require file time within the child lifetime.
  - Implication: escalate when the child writes or renames scriptable or executable content under temp, profile, public, startup, or deceptive paths, especially with internet provenance or type/extension mismatch; absent file telemetry is unresolved, not benign.

- Did same-process network events show retrieval, staging, or callback behavior?
  - Focus: network events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, separating DNS `dns.question.name` and `dns.resolved_ip` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. $investigate_1
  - Hint: map DNS `dns.resolved_ip` to later connections before treating a domain as confirmed.
  - Implication: escalate when the process reaches external script-delivery, paste, storage, or C2 infra unrelated to the workflow; lower network risk when connections stay on recognized internal, proxy, or vendor services. Missing network telemetry is unresolved, not benign.

- If local evidence stays suspicious or unresolved, does the same pattern appear in related alerts?
  - Focus: related alerts for `user.id`, checking execution, persistence, defense-evasion, or outbound context before comparing preserved `process.parent.executable`, `process.parent.command_line`, or `process.command_line` fragments. $investigate_3
  - Hint: use `host.id` alerts to test whether the chain is isolated, repeats with suspicious activity, or appears as adjacent variants such as "cscript.exe" launchers or delayed descendant shells. $investigate_4
  - Implication: broaden scope when the same user or host shows repeated script-host launches, task or service changes, persistence, or outbound staging; keep local only when the pattern is isolated and local evidence supports one recognized workflow.

- Escalate when parent provenance, command intent, identity, artifacts, destinations, or related alerts support proxy execution or second-stage activity; close only when alert-local evidence and recovery bind one recognized workflow, with outside confirmation for telemetry gaps; preserve artifacts and escalate when evidence conflicts or visibility is incomplete.

### False positive analysis

- Logon scripts and deployment wrappers can legitimately launch cmd or PowerShell through Windows Script Host. Confirm only when `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, `host.id`, and same-process `file.path` or `destination.ip` recovered through `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, align with one recognized workflow. If file or network telemetry is absent, use outside confirmation. Stable recurrence for that parent source, child command, user, and host can support closure when script inventory or change context exists; first-observed workflows need outside confirmation before exceptioning. Any mismatch keeps the case suspicious.
- Vendor/installer/hardware-diagnostic HTA/VBS launchers can trigger this rule. Confirm only when `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, parent script path, file writes, and destinations match one vendor package. Without package context, recurring signer/hash, parent source, child command, and host cohort can support closure; first-observed packages need outside confirmation.
- For exceptions, validate: `process.parent.executable`, `process.parent.command_line`, child `process.executable`, stable `process.command_line` fragment, `process.code_signature.subject_name`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, child `process.executable`, or parent process name alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and record the parent script path, child command pattern, signer, `user.id`, and `host.id` proving the workflow. Create exceptions only for exact workflows recurring in prior rule alerts.
- If suspicious but unconfirmed, preserve the process event, `process.entity_id` or `process.pid` with `host.id` and time, command lines, suspicious `file.path` values, and confirmed `dns.question.name`, `destination.ip`, or `destination.port` before response. Apply reversible containment first: temporary destination blocking, disabling newly created scripts or tasks, or heightened host monitoring. Isolate only when corroborating staging, persistence, or outbound activity is confirmed and interruption is tolerable. Avoid destructive cleanup until scope is clearer.
- If confirmed malicious, preserve `process.entity_id`, `process.parent.entity_id`, command lines, written `file.path` artifacts, and confirmed destinations, then isolate the host or block destinations based on staging and network evidence. Terminate malicious child or descendant processes after evidence capture; if direct endpoint response is unavailable, hand off artifacts for isolation or destination blocking.
- Review related hosts and users for the same parent-child command pattern, confirmed destinations, and confirmed staged files only when endpoint file telemetry or related alerts preserve them. Then remove malicious scripts, HTA content, scheduled tasks, or dropped payloads, and remediate the delivery path.
- Post-incident hardening: restrict unsupported "mshta.exe" and Windows Script Host use on workstations, retain process/file/network telemetry needed for this investigation, and record adjacent variants found during triage.
"""

setup = """## Setup

This rule requires telemetry from one of the configured source integrations to be enabled and ingested.

### Supported data sources

This rule can use the following data sources. For setup instructions, refer to the links below:

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

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

[transform]

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

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

[[transform.investigate]]
label = "Child process events for the script-launched process"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "event.type", queryType = "phrase", value = "start", 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 = "event.type", queryType = "phrase", value = "start", 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 = "Alerts associated with the user"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

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

[[rule.threat.technique]]
id = "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.technique.subtechnique]]
id = "T1059.003"
name = "Windows Command Shell"
reference = "https://attack.mitre.org/techniques/T1059/003/"

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

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

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

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

[[rule.threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"

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

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

[rule]
description = """
Detects when curl is executed as part of a shell script that gets executed via a forked shell interpreter. The activity
has been observed in many different samples of the malware known as Shlayer. Shlayer uses this technique in order to
avoid traditional scanning and command line detections. The Shlayer malware brings along an encoded shell script within
a, usually, signed or sometimes valid application that gets decoded and passed to a forked shell interpreter (to avoid
process lineage detections) for execution via the "-c" command parameter.
"""
id = "14f0cd76-79cc-46e8-b059-fcca9e41a804"
license = "Elastic License v2"
name = "Curl Execution via CommandLine Shell Script"
os_list = ["macos"]
reference = [
    "https://www.sentinelone.com/blog/coming-out-of-your-shell-from-shlayer-to-zshlayer/",
    "https://www.uptycs.com/blog/macos-bashed-apples-of-shlayer-and-bundlore",
]
version = "1.0.5"

query = '''
sequence by process.entity_id with maxspan=30s
[process where event.type == "start" and event.action == "fork" and 
  process.name in ("bash", "sh", "zsh") and
  process.args == "-c" and process.args_count == 3 and
  process.command_line == null and 
  process.parent.name in ("bash", "sh", "zsh")]
[process where event.type == "start" and event.action == "exec" and 
  process.name in ("curl", "nscurl")]
'''

min_endpoint_version = "8.7.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 = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"


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

[internal]
min_endpoint_version = "8.7.0"

[rule]
description = """
Detects when Curl is seen creating a .pdf or .doc file in a suspicious directory like /tmp or /users/shared. A recent
DPRK sample was seen downloading a decoy document via Curl like this.
"""
id = "a39d0c2f-30d0-4a32-b198-41b135f85bad"
license = "Elastic License v2"
name = "Decoy Document Creation via Curl"
os_list = ["macos"]
reference = ["https://www.kandji.io/blog/todoswift-disguises-malware-download-behind-bitcoin-pdf"]
version = "1.0.14"

query = '''
sequence by process.entity_id with maxspan=1m
[process where event.type == "start" and event.action == "exec" and process.name in ("curl", "nscurl")]
[file where event.action == "modification" and file.path like ("/tmp/*", "/private/tmp/*", "/Users/Shared/*", "/Users/*/Library/*") and
 file.extension in ("pdf", "doc") and process.name in ("curl", "nscurl") and
 not Effective_process.executable like~ (
  "/Applications/Cursor.app/Contents/MacOS/Cursor",
  "/Applications/Codex.app/Contents/MacOS/*",
  "/Applications/ChatGPT.app/Contents/MacOS/ChatGPT",
  "/Applications/Visual Studio Code.app/Contents/MacOS/Code",
  "/Users/*/Library/Application Support/Claude/claude-code/*/claude.app/Contents/MacOS/claude",
  "/Applications/Visual Studio Code.app/Contents/MacOS/Electron",
  "/Users/*/.local/share/claude/versions/*"
) and not 
(Effective_process.executable like "/Applications/Microsoft Word.app/Contents/MacOS/Microsoft Word" and 
  file.path like "/Users/*/Library/Containers/com.microsoft.Word/Data/tmp/Content.MSO/*") and 
 not file.path like "/private/tmp/claude*"]
'''

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

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

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

[metadata]
creation_date = "2026/01/30"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/05/08"

[rule]
author = ["Elastic"]
description = """
Detects when a DNS request is made for an IP lookup service to determine the external IP address of the 
system via an unsigned or untrusted binary. This is commonly used by malware for reconnaissance before 
establishing C2 connections.
"""
from = "now-9m"
index = ["logs-endpoint.events.network-*"]
language = "eql"
license = "Elastic License v2"
name = "DNS Request for IP Lookup Service via Unsigned Binary"
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 DNS Request for IP Lookup Service via Unsigned Binary

This detects an unsigned or untrusted process on macOS performing DNS lookups for common “what is my public IP” and geolocation services, a frequent reconnaissance step before external communications. It matters because malware uses the host’s external IP and region to choose C2 infrastructure, gate payload delivery, or evade sandboxing. A typical pattern is a dropped, unsigned Mach-O or script resolving api.ipify.org or ipinfo.io immediately after execution, then initiating outbound beacons.

### Possible investigation steps

- Identify the initiating process and parent chain, then validate whether the binary is expected for the host/user and whether it is actually unsigned versus a transient signature collection issue.  
- Review the same process’s near-term network activity for follow-on HTTP(S) requests to the resolved service and any subsequent connections to rare/new domains or IPs that could indicate C2 staging.  
- Pivot from the resolved domain to other endpoints to determine prevalence and timing, then prioritize isolated single-host hits with recent first-seen binaries.  
- Examine how the binary was introduced by correlating with recent downloads, archive mounts, installer executions, or quarantine/Gatekeeper events around the process start time.  
- Acquire and analyze the binary (hash reputation, static strings, entitlements, persistence mechanisms, and launch agents/daemons) to confirm intent and scope of compromise.

### False positive analysis

- A developer-built or locally compiled macOS utility/script (run from a user directory) performs a “what is my public IP” DNS lookup for telemetry, diagnostics, or environment detection, and is flagged because it lacks a trusted code signature.  
- An unsigned helper binary dropped by a legitimate installer/updater workflow briefly runs during setup to validate external connectivity or geolocation by resolving an IP-lookup domain, and is detected before the binary is signed or placed in its final trusted location.

### Response and remediation

- Isolate the affected macOS host from the network if the unsigned process continues to resolve IP-lookup domains (e.g., api.ipify.org, ipinfo.io) or initiates new outbound connections immediately after the lookup.  
- Quarantine the unsigned executable and any associated scripts from disk (preserving path, hashes, and a copy for analysis) and remove its persistence artifacts such as newly created LaunchAgents/LaunchDaemons, login items, or cron entries tied to the same binary.  
- Block the observed IP-lookup domains used by the unsigned process at DNS/web egress and add temporary deny rules for any follow-on suspicious destinations the process contacted after resolution.  
- Reset compromised credentials and invalidate active sessions for the logged-in user if the process originated from user-writable locations (Downloads, Desktop, /tmp) or if additional discovery/collection behavior is found on the host.  
- Reimage or restore the endpoint from a known-good state when persistence or tampering is confirmed, then verify Gatekeeper/XProtect status, re-enable security tooling, and monitor for recurrence of the same binary hash or domain pattern.  
- Escalate to the incident response team if the unsigned binary is newly seen in the environment, appears on multiple hosts, or is followed by connections to rare domains/IPs indicative of staging or command-and-control.
"""
risk_score = 47
rule_id = "47e46d85-3963-44a0-b856-bccff48f8676"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
network where host.os.type == "macos" and event.action == "lookup_result" and 
  (process.code_signature.trusted == false or process.code_signature.exists == false) and
  dns.question.name like~ ("*ip-api.com*", "*ipwho.is*", "*checkip.dyndns.org*", "*api.ipify.org*",
                           "*api.npoint.io*", "*whatismyip.akamai.com*", "*bot.whatismyipaddress.com*",
                           "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", "*ipof.in*", "*ip.tyk.nu*",
                           "*ipwhois.app*", "*freeipapi.com*", "*icanhazip.com*", "*curlmyip.com*",
                           "*wgetip.com*", "*eth0.me*", "*ipecho.net*", "*ip.appspot.com*",
                           "*api.myip.com*", "*geoiptool.com*", "*api.2ip.ua*", "*api.ip.sb*",
                           "*ipinfo.io*", "*checkip.amazonaws.com*", "*wtfismyip.com*", "*iplogger.*",
                           "*freegeoip.net*", "*freegeoip.app*", "*myip.ipip.net*", "*geoplugin.net*",
                           "*myip.dnsomatic.com*", "*www.geoplugin.net*", "*api64.ipify.org*",
                           "*ip4.seeip.org*", "*.geojs.io*", "*portmap.io*", "*api.db-ip.com*",
                           "*geolocation-db.com*", "*inet-ip.info*", "*httpbin.org*", "*myip.opendns.com*") and
  not process.executable like "/Users/*/Library/Developer/CoreSimulator/*"
'''

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

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

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

    [[rule.threat.technique.subtechnique]]
    name = "Internet Connection Discovery"
    id = "T1016.001"
    reference = "https://attack.mitre.org/techniques/T1016/001/"

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

[rule]
author = ["Elastic"]
description = """
Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are
registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event;
registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of
adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new
Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered
device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets,
so multiple registrations on a single low-privilege identity establish device-bound persistence at scale.
"""
false_positives = [
    """
    A user legitimately enrolling several devices in a short window (for example, a new laptop and phone during
    onboarding, or re-registering a device after a wipe) can produce three or more registrations. Validate against the
    user's device inventory and onboarding activity, and consider raising the threshold or tightening the window if
    benign multi-device enrollment is common in the environment.
    """,
    """
    Bulk provisioning workflows, autopilot/MDM rollouts, or device-management tooling that registers devices on behalf
    of users may generate multiple registrations across many users at once. Suppress during planned rollout windows.
    """,
]
from = "now-30m"
language = "esql"
license = "Elastic License v2"
name = "Entra ID Multiple Device Registrations by a Single User"
note = """## Triage and analysis

### Investigating Entra ID Multiple Device Registrations by a Single User

A single Entra ID "Register device" event is routine: a user enrolling one device emits one registration. Concentrating three or more distinct device registrations onto one user inside a 15-minute window is uncommon for legitimate activity and is the fingerprint of either:

- An AiTM phishing-kit relay session that, after capturing the victim's sign-in, registers one or more Azure AD-joined devices of its own from the kit infrastructure within minutes (observed cadence of roughly one device every 2-6 minutes, e.g. Kali365 registering five devices in ~12 minutes).
- Token-replay tooling driving multiple device joins in quick succession off a stolen refresh token or PRT.

Each registered device is a separate principal with its own certificate-bound PRT. Because user-level controls (`revokeSignInSessions`, password reset) do not invalidate device-bound PRTs, every device left in place is an independent, persistent foothold.

### Possible investigation steps

- Identify the user (`azure.auditlogs.properties.initiated_by.user.userPrincipalName`) and review the registered devices in `Esql.device_name_values`. Tool-driven joins frequently use default Windows-style names such as `DESKTOP-<6 alphanumeric>` and a homogeneous, hardcoded OS build.
- Inspect `Esql.user_agent_values` from the `Register device` events. A spoofed Windows device-registration client string (`Dsreg/10.0 (Windows <build>)`) or a raw HTTP client (`axios/*`, `python-requests/*`, `Microsoft.OData.Client/*`) instead of a genuine browser/endpoint user agent is high-fidelity tooling.
- Pivot to the paired `Add device` events for each device (correlate via `azure.correlation_id`) and review the modified properties: `DeviceOSType`, `DeviceOSVersion`/`CloudDeviceOSVersion`, and `DeviceTrustType`. A `DeviceTrustType` of `AzureAd` (full join) on a low-privilege user, and an identical hardcoded OS build across all devices in the window, are strong indicators.
- Review the origin surfaced on the alert: `Esql.source_ip_values`, `Esql.source_as_number_values`, `Esql.source_as_organization_values`, and `Esql.source_country_values`/`Esql.source_city_values`/`Esql.source_region_values`. Hosting/VPS ASNs (for example Tencent, Alibaba, or other cloud providers) and unexpected geographies for a device-registration event are high-fidelity suspicious. A single source IP/ASN across every registration in the window is consistent with one piece of kit infrastructure driving the joins.
- Cross-reference `logs-azure.signinlogs-*` for the same user around the registration window. The registrations are brokered through the `Microsoft Authentication Broker` application against the `Device Registration Service` resource; confirm whether the broker was subsequently used to mint tokens for other resources (for example Microsoft Graph) from the same source.
- Cross-reference `logs-azure.auditlogs-*` for a security-info / MFA method registration (`User registered security info`) by the same user near the registration window; AiTM kits commonly plant their own MFA method alongside the device persistence.
- Confirm with the user whether they performed a multi-device enrollment or onboarding action during the window.

### False positive analysis

- New-device or onboarding flows where a user enrolls three or more devices in a short window can fire. Validate against the user's known device inventory and any onboarding or device-refresh events.
- Bulk provisioning, autopilot, or MDM rollouts can register multiple devices per user concurrently. Consider suppression during planned rollouts.
- If benign multi-device enrollment is routine in the environment, raise the distinct-device threshold or shorten the window.

### Response and remediation

- Treat as likely AiTM compromise or token replay until proven otherwise. Remove the rogue device registrations BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions` and a device left in place re-establishes access.
    - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for each unrecognized device in the window.
- Revoke refresh tokens and sessions, then reset credentials and re-register MFA.
    - `POST /v1.0/users/{id}/revokeSignInSessions`.
- Temporarily disable the account if activity must be halted during investigation.
    - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`.
- Remove other attacker persistence established alongside the device joins: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents.
- Hunt for the same device-name pattern, OS build, and registration user agent across other users and tenants, and apply Conditional Access to restrict device registration (require a compliant/managed device or trusted network).
"""
references = [
    "https://any.run/malware-trends/kali365/",
    "https://www.huntress.com/blog/kali365-device-code-phishing-kit",
    "https://www.ic3.gov/PSA/2026/PSA260521",
    "https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/"
]
risk_score = 47
rule_id = "960b1cef-f94d-4150-863d-b1dc311739de"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-azure.auditlogs-*
| where data_stream.dataset == "azure.auditlogs"
    and azure.auditlogs.operation_name == "Register device"
    and azure.auditlogs.properties.initiated_by.user.userPrincipalName is not null
    // For "Register device" the registered device is the primary target resource (index 0);
    // target_resources is a numeric-indexed object array in this integration, so wildcard/name-based matching is not available.
    and `azure.auditlogs.properties.target_resources.0.display_name` is not null

| eval Esql.bucket_window = date_trunc(15 minutes, @timestamp)

| stats
    Esql.count_distinct_devices = count_distinct(`azure.auditlogs.properties.target_resources.0.display_name`),
    Esql.device_name_values = values(`azure.auditlogs.properties.target_resources.0.display_name`),
    Esql.user_agent_values = values(azure.auditlogs.properties.userAgent),
    Esql.source_ip_values = values(source.ip),
    Esql.source_as_number_values = values(source.`as`.number),
    Esql.source_as_organization_values = values(source.`as`.organization.name),
    Esql.source_country_values = values(source.geo.country_name),
    Esql.source_city_values = values(source.geo.city_name),
    Esql.source_region_values = values(source.geo.region_name),
    Esql.correlation_id_values = values(azure.correlation_id),
    Esql.timestamp_first_seen = min(@timestamp),
    Esql.timestamp_last_seen = max(@timestamp),
    Esql.event_count = count(*)
    by azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.bucket_window

| where Esql.count_distinct_devices >= 3

| keep azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.*
'''


[[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.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[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 = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"


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

[rule.investigation_fields]
field_names = [
    "azure.auditlogs.properties.initiated_by.user.userPrincipalName",
    "Esql.count_distinct_devices",
    "Esql.device_name_values",
    "Esql.user_agent_values",
    "Esql.source_ip_values",
    "Esql.source_as_organization_values",
]

[metadata]
creation_date = "2025/03/10"
integration = ["azure"]
maturity = "production"
updated_date = "2026/08/12"

[rule]
author = ["Elastic"]
description = """
Detects rare non-interactive sign-ins where an Entra ID client application authenticates on behalf of a principal user
using an application (client) ID that is not commonly associated with that user's historical sign-in behavior.
Adversaries with stolen credentials or OAuth tokens may abuse Entra ID–managed or first-party client IDs to perform
on-behalf-of (OBO) authentication, blending into legitimate cloud traffic while avoiding traditional interactive sign-in
flows. This technique is commonly observed in OAuth phishing, token theft, and access broker operations, and may precede
lateral movement, persistence, or data access via Microsoft Graph or other cloud resources. The rule uses a New Terms
approach to identify first-seen combinations of the UPN and Client ID within a defined history window, helping surface
unexpected client usage that may indicate compromised identities, malicious automation, or unauthorized application
impersonation.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID User Sign-in with Unusual Client"
note = """## Triage and analysis

### Investigating Entra ID User Sign-in with Unusual Client

This rule identifies rare Azure Entra apps IDs requesting authentication on-behalf-of a principal user. An adversary with stolen credentials may specify an Azure-managed app ID to authenticate on-behalf-of a user. This is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The app ID specified may not be commonly used by the user based on their historical sign-in activity.

### Possible investigation steps

- Identify the source IP address from which the failed login attempts originated by reviewing `source.ip`. Determine if the IP is associated with known malicious activity using threat intelligence sources or if it belongs to a corporate VPN, proxy, or automation process.
- Analyze affected user accounts by reviewing `azure.signinlogs.properties.user_principal_name` to determine if they belong to privileged roles or high-value users. Look for patterns indicating multiple failed attempts across different users, which could suggest a password spraying attempt.
- Examine the authentication method used in `azure.signinlogs.properties.authentication_details` to identify which authentication protocols were attempted and why they failed. Legacy authentication methods may be more susceptible to brute-force attacks.
- Review the authentication error codes found in `azure.signinlogs.properties.status.error_code` to understand why the login attempts failed. Common errors include `50126` for invalid credentials, `50053` for account lockouts, `50055` for expired passwords, and `50056` for users without a password.
- Correlate failed logins with other sign-in activity by looking at `event.outcome`. Identify if there were any successful logins from the same user shortly after multiple failures or if there are different geolocations or device fingerprints associated with the same account.
- Review `azure.signinlogs.properties.app_id` to identify which applications were initiating the authentication attempts. Determine if these applications are Microsoft-owned, third-party, or custom applications and if they are authorized to access the resources.
- Check for any conditional access policies that may have been triggered by the failed login attempts by reviewing `azure.signinlogs.properties.authentication_requirement`. This can help identify if the failed attempts were due to policy enforcement or misconfiguration.

## False positive analysis

- Automated scripts or applications using non-interactive authentication may trigger this detection, particularly if they rely on legacy authentication protocols recorded in `azure.signinlogs.properties.authentication_protocol`.
- Corporate proxies or VPNs may cause multiple users to authenticate from the same IP, appearing as repeated failed attempts under `source.ip`.
- User account lockouts from forgotten passwords or misconfigured applications may show multiple authentication failures in `azure.signinlogs.properties.status.error_code`.
- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`.
- Exclude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication.
- Microsoft Feedback Portal UX generates benign first-seen client activity through PRT-based, non-interactive sign-ins and is excluded by application ID.
- Microsoft Teams routinely requests tokens for its internal Teams Services, IC3 Gateway, Chat Aggregator, and CMD Services resources; these client-resource combinations are excluded.
- Managed Windows devices routinely request OfficeHome PRTs with Microsoft 365 Copilot scopes through the standard Microsoft 365 desktop client; this combination is excluded.
- Ignore principals with a history of failed logins due to legitimate reasons, such as expired passwords or account lockouts, by filtering `azure.signinlogs.properties.user_principal_name`.
- Correlate sign-in failures with password reset events or normal user behavior before triggering an alert.

## Response and remediation

- Block the source IP address in `source.ip` if determined to be malicious.
- Reset passwords for all affected user accounts listed in `azure.signinlogs.properties.user_principal_name` and enforce stronger password policies.
- Ensure basic authentication is disabled for all applications using legacy authentication protocols listed in `azure.signinlogs.properties.authentication_protocol`.
- Enable multi-factor authentication (MFA) for impacted accounts to mitigate credential-based attacks.
- Review conditional access policies to ensure they are correctly configured to block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`.
- Review Conditional Access policies to enforce risk-based authentication and block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`.
- Implement a zero-trust security model by enforcing least privilege access and continuous authentication.
- Regularly review and update conditional access policies to ensure they are effective against evolving threats.
- Restrict the use of legacy authentication protocols by disabling authentication methods listed in `azure.signinlogs.properties.client_app_used`.
- Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks.
- Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft.
"""
references = ["https://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf"]
risk_score = 47
rule_id = "c766bc56-fdca-11ef-b194-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Entra ID",
    "Data Source: Entra ID Sign-in",
    "Platform: Entra ID",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "azure.signinlogs" and event.category: "authentication"
    and azure.signinlogs.properties.is_interactive: false
    and azure.signinlogs.properties.user_type: "Member"
    and not azure.signinlogs.properties.client_app_used: "Browser"
    and not source.as.organization.name: "MICROSOFT-CORP-MSN-AS-BLOCK"
    and not azure.signinlogs.properties.app_id: (
        "1b3c667f-cde3-4090-b60b-3d2abd0117f0" or
        "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or
        "4b0964e4-58f1-47f4-a552-e2e1fc56dcd7" or
        "ecd6b820-32c2-49b6-98a6-444530e5a77a" or
        "268761a2-03f3-40df-8a8b-c3db24145b6b" or
        "fc0f3af4-6835-4174-b806-f7db311fd2f3" or
        "de50c81f-5f80-4771-b66b-cebd28ccdfc1" or
        "ab9b8c07-8f02-4f72-87fa-80105867a763" or
        "6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3" or
        "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or
        "52c2e0b5-c7b6-4d11-a89c-21e42bcec444" or
        "38aa3b87-a06d-4817-b275-7a316988d93b" or
        "27922004-5251-4030-b22d-91ecd9a37ea4" or
        "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or
        "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or
        "3a4d129e-7f50-4e0d-a7fd-033add0a29f4" or
        "29d9ed98-a469-4536-ade2-f981bc1d605e" or
        "c0ab8ce9-e9a0-42e7-b064-33d422df41f1" or
        "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7" or
        "4813382a-8fa7-425e-ab75-3b753aab3abb" or
        "08e18876-6177-487e-b8b5-cf950c1e598c" or
        "0ec893e0-5785-4de6-99da-4ed124e5296c" or
        "d3590ed6-52b3-4102-aeff-aad2292ab01c" or
        "0dc2408a-bbc0-4238-871e-13b372f0200f" or
        "af124e86-4e96-495a-b70a-90f90ab96707" or
        "e9c51622-460d-4d3d-952d-966a5b1da34c" or
        "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or
        "e2ef5054-0287-4db6-afa3-013d96881fd3" or
        "82864fa0-ed49-4711-8395-a0e6003dca1f" or
        "60c8bde5-3167-4f92-8fdb-059f6176dc0f" or
        "5d661950-3475-41cd-a2c3-d671a3162bc1" or
        "145fc680-eb72-4bcf-b4d5-8277021a1ce8" or
        "c1c74fed-04c9-4704-80dc-9f79a2e515cb" or
        "a2760c41-63c9-42b5-8d58-bfa1fd9e2eb3" or
        "6dec647e-42c4-45a6-8f13-e8250d34e033" or
        "c98e5057-edde-4666-b301-186a01b4dc58" or
        "0a31c71e-0abf-4238-add7-b1a24c165dc1" or
        "a8759234-4b8b-4d94-8c0a-ee1ab73af270" or
        "dae89220-69ba-4957-a77a-47b78695e883" or
        "fd5f78f6-a28f-450b-abc7-777f3dbbfcba" or
        "821caec6-bec3-4542-bead-d3c5fb6b4ef0" or
        "a40d7d7d-59aa-447e-a655-679a4107e548" or
        "bed12bc0-3a62-470d-998c-e47546e7b039" or
        "f4060917-6abe-40d7-baa6-f634c0eda4ac" or
        "b26aadf8-566f-4478-926f-589f601d9c74" or
        "1f7f6f43-2f81-429c-8499-293566d0ab0c" or
        "75f31797-37c9-498e-8dc9-53c16a36afca" or
        "3e050dd7-7815-46a0-8263-b73168a42c10" or
        "243c63a3-247d-41c5-9d83-7788c43f1c43" or
        "75efb5bc-18a1-4e7b-8a66-2ad2503d79c6" or
        "d32f3b53-b7d7-48df-8d0f-f8bf233b3f1f" or
        "95de633a-083e-42f5-b444-a4295d8e9314" or
        "3ff8e6ba-7dc3-4e9e-ba40-ee12b60d6d48" or
        "871c010f-5e61-4fb1-83ac-98610a7e9110" or
        "3e62f81e-590b-425b-9531-cad6683656cf" or
        "8ec6bc83-69c8-4392-8f08-b3c986009232" or
        "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or
        "dd762716-544d-4aeb-a526-687b73838a22" or
        "7f8f922d-7ee4-40a6-b435-aad8b84ebde0" or
        "f8d98a96-0999-43f5-8af3-69971c7bb423" or
        "aa580612-c342-4ace-9055-8edee43ccb89" or
        "7f67af8a-fedc-4b08-8b4e-37c4d127b6cf" or
        "00bf137d-f689-4c5d-83d9-7fc31904a7ea" or
        "ceb96695-e468-48ba-ba21-35e2a242d396" or
        "7fba38f4-ec1f-458d-906c-f4e3c4f41335" or
        "a2a1fecc-b06e-4a1e-95c1-2afd94bcadff" or
        "15ddab63-ba81-45db-9bb6-6f8bc445c459" or
        "bc59ab01-8403-45c6-8796-ac3ef710b3e3" or
        "00000003-0000-0ff1-ce00-000000000000" or
        "4e291c71-d680-4d0e-9640-0a3358e31177" or
        "4fb5cc57-dbbc-4cdc-9595-748adff5f414" or
        "22098786-6e16-43cc-a27d-191a01a1e3b5" or
        "ebde7daf-df42-4ade-81a4-d67b339b49e9" or
        "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or
        "a672d62c-fc7b-4e81-a576-e60dc46e951d" or
        "0b1df6d3-2deb-44d4-b44b-7101937e0726" or
        "04f0c124-f2bc-4f59-8241-bf6df9866bbd" or
        "86f4c005-6582-4559-b6cf-8b3111236736" or
        "a0a3c1d3-7b82-4010-bdb0-e7048fb8f1fe" or
        "a187e399-0c36-4b98-8f04-1edc167a0996" or
        "2d4d3d8e-2be3-4bef-9f87-7875a61c29de" or
        "c475db56-f463-48d8-931a-cfa7cd642289" or
        "71a7c376-13e6-4100-968e-92ce98c5d3d2"
    )
    and not (
        azure.signinlogs.properties.app_id: "1fec8e78-bce4-4aaf-ab1b-5451cc387264" and
        azure.signinlogs.properties.resource_id: (
            "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or
            "39aaf054-81a5-48c7-a4f8-0293012095b9" or
            "b1379a75-ce5e-4fa3-80c6-89bb39bf646c" or
            "6bc3b958-689b-49f5-9006-36d165f30e00"
        )
    )
    and not (
        azure.signinlogs.properties.app_id: "4765445b-32c6-49b0-83e6-1d93765276ca" and
        azure.signinlogs.properties.resource_id: "4765445b-32c6-49b0-83e6-1d93765276ca" and
        azure.signinlogs.properties.authentication_processing_details: *M365Copilot.Read.All* and
        azure.signinlogs.properties.incoming_token_type: "primaryRefreshToken" and
        azure.signinlogs.properties.client_app_used: "Mobile Apps and Desktop clients" and
        azure.signinlogs.properties.device_detail.is_managed: true and
        azure.signinlogs.properties.device_detail.operating_system: "Windows10" and
        user_agent.original: Mozilla*Edge/18.*
    )
'''


[[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 = "T1528"
name = "Steal Application Access Token"
reference = "https://attack.mitre.org/techniques/T1528/"

[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 = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.user_id",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.client_app_used",
    "azure.signinlogs.properties.incoming_token_type",
    "azure.signinlogs.properties.authentication_protocol",
    "azure.signinlogs.properties.authentication_requirement",
    "azure.signinlogs.properties.token_issuer_type",
    "azure.signinlogs.properties.resource_display_name",
    "source.ip",
    "source.as.number",
    "source.geo.country_name",
    "azure.signinlogs.properties.correlation_id",
    "azure.signinlogs.properties.session_id",
]

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

[rule]
description = """
Identifies attempts to execute a child process from within the context of an Electron application using the
child_process Node.js module. Adversaries may abuse this technique to inherit permissions from parent processes.
"""
id = "1d43f87d-2466-4714-8fef-d52816cc25fb"
license = "Elastic License v2"
name = "Execution via Electron Child Process Node.js Module"
os_list = ["macos"]
reference = [
    "https://www.matthewslipper.com/2019/09/22/everything-you-wanted-electron-child-process.html",
    "https://www.trustedsec.com/blog/macos-injection-via-third-party-frameworks/",
    "https://nodejs.org/api/child_process.html",
]
version = "1.0.36"

query = '''
process where event.action == "exec" and
 process.args == "-e" and process.command_line like~ "*require*child_process*" and
 process.command_line like~ "*spawn*" and
 (
   /* Spawning shells with inline commands */
   process.command_line like~ ("*spawn*bash*-c*", "*spawn*sh*-c*", "*spawn*zsh*-c*") or
   /* Spawning curl/wget for download */
   process.command_line like~ ("*spawn*curl*", "*spawn*wget*") or
   /* Spawning osascript */
   process.command_line like~ "*spawn*osascript*" or
   /* Spawning python with inline code */
   process.command_line like~ "*spawn*python*-c*" or
   /* Base64 decode patterns */
   process.command_line like~ "*spawn*base64*" or
   /* Execution from suspicious staging paths */
   process.command_line like~ ("*spawn*/tmp/*", "*spawn*/Users/Shared/*", "*spawn*/private/tmp/*", "*spawn*/var/tmp/*")
 ) and
 not process.executable like
             ("/usr/bin/grep",
              "/Applications/Docker.app/Contents/Resources/bin/docker",
              "/Applications/Docker.app/Contents/Resources/bin/com.docker.cli") and
 not process.Ext.effective_parent.executable like 
    ("/Users/*/Library/Application Support/Claude/claude-code/*/claude.app/Contents/MacOS/claude",
      "/Applications/ChatGPT.app/Contents/MacOS/ChatGPT")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.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 = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"


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

[internal]
min_endpoint_version = "8.10.2"

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

[rule]
author = ["Elastic"]
description = """
Identifies when a firewall rule is deleted in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine.
These firewall rules can be configured to allow or deny connections to or from virtual machine (VM) instances or
specific applications. An adversary may delete a firewall rule in order to weaken their target's security controls.
"""
false_positives = [
    """
    Firewall rules may be deleted by system administrators. Verify that the firewall 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 Firewall Rule Deletion"
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 Firewall Rule Deletion

In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors audit logs for deletion actions, flagging potential defense evasion attempts by identifying specific deletion events in VPC or App Engine environments.

### Possible investigation steps

- Review the audit logs for the specific event.dataset:gcp.audit to confirm the deletion action and gather details such as the timestamp, user identity, and source IP address associated with the event.
- Investigate the event.action field to determine whether the deletion occurred in the VPC or App Engine environment, and identify the specific firewall rule that was deleted.
- Check the user or service account activity around the time of the deletion to identify any suspicious behavior or unauthorized access attempts.
- Assess the impact of the deleted firewall rule by reviewing the network traffic patterns and security posture before and after the deletion.
- Collaborate with the network security team to determine if the deletion was part of a legitimate change management process or if it indicates a potential security incident.

### False positive analysis

- Routine maintenance or updates by authorized personnel may trigger firewall rule deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
- Automated scripts or tools used for infrastructure management might delete and recreate firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service accounts or tags associated with these tools.
- Changes in application deployment processes, especially in environments like App Engine, can lead to legitimate firewall rule deletions. Review deployment logs and processes to identify patterns and exclude these from alerts.
- Organizational policy changes that involve restructuring network security may result in bulk deletions of firewall rules. Coordinate with network security teams to understand planned changes and temporarily adjust detection rules during these periods.
- Test environments often have dynamic configurations where firewall rules are frequently added and removed. Exclude specific projects or environments designated for testing from the detection rule to reduce noise.

### Response and remediation

- Immediately isolate affected VM instances or applications by applying restrictive firewall rules to prevent further unauthorized access or data exfiltration.
- Review audit logs to identify the source of the deletion action, including user accounts and IP addresses involved, and verify if the action was authorized.
- Recreate the deleted firewall rules based on the last known good configuration to restore security controls and prevent unauthorized access.
- Conduct a security review of the affected environment to identify any additional unauthorized changes or indicators of compromise.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
- Implement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future.
- Review and update access controls and permissions for users and service accounts to ensure that only authorized personnel can modify firewall rules.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://cloud.google.com/vpc/docs/firewalls",
    "https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls",
]
risk_score = 47
rule_id = "ff9b571e-61d6-4f6c-9561-eb4cca3bafe1"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule)
'''


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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies remote execution via Windows PowerShell remoting. Windows PowerShell remoting allows a user to run any
Windows PowerShell command on one or more remote computers. This could be an indication of lateral movement.
"""
false_positives = [
    """
    PowerShell remoting is a dual-use protocol that can be used for benign or malicious activity. It's important to
    baseline your environment to determine the amount of noise to expect from this tool.
    """,
]
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "logs-windows.sysmon_operational-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Incoming Execution via PowerShell Remoting"
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 Incoming Execution via PowerShell Remoting

PowerShell Remoting enables administrators to execute commands on remote Windows systems, facilitating efficient management. However, adversaries can exploit this feature for lateral movement within a network. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by PowerShell Remoting, flagging potential unauthorized remote executions.

### Possible investigation steps

- Review the network traffic logs to identify the source IP address involved in the alert, ensuring it is not a known or authorized management system.
- Check the destination port (5985 or 5986) to confirm it aligns with PowerShell Remoting activity and verify if the connection was expected or authorized.
- Investigate the process tree on the affected host to determine if the process initiated by wsmprovhost.exe is legitimate or if it shows signs of suspicious activity.
- Examine the parent process of wsmprovhost.exe to identify any unusual or unauthorized processes that may have triggered the PowerShell Remoting session.
- Correlate the event with user activity logs to determine if the remote execution was performed by a legitimate user or if there are signs of compromised credentials.
- Assess the risk score and severity in the context of the organization's environment to prioritize the response and determine if further containment or remediation actions are necessary.

### False positive analysis

- Legitimate administrative tasks using PowerShell Remoting can trigger the rule. To manage this, identify and whitelist known administrative IP addresses or user accounts that frequently perform remote management tasks.
- Automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance might be flagged. Review and document these scripts, then create exceptions for their specific process names or execution paths.
- Security tools or monitoring solutions that leverage PowerShell Remoting for legitimate purposes may cause alerts. Verify these tools and exclude their associated network traffic or processes from the detection rule.
- Internal IT support activities that involve remote troubleshooting using PowerShell Remoting can be mistaken for threats. Maintain a list of support personnel and their IP addresses to exclude them from triggering alerts.
- Regular software updates or patch management processes that utilize PowerShell Remoting should be considered. Identify these processes and exclude their network traffic or process executions to prevent false positives.

### Response and remediation

- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary.
- Terminate any suspicious PowerShell processes identified, especially those initiated by wsmprovhost.exe, to stop unauthorized remote executions.
- Conduct a thorough review of recent user activity and access logs on the affected host to identify any unauthorized access or changes.
- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access.
- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited.
- Enhance monitoring on the network for unusual activity on ports 5985 and 5986 to detect any future attempts at unauthorized PowerShell Remoting.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
references = [
    "https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands?view=powershell-7.1",
]
risk_score = 47
rule_id = "2772264c-6fb9-4d9d-9014-b416eed21254"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by host.id with maxspan = 30s
   [network where host.os.type == "windows" and network.direction : ("incoming", "ingress") and destination.port in (5985, 5986) and
    source.ip != "127.0.0.1" and source.ip != "::1"]
   [process where host.os.type == "windows" and
    event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"]
'''

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:

- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
"""


[[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.006"
name = "Windows Remote Management"
reference = "https://attack.mitre.org/techniques/T1021/006/"



[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[[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/"