Elastic rules: 21

[metadata]
creation_date = "2022/09/03"
integration = ["endpoint", "auditd_manager"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies the use of the AWS Systems Manager (SSM) `SendCommand` API with the either `AWS-RunShellScript` or
`AWS-RunPowerShellScript` parameters. The `SendCommand` API call allows users to execute commands on EC2 instances using
the SSM service. Adversaries may use this technique to execute commands on EC2 instances without the need for SSH or RDP
access. This behavior may indicate an adversary attempting to execute commands on an EC2 instance for malicious
purposes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags
when this behavior is observed for the first time on a host in the last 7 days.
"""
false_positives = [
    """
    Legitimate use of the `SendCommand` API call to execute commands on EC2 instances using the SSM service may be done
    by system administrators or DevOps engineers for legitimate purposes.
    """,
]
from = "now-9m"
index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SSM `SendCommand` with Run Shell Command Parameters"
references = [
    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc",
    "https://securitycafe.ro/2023/01/17/aws-post-explitation-with-ssm-sendcommand/",
]
risk_score = 47
rule_id = "c371e9fc-6a10-11ef-a0ac-f661ea17fbcc"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
event.category: "process" and event.type: "start" and process.name: "aws"
and (
    host.os.type: ("windows" or "macos")
    or (
        host.os.type: "linux"
        and event.action: ("exec" or "exec_event" or "executed" or "process_started")
    )
)
and process.args: (
    "send-command" and "--parameters" and commands=*
    and ("AWS-RunShellScript" or "AWS-RunPowerShellScript")
)
'''
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 AWS SSM `SendCommand` with Run Shell Command Parameters

AWS Systems Manager (SSM) allows remote command execution on EC2 instances via the `SendCommand` API, using scripts like `AWS-RunShellScript` or `AWS-RunPowerShellScript`. Adversaries may exploit this to execute unauthorized commands without direct access. The detection rule identifies unusual command executions by monitoring process activities, flagging first-time occurrences within a week to spot potential threats.

### Possible investigation steps

- Review the alert details to identify the specific EC2 instance and the user account associated with the `SendCommand` API call.
- Check the AWS CloudTrail logs for the `SendCommand` event to gather additional context, such as the source IP address, user agent, and any associated IAM roles or policies.
- Investigate the command parameters used in the `SendCommand` API call, focusing on the `commands` field to determine the nature and intent of the executed script.
- Examine the process execution history on the affected host to identify any unusual or unauthorized processes that may have been initiated as a result of the command.
- Assess the recent activity of the user account involved in the alert to identify any other suspicious actions or deviations from normal behavior.
- Verify the integrity and security posture of the affected EC2 instance, checking for any signs of compromise or unauthorized changes.

### False positive analysis

- Routine administrative tasks using AWS SSM SendCommand may trigger alerts. Identify and document regular maintenance scripts and exclude them from detection to reduce noise.
- Automated deployment processes often use AWS-RunShellScript or AWS-RunPowerShellScript. Review deployment logs and whitelist these processes if they are verified as non-threatening.
- Monitoring or compliance checks that utilize SSM for gathering system information can be mistaken for malicious activity. Confirm these activities with the relevant teams and create exceptions for known benign operations.
- Scheduled tasks or cron jobs that execute commands via SSM should be reviewed. If they are part of standard operations, consider excluding them from the rule to prevent false positives.
- Development and testing environments frequently use SSM for testing scripts. Ensure these environments are well-documented and apply exceptions to avoid unnecessary alerts.

### Response and remediation

- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution and potential lateral movement.
- Review the AWS CloudTrail logs to identify the source of the `SendCommand` API call, including the IAM user or role that initiated the command, and assess whether the access was legitimate or compromised.
- Revoke or rotate the credentials of the IAM user or role involved in the suspicious activity to prevent further unauthorized access.
- Conduct a thorough examination of the affected EC2 instance to identify any unauthorized changes or installed malware, and restore the instance from a known good backup if necessary.
- Implement stricter IAM policies and permissions to limit the use of the `SendCommand` API to only trusted users and roles, ensuring the principle of least privilege is enforced.
- Enable multi-factor authentication (MFA) for all IAM users with permissions to execute commands on EC2 instances to add an additional layer of security.
- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources have been compromised."""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "process.user.name",
    "process.entry_leader.group.name",
    "process.entry_leader.real_user.name",
    "event.action",
    "event.type",
    "host.os.type",
    "host.os.kernel",
    "process.entry_leader.executable",
    "process.entry_leader.working_directory",
    "process.parent.executable",
    "process.executable",
    "process.hash.sha256",
    "process.parent.command_line",
    "process.command_line",
    "process.args"
]

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

[[rule.threat.technique]]
id = "T1651"
name = "Cloud Administration Command"
reference = "https://attack.mitre.org/techniques/T1651/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[rule.new_terms]
field = "new_terms_fields"
value = ["host.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

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

[rule]
author = ["Elastic"]
description = """
Detects when a service principal authenticates to Microsoft Entra ID and then lists credentials for an Azure
Arc-connected Kubernetes cluster within a short time window. The `listClusterUserCredential` action retrieves tokens
that enable kubectl access through the Arc Cluster Connect proxy. This sequence (service principal sign-in followed by
Arc credential retrieval), represents the exact attack chain used by adversaries with stolen service principal secrets
to establish a proxy tunnel into Kubernetes clusters. Service principals that authenticate externally (as opposed to
managed identities) and immediately access Arc cluster credentials warrant investigation, particularly when the sign-in
originates from an unexpected location or ASN.
"""
false_positives = [
    """
    CI/CD pipelines that authenticate as a service principal and then access Arc clusters as part of deployment
    workflows will trigger this rule. Identify and exclude known automation service principal app IDs.
    """,
    """
    Administrators using service principal credentials to manage Arc-connected clusters during maintenance windows may
    trigger this rule. Correlate with change management records.
    """,
]
from = "now-30m"
index = ["logs-azure.signinlogs-*", "logs-azure.activitylogs-*"]
interval = "15m"
language = "eql"
license = "Elastic License v2"
name = "Azure Service Principal Sign-In Followed by Arc Cluster Credential Access"
note = """## Triage and analysis

### Investigating Azure Service Principal Sign-In Followed by Arc Cluster Credential Access

This rule detects the complete attack entry point for Arc-proxied Kubernetes attacks: a service principal authenticates
to Azure AD, then immediately retrieves Arc cluster credentials. This is the prerequisite sequence before any
Kubernetes-level activity can occur through the Arc proxy.

### Possible investigation steps

- Identify the service principal using the `app_id` from the sign-in event and resolve it in Azure AD — is this a
  known application?
- Check the sign-in source IP and geolocation — does it match expected infrastructure locations for this SP?
- Review when the SP credentials were last rotated — stale credentials are more likely compromised.
- Check the ASN of the sign-in source — is it from a known cloud provider, corporate network, or unexpected consumer ISP?
- Examine Azure Activity Logs after the credential listing for any Arc-proxied operations (secret/configmap CRUD).
- Correlate with Kubernetes audit logs for operations by the Arc proxy service account
  (`system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa`) in the same time window.
- Review Azure AD Audit Logs for recent changes to this SP (new credentials, federated identities, owner changes).

### Response and remediation

- Immediately rotate the service principal credentials (secrets and certificates).
- Revoke active sessions and tokens for the SP.
- Review and remove any unauthorized Azure role assignments on Arc-connected clusters.
- Check Kubernetes audit logs for any operations performed through the Arc proxy after credential access.
- Rotate any Kubernetes secrets that may have been accessed through the proxy tunnel.
- Enable conditional access policies to restrict service principal authentication by location if supported.
"""
references = [
    "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect",
    "https://learn.microsoft.com/en-us/cli/azure/connectedk8s#az-connectedk8s-proxy",
    "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins",
    "https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence",
    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
]
risk_score = 47
rule_id = "dacfbecd-7927-46a7-a8ba-feb65a2e990d"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Azure Arc",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-In Logs",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence with maxspan=30m
[authentication where data_stream.dataset == "azure.signinlogs"
    and azure.signinlogs.category == "ServicePrincipalSignInLogs"
    and azure.signinlogs.properties.status.error_code == 0
] by azure.signinlogs.properties.app_id
[any where data_stream.dataset == "azure.activitylogs"
    and azure.activitylogs.operation_name : "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION"
    and event.outcome : ("Success", "success")
] by azure.activitylogs.identity.claims.appid
'''


[[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.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"

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

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

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

[[rule.threat.technique]]
id = "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.investigation_fields]
field_names = [
    "@timestamp",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.service_principal_name",
    "azure.signinlogs.category",
    "azure.activitylogs.operation_name",
    "azure.activitylogs.identity.claims.appid",
    "azure.resource.id",
    "source.ip",
    "source.geo.country_name",
    "source.geo.city_name",
    "source.as.organization.name",
]

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

[rule]
author = ["Elastic"]
description = """
This rule detects the use of system search utilities like grep and find to search for AWS credentials inside a
container. Unauthorized access to these sensitive files could lead to further compromise of the container
environment or facilitate a container breakout to the underlying cloud environment.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Cloud Credential Search Detected via Defend for Containers"
references = ["https://sysdig.com/blog/threat-detection-aws-cloud-containers/"]
risk_score = 47
rule_id = "d0b0f3ed-0b37-44bf-adee-e8cb7de92767"
severity = "medium"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate", "cat", "sed", "awk") or
  (
    /* Account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
    process.args in (
      "grep", "/bin/grep", "/usr/bin/grep", "/usr/local/bin/grep",
      "egrep", "/bin/egrep", "/usr/bin/egrep", "/usr/local/bin/egrep",
      "fgrep", "/bin/fgrep", "/usr/bin/fgrep", "/usr/local/bin/fgrep",
      "find", "/bin/find", "/usr/bin/find", "/usr/local/bin/find",
      "locate", "/bin/locate", "/usr/bin/locate", "/usr/local/bin/locate",
      "mlocate", "/bin/mlocate", "/usr/bin/mlocate", "/usr/local/bin/mlocate",
      "cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
      "sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
      "awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
    ) and 
    /* default exclusion list to not FP on default multi-process commands */
    not process.args in (
      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
    )
  )
)
and
process.args like~ (
  /* AWS Credentials */
  "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*",
  "*access_key*", "*.aws/credentials*",

  /* Azure Credentials */
  "*AZURE_CLIENT_ID*", "*AZURE_TENANT_ID*", "*AZURE_CLIENT_SECRET*", "*AZURE_FEDERATED_TOKEN_FILE*",
  "*IDENTITY_ENDPOINT*", "*IDENTITY_HEADER*", "*MSI_ENDPOINT*", "*MSI_SECRET*",
  "*/.azure/*", "*/var/run/secrets/azure/*",

  /* GCP Credentials */
  "*/.config/gcloud/*", "*application_default_credentials.json*",
  "*type: service_account*", "*client_email*", "*private_key_id*", "*private_key*",
  "*/var/run/secrets/google/*", "*GOOGLE_APPLICATION_CREDENTIALS*"
) and container.id like "*" 
'''

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

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

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

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

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

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

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

[rule]
description = """
Identifies a file extension used by DARKRADIATION bash ransomware that abuses the openssl utility to encrypt files.
Adversaries may encrypt data on target systems or on large numbers of systems in a network to interrupt availability to
system and network resources.
"""
id = "33309858-3154-47a6-b601-eda2de62557b"
license = "Elastic License v2"
name = "DARKRADIATION Ransomware Infection"
os_list = ["linux", "macos"]
reference = [
    "https://www.trendmicro.com/en_us/research/21/f/bash-ransomware-darkradiation-targets-red-hat--and-debian-based-linux-distributions.html",
]
version = "1.0.29"

query = '''
process where event.type == "start" and event.action == "exec" and
 process.name == "xargs" and process.args == "openssl" and process.args == "enc" and
 /* radiation unicode symbol used by DARKRADIATION ransomware */
 process.command_line like "*.☢*"
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1486"
name = "Data Encrypted for Impact"
reference = "https://attack.mitre.org/techniques/T1486/"


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2026/07/02"
integration = ["endpoint"]
maturity = "production"
min_stack_version = "9.3.0"
min_stack_comments = "DNS for Linux support was introduced in 9.3.0"
updated_date = "2026/07/20"

[rule]
author = ["Elastic"]
description = """
This rule detects DNS queries to commonly abused top level domains. Malware authors may use these
domains to host command and control infrastructure, exfiltrate data, or to download payloads
for later execution.
"""
from = "now-9m"
index = ["logs-endpoint.events.network-*"]
language = "eql"
license = "Elastic License v2"
name = "DNS Request to Suspicious Top Level Domain"
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 to Suspicious Top Level Domain

This rule flags a Linux process making DNS lookups for top-level domains that threat actors frequently abuse, which can reveal command-and-control staging, payload retrieval, or data theft paths that blend into normal name resolution. A common pattern is a compromised Linux server or container resolving a .xyz, .top, or .ru domain immediately before a downloader, backdoor, or script beacon starts exchanging instructions or uploading collected data.

### Possible investigation steps

- Review the originating binary’s full command line, executable path, parent or child lineage, and user or service account to determine whether the lookup came from approved software, an admin script, or an unexpected downloader or shell.
- Correlate the DNS event with nearby outbound connections, HTTP or TLS sessions, and file activity on the same host to see whether the domain was followed by beaconing, payload retrieval, or data transfer.
- Enrich the queried domain and any resolved IPs with passive DNS, registration age, reputation, ASN or geolocation, and prevalence in your environment to distinguish newly created or low-reputation infrastructure from known business services.
- Determine whether the host is a server, workstation, or containerized workload and validate if the domain fits its normal role by comparing against recent activity, peer hosts, deployed applications, and change or deployment records.
- If the activity is not readily explained, inspect for adjacent compromise indicators such as new cron jobs or systemd timers, unexpected binaries in writable paths, recent package or script changes, and authentication or privilege escalation events around the same timeframe.

### False positive analysis

- Newly deployed or updated Linux applications, scripts, or package retrieval tasks may legitimately resolve domains in low-cost or regional TLDs for updates, licensing, or content delivery; verify the process path and parent chain match approved software and that similar lookups appear on peer hosts during the same change window.
- A user or service performing legitimate research or accessing region-specific content may query a country-code or commonly abused TLD from a browser or expected application; confirm the domain aligns with the host’s business purpose and that the activity is limited to normal browsing without subsequent suspicious connections, downloads, or persistence changes.

### Response and remediation

- Isolate the affected Linux host or container from the network except for approved management access, and immediately block the suspicious domain, its resolved IP addresses, and any follow-on destinations at DNS, proxy, and firewall controls.
- Terminate the offending process and remove persistence tied to the activity, including unauthorized systemd services or timers, cron entries, startup scripts, shell profile changes, and newly added SSH authorized_keys for the impacted account.
- Preserve the malicious binary or script and relevant logs for scoping, then rebuild the system from a known-good image or snapshot rather than cleaning in place, and restore altered files only from trusted backups.
- Rotate credentials and secrets exposed on the host, especially SSH keys, API tokens, service account passwords, and cloud or instance metadata credentials, because DNS-based command-and-control often precedes remote tasking and data theft.
- Escalate to incident response immediately if the same domain or related infrastructure appears on multiple hosts, if the process ran as root or a privileged service account, or if you identify outbound uploads, payload downloads, or lateral movement activity.
- Harden the environment by forcing outbound DNS through approved resolvers, restricting egress to required destinations, monitoring Linux systems for new systemd or cron persistence, and adding detections for the domain, executable hash, and related infrastructure.
"""
risk_score = 21
rule_id = "44a2de72-fe41-4558-b7ec-3e42de5f0432"
severity = "low"
tags = [
    "Domain: Endpoint",
    "Domain: Network",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Tactic: Exfiltration",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
network where host.os.type == "linux" and dns.question.name != null and process.name != null and
dns.question.name like~ (
  "*.forum", "*.pro", "*.team", "*.lol", "*.kr", "*.ke", "*.nu", "*.space", "*.capital", "*.in", "*.cfd", "*.online",
  "*.ru", "*.info", "*.top", "*.buzz", "*.xyz", "*.rest", "*.ml", "*.cf", "*.gq", "*.ga", "*.onion", "*.network",
  "*.monster", "*.marketing", "*.cyou", "*.quest", "*.cc", "*.bar", "*.click", "*.cam", "*.surf", "*.tk", "*.shop",
  "*.club", "*.icu", "*.pw", "*.ws", "*.fun", "*.life", "*.boats", "*.store", "*.hair", "*.mom",
  "*.beauty", "*.bond", "*.biz", "*.live", "*.zone"
)
'''

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1090.002"
name = "External Proxy"
reference = "https://attack.mitre.org/techniques/T1090/002/"

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

[[rule.threat.technique.subtechnique]]
id = "T1102.001"
name = "Dead Drop Resolver"
reference = "https://attack.mitre.org/techniques/T1102/001/"

[[rule.threat.technique.subtechnique]]
id = "T1102.002"
name = "Bidirectional Communication"
reference = "https://attack.mitre.org/techniques/T1102/002/"

[[rule.threat.technique]]
id = "T1568"
name = "Dynamic Resolution"
reference = "https://attack.mitre.org/techniques/T1568/"

[[rule.threat.technique.subtechnique]]
id = "T1568.002"
name = "Domain Generation Algorithms"
reference = "https://attack.mitre.org/techniques/T1568/002/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1567.001"
name = "Exfiltration to Code Repository"
reference = "https://attack.mitre.org/techniques/T1567/001/"

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

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

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

[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 Remote Management (WinRM) remote shell on a target host. This could be an
indication of lateral movement.
"""
false_positives = [
    """
    WinRM 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 WinRM Remote Shell"
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 WinRM Remote Shell

Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. While beneficial for legitimate administrative tasks, adversaries can exploit WinRM for lateral movement by executing commands remotely. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by WinRM, flagging potential unauthorized remote executions.

### Possible investigation steps

- Review the network traffic logs to confirm the presence of incoming connections on ports 5985 or 5986, which are used by WinRM, and verify if these connections are expected or authorized.
- Identify the source IP address of the incoming connection and determine if it belongs to a known and trusted network or device. Investigate any unfamiliar or suspicious IP addresses.
- Examine the process tree for the process initiated by winrshost.exe to identify any unusual or unauthorized processes that were started as a result of the remote execution.
- Check the user account associated with the WinRM session to ensure it is legitimate and has not been compromised. Look for any signs of unauthorized access or privilege escalation.
- Correlate the event with other security logs, such as authentication logs, to identify any related suspicious activities or patterns that might indicate lateral movement or a broader attack campaign.
- Investigate the timeline of events to determine if there are any other related alerts or activities occurring around the same time that could provide additional context or evidence of malicious intent.

### False positive analysis

- Legitimate administrative tasks using WinRM can trigger alerts. Regularly review and whitelist known administrative IP addresses or users to reduce false positives.
- Automated scripts or management tools that use WinRM for routine tasks may be flagged. Identify these scripts and create exceptions for their specific process names or execution paths.
- Monitoring tools that check system health via WinRM might be misidentified as threats. Exclude these tools by specifying their source IPs or process names in the detection rule.
- Scheduled tasks that utilize WinRM for updates or maintenance can cause alerts. Document these tasks and adjust the rule to ignore their specific execution patterns.
- Internal security scans or compliance checks using WinRM should be accounted for. Coordinate with security teams to recognize these activities and exclude them from triggering alerts.

### Response and remediation

- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration.
- Terminate any suspicious processes associated with WinRM, particularly those not originating from legitimate administrative tools or known good sources.
- Review and revoke any unauthorized access credentials or accounts that may have been used to initiate the WinRM session.
- Conduct a thorough examination of the affected host for any additional signs of compromise, such as unauthorized software installations or changes to system configurations.
- Restore the affected system from a known good backup if any malicious activity or unauthorized changes are confirmed.
- Implement network segmentation to limit the ability of threats to move laterally across the network, focusing on restricting access to critical systems.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
risk_score = 47
rule_id = "1cd01db9-be24-4bef-8e7c-e923f0ff78ab"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
    "Data Source: SentinelOne",
]
type = "eql"

query = '''
sequence by host.id with maxspan=30s
   [network where host.os.type == "windows" and process.pid == 4 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 : "winrshost.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]
description = """
Detects when a hidden file gets mounted. This is suspicious behavior, and has been observed in MacOS and Linux malware
samples.
"""
id = "5b544dbb-2c66-42cd-a4ee-8d1e5afe9903"
license = "Elastic License v2"
name = "Linux Hidden File Mounted"
os_list = ["linux"]
version = "1.0.6"

query = '''
process where event.type == "start" and event.action == "exec" and (
  process.name in ("mount", "pmount", "lsblk") or 
  (process.name == "udisksctl" and process.args == "mount") 
) and process.args like ("/media/.*", "/mnt/.*", "/tmp/mnt/.*") and 
not process.parent.command_line == "/usr/sbin/automount --pid-file /var/run/autofs.pid"
'''

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

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



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


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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2020/03/25"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
An instance of MSBuild, the Microsoft Build Engine, was started by a script or the Windows command interpreter. This
behavior is unusual and is sometimes used by malicious payloads.
"""
false_positives = ["The Build Engine is commonly used by Windows developers but use by non-engineers is unusual."]
from = "now-9m"
index = ["winlogbeat-*", "logs-endpoint.events.process-*", "logs-windows.sysmon_operational-*"]
language = "kuery"
license = "Elastic License v2"
name = "Microsoft Build Engine Started by a Script Process"
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 Microsoft Build Engine Started by a Script Process

The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit its ability to execute inline tasks, using it as a proxy for executing malicious code. The detection rule identifies unusual MSBuild invocations initiated by script interpreters, signaling potential misuse for stealthy execution or defense evasion tactics.

### Possible investigation steps

- Review the process tree to understand the parent-child relationship, focusing on the parent process names such as cmd.exe, powershell.exe, pwsh.exe, powershell_ise.exe, cscript.exe, wscript.exe, or mshta.exe, which initiated the msbuild.exe process.
- Examine the command line arguments used to start msbuild.exe to identify any suspicious or unusual inline tasks or scripts that may indicate malicious activity.
- Check the user account associated with the msbuild.exe process to determine if it aligns with expected usage patterns or if it might be compromised.
- Investigate the timing and frequency of the msbuild.exe execution to see if it coincides with known legitimate build activities or if it appears anomalous.
- Look for any related network activity or file modifications around the time of the msbuild.exe execution to identify potential data exfiltration or further malicious actions.
- Cross-reference the alert with other security events or logs to identify any correlated indicators of compromise or additional suspicious behavior.

### False positive analysis

- Development environments where scripts are used to automate builds may trigger this rule. To manage this, identify and whitelist specific script processes or directories commonly used by developers.
- Automated testing frameworks that utilize scripts to initiate builds can cause false positives. Exclude these processes by creating exceptions for known testing tools and their associated scripts.
- Continuous integration/continuous deployment (CI/CD) pipelines often use scripts to invoke MSBuild. Consider excluding the parent processes associated with these pipelines from the rule.
- Administrative scripts that perform legitimate system maintenance tasks might start MSBuild. Review and exclude these scripts if they are verified as non-threatening.
- Custom scripts developed in-house for specific business functions may also trigger alerts. Conduct a review of these scripts and exclude them if they are deemed safe and necessary for operations.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate the suspicious MSBuild process and any associated script interpreter processes (e.g., cmd.exe, powershell.exe) to stop the execution of potentially malicious code.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or artifacts.
- Review and analyze the parent script or command that initiated the MSBuild process to understand the scope and intent of the attack, and identify any additional compromised systems or accounts.
- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for MSBuild and script interpreter activities across the network to detect and respond to similar threats in the future."""
risk_score = 47
rule_id = "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae2"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:windows and event.category:process and event.type:start and (
  process.name.caseless:"msbuild.exe" or process.pe.original_file_name:"MSBuild.exe") and
  process.parent.name:("cmd.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "cscript.exe" or
    "wscript.exe" or "mshta.exe") and 
 not process.executable : (
  "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\MSBuild\\Current\\Bin\\MSBuild.exe" or 
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\MSBuild\\Current\\Bin\\MSBuild.exe" or 
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\MSBuild\\Current\\Bin\\MSBuild.exe" or 
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\MSBuild\\Current\\Bin\\amd64\\MSBuild.exe" or 
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\MSBuild\\Current\\Bin\\amd64\\MSBuild.exe" or 
  "C:\\Program Files (x86)\\MSBuild\\14.0\\Bin\\amd64\\MSBuild.exe" or 
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\MSBuild\\Current\\Bin\\MSBuild.exe" or 
  "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\MSBuild\\Current\\Bin\\MSBuild.exe" or 
  "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\MSBuild\\Current\\Bin\\amd64\\MSBuild.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:

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


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

[[rule.threat.technique]]
id = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"

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

[[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.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.new_terms]
field = "new_terms_fields"
value = ["host.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2021/03/08"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/05/03"

[rule]
author = ["Elastic"]
description = """
Identifies suspicious processes being spawned by the Microsoft Exchange Server worker process (w3wp). This activity may
indicate exploitation activity or access to an existing web shell backdoor.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process-*",
    "winlogbeat-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Microsoft Exchange Worker Spawning Suspicious Processes"
references = [
    "https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers",
    "https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities",
    "https://discuss.elastic.co/t/detection-and-response-for-hafnium-activity/266289",
]
risk_score = 73
rule_id = "f81ee52c-297e-46d9-9205-07e66931df26"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  process.parent.name : "w3wp.exe" and process.parent.args : "MSExchange*AppPool" and
  (
    (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") or
    ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE"))
  )
'''

note = """## Triage and analysis

### Investigating Microsoft Exchange Worker Spawning Suspicious Processes

#### Possible investigation steps

- What Exchange worker-child path did the alert capture?
  - Focus: child `process.executable` and `process.command_line`; worker `process.parent.executable`, `process.parent.args`, and `process.parent.command_line`; exact MSExchange app pool.
  - Implication: escalate when an Exchange app pool launches shell/PowerShell for execution, download, discovery, or staging; lower suspicion only when parent arguments and child command match one narrow maintenance task with no webshell or RCE indicators.
- What intent does the shell or PowerShell command show?
  - Focus: `process.command_line`; encoded or inline execution, download cradles, archive/export, discovery, Set-OabVirtualDirectory, mailbox access, or FrontEnd\\HttpProxy, aspnet_client, web.config, and applicationHost.config paths.
  - Implication: escalate on payload retrieval, web-root staging, credential access, account changes, mailbox export, cleanup, or lateral movement; lower suspicion only for one bounded recognized Exchange maintenance or validation action.
- Does token and session context support human administration or service-context abuse?
  - Why: w3wp.exe children often inherit app-pool or service identity, so user fields alone do not prove human administration.
  - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`.
  - Implication: escalate when a service, app-pool, or unexpected logon context launches interactive shell behavior or remote administration; lower suspicion only when identity, session type, and command scope match the same recognized workflow.
- Is the child binary expected or masqueraded?
  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
  - Implication: escalate when the child is renamed, user-writable, unsigned or untrusted, hash-new for the server, or mismatched to PE original name; a trusted Microsoft shell lowers identity concern but does not clear the unusual chain.
- If process evidence is suspicious or unresolved, did file evidence show webshells or artifacts?
  - Focus: with endpoint file telemetry, scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; inspect `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ASPX, scripts, binaries, DLLs, archives, or output under Exchange/IIS paths. $investigate_1
  - Hint: check whether a written `file.path` later appears as `process.executable`; missing file telemetry limits proof but is not benign.
  - Implication: escalate when the child writes new or modified ASPX, scripts, binaries, DLLs, archives, or output under Exchange FrontEnd\\HttpProxy, IIS aspnet_client, temp, or web-root paths; lower suspicion only when file activity stays inside the exact maintenance path with no web-content or payload staging.
- If process evidence is suspicious or unresolved, did network evidence show retrieval or callback?
  - Focus: with endpoint network telemetry, scope DNS and connections by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; read DNS (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`, `destination.port`). $investigate_2
  - Hint: map `dns.resolved_ip` to `destination.ip` before deciding whether the same process reached it. Missing network telemetry is unresolved, not benign.
  - Implication: escalate when the child downloads tools, reaches public staging or callback infrastructure, or connects to systems unrelated to the Exchange task; lower suspicion only when destinations are internal, proxy, or vendor services fitting the same bounded workflow.
- Does same-worker or same-host scope show broader Exchange compromise?
  - Focus: surrounding same-worker process starts and related alerts on `host.id` or `user.id`, especially `process.parent.executable`, `process.parent.args`, `process.command_line`, and `process.hash.sha256` for repeated w3wp.exe descendants, credential dumping, account changes, archiving, cleanup, or side-loading chains.
    - $investigate_3
    - $investigate_0
    - $investigate_4
  - Implication: escalate scope when the host shows credential dumping, account changes, archive creation, cleanup, lateral movement, or repeated Exchange worker children; keep local only when surrounding process evidence and related alerts stay confined to the same recognized maintenance window.
- Escalate on unexplained server-side execution, suspicious command intent, payload staging, suspicious destinations, or broader host compromise; close only when all available evidence aligns with one recognized Exchange workflow on this host; preserve artifacts and escalate when evidence is mixed or visibility incomplete.

### False positive analysis

- Recognized Exchange maintenance or controlled validation is the bounded benign path. Confirm only when `process.parent.args`, child `process.command_line`, `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `user.id`, and `host.id` align with one task, and any `file.path`, `dns.question.name`, or `destination.ip` evidence shows no payload staging or external callback. Use change records as corroboration; otherwise require recurring prior alerts with the same parent arguments, command pattern, child identity, user, host, and no contradictory artifacts or destinations.
- Build exceptions only from the minimum confirmed pattern: `process.parent.args`, child `process.executable` or `process.hash.sha256`, `process.code_signature.subject_name`, stable `process.command_line` fragment, `user.id`, `host.id`, and any bounded artifact or destination pattern distinguishing the benign task. Avoid exceptions on "w3wp.exe", `process.name`, or `host.id` alone.

### Response and remediation

- If confirmed benign, reverse temporary containment and document the exact evidence that validated the workflow: `process.parent.args`, child `process.executable`, `process.command_line`, `user.id`, `host.id`, and any bounded artifact or destination pattern. Create an exception only after the same pattern is stable across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert, process tree, child `process.entity_id` or `process.pid`, `process.command_line`, parent `process.parent.entity_id`, `process.parent.args`, child hash and signer, `user.id`, `host.id`, and any staged artifacts, destinations, or IIS/Exchange log snippets before containment. Apply reversible containment first: block confirmed malicious destinations, restrict external access to the implicated Exchange service, or increase monitoring. Isolate only when active compromise evidence and server criticality justify disruption.
- If confirmed malicious, contain the Exchange server or exposed service path based on the process, artifact, destination, and same-host evidence already preserved. Record process and artifact identifiers before terminating the child, then block confirmed malicious domains, IPs, and hashes.
- Eradicate only the webshells, scripts, archives, scheduled tasks, dropped utilities, and configuration changes identified during triage. Restore modified Exchange or IIS content from known-good state, patch the Exchange server, review the virtual directories and app pools implicated by `process.parent.args`, and rotate Exchange, application, or service credentials if credential access, configuration theft, or mailbox export was involved.
- Retain the related process, file, network, IIS, and Exchange logs that supported the decision. Document any adjacent variant or telemetry gap, such as missing endpoint file/network events or unavailable IIS request logs, for the detection engineering team.
"""

setup = """## Setup

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

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

### Additional data sources

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.name",
    "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.entity_id",
    "process.parent.executable",
    "process.parent.args",
]

[transform]

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

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

[[transform.investigate]]
label = "Network events for the suspicious child process"
description = ""
providers = [
  [
    { 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.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Process events from the same Exchange worker"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", 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"

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

[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"

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

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

[[rule.threat.technique]]
id = "T1505"
name = "Server Software Component"
reference = "https://attack.mitre.org/techniques/T1505/"

[[rule.threat.technique.subtechnique]]
id = "T1505.003"
name = "Web Shell"
reference = "https://attack.mitre.org/techniques/T1505/003/"

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

[rule]
description = """
Detects attempts to load an unsigned executable from known Microsoft Office add-ins directories. Adversaries may
leverage Office Addins for persistence.
"""
id = "aaa80718-1ed9-43bd-bcf7-97f2a6c93ea8"
license = "Elastic License v2"
name = "Microsoft Office AddIn Loaded"
os_list = ["windows"]
reference = ["https://docs.microsoft.com/en-us/previous-versions/technet-magazine/ee851671(v=msdn.10)"]
version = "1.0.27"

query = '''
library where
  process.name : ("winword.exe", "excel.exe") and
  (dll.code_signature.trusted == false or dll.code_signature.exists == false) and
  not dll.code_signature.status : ("errorExpired", "errorCode_endpoint*") and dll.hash.sha256 != null and
  dll.path :
    ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*",
     "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*",
     "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*") and

  /* mainly https://github.com/Excel-DNA/ExcelDna */
  not dll.hash.sha256 :
               ("77fbc709353e2fc68091ef4eaf92d9926b1f36201e1cb5c59583867c6b8979e2",
                "20a33e2b3bf3da40a44b2001b60fbdac5e047154a169d77170b2ef7b0f5ae75a",
                "cb9b45da021609e16290e8abed62a6bc3c5ac588316bab40b091f64ea137e7df",
                "cb9b45da021609e16290e8abed62a6bc3c5ac588316bab40b091f64ea137e7df",
                "20a33e2b3bf3da40a44b2001b60fbdac5e047154a169d77170b2ef7b0f5ae75a",
                "b89a91c4cacda40c8ecafc9d9accd42d75a9158457273f12b1dbd0d1962becf3",
                "a5b7f6173251349613213e8ee0517e7677c03367b213d70d62f0f251283c3253",
                "582098e0e01d7beddd8f63333569aac96e06bfcef2d1ce61a9fddd99f651caf1",
                "b0a8ca7e555f53536e4f570ba3c8bf34274745bb63e70539fb080a1010dba053",
                "6e5fab5ccee725eb32144e36e1f0486f892ed99ad85e8d6a0354ced2eeed3759",
                "582098e0e01d7beddd8f63333569aac96e06bfcef2d1ce61a9fddd99f651caf1",
                "b0a8ca7e555f53536e4f570ba3c8bf34274745bb63e70539fb080a1010dba053",
                "6e5fab5ccee725eb32144e36e1f0486f892ed99ad85e8d6a0354ced2eeed3759",
                "e6ae5ef0a7b1d1a0276be13de9df13c2effbb8c70df45379a24882188d681b51",
                "83fd2689932d14a23f17de26ddc201f5a9f69060f550992feb421396c6914b06",
                "ff0c659513d58f670e1518fd529ba77dc2b051599dd74d88392a6c0a94414ee2")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1137"
name = "Office Application Startup"
reference = "https://attack.mitre.org/techniques/T1137/"


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

[internal]
min_endpoint_version = "8.10.0"

[rule]
description = """
Identifies when a Windows script attempts to execute commands using the Windows Installer service via Component Object
Model.
"""
id = "1eae6aaf-7854-4fa7-8470-f19f87f9802a"
license = "Elastic License v2"
name = "Msiexec Execution via a Windows Script Interpreter"
os_list = ["windows"]
version = "1.0.5"

query = '''
sequence with maxspan=1m
 [process where event.action == "start" and not user.id : "S-1-5-18" and
  process.name : ("wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe", "mshta.exe", "cmstp.exe", "msxsl.exe") and
  not (process.name : "powershell.exe" and
       process.parent.executable : ("?:\\Program Files (x86)\\Microsoft Intune Management Extension\\agentexecutor.exe",
                                    "?:\\Program Files (x86)\\ScreenConnect Client*\\ScreenConnect.WindowsBackstageShell.exe",
                                    "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\dctask64.exe",
                                    "C:\\Program Files (x86)\\FastTrack Software\\Admin By Request\\AdminByRequest.exe",
                                    "C:\\Program Files\\Oracle Cloud Agent\\plugins\\unifiedmonitoring\\unifiedmonitoring.exe"))
  ] by process.entity_id
 [process where event.action == "start" and process.parent.name : "msiexec.exe" and
  not (process.name : "regsvr32.exe" and user.id : "S-1-5-18") and
  not (process.name : "cmd.exe" and
       process.command_line : "cmd /C if exist \"%appdata%/Messenger\" rmdir \"%appdata%/Messenger\" /s /q & if exist \"%appdata%/chatgenie\" rmdir \"%appdata%/chatgenie\" /s /q") and
  not (process.executable : "?:\\Windows\\Sys*\\msiexec.exe" and
       process.args : "/Z" and process.args : ("C:\\Program Files (x86)\\*.dll", "C:\\Program Files\\*.dll"))
  ] by process.Ext.effective_parent.entity_id
'''

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

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

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

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

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



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



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

[internal]
min_endpoint_version = "8.4.0"

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

[rule]
author = ["Elastic"]
description = """
Monitors for the execution of different processes that might be used by attackers for malicious intent. An alert from
this rule should be investigated further, as hack tools are commonly used by blue teamers and system administrators as
well.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Linux Hack Tool Launched"
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 Potential Linux Hack Tool Launched

Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts.

### Possible investigation steps

- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap".
- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised.
- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity.
- Examine the command line arguments used during the process execution to understand the intent and scope of the activity.
- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities.
- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives.

### False positive analysis

- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments.
- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill.
- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior.
- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts.
- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency.

### Response and remediation

- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities.
- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts.
- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed.
- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools.
- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
risk_score = 47
rule_id = "1df1152b-610a-4f48-9d7a-504f6ee5d9da"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name in~ (
  // exploitation frameworks
  "crackmapexec", "msfconsole", "msfvenom", "sliver-client", "sliver-server", "havoc",
  // network scanners (nmap left out to reduce noise)
  "zenmap", "nuclei", "netdiscover", "legion",
  // web enumeration
  "gobuster", "dirbuster", "dirb", "wfuzz", "ffuf", "whatweb", "eyewitness",
  // web vulnerability scanning
  "wpscan", "joomscan", "droopescan", "nikto",
  // exploitation tools
  "sqlmap", "commix", "yersinia",
  // cracking and brute forcing
  "john", "hashcat", "hydra", "ncrack", "cewl", "fcrackzip", "rainbowcrack",
  // host and network
  "linenum.sh", "linpeas.sh", "pspy32", "pspy32s", "pspy64", "pspy64s", "binwalk", "evil-winrm",
  "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh"
)
'''


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

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

[[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.001"
name = "Password Guessing"
reference = "https://attack.mitre.org/techniques/T1110/001/"

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

[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 = "T1046"
name = "Network Service Discovery"
reference = "https://attack.mitre.org/techniques/T1046/"

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

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

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

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

[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"

[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 = "T1595"
name = "Active Scanning"
reference = "https://attack.mitre.org/techniques/T1595/"

[[rule.threat.technique.subtechnique]]
id = "T1595.002"
name = "Vulnerability Scanning"
reference = "https://attack.mitre.org/techniques/T1595/002/"

[[rule.threat.technique.subtechnique]]
id = "T1595.003"
name = "Wordlist Scanning"
reference = "https://attack.mitre.org/techniques/T1595/003/"

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

[metadata]
creation_date = "2026/02/19"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a
time window, indicating coordinated attacks using IP rotation to evade single-source detection.
"""
false_positives = [
    "Large enterprises with many users experiencing simultaneous password issues during credential rotation events.",
    "Automated monitoring or penetration testing tools scanning from multiple IPs.",
]
from = "now-1h"
interval = "15m"
language = "esql"
license = "Elastic License v2"
name = "Potential Okta Password Spray (Multi-Source)"
note = """## Triage and analysis

### Investigating Potential Okta Password Spray (Multi-Source)

This rule identifies coordinated password spray attacks where multiple source IPs target multiple user accounts within a time window. This pattern indicates attackers using IP rotation to evade single-source detection while spraying passwords across the organization.

#### Possible investigation steps
- Review the list of targeted user accounts and check if any authentications succeeded.
- Examine the source IPs and their ASN ownership for signs of proxy, VPN, or cloud infrastructure.
- Check if Okta flagged any of the sources as known threats or proxies.
- Analyze the attempts-per-user ratio to confirm spray behavior versus brute force.
- Review the geographic distribution of source IPs for coordination patterns.
- Cross-reference with successful authentication events to identify potential compromises.

### False positive analysis
- Organization-wide password rotation or expiration events may cause widespread authentication failures.
- Misconfigured SSO or SAML integrations can cause batch failures from legitimate infrastructure.
- Penetration testing should be coordinated and whitelisted in advance.

### Response and remediation
- If attack is confirmed, notify affected users and enforce password resets for potentially compromised accounts.
- Block attacking IP ranges at the network perimeter.
- Enable or strengthen MFA for targeted accounts.
- Review Okta sign-on policies to add additional friction for suspicious authentication patterns.
- Consider temporary lockdowns for highly targeted accounts.
"""
references = [
    "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta",
    "https://www.okta.com/identity-101/brute-force/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 47
rule_id = "2d3c27d5-d133-4152-8102-8d051619ec4a"
setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
severity = "medium"
tags = [
    "Domain: Identity",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Data Source: Okta",
    "Data Source: Okta System Logs",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-okta.system-* METADATA _id, _version, _index
| WHERE
    data_stream.dataset == "okta.system"
    AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
    AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
    AND okta.actor.alternate_id IS NOT NULL

// Bucket into 15-minute windows and create user-source mapping for context
| EVAL
    Esql.time_bucket = DATE_TRUNC(15 minutes, @timestamp),
    Esql.user_source_info = CONCAT(
      "{\"user\":\"", okta.actor.alternate_id,
      "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"),
      "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}"
    )

// Aggregate across entire tenant per time bucket to detect distributed spray
| STATS
    Esql.unique_users = COUNT_DISTINCT(okta.actor.alternate_id),
    Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip),
    Esql.total_attempts = COUNT(*),
    Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
    Esql.unique_asns = COUNT_DISTINCT(source.as.number),
    Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name),
    Esql.first_seen = MIN(@timestamp),
    Esql.last_seen = MAX(@timestamp),
    Esql.target_users = VALUES(okta.actor.alternate_id),
    Esql.source_ip_values = VALUES(okta.client.ip),
    Esql.user_source_mapping = VALUES(Esql.user_source_info),
    Esql.event_action_values = VALUES(event.action),
    Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
    Esql.device_values = VALUES(okta.client.device),
    Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
    Esql.geo_country_values = VALUES(client.geo.country_name),
    Esql.geo_city_values = VALUES(client.geo.city_name),
    Esql.source_asn_values = VALUES(source.as.number),
    Esql.source_asn_org_values = VALUES(source.as.organization.name),
    Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
    Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
    Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
  BY Esql.time_bucket

// Calculate spray metrics
| EVAL
    Esql.attempts_per_user = Esql.total_attempts * 1.0 / Esql.unique_users,
    Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips,
    Esql.users_per_ip = Esql.unique_users * 1.0 / Esql.unique_source_ips

// Distributed spray: many IPs, many users, moderate spread across both
// Key differentiator: attacks come from multiple IPs (evading per-IP rules)
| WHERE
    Esql.unique_source_ips >= 5
    AND Esql.unique_users >= 8
    AND Esql.total_attempts >= 25
    AND Esql.attempts_per_user <= 5.0
    AND Esql.users_per_ip >= 1.0

| SORT Esql.total_attempts DESC
| KEEP Esql.*
'''


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