User Detected with Suspicious Windows Process(es)

ELASTIC detection rule by Elastic · Elastic License v2

A machine learning job combination has identified a user with one or more suspicious Windows processes that exhibit unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious processes, each process has the same user name, and the aggregate score of the event cluster was calculated to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly involving LOLbins, that may be resistant to detection using conventional search rules.

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

[rule]
anomaly_threshold = 75
author = ["Elastic"]
description = """
A machine learning job combination has identified a user with one or more suspicious Windows processes that exhibit
unusually high malicious probability scores. These process(es) have been classified as malicious in several ways. The
process(es) were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of
suspicious processes, each process has the same user name, and the aggregate score of the event cluster was calculated
to be unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity,
possibly involving LOLbins, that may be resistant to detection using conventional search rules.
"""
from = "now-45m"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = "problem_child_high_sum_by_user_ea"
name = "User Detected with Suspicious Windows Process(es)"
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 User Detected with Suspicious Windows Process(es)

The detection leverages machine learning to identify clusters of Windows processes with high malicious probability, often linked to tactics like masquerading. Adversaries exploit legitimate tools (LOLBins) to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters, focusing on user-associated anomalies to uncover potential threats.

### Possible investigation steps

- Review the list of processes flagged by the alert to identify any known legitimate applications or tools that might have been misclassified.
- Investigate the user account associated with the suspicious process cluster to determine if there is any history of unusual activity or if the account has been compromised.
- Examine the parent-child relationship of the processes to understand the execution chain and identify any potential masquerading attempts or use of LOLBins.
- Check for any recent changes or updates to the system that might explain the unusual process behavior, such as software installations or updates.
- Correlate the detected processes with any known indicators of compromise (IOCs) or threat intelligence feeds to assess if they are linked to known malicious activity.
- Analyze the network activity associated with the processes to identify any suspicious outbound connections or data exfiltration attempts.

### False positive analysis

- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may trigger false positives due to their frequent use in system management. Users can create exceptions for these tools when used by trusted administrators.
- Software updates or installations often involve processes that mimic suspicious behavior. Exclude these processes by identifying and whitelisting update-related activities from known software vendors.
- Automated scripts or scheduled tasks that perform routine maintenance can be misclassified as malicious. Review and whitelist these tasks if they are part of regular system operations.
- Development environments may spawn multiple processes that resemble malicious clusters. Developers should document and exclude these processes when they are part of legitimate development activities.
- Security software or monitoring tools might generate process clusters that appear suspicious. Ensure these tools are recognized and excluded from analysis to prevent false alerts.

### Response and remediation

- Isolate the affected system from the network to prevent further spread of potential malicious activity.
- Terminate the suspicious processes identified by the alert to halt any ongoing malicious actions.
- Conduct a thorough review of the affected user's account for any unauthorized access or changes, and reset credentials if necessary.
- Analyze the use of any identified LOLBins to determine if they were used maliciously and restrict their execution through application whitelisting or policy adjustments.
- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope of the incident.
- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional systems are compromised.
- Implement enhanced monitoring and detection rules to identify similar patterns of behavior in the future, focusing on the specific tactics and techniques used in this incident."""
references = [
    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
    "https://docs.elastic.co/en/integrations/problemchild",
    "https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration",
]
risk_score = 21
rule_id = "1224da6c-0326-4b4f-8454-68cdc5ae542b"
setup = """## Setup

The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat.

### LotL Attack Detection Setup
The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.

#### Prerequisite Requirements:
- Fleet is required for LotL Attack Detection.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
- Windows process events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint) integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html).
- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
- To set up and run Winlogbeat, follow [this](https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html) guide.

#### The following steps should be executed to install assets associated with the LotL Attack Detection integration:
- Go to the Kibana homepage. Under Management, click Integrations.
- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it.
- Follow the instructions under the **Installation** section.
- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Use Case: Living off the Land Attack Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
type = "machine_learning"
[[rule.threat]]
framework = "MITRE ATT&CK"

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

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

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

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

bd2a2a8e-9fea-416e-98ef-ea7ad0e8416a

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion