From a950f4738ec7b8f8def2699aec7ec2fa38f5780c Mon Sep 17 00:00:00 2001 From: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> Date: Mon, 6 Apr 2026 13:06:24 -0300 Subject: [PATCH] [Rule Tuning] Windows High-Severity Rules Revamp - 2 (#5900) * [Rule Tuning] Windows High-Severity Rules Revamp - 2 * ++ * Compress guides * ++ * ++ --- ...ly_observed_screenconnect_host_server.toml | 154 +++++++++++++--- ...command_and_control_outlook_home_page.toml | 156 ++++++++++++---- .../command_and_control_rdp_tunnel_plink.toml | 162 +++++++++++++---- .../command_and_control_remcos_rat_iocs.toml | 141 ++++++++++++--- ..._and_control_rmm_netsupport_susp_path.toml | 171 ++++++++++++++---- 5 files changed, 618 insertions(+), 166 deletions(-) diff --git a/rules/windows/command_and_control_newly_observed_screenconnect_host_server.toml b/rules/windows/command_and_control_newly_observed_screenconnect_host_server.toml index 4c65b8bfe..ba62bfb2b 100644 --- a/rules/windows/command_and_control_newly_observed_screenconnect_host_server.toml +++ b/rules/windows/command_and_control_newly_observed_screenconnect_host_server.toml @@ -2,7 +2,7 @@ creation_date = "2026/03/09" integration = ["endpoint"] maturity = "production" -updated_date = "2026/03/09" +updated_date = "2026/03/30" [rule] author = ["Elastic"] @@ -14,30 +14,6 @@ interval = "6m" language = "esql" license = "Elastic License v2" name = "Newly Observed ScreenConnect Host Server" -note = """## Triage and analysis - -### Investigating Newly Observed ScreenConnect Host Server - -ScreenConnect (ConnectWise Control) is legitimate RMM software often abused by threat actors for command-and-control and persistence. This rule fires when a host is seen connecting to a ScreenConnect server host that was not seen before (within the rule window) and that is not the official *.screenconnect.com cloud—surfacing self-hosted or non-standard relay servers that may indicate abuse. - -### Possible investigation steps - -- Identify the host and user from the alert and confirm whether use of ScreenConnect is approved. -- Inspect the parsed ScreenConnect server host (Esql.screenconnect_server)—is it an internal host, a known vendor, or an unknown domain/IP? -- Review the process command line for the full connection parameters and any other suspicious options. -- Correlate with the companion rule "First Time Seen Remote Monitoring and Management Tool" for the same host. -- Check for other alerts on the host or user in the past 48 hours. - -### False positive analysis - -- Legitimate use of self-hosted ScreenConnect/ConnectWise Control by IT or MSP will trigger; allowlist known relay servers by host or exception if appropriate. -- New deployments of on-prem ScreenConnect relays will appear as newly observed; validate with change management. - -### Response and remediation - -- If unauthorized RMM use or an unknown relay is confirmed: isolate the host, remove or block the client, and investigate how the software was installed and who operates the server. -- Enforce policy that only approved RMM tools and approved relay servers may be used. -""" references = [ "https://attack.mitre.org/techniques/T1219/002/", "https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a", @@ -57,7 +33,7 @@ timestamp_override = "event.ingested" type = "esql" query = ''' -from logs-endpoint.events.process-* metadata _id, _version, _index +from logs-endpoint.events.process-* | where event.category == "process" and event.type == "start" and (process.name == "ScreenConnect.ClientService.exe" or process.code_signature.subject_name == "ConnectWise, LLC") | grok process.command_line """e=Access&y=Guest&h=(?[^&]+)&p""" | where Esql.screenconnect_server is not null and not Esql.screenconnect_server like "*.screenconnect.com" @@ -66,15 +42,135 @@ from logs-endpoint.events.process-* metadata _id, _version, _index Esql.user_name_values = values(user.name), Esql.command_line_values = values(process.command_line), Esql.host_id_values = values(host.id), - Esql.host_name_values = values(host.name) by Esql.screenconnect_server + Esql.host_name_values = values(host.name), + Esql.process_entity_id_values = values(process.entity_id) by Esql.screenconnect_server | eval Esql.recent = date_diff("minute", Esql.first_time_seen, now()) | where Esql.recent <= 6 and Esql.count_distinct_host_id == 1 | eval host.id = mv_first(Esql.host_id_values), host.name = mv_first(Esql.host_name_values), - process.command_line = mv_first(Esql.command_line_values) -| keep host.id, host.name, process.command_line, Esql.screenconnect_server + process.command_line = mv_first(Esql.command_line_values), + process.entity_id = mv_first(Esql.process_entity_id_values) +| keep host.id, host.name, process.command_line, process.entity_id, Esql.screenconnect_server, Esql.user_name_values, Esql.first_time_seen ''' +note = """## Triage and analysis + +### Investigating Newly Observed ScreenConnect Host Server + +#### Possible investigation steps + +- What do the alert-preserved fields tell you about this new ScreenConnect relay? + - Focus: `Esql.screenconnect_server`, `Esql.user_name_values`, `Esql.first_time_seen`, `host.id`, `host.name`, and `process.command_line`; note `Esql.*` fields are alert-local, not source-event records. + - Implication: supports concern when the relay is an IP literal or unknown domain; weaker when it points to a recognized internal relay or managed service provider host. + +- Does the ScreenConnect client binary and install path match recognized software on this host? + - Focus: recover from source events via `process.entity_id`: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0 + - Implication: suspicious when unsigned, portable, user-writable, or mismatched to its original file name; consistent only when signer and path match the expected ScreenConnect installation. + +- Does the parent and ancestry explain why this host initiated a new relay connection now? + - Focus: from the recovered source event: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`. + - Implication: harder to justify when a script host, Office application, installer, or unexpected interactive session starts the client; easier to explain when the lineage resolves to a recognized service deployment or management tooling chain. + +- Do network events show the host contacting infrastructure consistent with the parsed relay? + - Why: `Esql.screenconnect_server` is an alert-level field, so source DNS and connection events are needed to confirm what the host actually contacted. + - Focus: DNS "lookup_result" events for `Esql.screenconnect_server` and connection events scoped to `process.entity_id` and `host.id`, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.as.organization.name`. $investigate_1 + - Implication: supports concern when the process reaches public infrastructure with unknown ownership, or when multiple destinations cluster around the same relay; less concerning when the infrastructure matches the relay and belongs to a known hosting provider. Missing network telemetry is unresolved, not benign. + +- Does the host context fit managed service provider or internal ScreenConnect use? + - Focus: `host.id` and `Esql.user_name_values` pairing, and whether the same `Esql.screenconnect_server`, signer, and parent workflow recur across a known admin host group. + - Implication: more concerning if ScreenConnect appears on end-user or sensitive hosts not typically managed remotely, or if the user and host evidence do not fit the expected workflow; more explainable when the same managed host group, operator identity, and deployment pattern recur together. + +- Have other hosts in the environment resolved the same ScreenConnect relay domain? + - Focus: DNS events across all hosts where `dns.question.name` matches the relay from `Esql.screenconnect_server` over the last 30 days. $investigate_2 + - Implication: multiple unrelated hosts resolving the same relay suggests a campaign or broad rollout; a single host stays locally bounded. + +- Does this host show related alerts or adjacent remote-access tooling that suggest broader compromise? + - Focus: related alerts for the same `host.id` in the last 48 hours, plus adjacent remote-access, persistence, credential-access, or delivery activity, especially renamed or portable ConnectWise or ScreenConnect binaries tied to the same relay. $investigate_3 + - Implication: suggests broader host compromise when the asset also shows suspicious precursor delivery, persistence, credential theft, or additional remote-access tooling; stays locally bounded when the surrounding alert history is limited to expected admin activity or unrelated benign activity. + +- Escalate when the relay, client identity, launch lineage, contacted infrastructure, or host spread point to unauthorized remote access; close only when all evidence aligns with a recognized ScreenConnect workflow; if mixed or incomplete, preserve and escalate. + +### False positive analysis + +- Legitimate self-hosted ScreenConnect or managed service provider ConnectWise Control can trigger this rule. Confirm when the same `Esql.screenconnect_server`, recovered `process.executable`, signer, parent workflow, and DNS evidence all align with one recognized operator. If change records are unavailable, require the same client identity and admin host group to show prior new-relay alerts from this rule. +- Before creating an exception, confirm the relay is authorized through organizational records, then build the exception on the relay domain in `process.command_line`. Avoid exceptions on `host.name` or `host.id` alone, since the rule fires per host and those would suppress only one endpoint. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and document the authorized relay, client signer and path, and source-event lineage. Build the exception on the relay domain in `process.command_line` once authorization is confirmed through organizational records. +- If suspicious but unconfirmed, preserve the alert's `process.entity_id`, `process.command_line`, `Esql.screenconnect_server`, and any linked `dns.question.name` or `destination.ip` evidence. Apply reversible containment such as temporary DNS or egress blocking for the relay host. Escalate to host isolation only when the relay, lineage, or network evidence shows meaningful risk and the host's support role can tolerate it. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, document the alert's `process.entity_id`, recovered `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `Esql.screenconnect_server`, and any confirmed `dns.question.name` or `destination.ip` values before initiating response actions. Use available endpoint response integrations to isolate the host when the relay, client identity, lineage, or contacted infrastructure indicates unauthorized remote access. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. +- Review how the software was installed, who operated the relay, and whether additional remote-access tooling or credential exposure is present on the host. Then block the malicious relay host and any confirmed relay IPs, and remove or disable the unauthorized ScreenConnect client, service, persistence mechanism, or installer artifacts identified during the investigation. +- After containment, enforce approved-relay policy for remote-access tools and retain Elastic Defend process and network telemetry needed to validate future relay changes. +""" + +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 +""" + +[rule.investigation_fields] +field_names = [ + "host.id", + "host.name", + "process.command_line", + "Esql.screenconnect_server", + "Esql.user_name_values", + "Esql.first_time_seen", + "process.entity_id", +] + +[[transform.investigate]] +label = "Process events for the ScreenConnect client" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Network events for the ScreenConnect client" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Hosts resolving the same ScreenConnect relay domain" +description = "" +providers = [ + [ + { excluded = false, field = "dns.question.name", queryType = "phrase", value = "{{Esql.screenconnect_server}}", valueType = "string" } + ] +] +relativeFrom = "now-30d/d" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/windows/command_and_control_outlook_home_page.toml b/rules/windows/command_and_control_outlook_home_page.toml index c4997d4fb..aa851b498 100644 --- a/rules/windows/command_and_control_outlook_home_page.toml +++ b/rules/windows/command_and_control_outlook_home_page.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/01" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/03/24" +updated_date = "2026/03/30" [rule] author = ["Elastic"] @@ -23,40 +23,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Outlook Home Page Registry Modification" -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 Outlook Home Page Registry Modification - -The Outlook Home Page feature allows users to set a webpage as the default view for folders, leveraging registry keys to store URL configurations. Adversaries exploit this by modifying these keys to redirect to malicious sites, enabling command and control or persistence. The detection rule identifies suspicious registry changes, focusing on URL entries within specific paths, flagging potential misuse for further investigation. - -### Possible investigation steps - -- Review the registry path and value to confirm the presence of a suspicious URL entry in the specified registry paths, such as "HKCU\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL". -- Investigate the URL found in the registry data strings to determine if it is known to be malicious or associated with suspicious activity. -- Check the modification history of the registry key to identify when the change occurred and which user or process made the modification. -- Correlate the registry modification event with other security events on the host, such as network connections or process executions, to identify potential malicious activity. -- Assess the affected system for signs of compromise, including unusual network traffic or unauthorized access attempts, to determine the scope of the incident. -- Consult threat intelligence sources to see if the URL or related indicators are associated with known threat actors or campaigns. - -### False positive analysis - -- Legitimate software updates or installations may modify the registry keys associated with Outlook's Home Page feature. Users can create exceptions for known software update processes to prevent unnecessary alerts. -- Custom scripts or administrative tools used by IT departments to configure Outlook settings across multiple machines might trigger this rule. Identifying and excluding these trusted scripts or tools can reduce false positives. -- Some third-party Outlook add-ins or plugins may alter the registry keys for legitimate purposes. Users should verify the legitimacy of these add-ins and whitelist them if they are deemed safe. -- Automated backup or recovery solutions that restore Outlook settings might cause registry changes. Users can exclude these processes if they are part of a regular and secure backup routine. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further communication with potentially malicious sites. -- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the modified registry keys. -- Restore the modified registry keys to their default values to remove the malicious URL configuration. -- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. -- Review and analyze network logs to identify any outbound connections to suspicious domains or IP addresses, and block these at the firewall. -- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems are affected. -- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and network activity.""" references = [ "https://cloud.google.com/blog/topics/threat-intelligence/breaking-the-rules-tough-outlook-for-home-page-attacks/", "https://github.com/trustedsec/specula", @@ -86,12 +52,130 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi registry.path : ( "*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\*", "*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Today\\*" - ) and registry.data.strings : ("*://*", "*:\\*") + ) and registry.data.strings : ("*://*", "*:\\*", "\\\\*\\*") ''' +note = """## Triage and analysis + +### Investigating Outlook Home Page Registry Modification + +#### Possible investigation steps + +- What does the written registry value tell you about the configured Outlook content target? + - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`, plus which Outlook folder or Today page the key controls. + - Hint: check for a deletion on the same `registry.path` after the alert time -- if removed, urgency shifts to post-exploitation cleanup or transient testing. If a loopback or localhost URL is present, check for COM object registrations (CLSID entries) serving content on that port. + - Implication: a loopback or localhost URL with a non-standard port is a strong indicator of Specula-style COM server abuse -- do not treat it as benign internal traffic. External URLs, local HTML files, and UNC paths also support concern. The investigation path is narrower only when the target uses a non-loopback internal hostname or a path consistent with enterprise branding. + +- Which process wrote the setting, and does the writer context fit expected Outlook administration? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `user.id`. + - Hint: if the direct writer is a broker or service process, check `Effective_process.executable` for the true initiator. If signer fields are absent on the registry event, recover the writer from surrounding process telemetry. + - Implication: the writer context is harder to justify when a script host, LOLBin, unsigned, or user-writable binary writes the key, or when the user context does not match known Outlook administration tooling; it is more explainable when the writer is a signed deployment or profile-management tool with a recognized signer. + +- What does the target URL or path resolve to, and does it fit a known abuse pattern? + - Focus: the written target in `registry.data.strings`; for URL targets, review same-host DNS "lookup_result" and connection events with `dns.question.name`, `dns.resolved_ip`, and `destination.ip`; for path targets, pivot to `file.path` on the same `host.id`. + - Hint: if the target is a UNC path, confirm whether the same host reached the backing server in surrounding connection activity and whether a local `file.path` copy was staged before Outlook could render it. + - Implication: external URLs to rare domains or public IPs, user-writable HTML files, and unrecognized network shares support concern. The target is less concerning when it resolves to a recognized enterprise portal or branding content path. Missing corroborating network or file telemetry is unresolved, not benign. + +- Do file events or Outlook process events show the target being staged or activated? + - Focus: same-host file activity tied to the writer or target path (`file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`), and Outlook or Office process events (`process.executable`, `process.parent.executable`) that access the configured target. + - Hint: for URL targets, correlate Outlook activity to the same resolved IPs or domains; for local or UNC paths, look for the same path being opened after the write. + - Implication: concern rises when the writer stages HTML or script content in user-writable locations and Outlook reaches the same target, or when the modified profile triggers suspicious child or network activity. Absence of staging or activation does not clear the registry write but reduces immediate execution risk. + +- If the local evidence stays suspicious, how did the account authenticate to this host before the registry write? + - Why: writing the Outlook Home Page key requires HKCU hive access, so the session origin can reveal compromised credentials, lateral movement, or unexpected remote access. + - Focus: if Windows Security logs are ingested, query authentication events for `user.id` and `host.id` around the alert time, checking `winlog.logon.type`, `source.ip`, and `winlog.event_data.AuthenticationPackageName`. If authentication data is unavailable, fall back to `process.Ext.session_info.logon_type` from the writer's process event. + - Implication: supports concern when the session originated from an unexpected source IP, used an unusual logon type or authentication package, or cannot be tied to the user's normal access pattern for this host. + +- If the local evidence stays suspicious, does this host show related alerts or adjacent Outlook Home Page variants? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to identify precursor delivery, suspicious Office execution, network command-and-control, or additional persistence activity on the same asset or user. + - $investigate_0 + - $investigate_1 + - Implication: broader compromise when the asset also shows delivery, suspicious Office execution, or follow-on persistence alerts; stays locally bounded when surrounding host alerts are limited to routine administration or unrelated benign activity. + +- Escalate when the registry change, writer context, target resolution, execution evidence, and alert scope align on unauthorized Outlook customization or persistence; close only when all evidence fits a recognized Outlook customization or profile-management workflow; if mixed or incomplete, preserve and escalate. + +### False positive analysis + +- Enterprise branding, profile migration, or configuration-management tooling can legitimately write these keys. Confirm when the `registry.path` family, `registry.data.strings` target, and writer identity all match the same customization or deployment workflow, with no staged external content or divergent infrastructure. +- Before creating an exception, build on the specific `registry.data.strings` value, `process.code_signature.subject_name` or `Effective_process.executable`, and the specific `registry.path` family. Avoid exceptions on `registry.value` alone, `user.name` alone, or the entire Outlook registry subtree. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and document the confirmed `registry.path` family, `registry.data.strings` target, and writer identity that proved the Outlook customization workflow. Create an exception using the same `registry.data.strings` value, writer signer, and `registry.path` family. +- If suspicious but unconfirmed, preserve the modified `registry.path`, written value data, recovered `process.entity_id`, writer identity, any staged `file.path` content, and any related destination or alert context. Apply reversible containment first, such as blocking the page target or limiting Outlook use on the affected host, and avoid destructive cleanup until scope is clearer. +- If confirmed malicious, document the recovered `process.entity_id`, `process.command_line`, `process.code_signature.subject_name`, `registry.data.strings` target, and the modified `registry.path` values before initiating response actions. Use available endpoint response integrations to contain the affected host or account when the writer, target, staging, or activation evidence indicates unauthorized Outlook Home Page abuse. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. +- Restore the affected Outlook Webview or Today values to a known-good state, remove any malicious local HTML or script content identified during the investigation, and block confirmed malicious domains, IPs, or network shares referenced by the page target. +- If the target points to external infrastructure or a shared path, review proxy, DNS, firewall, and related-alert data for additional hosts or users that reached the same content, then scope any follow-on delivery or persistence activity found on those assets. +- After containment, review whether Outlook Home Page functionality is still needed in the environment and restrict who can manage those settings. +""" + +setup = """## Setup + +This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + +### Additional data sources + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- [CrowdStrike](https://ela.st/crowdstrike-integration) +- [Microsoft Defender XDR](https://ela.st/m365-defender) +- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel) +- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.id", + "host.name", + "user.id", + "user.name", + "registry.path", + "registry.value", + "registry.data.type", + "registry.data.strings", + "process.executable", + "process.entity_id", + "process.code_signature.subject_name", + "Effective_process.executable", +] + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1071" +name = "Application Layer Protocol" +reference = "https://attack.mitre.org/techniques/T1071/" +[[rule.threat.technique.subtechnique]] +id = "T1071.001" +name = "Web Protocols" +reference = "https://attack.mitre.org/techniques/T1071/001/" [rule.threat.tactic] id = "TA0011" diff --git a/rules/windows/command_and_control_rdp_tunnel_plink.toml b/rules/windows/command_and_control_rdp_tunnel_plink.toml index b3e6cdf40..ea76d1d25 100644 --- a/rules/windows/command_and_control_rdp_tunnel_plink.toml +++ b/rules/windows/command_and_control_rdp_tunnel_plink.toml @@ -2,13 +2,13 @@ creation_date = "2020/10/14" integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "system", "crowdstrike"] maturity = "production" -updated_date = "2026/03/24" +updated_date = "2026/03/30" [rule] author = ["Elastic"] description = """ -Identifies potential use of an SSH utility to establish RDP over a reverse SSH Tunnel. This can be used by attackers to -enable routing of network packets that would otherwise not reach their intended destination. +Identifies potential use of an SSH utility to establish RDP over an SSH Tunnel. This can be used by attackers to enable +routing of network packets that would otherwise not reach their intended destination. """ from = "now-9m" index = [ @@ -25,40 +25,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Potential Remote Desktop Tunneling Detected" -note = """## Triage and analysis - -### Investigating Potential Remote Desktop Tunneling Detected - -Protocol Tunneling is a mechanism that involves explicitly encapsulating a protocol within another for various use cases, ranging from providing an outer layer of encryption (similar to a VPN) to enabling traffic that network appliances would filter to reach their destination. - -Attackers may tunnel Remote Desktop Protocol (RDP) traffic through other protocols like Secure Shell (SSH) to bypass network restrictions that block incoming RDP connections but may be more permissive to other protocols. - -This rule looks for command lines involving the `3389` port, which RDP uses by default and options commonly associated with tools that perform tunneling. - -#### Possible investigation steps - -- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. -- Identify the user account that performed the action and whether it should perform this kind of action. -- Contact the account and system owners and confirm whether they are aware of this activity. -- Investigate other alerts associated with the user/host during the past 48 hours. -- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. -- Examine network data to determine if the host communicated with external servers using the tunnel. - -### False positive analysis - -- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. -- Investigate the command line for the execution of programs that are unrelated to tunneling, like Remote Desktop clients. - -### Response and remediation - -- Initiate the incident response process based on the outcome of the triage. -- Isolate the involved host to prevent further post-compromise behavior. -- Take the necessary actions to disable the tunneling, which can be a process kill, service deletion, registry key modification, etc. Inspect the host to learn which method was used and to determine a response for the case. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. -- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. -- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. -- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). -""" references = ["https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/"] risk_score = 73 rule_id = "76fd43b7-3480-4dd9-8ad7-8bd36bfad92f" @@ -83,11 +49,127 @@ type = "eql" query = ''' process where host.os.type == "windows" and event.type == "start" and - /* RDP port and usual SSH tunneling related switches in command line */ - process.args : "*:3389" and - process.args : ("-L", "-P", "-R", "-pw", "-ssh") + /* RDP port with SSH local or reverse port-forwarding flags */ + process.args : "*:3389" and process.args : ("-L", "-R") ''' +note = """## Triage and analysis + +### Investigating Potential Remote Desktop Tunneling Detected + +#### Possible investigation steps + +- Does the command line describe local or reverse forwarding of RDP, and who is being exposed through it? + - Why: tunnel direction changes the risk. "-L" accesses a remote RDP service through the tunnel (common admin pattern); "-R" exposes a host's RDP service outward through an attacker-controlled SSH server (the classic plink reverse-tunnel attack pattern). + - Focus: `process.command_line` and `process.executable`, checking whether the flag is "-L" (local) or "-R" (reverse), which host and port 3389 are forwarded, and whether inline credentials ("-pw") or saved sessions ("-load") are present. Many SSH clients ship unsigned, so use `process.Ext.relative_file_creation_time` to distinguish long-installed tools from recently dropped ones. + - Implication: "-R" (reverse forward) exposes an internal RDP service outward through the SSH server and is the higher-risk direction; "-L" (local forward) accesses a remote RDP service through the tunnel and is common in admin jump-host workflows. Both directions are common. Concern rises further when inline credentials are embedded, the remote endpoint is obscured behind a wrapper, or the binary is renamed, portable, or recently dropped. + +- Do surrounding artifacts show the operator seeded trust or tried to keep the tunnel reusable? + - Why: persistent tunnels are often paired with host-key trust, saved configuration, or scheduled relaunch so the tunnel can start non-interactively and survive user interruption. + - Focus: for OpenSSH clients, check `file.path` for recent changes to `~/.ssh/known_hosts`, `~/.ssh/config`, or `~/.ssh/authorized_keys`, and surrounding `process.command_line` for "schtasks.exe", "at.exe", or scripted relaunches. For PuTTY/plink, check `registry.path` and `registry.data.strings` for "SshHostKeys", "Sessions", or "-load" session reuse. + - Implication: more concerning when new host-key entries, saved configurations, or scheduled relaunch activity appear just before or after the tunnel start; more explainable when the trust cache and relaunch method already belong to an established workflow with no new persistence changes. + +- Does network telemetry show an SSH session to a destination that fits the expected workflow? + - Focus: the SSH destination is already in `process.args` from the alert. Use the network transform to confirm the connection succeeded and to check `destination.as.organization.name` for ownership context, especially for reverse forwards to external servers. $investigate_2 + - Hint: if the command line already names an internal hostname you can verify, the network transform is optional. It adds the most value when the destination is an IP literal or an unfamiliar external host. + - Implication: supports concern when the process reaches a rare external destination, an unexpected SSH port, or infrastructure with no recognizable ownership; less concerning when the destination, port, and domain pattern fit a known bastion or jump host. Missing network telemetry is unresolved, not benign. + +- If the local evidence stays suspicious, does this host or user show related alerts or repeated tunneling activity? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours, looking for delivery, persistence, credential access, or other remote-access activity around the tunnel event. + - $investigate_0 + - $investigate_1 + - Implication: supports concern when the host or user shows delivery, credential theft, or follow-on remote-access alerts; keeps the case locally bounded when alert history stays tied to one recognized admin workflow. + +- Escalate when tunnel direction, binary context, persistence artifacts, network destination, or alert scope align on unauthorized RDP exposure or SSH tunneling; close only when all evidence fits a recognized administration workflow; if mixed or incomplete, preserve and escalate. + +### False positive analysis + +- Bastion or jump-host tunneling can legitimately trigger this rule. Confirm it when `process.executable`, `process.parent.executable`, the forwarding direction and target in `process.args`, and the `user.id`/`host.id` pairing all align with one recognized admin workflow. If records are unavailable, require the same binary path, parent, and tunnel pattern to recur across prior alerts. +- Before creating an exception, build on the forwarding target in `process.command_line` (e.g., the specific host and port being tunneled) combined with `process.executable`, `user.id`, and `host.id`. Most SSH clients triggering this rule are unsigned, so `process.code_signature.subject_name` is usually empty and `process.hash.sha256` changes with updates. Avoid exceptions on port 3389, `process.name`, or SSH switches alone. + +### Response and remediation + +- If confirmed benign, reverse temporary destination blocks or process suspension and document the evidence that proved the workflow, including `process.hash.sha256`, `process.parent.executable`, `process.command_line`, `destination.ip` or `dns.question.name`, any linked `source.ip`, and the bounded `user.id` and `host.id` scope. Create an exception only if that same workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the full `process.command_line`, the alert's `process.entity_id`, `process.hash.sha256`, signer details, `destination.ip`, `dns.question.name`, linked `winlog.event_data.TargetLogonId` and `source.ip`, and any trust-seeding or relaunch artifacts (OpenSSH config files or PuTTY registry entries). Apply reversible containment first, such as blocking the SSH destination, suspending the tunneling process, or restricting the affected account. Escalate to host isolation only if the host role can tolerate it and the session or related-alert evidence suggests active abuse. +- If confirmed malicious, use endpoint response to isolate the host and terminate or suspend the tunneling process after recording `process.entity_id`, the parent chain, destination indicators, linked logon details, and any scheduled task, service, script, or registry artifacts that relaunch the tunnel. If direct endpoint response is unavailable, escalate with that artifact set to the team that can contain the host or account. +- Before deleting artifacts or resetting accounts, review other hosts and users for the same destination pattern, launcher lineage, or scheduled relaunch method so scoping is complete. Then remove the scheduled task, service, script, registry entries, and SSH client artifacts that sustained the tunnel, review any RDP-reachable systems for follow-on access, and reset credentials where the session review shows likely exposure or misuse. +- Post-incident hardening: restrict which hosts and accounts can run SSH tunneling tools, limit outbound SSH to recognized bastions, and retain process, file, and registry telemetry for SSH client activity. +""" + +setup = """## Setup + +This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + +### Additional data sources + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- [CrowdStrike](https://ela.st/crowdstrike-integration) +- [Microsoft Defender XDR](https://ela.st/m365-defender) +- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel) +- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup) +- [Windows Process Creation Logs](https://ela.st/audit-process-creation) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "user.name", + "user.id", + "user.domain", + "process.entity_id", + "process.executable", + "process.command_line", + "process.hash.sha256", + "process.pe.original_file_name", + "process.parent.executable", + "process.parent.command_line", + "process.code_signature.subject_name", + "process.code_signature.trusted", + "process.working_directory", + "process.Ext.relative_file_creation_time", +] + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Network activity for the alerting process" +description = "" +providers = [ + [ + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/command_and_control_remcos_rat_iocs.toml b/rules/windows/command_and_control_remcos_rat_iocs.toml index 9b9784c5f..828650100 100644 --- a/rules/windows/command_and_control_remcos_rat_iocs.toml +++ b/rules/windows/command_and_control_remcos_rat_iocs.toml @@ -1,13 +1,13 @@ [metadata] creation_date = "2025/08/20" -integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "system"] +integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender"] maturity = "production" -updated_date = "2026/03/24" +updated_date = "2026/03/30" [rule] author = ["Elastic"] description = """ -Identifies known execution traces of the REMCOS Remote Access Trojan. Remcos RAT is used by attackers to perform actions on infected machines remotely. +Identifies known file and registry traces of the REMCOS Remote Access Trojan, including log files, persistence values, and cleanup artifacts. Adversaries use Remcos to maintain persistent remote access to compromised hosts. """ from = "now-9m" index = [ @@ -16,35 +16,12 @@ index = [ "logs-endpoint.events.file-*", "logs-m365_defender.event-*", "logs-sentinel_one_cloud_funnel.*", - "logs-system.security*", "logs-windows.sysmon_operational-*", "winlogbeat-*", ] language = "eql" license = "Elastic License v2" name = "Potential REMCOS Trojan Execution" -note = """## Triage and analysis - -### Investigating Potential REMCOS Trojan Execution - -Remcos RAT is used by attackers to perform actions on infected machines remotely. - -### Possible investigation steps - -- Review the origin of the REMCOS file and the execution chain to identify the initial vector.. -- Examine if the process is set to persist in the affected system via scheduled task, Startup folder or Run key. -- Check the network, files and child processes activity associated with the every suspicious process in the execution chain of REMCOS. -- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activities. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. -- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity. -- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe. -- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker. -- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised. -- 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 ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.""" references = [ "https://any.run/malware-trends/remcos", "https://attack.mitre.org/software/S0332/", @@ -63,8 +40,7 @@ tags = [ "Data Source: Elastic Defend", "Data Source: Sysmon", "Data Source: SentinelOne", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: Windows Security Event Logs" + "Data Source: Microsoft Defender for Endpoint" ] timestamp_override = "event.ingested" type = "eql" @@ -72,7 +48,7 @@ type = "eql" query = ''' any where host.os.type == "windows" and ( - (event.category == "file" and event.type == "deletion" and file.path like "C:\\Users\\*\\AppData\\Local\\Temp\\TH????.tmp") or + (event.category == "file" and event.type == "deletion" and file.path like "?:\\Users\\*\\AppData\\Local\\Temp\\TH????.tmp") or (event.category == "file" and file.path : "?:\\Users\\*\\AppData\\Roaming\\remcos\\logs.dat") or @@ -88,6 +64,113 @@ any where host.os.type == "windows" and ) ''' +note = """## Triage and analysis + +### Investigating Potential REMCOS Trojan Execution + +#### Possible investigation steps + +- Which Remcos-related artifact family matched, and does it indicate install, persistence, or cleanup evidence? + - Focus: `event.category` plus the matched `file.path`, `registry.path`, `registry.value`, `registry.data.strings`, and whether the trace's user profile or hive scope matches `user.id`. + - Implication: "logs.dat" indicates active or recent keystroke/clipboard logging; a Run-key or licence registry path indicates persistence is set; a temp-file deletion indicates installer cleanup. The artifact's user profile or hive scope identifies which account is compromised. + +- Which process or user touched the Remcos trace, and does that writer fit detonation, remediation, or malware execution? + - Focus: the recovered writer identity and launch context, especially `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, and `user.id`. + - Hint: if the source event lacks process identity, recover the writer via `process.entity_id` or `process.pid` plus a tight time window on the same `host.id`. + - Implication: if the writer is an unknown binary on a non-lab host, treat it as the Remcos payload or its installer. If the writer is a known sandbox, detonation engine, or IR cleanup tool on a designated lab host, the trace is expected. + +- What payload or persistence target do adjacent file and registry events resolve to? + - Focus: file and registry events on the same `host.id`: `file.path`, `file.Ext.original.path`, `registry.path`, `registry.data.strings`, and any payload or autorun target tied to `process.entity_id`. + - Implication: a surviving Run-key target, startup copy, or staged binary under `%APPDATA%` or `%TEMP%` confirms the infection has active persistence and the payload is still present. Bounded removal of those artifacts without a surviving payload indicates cleanup is underway but verify that ALL persistence mechanisms are gone, not just the ones visible in the alert. + +- Is there active outbound C2 or proxy traffic on this host? + - Focus: host-scoped network events around the alert time, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port` for connections to rare public destinations, direct-IP egress, dynamic-DNS infrastructure, or unusual ports consistent with Remcos controller or SOCKS proxy use. + - Implication: active C2 traffic confirms the infection is live and requires immediate containment; absence of C2 traffic may indicate the payload was already removed or has not yet activated. Missing network telemetry is unresolved, not benign. + +- If the local evidence stays suspicious, does this host or user show related alerts that explain precursor compromise or follow-on access? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to identify delivery, persistence, credential, command-and-control, or lateral-movement activity. + - $investigate_0 + - $investigate_1 + - Implication: broaden when the host or user shows delivery, credential theft, or follow-on remote-access alerts after the artifact; keep the case narrower when related activity is absent or resolves to one detonation or remediation workflow. + +- Escalate when the artifact, writer, persistence status, C2 activity, or alert scope align with active Remcos execution; close only when all evidence fits a recognized detonation or remediation workflow; if mixed or incomplete, preserve and escalate. + +### False positive analysis + +- Malware-analysis or detonation hosts can legitimately create Remcos traces. Confirm it when the writer identity, `host.id`, and any network activity all stay inside a known lab or sandbox environment. If lab records are unavailable, require the same writer and `host.id` to recur across prior alerts. +- Incident-response cleanup can remove Remcos artifacts. Confirm it when the writer matches a known cleanup tool, surrounding events show bounded removal, and no new C2 or lateral-movement activity follows. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and document the confirmed writer, `host.id`, and artifact family that justified the closure. Create an exception only if that same workflow recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the matched `file.path` or `registry.path`, `registry.data.strings`, recovered `process.entity_id`, writer executable and parent context. Apply the least disruptive reversible containment that matches the findings, starting with outbound restrictions on confirmed destinations and using host isolation only when active command-and-control or lateral movement is still plausible for that asset. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, use endpoint response to isolate the host after weighing host criticality and record the `process.entity_id`, command line, parent chain, and trace paths. If direct endpoint response is unavailable, escalate with that evidence set to the team that can contain the host and implicated accounts. +- Before eradicating or reimaging, review other hosts and users for the same writer identity, artifact family, or C2 destinations so scoping is complete. For confirmed infections, consider reimaging over manual cleanup -- Remcos can establish multiple persistence mechanisms and manual eradication risks missing one. If reimaging is not feasible, eradicate all identified Remcos artifacts including Run keys, licence-related registry paths, staged binaries, "logs.dat", and linked temp artifacts, then verify no alternate persistence survives. +- Post-incident hardening: review how the payload reached the host, restrict user-writable persistence paths where practical, and retain registry and network telemetry for Remcos-related activity. +""" + +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 11 - File Create](https://ela.st/sysmon-event-11-setup) +- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup) +- [Sysmon Event ID 23 - File Delete](https://ela.st/sysmon-event-23-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.category", + "event.type", + "event.action", + "host.name", + "host.id", + "user.name", + "user.id", + "process.name", + "process.executable", + "process.entity_id", + "process.pid", + "process.code_signature.subject_name", + "file.path", + "file.name", + "registry.path", + "registry.value", + "registry.data.strings", +] + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/command_and_control_rmm_netsupport_susp_path.toml b/rules/windows/command_and_control_rmm_netsupport_susp_path.toml index 47a032b3b..5070ea249 100644 --- a/rules/windows/command_and_control_rmm_netsupport_susp_path.toml +++ b/rules/windows/command_and_control_rmm_netsupport_susp_path.toml @@ -2,13 +2,13 @@ creation_date = "2025/08/20" integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "system", "crowdstrike"] maturity = "production" -updated_date = "2025/08/20" +updated_date = "2026/03/30" [rule] author = ["Elastic"] description = """ Identifies execution of the NetSupport remote access software from non-default paths. Adversaries may abuse NetSupport -Manager to control a target victim machine. +Manager to control a victim machine. """ from = "now-9m" index = [ @@ -24,32 +24,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "NetSupport Manager Execution from an Unusual Path" -note = """## Triage and analysis - -### Investigating NetSupport Manager Execution from an Unusual Path - -NetSupport Manager, is a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. - -### Possible investigation steps - -- Review the origin of the NetSupport file and if it's related to an authorized IT Support case. -- Examine if the NetSupport process is set to persist in the affected system via scheduled task, Startup folder or Run key. -- Check the network, files and child processes activity associated with the NetSupport client32.exe process. -- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activities. - -### False positive analysis - -- Legitimate IT support activities using NetSupport by IT support accounts. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. -- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity. -- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe. -- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker. -- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised. -- 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 ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.""" references = [ "https://www.netsupportsoftware.com/", ] @@ -80,12 +54,147 @@ process where host.os.type == "windows" and event.type == "start" and process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe", - "\\Device\\HarddiskVolume?\\Users\\*.exe", - "\\Device\\HarddiskVolume?\\ProgramData\\*.exe") or + "\\Device\\HarddiskVolume*\\Users\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\*.exe") or ?process.parent.executable : ("?:\\Users\\*\\client32.exe", "?:\\ProgramData\\*\\client32.exe") ) ''' +note = """## Triage and analysis + +### Investigating NetSupport Manager Execution from an Unusual Path + +#### Possible investigation steps + +- What is the alerting process and how did NetSupport reach this host from a non-default path? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when the client is unsigned, portable, or mismatched to its original file name, or when the parent chain starts from a script host, archive utility, browser, or Office process; lower suspicion when signer, path, and parent chain resolve to a recognized deployment. Identity alone does not clear the behavior. + +- Does the client or child command line show recognized deployment behavior or covert control intent? + - Focus: `process.command_line`, `process.working_directory`, and `process.parent.command_line`, with attention to connection targets, relay parameters, and hidden or scripted launch behavior. + - Hint: if the alert fired on a child process and the parent command line is absent or truncated, recover the NetSupport client start event on the same `host.id` before judging deployment or relay intent. + - Implication: escalate when the command line reveals external control targets, stealthy launch parameters, or deployment behavior that does not fit expected support tooling; lower suspicion when the arguments match a recognized support or managed rollout workflow. + +- Do network events show expected support infrastructure or suspicious relay traffic? + - Focus: process-scoped DNS and connection events for `process.entity_id`, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port`, and `destination.as.organization.name`. $investigate_2 + - Implication: escalate when the process reaches rare public destinations or unexpected relay infrastructure; lower suspicion when destinations align with known internal support infrastructure. Missing network telemetry is unresolved, not benign. + +- Do file events show staged components, renamed NetSupport files, or persistence artifacts? + - Focus: file events scoped to `process.entity_id`: `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, `file.Ext.header_bytes`, and adjacent NetSupport files ("client32u.ini", "NSM.lic", "NSM.ini", "CKSINI.EXE"). + - Implication: escalate when the process writes portable components, renamed files, or bundled config/license files, or when artifacts later appear in persistence or execution telemetry; lower suspicion when file activity stays in a recognized installation path with no suspicious reuse. + +- Do child processes launched from NetSupport show interactive abuse beyond normal support? + - Focus: child process events from `process.entity_id`, checking `process.executable` and `process.command_line`. $investigate_3 + - Implication: escalate when NetSupport spawns shells, scripting engines, archivers, credential tools, or other hands-on-keyboard tooling; lower suspicion when child activity stays limited to expected helper processes or no secondary execution follows. + +- If the local evidence stays suspicious, does this host or user show related alerts or a recurring deployment pattern? + - Focus: related alerts for `host.id` and `user.id` in the last 48 hours, checking for delivery, persistence, remote-access, or credential activity, and whether the same client path, signer, and destination pattern recur across prior alerts. + - $investigate_0 + - $investigate_1 + - Hint: if workflow documentation is unavailable, recurrence of the same client path, signer, and destination pattern across prior alerts is the strongest telemetry-based benign signal. + - Implication: broaden when the host or user shows suspicious precursor, follow-on, or cross-host activity; lower suspicion when the same deployment pattern recurs with no contradictory alerts. + +- Escalate when binary identity, launch chain, network destinations, staged artifacts, or child-process behavior point to unauthorized NetSupport deployment or interactive abuse; close only when all evidence aligns with a recognized support deployment; if mixed or incomplete, preserve and escalate. + +### False positive analysis + +- Legitimate IT support or managed deployment can stage NetSupport in non-default paths. Confirm it when the client is signed by NetSupport Ltd, the parent is an IT deployment tool (SCCM, GPO, management agent), bundled config files (client32u.ini, NSM.lic) sit alongside the client in the same directory, and network destinations resolve to internal support infrastructure. +- Before creating an exception, build on `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, `user.id`, and `host.id`. Avoid exceptions on `process.name` alone, the user alone, or the host alone. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and document `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, the destination pattern, and the `user.id`/`host.id` pairing. Create an exception using the fields from the FP guidance above. +- If suspicious but unconfirmed, preserve the alert's `process.entity_id`, client path, signer, `process.command_line`, related `file.path` values, child-process lineage, and any linked `destination.ip`, `dns.question.name`, or `dns.resolved_ip` values. Apply reversible containment such as temporary blocking of confirmed destinations. Escalate to host isolation only when live remote control or lateral movement is still plausible and the asset can tolerate it. +- If confirmed malicious, use endpoint response to contain the host after recording the alert's `process.entity_id`, client path, signer, command line, child-process details, written artifact paths, and confirmed destinations. If direct endpoint response is unavailable, escalate with that evidence set to the team that can terminate the process, isolate the host, and block the malicious destinations and dropped artifact hashes identified during the investigation. +- Before deleting files or removing access, review the same client path family, destinations, bundled config or license files, and dropped artifact names across other hosts and users so portable staging or shared controller infrastructure does not stay localized by mistake. Then eradicate the unauthorized NetSupport client, persistence mechanism, installer artifacts, and follow-on tooling uncovered during the file and child-process review. +- Post-incident hardening: restrict remote-access tool installs to approved signed packages and approved paths, review software-allowlisting or deployment controls that allowed the portable client to run, and retain endpoint process, file, and network telemetry. +""" + +setup = """## Setup + +This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + +### Additional data sources + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- [CrowdStrike](https://ela.st/crowdstrike-integration) +- [Microsoft Defender XDR](https://ela.st/m365-defender) +- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel) +- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup) +- [Windows Process Creation Logs](https://ela.st/audit-process-creation) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "user.name", + "user.id", + "user.domain", + "process.entity_id", + "process.executable", + "process.command_line", + "process.working_directory", + "process.pe.original_file_name", + "process.parent.executable", + "process.parent.command_line", + "process.code_signature.subject_name", + "process.code_signature.trusted", +] + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Network activity for the NetSupport process" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Child processes launched by the NetSupport client" +description = "" +providers = [ + [ + { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" @@ -94,9 +203,7 @@ id = "T1219" name = "Remote Access Tools" reference = "https://attack.mitre.org/techniques/T1219/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" -