Suspicious Windows Process Cluster Spawned by a Host

A machine learning job combination has detected a set of one or more suspicious Windows processes with unusually high scores for malicious probability. 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 host 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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/10/16"
  3integration = ["problemchild", "endpoint", "windows"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6min_stack_version = "8.14.0"
  7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
  8
  9[rule]
 10anomaly_threshold = 75
 11author = ["Elastic"]
 12description = """
 13A machine learning job combination has detected a set of one or more suspicious Windows processes with unusually high
 14scores for malicious probability. These process(es) have been classified as malicious in several ways. The process(es)
 15were predicted to be malicious by the ProblemChild supervised ML model. If the anomaly contains a cluster of suspicious
 16processes, each process has the same host name, and the aggregate score of the event cluster was calculated to be
 17unusually high by an unsupervised ML model. Such a cluster often contains suspicious or malicious activity, possibly
 18involving LOLbins, that may be resistant to detection using conventional search rules.
 19"""
 20from = "now-45m"
 21interval = "15m"
 22license = "Elastic License v2"
 23machine_learning_job_id = "problem_child_high_sum_by_host"
 24name = "Suspicious Windows Process Cluster Spawned by a Host"
 25references = [
 26    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
 27    "https://docs.elastic.co/en/integrations/problemchild",
 28    "https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration",
 29]
 30risk_score = 21
 31rule_id = "bdfebe11-e169-42e3-b344-c5d2015533d3"
 32setup = """## Setup
 33
 34The 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.
 35
 36### LotL Attack Detection Setup
 37The LotL Attack Detection integration detects living-off-the-land activity in Windows process events.
 38
 39#### Prerequisite Requirements:
 40- Fleet is required for LotL Attack Detection.
 41- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 42- 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).
 43- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 44- To set up and run Winlogbeat, follow [this](https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html) guide.
 45
 46#### The following steps should be executed to install assets associated with the LotL Attack Detection integration:
 47- Go to the Kibana homepage. Under Management, click Integrations.
 48- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it.
 49- Follow the instructions under the **Installation** section.
 50- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
 51"""
 52severity = "low"
 53tags = [
 54    "Use Case: Living off the Land Attack Detection",
 55    "Rule Type: ML",
 56    "Rule Type: Machine Learning",
 57    "Tactic: Defense Evasion",
 58    "Resources: Investigation Guide",
 59]
 60type = "machine_learning"
 61note = """## Triage and analysis
 62
 63> **Disclaimer**:
 64> 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.
 65
 66### Investigating Suspicious Windows Process Cluster Spawned by a Host
 67
 68The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion.
 69
 70### Possible investigation steps
 71
 72- Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts.
 73- Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading.
 74- Check the timeline of the process execution to see if it coincides with any known scheduled tasks or user activity that could explain the anomaly.
 75- Investigate the parent-child relationship of the processes to identify any unexpected or unauthorized process spawning patterns.
 76- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activity.
 77- Assess the network activity associated with the host during the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses.
 78
 79### False positive analysis
 80
 81- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may be flagged as suspicious due to their dual-use nature. Users can create exceptions for these tools when used by trusted administrators or during scheduled maintenance.
 82- Automated scripts or scheduled tasks that perform routine system checks or updates might trigger alerts. Review these processes and whitelist them if they are verified as part of regular operations.
 83- Software updates or installations that involve multiple processes spawning in a short time frame can be mistaken for malicious clusters. Ensure that these activities are documented and create exceptions for known update processes.
 84- Development or testing environments where new or experimental software is frequently executed may generate false positives. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these specific hosts.
 85- Frequent use of remote desktop or remote management tools by IT staff can appear suspicious. Implement user-based exceptions for known IT personnel to reduce unnecessary alerts.
 86
 87### Response and remediation
 88
 89- Isolate the affected host immediately to prevent further spread of potential malicious activity. Disconnect it from the network to contain the threat.
 90- Terminate the suspicious processes identified by the alert. Use task management tools or scripts to ensure all instances of the processes are stopped.
 91- Conduct a thorough review of the host's system logs and process history to identify any additional indicators of compromise or related malicious activity.
 92- Restore the host from a known good backup if available, ensuring that the backup is free from any signs of compromise.
 93- Update and patch the host's operating system and all installed software to close any vulnerabilities that may have been exploited.
 94- Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future.
 95- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional hosts are affected."""
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98[[rule.threat.technique]]
 99id = "T1036"
100name = "Masquerading"
101reference = "https://attack.mitre.org/techniques/T1036/"
102
103
104[rule.threat.tactic]
105id = "TA0005"
106name = "Defense Evasion"
107reference = "https://attack.mitre.org/tactics/TA0005/"
...
toml

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.

The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion.

  • Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts.
  • Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading.
  • Check the timeline of the process execution to see if it coincides with any known scheduled tasks or user activity that could explain the anomaly.
  • Investigate the parent-child relationship of the processes to identify any unexpected or unauthorized process spawning patterns.
  • Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activity.
  • Assess the network activity associated with the host during the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses.
  • Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may be flagged as suspicious due to their dual-use nature. Users can create exceptions for these tools when used by trusted administrators or during scheduled maintenance.
  • Automated scripts or scheduled tasks that perform routine system checks or updates might trigger alerts. Review these processes and whitelist them if they are verified as part of regular operations.
  • Software updates or installations that involve multiple processes spawning in a short time frame can be mistaken for malicious clusters. Ensure that these activities are documented and create exceptions for known update processes.
  • Development or testing environments where new or experimental software is frequently executed may generate false positives. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these specific hosts.
  • Frequent use of remote desktop or remote management tools by IT staff can appear suspicious. Implement user-based exceptions for known IT personnel to reduce unnecessary alerts.
  • Isolate the affected host immediately to prevent further spread of potential malicious activity. Disconnect it from the network to contain the threat.
  • Terminate the suspicious processes identified by the alert. Use task management tools or scripts to ensure all instances of the processes are stopped.
  • Conduct a thorough review of the host's system logs and process history to identify any additional indicators of compromise or related malicious activity.
  • Restore the host from a known good backup if available, ensuring that the backup is free from any signs of compromise.
  • Update and patch the host's operating system and all installed software to close any vulnerabilities that may have been exploited.
  • Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future.
  • Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional hosts are affected.

References

Related rules

to-top