From 05f3665214251c01e90e53992e94db24e7f0fffd Mon Sep 17 00:00:00 2001 From: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> Date: Sun, 3 May 2026 17:37:59 -0300 Subject: [PATCH 1/4] [Rule Tuning] Windows High-Severity Rules Revamp - 13 --- .../initial_access_url_cve_2025_33053.toml | 194 ++++++++++++++--- ..._access_webshell_screenconnect_server.toml | 195 ++++++++++++++---- ...redential_access_kerberos_correlation.toml | 188 ++++++++++++----- rules/windows/lateral_movement_dcom_hta.toml | 185 +++++++++++++---- .../windows/lateral_movement_dcom_mmc20.toml | 164 +++++++++++---- ...ateral_movement_evasion_rdp_shadowing.toml | 183 ++++++++++++---- ..._movement_execution_from_tsclient_mup.toml | 168 +++++++++++---- .../lateral_movement_rdp_sharprdp_target.toml | 90 +++++--- ...movement_unusual_dns_service_children.toml | 195 ++++++++++++++---- ...l_movement_via_startup_folder_rdp_smb.toml | 166 +++++++++++---- 10 files changed, 1370 insertions(+), 358 deletions(-) diff --git a/rules/windows/initial_access_url_cve_2025_33053.toml b/rules/windows/initial_access_url_cve_2025_33053.toml index e83f5c2c651..e84aac6765a 100644 --- a/rules/windows/initial_access_url_cve_2025_33053.toml +++ b/rules/windows/initial_access_url_cve_2025_33053.toml @@ -2,12 +2,13 @@ creation_date = "2025/06/11" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/05/03" [rule] author = ["Elastic"] description = """ -Identifies a suspicious Diagnostics Utility for Internet Explorer child process. This may indicate the successful exploitation of the vulnerability CVE-2025-33053. +Identifies Internet Explorer Diagnostics launching a helper name from a non-System32 path, which may indicate +CVE-2025-33053 exploitation. """ from = "now-9m" index = [ @@ -21,30 +22,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Potential CVE-2025-33053 Exploitation" -note = """## Triage and analysis - -### Investigating Potential CVE-2025-33053 Exploitation - -### Possible investigation steps - -- Review the process details to confirm the suspicious child process was indeed started by iediagcmd.exe. -- Check any URL file type creation before the alert and review the source of those files. -- Investigate the process tree and make sure all descendant processes are terminated. -- Examine the network activity associated with the suspicious process to detect any unauthorized data exfiltration or communication with known malicious IP addresses. -- Assess the system for any additional indicators of compromise, such as unexpected changes in system files or registry keys, which might suggest a broader attack. - -### False positive analysis - -- This behavior is very rare and should be highly suspicious. - -### Response and remediation - -- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. -- Terminate the suspicious child process identified in the alert. -- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. -- Implement additional monitoring and alerting for similar suspicious activities involving explorer.exe to enhance detection capabilities and prevent recurrence. -- Review and update endpoint security policies to restrict the execution of potentially malicious URL files.""" references = [ "https://research.checkpoint.com/2025/stealth-falcon-zero-day/", "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-33053", @@ -57,7 +34,6 @@ tags = [ "OS: Windows", "Use Case: Threat Detection", "Tactic: Initial Access", - "Tactic: Defense Evasion", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", @@ -81,6 +57,170 @@ process where host.os.type == "windows" and event.type == "start" and "C:\\Windows\\System32\\makecab.exe") ''' +note = """## Triage and analysis + +### Investigating Potential CVE-2025-33053 Exploitation + +#### Possible investigation steps + +- Does the alert show "iediagcmd.exe" launching a non-system helper? + - Focus: `process.parent.executable`, `process.name`, `process.executable`, and `process.command_line`; check for WebDAV, UNC, temp, downloads, archive-extracted, or user-writable helper paths. + - Implication: escalate when the helper name matches a diagnostics utility but `process.executable` is outside "C:\\Windows\\System32\\" or points to remote/user-writable content; lower suspicion only when the path is a controlled diagnostic harness bounded to this `host.id` and `user.id`. +- Does child identity fit the claimed system utility? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is unsigned, newly seen, remotely hosted, user-writable, or PE metadata mismatches the helper name; a trusted signer/familiar name confirms identity only, not benign "iediagcmd.exe" use. +- Does parent/session context fit user-triggered execution? + - Focus: `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`. + - Hint: inspect `process.Ext.ancestry` only when direct parent/child context is incomplete. + - Implication: escalate when the parent command line/ancestry points to a shortcut, archive, browser, mail client, or document-open path in an interactive user session; lower suspicion when parent/session evidence stays inside a controlled diagnostic or authorized test launch path. +- If file telemetry is available, did the lure or child stage follow-on artifacts? + - Focus: recover file events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Review `file.name`, `file.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ".url" lures, archive extraction, decoy PDFs, copied helpers, DLLs, or payloads. $investigate_0 + - Hint: if the child writes a file, check later starts where `process.executable` equals `file.path`. + - Implication: escalate on internet provenance, WebDAV/UNC lure paths, decoys, copied utilities, DLLs, or written artifacts later executed; missing file telemetry is unresolved, not benign. +- If DNS/connection telemetry is available, did the child contact a remote share or callback? + - Focus: recover network events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Separate DNS `dns.question.name`/`dns.resolved_ip` from connection `destination.ip`/`destination.port`. $investigate_1 + - Hint: map "lookup_result" `dns.question.name` to `dns.resolved_ip`, then compare with `destination.ip` and any remote host from the helper path or lure. + - Implication: escalate when the child reaches a remote-share host, rare public destination, or later C2-like infrastructure unrelated to diagnostics; missing DNS/connection telemetry is unresolved, not benign. +- Do descendants or siblings show cleanup, decoy opening, or payload execution? + - Focus: later process starts on the same `host.id`, using direct `process.parent.entity_id` links first; review `process.executable`, `process.command_line`, `process.Ext.created_suspended`, and signer context. $investigate_2 + - Hint: use PID matching only in a tight alert-time window, and inspect `process.Ext.ancestry` only when direct lineage is incomplete. + - Implication: escalate when the chain launches "taskkill.exe", opens a decoy through "cmd.exe", starts a browser from an abnormal path, creates a suspended process, or runs unsigned follow-on payloads; keep host-local only when no follow-on evidence contradicts a bounded diagnostic or test path. +- If local evidence is suspicious or incomplete, do related alerts show broader delivery or post-exploitation? + - Focus: review same-`user.id` alerts over 48 hours for the same lure, proxy-execution, payload, or C2 pattern. $investigate_3 + - Hint: if the user scope is sparse or shared, compare same-`host.id` alerts for the same ".url", WebDAV, child hash, or payload pattern. $investigate_4 + - Implication: expand response scope when related alerts show the same lure, remote working directory, payload, or post-exploitation pattern; keep response host-local only when related alerts are absent and local telemetry fully explains one recognized workflow. +- What disposition do helper-path, identity, launch, artifact, network, descendant, and related-alert findings support? + - Implication: escalate on remote working-directory abuse, lure delivery, payload staging, suspicious destinations, cleanup, or broader compromise; close only when process, artifact, network, descendant, and alert-scope evidence bind one recognized diagnostic or authorized test workflow; preserve and escalate on incomplete or mixed visibility. + +### False positive analysis + +- Routine diagnostics resolve helpers from "C:\\Windows\\System32\\". Treat helper execution from WebDAV, UNC, temp, downloads, or archive paths as an operational anti-pattern unless telemetry proves a controlled harness or authorized exploit test: child identity (`process.executable`, `process.hash.sha256`, signer, `process.command_line`), parent launch context, `user.id`, `host.id`, and ".url", file-provenance, DNS, or destination evidence stay inside the same bounded workflow; use testing records only to corroborate telemetry. +- Before exceptions, validate the minimum recurring pattern: child path or hash, signer, command line, `process.parent.executable`, `user.id`, `host.id`, and bounded lure or destination pattern. Avoid exceptions on "iediagcmd.exe", `process.name`, helper basename, or `host.id` alone because those fields also match malicious working-directory hijack chains. + +### Response and remediation + +- If confirmed benign, reverse containment and document the exact child path/hash, command line, parent launch context, `user.id`, `host.id`, and lure or destination evidence proving the diagnostic or testing workflow. Create an exception only for that recurring bounded pattern. +- If suspicious but unconfirmed, preserve a case export of the alert, parent/child process details, suspicious helper binary, ".url" or archive artifacts, file-provenance records, DNS/connection records, and descendant process evidence before containment. Apply reversible containment first: block the confirmed WebDAV or callback destination, remove remote-share access, or raise monitoring on `host.id`; isolate only when artifact, network, or descendant evidence shows active compromise and the host role can tolerate disruption. +- If confirmed malicious, isolate the host or terminate the malicious child and confirmed descendants only after recording process entity IDs, command lines, hashes, lure paths, destination indicators, and related alert identifiers. If endpoint response is unavailable, hand off preserved evidence to contain the endpoint or block remote infrastructure. +- Before deleting artifacts, scope other users and hosts for the same ".url" filename pattern, WebDAV/UNC host, child hash, command line, decoy path, and payload path. Remove only lure files, dropped helpers, DLLs, decoys, archives, and payloads found during the investigation, then restore modified execution paths that supported the hijack chain. +- After containment, apply the June 2025 Windows security updates for CVE-2025-33053 where missing, restrict untrusted Internet Shortcut content and remote-working-directory execution paths, retain process/file/network telemetry, and document variants such as helper names or WebDAV paths for detection engineering review. +""" + +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.id", + "user.id", + "process.name", + "process.pid", + "process.entity_id", + "process.executable", + "process.command_line", + "process.Ext.session_info.logon_type", + "process.pe.original_file_name", + "process.code_signature.subject_name", + "process.code_signature.trusted", + "process.parent.executable", + "process.parent.command_line", + "process.hash.sha256", +] + +[transform] + +[[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" } + ], + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" } + ] +] +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" } + ], + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Child process starts from the suspicious child process" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" } + ], + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/initial_access_webshell_screenconnect_server.toml b/rules/windows/initial_access_webshell_screenconnect_server.toml index 61a539319e7..33b6eaf4236 100644 --- a/rules/windows/initial_access_webshell_screenconnect_server.toml +++ b/rules/windows/initial_access_webshell_screenconnect_server.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/26" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -25,41 +25,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "ScreenConnect Server Spawning Suspicious Processes" -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 ScreenConnect Server Spawning Suspicious Processes - -ScreenConnect, a remote support tool, allows administrators to control systems remotely. Adversaries may exploit this by executing unauthorized commands or scripts, potentially using it as a backdoor. The detection rule identifies unusual child processes like command shells spawned by the ScreenConnect service, signaling possible exploitation or web shell activity, thus aiding in early threat detection. - -### Possible investigation steps - -- Review the alert details to confirm the parent process is ScreenConnect.Service.exe and identify the suspicious child process name, such as cmd.exe or powershell.exe. -- Check the timestamp of the process start event to determine when the suspicious activity occurred and correlate it with any other unusual activities or alerts around the same time. -- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised. -- Examine the command line arguments of the spawned process to identify any malicious or unauthorized commands being executed. -- Review network logs for any unusual outbound connections initiated by the ScreenConnect service or the suspicious child process, which may indicate data exfiltration or communication with a command and control server. -- Analyze the system for any additional indicators of compromise, such as unexpected file modifications or the presence of web shells, to assess the extent of the potential breach. - -### False positive analysis - -- Legitimate administrative tasks using command shells or scripting tools like cmd.exe or powershell.exe may trigger the rule. To manage this, create exceptions for known administrative scripts or tasks that are regularly executed by trusted users. -- Automated maintenance scripts that utilize ScreenConnect for legitimate purposes can be mistaken for suspicious activity. Identify these scripts and whitelist their execution paths or specific process names to prevent false alerts. -- Software updates or installations that require command line execution through ScreenConnect might be flagged. Document these processes and exclude them from the rule by specifying the associated process names or hashes. -- Security tools or monitoring solutions that interact with ScreenConnect for legitimate scanning or logging purposes may inadvertently trigger the rule. Verify these tools and add them to an exception list based on their process identifiers or parent-child process relationships. -- Training or demonstration sessions using ScreenConnect to showcase command line features could be misinterpreted as threats. Schedule these sessions and temporarily adjust the rule sensitivity or disable it during the known timeframes to avoid false positives. - -### Response and remediation - -- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Terminate any suspicious processes identified as being spawned by ScreenConnect.Service.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. -- Conduct a thorough review of recent ScreenConnect session logs to identify unauthorized access or unusual activity patterns, and revoke any compromised credentials. -- Scan the affected system for additional indicators of compromise, such as web shells or other malware, using endpoint detection and response tools. -- Apply security patches and updates to the ScreenConnect server and any other vulnerable applications to mitigate exploitation risks. -- Restore the system from a known good backup if evidence of compromise is confirmed, ensuring that the backup is free from malicious artifacts. -- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and evidence for further investigation.""" references = ["https://blackpointcyber.com/resources/blog/breaking-through-the-screen/"] risk_score = 73 rule_id = "3d00feab-e203-4acc-a463-c3e15b7e9a73" @@ -69,7 +34,6 @@ tags = [ "OS: Windows", "Use Case: Threat Detection", "Tactic: Initial Access", - "Tactic: Execution", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Sysmon", @@ -86,9 +50,164 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.parent.name : "ScreenConnect.Service.exe" and (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or - ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE")) + ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE", "csc.exe")) ''' +note = """## Triage and analysis + +### Investigating ScreenConnect Server Spawning Suspicious Processes + +#### Possible investigation steps + +- Does the alert prove ScreenConnect application-server execution rather than client-side remote command use? + - Why: the reference separates server compromise from routine client deployment; server-side abuse uses "ScreenConnect.Service.exe", while client-side commands usually involve "ScreenConnect.ClientService.exe". + - Focus: alert-local `process.parent.name`, `process.parent.executable`, `process.name`, `process.pe.original_file_name`, `host.id`, and `host.name`. + - Implication: escalate sooner when "ScreenConnect.Service.exe" on the application server spawned "cmd.exe", PowerShell, or "csc.exe"; lower suspicion only when parent or host evidence proves this is not server-side execution, then resolve the mismatch before applying this guide. + +- Is the spawned child the genuine Windows tool expected by its name? + - 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 runs from a user-writable or ScreenConnect content path, is unsigned or untrusted, or PE metadata does not match the shell, PowerShell, or compiler name; confirmed identity says what ran, not that the launch is benign. + +- What intent is visible in the child command line and service context? + - Why: ScreenConnect server exploitation often inherits the service identity, so SYSTEM or the expected service account does not reduce risk by itself. + - Focus: `process.command_line`, `process.parent.command_line`, and `user.id`. + - Implication: escalate when the command shows encoded PowerShell, download or staging, account creation, service changes, webshell-style shell use, or "csc.exe" compiling from temporary or ScreenConnect content paths; lower suspicion only for narrow maintenance, extension, or vendor-support action and later evidence agrees. + +- Do ScreenConnect server artifacts corroborate authentication bypass, extension traversal, or webshell staging? + - Why: the reference describes CVE-2024-1709 admin-user changes in "Users.xml" and CVE-2024-1708 web-accessible ASP.NET content under "App_Extensions". + - Focus: if file telemetry exists, query file events on `host.id` where `process.entity_id` equals server service `process.parent.entity_id`; if absent, pivot on `host.id`, service PID, and alert time, then review `file.path` and `file.name` for "Users.xml", "App_Extensions", ASP.NET files, or extension archives. $investigate_0 + - Hint: if file telemetry is unavailable or empty, inspect those server paths directly; missing file telemetry is unresolved, not benign. + - Implication: escalate when "Users.xml" shows an unexpected admin, "App_Extensions" contains a lone ASP.NET file, or extension content appears outside GUID-scoped folders; lower suspicion only when artifacts stay inside expected extension paths and process evidence supports the same workflow. + +- Did the spawned child make network connections consistent with follow-on tooling or external control? + - Focus: if network telemetry exists, query `host.id` and child `process.entity_id`; if absent, pivot on `host.id`, `process.pid`, and alert time, separating DNS `dns.question.name` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. $investigate_1 + - Hint: Missing network telemetry is unresolved, not benign. + - Implication: escalate when the shell, PowerShell, or compiler reaches a public destination with no ScreenConnect/vendor relationship, a staging domain, or any destination inconsistent with the recovered command; lower suspicion for absent destinations only after telemetry is verified and local process/artifact evidence resolve cleanly. + +- Do related host alerts change scope when local findings are suspicious or unresolved? + - Focus: child process starts, additional children from the same ScreenConnect service parent, plus related alerts for `host.id`, especially webshell, persistence, credential-access, service-creation, or secondary-RMM alerts. $investigate_3 + $investigate_4 + $investigate_2 + - Implication: broaden response scope when the ScreenConnect server also shows exploitation, persistence, credential access, or secondary remote-access activity; keep scope local only when this alert is isolated and process, artifact, and destination evidence all resolve to one exact benign workflow. + +- Escalate when server-side parentage combines with suspicious child identity or command intent, or artifacts, destinations, or related alerts support compromise; close only when process evidence and recovery tie to one exact ScreenConnect maintenance, extension, or vendor-support workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + +### False positive analysis + +- ScreenConnect server maintenance, extension installation, or vendor troubleshooting can legitimately spawn "powershell.exe", "cmd.exe", or "csc.exe". Confirm the same workflow across child identity, signer or hash, command intent, `host.id`, `user.id`, recovered server artifacts, and destinations when network telemetry exists. Use change records or vendor cases as corroboration, not a replacement for telemetry gaps. +- Do not treat generic administrative scripting or compile activity as benign on a ScreenConnect server. Confirm only narrow recurring service workflow: same parent path, child identity, command pattern, `user.id`, and quiet artifact or destination pattern on the same `host.id` across prior alerts or source events when external records are unavailable. One-off shells, downloaders, account changes, or root-level "App_Extensions" files remain suspicious. +- Before creating an exception, build it from the minimum confirmed workflow pattern: `process.parent.executable`, `process.executable`, a constrained `process.command_line` pattern, stable signer or hash, `host.id`, and the specific ScreenConnect maintenance or extension context. Avoid exceptions on `process.name` or "ScreenConnect.Service.exe" alone. + +### Response and remediation + +- Before restriction or cleanup in suspicious cases, preserve a case export of the alert process and parent records, recovered file and network events, ScreenConnect and IIS logs around the alert time, "Users.xml", the "App_Extensions" tree, suspicious extension archives or ASP.NET files, and staged payloads. +- If confirmed benign, reverse temporary restrictions and document evidence proving the workflow: parent and child identity, command intent, server scope, expected ScreenConnect artifacts, and expected destinations if present. Build a narrow exception only after the same workflow recurs consistently. +- If suspicious but unconfirmed, apply reversible containment tied to the findings: restrict public access to the ScreenConnect web interface, temporarily limit egress from the affected `host.id`, or suspend a newly created ScreenConnect admin account where operationally safe. Weigh server criticality before full host isolation. +- If confirmed malicious, preserve the artifacts above before terminating processes or deleting files. Then isolate the server or disable public exposure, remove malicious admin accounts, webshells, extensions, secondary RMM services, and other persistence found during the investigation, and rotate compromised ScreenConnect, service, or domain credentials. +- Patch ScreenConnect to a fixed version and review whether the attacker used the server to reach managed clients or create admin or service accounts. +- After containment, retain process, file, and network telemetry needed for future ScreenConnect investigations, restrict who can manage extensions or internet exposure, and document any telemetry gaps that limited this investigation.""" + +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.id", + "process.entity_id", + "process.pid", + "process.executable", + "process.pe.original_file_name", + "process.command_line", + "process.parent.entity_id", + "process.parent.executable", + "process.parent.command_line", + "process.code_signature.subject_name", + "process.code_signature.trusted", + "process.hash.sha256", +] + +[transform] + +[[transform.investigate]] +label = "File events for the ScreenConnect server 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.parent.entity_id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Network events for the spawned 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 = "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 = "Child process events from the suspicious child" +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.entity_id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process events from the same ScreenConnect service" +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" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml b/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml index 4453dc6b459..2c0733c0568 100644 --- a/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml +++ b/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml @@ -2,13 +2,13 @@ creation_date = "2025/10/28" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2026/03/24" +updated_date = "2026/05/03" [rule] author = ["Elastic"] description = """ -Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos -authentication ticket request from the target domain controller. +Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a +Kerberos authentication ticket request from the target domain controller. """ from = "now-9m" index = [ @@ -21,45 +21,10 @@ index = [ language = "eql" license = "Elastic License v2" name = "Suspicious Kerberos Authentication Ticket Request" -note = """## Triage and analysis - -### Investigating Suspicious Kerberos Authentication Ticket Request - -Kerberos is the default authentication protocol in Active Directory, designed to provide strong authentication for client/server applications by using secret-key cryptography. - -Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of traffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of Kerberos tickets. - -#### 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. -- Investigate other alerts associated with the user/host during the past 48 hours. -- Check if the Destination IP is related to a Domain Controller. -- Review events ID 4769 and 4768 for suspicious ticket requests. -- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. - -### False positive analysis - -- Active Directory audit tools. - -### 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. -- 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. - - Ticket requests can be used to investigate potentially compromised accounts. -- If the triage identified malware, search the environment for additional compromised hosts. - - Implement temporary network rules, procedures, and segmentation to contain the malware. - - Stop suspicious processes. - - Immediately block the identified indicators of compromise (IoCs). - - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. -- Remove and block malicious artifacts identified during triage. -- 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://github.com/its-a-feature/bifrost", -"https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768" +"https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768", +"https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769" ] risk_score = 73 rule_id = "c6b40f4c-c6a9-434e-adb8-989b0d06d005" @@ -70,7 +35,6 @@ tags = [ "OS: Windows", "Use Case: Threat Detection", "Tactic: Credential Access", - "Tactic: Lateral Movement", "Use Case: Active Directory Monitoring", "Data Source: Active Directory", "Data Source: Elastic Defend", @@ -85,17 +49,145 @@ query = ''' sequence by source.port, source.ip with maxspan=3s [network where host.os.type == "windows" and destination.port == 88 and process.executable != null and process.pid != 4 and - not process.executable : - ("?:\\Windows\\system32\\lsass.exe", - "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe", - "\\device\\harddiskvolume*\\windows\\system32\\svchost.exe") and - not (process.executable : ("C:\\Windows\\System32\\svchost.exe", - "C:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe", - "F:\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe") and user.id in ("S-1-5-20", "S-1-5-18")) and + not process.executable : ( + "?:\\Windows\\system32\\lsass.exe", + "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe", + "\\device\\harddiskvolume*\\windows\\system32\\svchost.exe" + ) and + not ( + process.executable : ( + "C:\\Windows\\System32\\svchost.exe", + "C:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe", + "C:\\Program Files\\Omnissa\\Horizon\\Server\\bin\\ws_TomcatService.exe", + "F:\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe" + ) and + user.id in ("S-1-5-20", "S-1-5-18") + ) and source.ip != "127.0.0.1" and destination.ip != "::1" and destination.ip != "127.0.0.1"] [authentication where host.os.type == "windows" and event.code in ("4768", "4769")] ''' +note = """## Triage and analysis + +### Investigating Suspicious Kerberos Authentication Ticket Request + +#### Possible investigation steps + +- Which Timeline member events define this Kerberos sequence? + - Focus: Timeline members keyed by alert `source.ip` and `source.port`; recover source `process.executable`, Kerberos `destination.ip`, and auth `event.code`. + - Hint: record `host.id` and `process.entity_id`; verify auth `winlog.computer_name` is the DC. + - Implication: escalate when one non-"lsass.exe" source process maps to a DC "4768" or "4769" event in the sequence window; lower concern for socket reuse, a different process, or non-DC destination. + +- Is the recovered source process a recognized Kerberos-capable client? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: open process start with recovered `host.id` and `process.entity_id`; if absent, use `host.id`, `process.pid`, and sequence window. + - Implication: escalate when the binary is unsigned, renamed, user-writable, signer-mismatched, or outside known AD audit, Kerberos diagnostic, or security-test tooling; lower concern only when path, signer, hash history, command, and parent converge on one known tool. + +- Does command-line and parentage show ticket-tool intent? + - Focus: recovered `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and broader process lineage when needed. + - Implication: escalate on Bifrost-like verbs or flags such as asktgt, asktgs, s4u, ptt, kerberoast, service/SPN targets, hashes, keytabs, RC4, or base64 tickets, especially from shell or script parents; bounded diagnostics from a recognized admin tool reduce but do not clear concern. + +- Which ticket path and target account did the DC member event show? + - Focus: recovered auth `event.code`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetDomainName`. + - Implication: escalate when "4769" shows service-ticket activity or "4768" shows TGT handling for privileged, service, machine, or delegation-sensitive targets from the unusual process; fan-out increases concern. + +- Does the source user and session context fit one bounded admin or audit source? + - Focus: recovered `user.id`, `user.name`, `user.domain`, and `winlog.event_data.TargetUserName`. + - Implication: escalate when privileged, service, or user-account tickets originate from a workstation, user session, or non-management tool; lower concern only when source host, user, process identity, command/parent, and target account recur as one bounded Kerberos diagnostic or audit pattern. + +- Do surrounding Kerberos events show repetition or account fan-out? + - Focus: same-source Kerberos network and authentication events, checking additional "4768"/"4769" events and `winlog.event_data.TargetUserName`. + - $investigate_0 + - $investigate_1 + - Implication: escalate when requests repeat or fan out across accounts; a single bounded request narrows scope but does not close if process identity or command intent remains suspicious. Missing network or authentication telemetry is unresolved, not benign. + +- Do later logon or explicit-credential events suggest ticket use? + - Focus: same-source authentication results, checking later `event.code` "4624"/"4648", `winlog.event_data.TargetUserName`, and 4648 `winlog.event_data.TargetServerName`. + - Implication: escalate when post-ticket logon or explicit-credential activity reaches sensitive accounts or servers from the same source; absence narrows impact but does not close if the ticket request remains suspicious. Missing same-source authentication telemetry leaves ticket use unresolved, not benign. + +- If local evidence remains suspicious or unresolved, does the same source show related alerts? + - Focus: related alerts for `source.ip`; manually pivot on recovered `process.hash.sha256` or `winlog.event_data.TargetUserName` when locally suspicious. $investigate_2 + - Implication: broaden scope when credential-access, Kerberoasting, relay, or lateral-movement alerts share the source, process, or target account; keep local only when related alerts are absent and recovered evidence resolves cleanly. + +- Escalate when sequence recovery, source-process identity, command intent, DC ticket target, account context, or surrounding ticket/logon activity show unauthorized direct Kerberos; close only when telemetry binds one recognized tool, source host, user, and target account and outside confirmation verifies exact activity when telemetry cannot; preserve and escalate when visibility is incomplete or evidence conflicts. + +### False positive analysis + +- AD audit tools, Kerberos diagnostics, interoperability testing, or security testing can request tickets directly instead of through "lsass.exe". Confirm only when process path, signer/hash, parent, command line, `source.ip`, `user.id`, `event.code`, and target account align with the same recognized tool on a dedicated admin, lab, or audit source; without outside records, require the same process identity, source host/user, target account, and bounded ticket pattern across prior alerts from this rule. +- Treat partial matches as unresolved when process identity fits but the command targets unusual SPNs, privileged accounts, RC4/kerberoast behavior, or follow-on "4624"/"4648" activity. Do not close on signer, source IP, or event code alone when ticket target or command intent contradicts benign workflow. +- Before creating an exception, anchor it to the minimum stable workflow: dedicated `source.ip` or source host, process signer/hash/path, parent workflow, `user.id`, target account, and bounded `event.code` pattern. Avoid exceptions on `source.port`, `event.code`, process name, or broad account patterns alone. + +### Response and remediation + +- If confirmed benign, reverse temporary containment and document the recovered source host/IP, process identity, command line, source user, DC ticket event, and target account that proved the recognized workflow. Create an exception only after the same dedicated source and process pattern recurs consistently. +- If suspicious but unconfirmed, preserve the alert, Timeline member events, suspicious process binary and command line, source socket, DC authentication record, and any follow-on "4624" or "4648" evidence before containment or process action. +- Apply reversible containment next: restrict the recovered source host's Kerberos/DC access or isolate the host when its role tolerates isolation, and suspend the recovered process only after process and authentication artifacts are captured. +- If confirmed malicious, isolate the recovered source host, terminate or suspend the recovered process after recording its `process.entity_id`, expire exposed Kerberos tickets where operationally appropriate, and reset or rotate impacted credentials, prioritizing privileged, service, machine, and delegation-capable accounts. +- Before cleanup, search for the same source IP, recovered process hash, target account, and related credential-access, Kerberoasting, relay, or lateral-movement activity so scope is not limited to the first sequence. +- After containment, retain DC "4768"/"4769" auditing and endpoint network telemetry, restrict direct Kerberos tooling to controlled admin/testing hosts, and document the recovered tool pattern and any logging gaps in the case record. +""" + +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 3 - Network Connection](https://ela.st/sysmon-event-3-setup) +- [Audit Kerberos Authentication Service](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-authentication-service) +- [Audit Kerberos Service Ticket Operations](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-service-ticket-operations) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "source.ip", + "source.port", + "host.id", +] + +[transform] + +[[transform.investigate]] +label = "Kerberos network events from the same source IP" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }, + { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" }, + { excluded = false, field = "destination.port", queryType = "phrase", value = "88", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Authentication events for the same source IP" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "authentication", valueType = "string" }, + { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the same source IP" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/lateral_movement_dcom_hta.toml b/rules/windows/lateral_movement_dcom_hta.toml index e232e9ab815..4b344c6b514 100644 --- a/rules/windows/lateral_movement_dcom_hta.toml +++ b/rules/windows/lateral_movement_dcom_hta.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/03" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2026/03/24" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -21,42 +21,7 @@ index = [ language = "eql" license = "Elastic License v2" name = "Incoming DCOM Lateral Movement via MSHTA" -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 DCOM Lateral Movement via MSHTA - -DCOM allows software components to communicate over a network, enabling remote execution of applications like MSHTA, which runs HTML applications. Adversaries exploit this by executing commands remotely, bypassing traditional security measures. The detection rule identifies suspicious MSHTA activity by monitoring process starts and network traffic, focusing on unusual port usage and remote IP addresses, indicating potential lateral movement attempts. - -### Possible investigation steps - -- Review the process start event for mshta.exe on the affected host to gather details such as the process entity ID, command-line arguments, and parent process information to understand how mshta.exe was executed. -- Analyze the network traffic associated with the mshta.exe process, focusing on the source and destination IP addresses and ports, to identify any unusual or unauthorized remote connections. -- Check the source IP address involved in the network event to determine if it is known or associated with any previous suspicious activity or if it belongs to an internal or external network. -- Investigate the timeline of events on the host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or lateral movement attempts. -- Correlate the findings with other security logs and alerts from the same host or network segment to identify any additional indicators of compromise or related malicious activities. -- Assess the risk and impact of the detected activity by considering the host's role within the network and any sensitive data or systems it may have access to. - -### False positive analysis - -- Legitimate administrative tasks using MSHTA for remote management can trigger the rule. Identify and document these tasks, then create exceptions for known administrative IP addresses or specific user accounts. -- Automated software updates or deployments that utilize MSHTA may appear as suspicious activity. Monitor and whitelist the IP addresses and ports associated with these updates to prevent false positives. -- Internal network scanning tools or security assessments might mimic lateral movement behavior. Coordinate with IT and security teams to recognize these activities and exclude them from triggering alerts. -- Custom applications that leverage MSHTA for inter-process communication could be flagged. Review these applications and exclude their known processes or network patterns from the detection rule. -- Remote desktop or support tools that use MSHTA for legitimate purposes should be identified. Whitelist these tools by their process names or associated network traffic to reduce unnecessary alerts. - -### Response and remediation - -- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration. -- Terminate the mshta.exe process on the affected host to stop any ongoing malicious activity. -- Conduct a thorough examination of the affected host to identify any additional malicious files or processes, focusing on those initiated around the time of the alert. -- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access. -- Review and restrict DCOM permissions and configurations on the affected host and other critical systems to limit the potential for similar attacks. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems have been compromised. -- Update detection mechanisms and threat intelligence feeds to enhance monitoring for similar DCOM-based lateral movement attempts in the future.""" -references = ["https://codewhitesec.blogspot.com/2018/07/lethalhta.html"] +references = ["https://code-white.com/blog/2018-07-lethalhta/"] risk_score = 73 rule_id = "622ecb68-fa81-4601-90b5-f8cd661e4520" severity = "high" @@ -82,6 +47,152 @@ sequence with maxspan=1m ] by host.id, process.entity_id ''' +note = """## Triage and analysis + +### Investigating Incoming DCOM Lateral Movement via MSHTA + +#### Investigation steps + +- Do recovered source events show remote COM activation of mshta on this host? + - Focus: alert `host.id` and `process.entity_id`; recover `process.command_line` plus matching network `source.ip`, `source.port`, `destination.port`, and `network.direction`. + - Implication: escalate when the COM-server process receives incoming non-loopback RPC-style TCP from an unconfirmed source; lower only when telemetry and exact confirmation tie source, target, and COM-server launch to recurring distribution or helpdesk activity. Missing source events leave the alert unresolved. + +- Is mshta the expected Windows COM server, not a staged or masqueraded copy? + - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`. + - Implication: escalate when mshta runs from a user-writable or non-Windows path, has an unexpected signer, or lacks a service/DCOM-style parent such as "svchost.exe"; Microsoft identity lowers only masquerade risk because source and retrieval still decide the case. + +- Do source, account, and logon context support the same confirmed workflow? + - Focus: recovered `source.ip`, target-side `user.id`, and session bridge `process.Ext.authentication_id`, `winlog.event_data.TargetLogonId`, and `winlog.event_data.AuthenticationPackageName`. + - Implication: escalate when source, account, session type, or auth package conflict with the source-event workflow; lower only when telemetry and exact confirmation identify a legitimate source-to-host relationship. Missing Windows Security telemetry leaves origin and auth method unresolved, not benign. + +- Does same-process DNS/connection data show remote script retrieval? + - Why: HTA COM can load remote script content into "mshta.exe"; same-process retrieval is direct corroboration. + - Focus: same-process DNS `dns.question.name` and `dns.resolved_ip`, then connection `destination.ip` and `destination.port`. $investigate_0 + - Hint: map `dns.question.name` to `dns.resolved_ip` before tying later `destination.ip` to retrieval. + - Implication: escalate when mshta resolves or connects to public, rare, or mismatched content hosts; lower only when the destination maps to the same recognized internal or vendor workflow as the source. Missing DNS or connection telemetry leaves retrieval unresolved, not benign. + +- Do file artifacts show cached HTA content or staged payloads? + - Focus: same-host file events tied to `host.id` and mshta or follow-on `process.entity_id`, especially `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.path`. $investigate_1 + - Range: start with the alert window; expand after the first suspicious write to confirm later execution. + - Implication: escalate when the chain writes HTA/script/payload content to temp, downloads, ADS-like, systemprofile "INetCache", or extensionless paths, or when the artifact later executes; lower when artifacts stay in one recurring deployment path. Missing file telemetry is unresolved, not benign. + +- Does mshta stay in-process or hand off execution? + - Why: LethalHTA can run JScript/VBScript, DotNetToJScript, CLR, or beacon code inside "mshta.exe"; absence of child processes does not clear the alert. + - Focus: child process starts from recovered mshta `process.entity_id`. $investigate_2 + - Library: same-process `dll.path`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. $investigate_3 + - Implication: escalate when mshta spawns shells, downloaders, proxy-execution utilities, or loads recent/untrusted libraries from writable or nonstandard paths; narrow only when no follow-on execution appears and earlier source, session, and retrieval fit one recognized workflow. Missing library telemetry leaves in-process payload review unresolved, not benign. + +- Do related alerts change scope? + - Focus: related lateral-movement, proxy-execution, or follow-on delivery alerts for `host.id` in the prior 48h. $investigate_4 + - Hint: use the host-scoped transform first; search recovered `source.ip`, `dns.question.name`, or `destination.ip` across other targets only if local evidence remains suspicious or unresolved. + - Implication: escalate scope when the host shows adjacent lateral-movement, proxy-execution, or follow-on delivery alerts, or when the source touches additional targets; keep the case local when the alert is isolated and earlier evidence fits one stable workflow. + +- Escalate unauthorized DCOM HTA execution when source-event chain, source/session fit, retrieval, artifacts/libraries, child execution, or related-alert scope remain suspicious; close only when pivots bind one recognized host workflow without contradictory retrieval, artifact, or follow-on activity; if answers stay mixed or incomplete, preserve evidence and escalate. + +### False positive analysis + +- Management tooling (software distribution, enrollment, or helpdesk launchers) can legitimately activate the HTA COM object. Confirm `source.ip` is the management host, mshta identity and `process.parent.executable` match that tool, DNS/destination pattern serves it, and artifacts, children, or libraries do not contradict it. Telemetry that cannot prove legitimacy needs change, distribution, asset, or owner confirmation. +- Do not close on partial context: known admin subnet, Microsoft-signed "mshta.exe", or familiar user alone. If any evidence dimension contradicts the expected workflow, or neither telemetry nor exact confirmation proves it, treat the alert as suspicious or unresolved. +- Anchor exceptions on the minimum confirmed workflow: recognized `source.ip`, stable `process.parent.executable`, recovered `process.command_line`, specific benign `dns.question.name` or `destination.ip`, and relevant `host.id`. Avoid exceptions on `process.name` of "mshta.exe", incoming high ports, or `user.name` alone. + +### Response and remediation + +- If confirmed benign, reverse temporary containment and document source, target host, mshta identity, parent context, destination pattern, and artifact evidence confirming the recognized workflow. Create an exception only for the exact pattern confirmed by telemetry and supporting records or owner confirmation. +- If suspicious but unconfirmed, preserve Timeline source events, mshta identity and command line, remote source and high-port pair, DNS and destination evidence, cached/staged files, child processes, suspicious libraries, and relevant case exports before containment or cleanup. +- Apply reversible containment first: restrict DCOM or web retrieval between the target and recovered source/destination, increase monitoring on `host.id` and `user.id`, or isolate the endpoint only when retrieval, child execution, or library evidence indicates active payload execution and the host role permits isolation. +- If confirmed malicious, isolate the target endpoint and contain the recovered source system or account when in scope. Block malicious domains, destinations, and hashes; record process and artifact IDs before killing processes or deleting files. +- Scope other hosts reached by the same recovered `source.ip`, `dns.question.name`, `destination.ip`, or `process.command_line` pattern before destructive eradication, credential removal, or broad DCOM changes. +- Eradicate only identified HTA, HTML, script, DLL, cached content, or staged payloads, then remediate the DCOM exposure, application workflow, or credentials that enabled remote execution. +- Post-incident hardening: restrict DCOM exposure to recognized management paths, keep Windows Firewall or equivalent RPC controls enabled for the host class, limit HTA use to recognized workflows, retain process/network/file/library telemetry, and record SMB/named-pipe delivery if found during scoping. +""" + +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) +- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.id", + "process.entity_id", +] + +[transform] + +[[transform.investigate]] +label = "Network events for the mshta 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 = "File events for the mshta 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 = "Child process starts from the mshta process" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Library events for the mshta process" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "library", 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 = "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/lateral_movement_dcom_mmc20.toml b/rules/windows/lateral_movement_dcom_mmc20.toml index 931dc6bc10e..c2a3e624226 100644 --- a/rules/windows/lateral_movement_dcom_mmc20.toml +++ b/rules/windows/lateral_movement_dcom_mmc20.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/06" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2026/03/24" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -21,40 +21,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Incoming DCOM Lateral Movement with MMC" -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 DCOM Lateral Movement with MMC - -Distributed Component Object Model (DCOM) enables software components to communicate over a network, often used in Windows environments for remote management. Adversaries exploit DCOM to execute commands remotely, leveraging applications like MMC20 to move laterally. The detection rule identifies suspicious activity by monitoring network traffic and process creation patterns, flagging potential misuse when MMC initiates remote commands, indicating possible lateral movement or defense evasion tactics. - -### Possible investigation steps - -- Review the network traffic logs to identify the source IP address that initiated the connection to the host running mmc.exe. Verify if this IP address is known and expected within the network environment. -- Examine the process creation logs to confirm the parent-child relationship between mmc.exe and any suspicious processes. Investigate the child processes for any unusual or unauthorized activities. -- Check the source and destination ports (both should be >= 49152) involved in the network connection to determine if they align with typical application behavior or if they are indicative of potential misuse. -- Investigate the timeline of events to see if there are any other related alerts or activities on the same host or originating from the same source IP address, which could provide additional context or indicate a broader attack pattern. -- Correlate the findings with any existing threat intelligence or known attack patterns related to DCOM abuse and lateral movement to assess the potential risk and impact on the organization. - -### False positive analysis - -- Legitimate administrative tasks using MMC may trigger the rule. Regularly review and document routine administrative activities to differentiate them from suspicious behavior. -- Automated scripts or management tools that use MMC for remote management can cause false positives. Identify and whitelist these tools by their process and network patterns. -- Internal network scanning or monitoring tools might mimic the behavior detected by the rule. Exclude known IP addresses or ranges associated with these tools to reduce noise. -- Scheduled tasks or maintenance operations that involve MMC could be misinterpreted as lateral movement. Ensure these tasks are logged and recognized as part of normal operations. -- Software updates or patches that require MMC to execute remote commands might trigger alerts. Maintain an updated list of such activities and exclude them from triggering the rule. - -### Response and remediation - -- Isolate the affected host immediately from the network to prevent further lateral movement and contain the threat. -- Terminate any suspicious processes associated with mmc.exe on the affected host to stop any ongoing malicious activity. -- Conduct a thorough review of the affected host's event logs and network traffic to identify any additional indicators of compromise or other affected systems. -- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. -- Apply patches and updates to the affected systems and any other vulnerable systems in the network to mitigate known vulnerabilities that could be exploited. -- Implement network segmentation to limit the ability of threats to move laterally within the network in the future. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional actions are necessary.""" references = ["https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/"] risk_score = 73 rule_id = "51ce96fb-9e52-4dad-b0ba-99b54440fc9a" @@ -64,7 +30,6 @@ tags = [ "OS: Windows", "Use Case: Threat Detection", "Tactic: Lateral Movement", - "Tactic: Defense Evasion", "Data Source: Elastic Defend", "Data Source: Sysmon", "Resources: Investigation Guide", @@ -74,13 +39,138 @@ type = "eql" query = ''' sequence by host.id with maxspan=1m [network where host.os.type == "windows" and event.type == "start" and process.name : "mmc.exe" and source.port >= 49152 and - destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and + destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and network.direction : ("incoming", "ingress") and network.transport == "tcp" ] by process.entity_id [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe" ] by process.parent.entity_id ''' +note = """## Triage and analysis + +### Investigating Incoming DCOM Lateral Movement with MMC + +#### Possible investigation steps + +- Which Timeline source events define the target MMC instance, spawned child, and remote source? + - Why: this asymmetric sequence links incoming "mmc.exe" network activity to a child process, and the alert may not preserve one reliable process identity. + - Focus: recover the target MMC network event and child process event, recording target MMC and child `process.entity_id`, `source.ip`, and child `process.command_line`. + - Implication: escalate if the chain does not resolve to one incoming MMC process spawning one child; lower suspicion only when it fits a recognized MMC administration source and child, then continue to command and network interpretation. +- Does the network event fit remote DCOM or RPC traffic into MMC? + - Focus: the recovered "mmc.exe" network event: `source.ip`, `source.port`, `destination.port`, `network.direction`, and `network.transport`. + - Implication: DCOM-style remote execution is supported by incoming TCP from a non-loopback `source.ip` with both ports in the high RPC range; concern rises when the source is a peer workstation, unrelated server, or unknown management origin. +- What did MMC execute through MMC20.Application COM automation? + - Focus: recovered child `process.executable` and `process.command_line`. + - Implication: escalate when MMC launches cmd.exe, PowerShell, script hosts, LOLBins, loaders, or download cradles; lower suspicion only when the exact child command is a recognized MMC snap-in helper or management binary and the source context also fits. +- Is the child binary identity consistent with the behavior, without treating signer trust as clearance? + - Focus: child `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and entity context. + - Implication: mismatched PE metadata, user-writable paths, unexpected publishers, or quick follow-on LOLBin execution increases concern; a trusted signer confirms identity only and does not clear remote command execution. +- Does the target-side user and session fit remote administration from the recovered source? + - Focus: child `user.id`, `user.name`, and `user.domain`, compared with the recovered source and target host. + - Implication: escalate when the user, service context, or session is unexpected for that target or cannot explain administrative access from the source; lower suspicion when source, identity, and session match a recognized admin or jump-host path. +- Did the MMC-spawned child launch descendants after execution? + - Focus: same-host process events from the child, checking child-of-child `process.parent.entity_id`. $investigate_2 + - Implication: escalate when the child launches more execution chains; absent descendants keeps the case centered on the recovered remote command, not benign. +- Did the child make DNS or connection activity? + - Focus: same-host network events, checking DNS `dns.question.name` and connection `destination.ip`. $investigate_3 + - Hint: separate DNS events from connection events and keep the pivot bounded to the alert window. Missing network telemetry is unresolved, not benign. + - Implication: escalate when the child resolves rare domains or connects to staging or command infrastructure. +- Does the recovered source or child command appear on other hosts after local triage stays suspicious? + - Focus: same-host alerts for `host.id`. $investigate_0 + - Hint: if the same account is suspicious, compare same-`user.id` alerts for lateral-movement or credential-access patterns across other hosts. $investigate_1 + - Hint: broaden only after local evidence remains suspicious or unresolved; use `source.ip` for spread and a distinctive child `process.command_line` fragment for tool reuse. + - Implication: expand scope when the same source touches more targets, the same child command appears elsewhere, or same-host alerts show lateral movement or defense evasion; keep the case local when the pattern stays confined and the workflow is otherwise explained. + +- Escalate when source identity, incoming high-RPC network shape, child intent, identity/session, or descendant/DNS/destination evidence supports unauthorized MMC20.Application execution; close only when recovered evidence, with external confirmation when telemetry cannot prove intent, binds one exact recognized MMC administration workflow with no contradictory follow-on evidence; mixed or incomplete evidence means preserve and escalate. + +### False positive analysis + +- Remote MMC, server-management automation, or vendor/internal tooling can legitimately trigger this rule when a management host uses DCOM to drive MMC snap-ins or support commands. Confirm the recovered `source.ip` is a recognized admin, jump, or tooling host; child `process.executable` and `process.command_line` show the exact console/helper action; `user.id` or `user.name` fits that path; child `process.hash.sha256` or `process.code_signature.subject_name` is stable when tooling is involved; and descendant, DNS, and connection evidence stays quiet. If inventory or change records are unavailable, telemetry-only closure still requires current evidence to prove the exact workflow; prior recurrence of the same `source.ip`, child command, and `host.id` pattern is corroboration, not closure by itself. +- Before creating an exception, anchor it on the minimum confirmed workflow pattern: recognized `source.ip`, child `process.executable`, stable `process.command_line`, expected `user.id` or `user.name`, and the relevant `host.id` scope. Avoid exceptions on `process.parent.name` of "mmc.exe" or high RPC ports alone. + +### Response and remediation + +- If confirmed benign, record the recovered `source.ip`, child `process.executable`, child `process.command_line`, `user.id` or `user.name`, and target `host.id` that established the management workflow, then reverse any temporary containment. Create an exception only if the same pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve a case export of the Timeline source events, the target MMC and child process instance IDs, child command line, source socket, and DNS/destination indicators before containment or cleanup. +- If suspicious but unconfirmed, apply reversible containment tied to the evidence, such as temporary DCOM/RPC restrictions from the recovered `source.ip` to the target `host.id`; isolate the host only when the child command or follow-on activity indicates payload execution and the host role can tolerate it. +- If confirmed malicious, first preserve the target MMC instance, child command, recovered source, descendant processes, and malicious DNS or destination indicators. Then isolate the target host and contain the recovered source system if it is in response scope; terminate processes or delete artifacts only after preservation and scoping. +- Review other hosts touched by the same recovered `source.ip` or child `process.command_line` pattern before terminating additional processes or removing artifacts so scoping completes before evidence is destroyed. +- Eradicate only scripts, binaries, persistence, or configuration changes identified during the investigation, then remediate the account, source host, or remote administration path that allowed the DCOM execution. +- Post-incident hardening: keep Windows Firewall enabled, disable unnecessary Microsoft Management Console inbound access, restrict DCOM/RPC between workstations, limit remote administrative rights to recognized jump hosts, and record the evidence and control changes for future triage.""" + +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) +- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.id", + "host.name", + "user.id", +] + +[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 = "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 = "Processes spawned by MMC on this host" +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.name", queryType = "phrase", value = "mmc.exe", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Network events for MMC on this host" +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.name", queryType = "phrase", value = "mmc.exe", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml index 308784a35cb..999d03591f6 100644 --- a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml +++ b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml @@ -2,7 +2,7 @@ creation_date = "2021/04/12" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -24,40 +24,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Potential Remote Desktop Shadowing Activity" -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 Remote Desktop Shadowing Activity - -Remote Desktop Shadowing allows administrators to view or control active RDP sessions, aiding in support and troubleshooting. However, adversaries can exploit this feature to monitor or hijack user sessions without consent. The detection rule identifies suspicious modifications to RDP Shadow registry settings and the execution of specific processes linked to shadowing, signaling potential misuse. - -### Possible investigation steps - -- Review the registry event details to confirm if there was a modification to the RDP Shadow registry path, specifically checking for changes in "HKLM\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow". -- Investigate the process events to identify if "RdpSaUacHelper.exe" or "RdpSaProxy.exe" were started by "svchost.exe", which could indicate unauthorized shadowing activity. -- Check for any instances of "mstsc.exe" being executed with the "/shadow:*" argument, as this could signify an attempt to shadow an RDP session. -- Correlate the identified processes and registry changes with user activity logs to determine if the actions were authorized or expected as part of legitimate administrative tasks. -- Analyze network logs for any unusual remote connections or lateral movement patterns that coincide with the timing of the detected shadowing activity. -- Consult endpoint security solutions like Microsoft Defender XDR or SentinelOne for additional context or alerts related to the same host or user account involved in the shadowing activity. - -### False positive analysis - -- Legitimate administrative activities may trigger alerts when IT staff use RDP Shadowing for support. To manage this, create exceptions for known IT administrator accounts or specific IP addresses. -- Scheduled maintenance or automated scripts that modify RDP Shadow registry settings can be mistaken for malicious activity. Identify and exclude these processes or scripts from the detection rule. -- Security software or monitoring tools that interact with RDP sessions might mimic shadowing behavior. Verify these tools and whitelist their processes to prevent false alerts. -- Training sessions or remote support tools that use RDP Shadowing features can generate alerts. Document and exclude these activities by identifying their unique process names or arguments. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. -- Terminate any suspicious processes identified in the alert, such as RdpSaUacHelper.exe, RdpSaProxy.exe, or mstsc.exe with shadowing arguments, to stop potential session hijacking. -- Revert any unauthorized changes to the RDP Shadow registry settings to their default or secure state to prevent further exploitation. -- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized changes have been made, and reset passwords for any compromised accounts. -- 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 RDP activities across the network to detect and respond to similar threats more quickly in the future. -- Review and update RDP access policies and configurations to ensure they align with best practices, such as enforcing multi-factor authentication and limiting RDP access to only necessary users and systems.""" references = [ "https://blog.bitsadmin.com/spying-on-users-using-rdp-shadowing", "https://swarm.ptsecurity.com/remote-desktop-services-shadowing/", @@ -95,12 +61,155 @@ any where host.os.type == "windows" and ) or (event.category == "process" and event.type == "start" and - (process.name : ("RdpSaUacHelper.exe", "RdpSaProxy.exe") and process.parent.name : "svchost.exe") or - (?process.pe.original_file_name : "mstsc.exe" and process.args : "/shadow:*") + ( + (process.name : ("RdpSaUacHelper.exe", "RdpSaProxy.exe") and process.parent.name : "svchost.exe") or + (?process.pe.original_file_name : "mstsc.exe" and process.args : "/shadow:*") + ) ) ) ''' +note = """## Triage and analysis + +### Investigating Potential Remote Desktop Shadowing Activity + +#### Possible investigation steps + +- Which RDP shadowing path fired? + - Focus: `event.category`, `process.name`, `process.command_line`, `registry.path`, `registry.data.strings`. + - Implication: escalate faster for active "mstsc.exe /shadow" use or a `Shadow` policy value that removes consent; lower suspicion only when alert-local evidence matches recognized helpdesk, training, or policy-setting activity with consent retained. +- Do process identity and lineage fit RDP shadowing components? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.command_line`. + - Hint: for registry alerts, recover same-process starts for lineage or command-line detail. $investigate_0 + - Implication: escalate when "mstsc.exe", "RdpSaUacHelper.exe", or "RdpSaProxy.exe" runs from a user-writable path, has an unexpected signer, or has a parent inconsistent with Remote Desktop Services or a support launcher. A trusted Microsoft binary confirms identity, not authorization. +- If the `Shadow` registry value fired, did the new setting remove consent or allow control? + - Focus: `registry.path`, `registry.data.strings` (decimal or hex: `1`/`0x00000001` = full control with consent, `2`/`0x00000002` = full control without consent, `3`/`0x00000003` = view only with consent, `4`/`0x00000004` = view only without consent), and `process.executable`. + - Implication: escalate when `registry.data.strings` is `2`/`0x00000002` (full control, no consent) or `4`/`0x00000004` (view, no consent) because these allow silent shadowing; treat `1`/`0x00000001` or `3`/`0x00000003` as weaker setup evidence because the user is prompted, unless active shadowing or unexplained lineage appears. +- If a process event fired, does it show active session shadowing? + - Focus: `process.name`, `process.command_line`, `process.parent.name`, `process.parent.executable`. + - Hint: if `process.command_line` is truncated or normalized, verify "/shadow", "/control", and "/noConsentPrompt" boundaries with `process.args` before lowering suspicion. + - Implication: escalate when "mstsc.exe" includes "/shadow" with "/control" or "/noConsentPrompt". Treat "RdpSaUacHelper.exe" or "RdpSaProxy.exe" under a service host as active target-side shadowing that escalates when paired with no-consent/control, unexplained lineage, or unrecognized user-host context; a plain "mstsc.exe" launch without shadowing arguments is not enough. +- Does user, host, and session context fit recognized support or training? + - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `process.Ext.session_info.logon_type`. + - Implication: escalate when `user.id` targets an unusual workstation, privileged session, or host with no matching shadow-support pattern; lower suspicion only when user-host pairing, session type, and branch evidence match the same recognized workflow. +- Did the same actor prepare, persist, or extend the host-side shadowing activity? + - Focus: `user.id`, `process.entity_id`, `process.command_line`, `registry.path`, `registry.data.strings`. + - Hint: start with recovered same-process events; expand to same-host process and registry events only when local capability or context remains suspicious. $investigate_1 + - Implication: escalate when the same user or lineage enumerates sessions, prepares alternate-token launch, changes Terminal Services or RDP state, launches admin tooling, or persists shadow settings; absent process or registry evidence narrows the case but does not clear the alert. +- If local findings stay suspicious or unresolved, do related alerts expand scope? + - Focus: related alerts for the same `user.id` and `host.id`, especially remote-access, credential, remote-service, and persistence alerts. + - Hint: review same-user alerts when local branch and capability questions remain suspicious. $investigate_2 + - Hint: review same-host alerts when host preparation or follow-on activity remains unresolved. $investigate_3 + - Implication: broaden scope when related alerts show the same user or host in remote-access, credential, or persistence activity; keep scope narrow only when local evidence fits a recognized workflow and related alerts do not contradict it. + +- Using branch, capability, identity, lineage, user-host fit, host-side activity, and related alerts, escalate unauthorized no-consent/control shadowing or stealthy policy relaxation; close only when evidence binds to one recognized support, training, or policy workflow with no contradictions; if mixed or incomplete, preserve process and registry artifacts and escalate. + +### False positive analysis + +- Helpdesk support, training labs, and supervised administration can legitimately use "mstsc.exe /shadow" or target-side "RdpSa*" helpers. Confirm `process.command_line`, `process.name`, `process.parent.name`, `user.id`, `host.id`, and any `Shadow` value align with the same authorized workflow, without contradictory `process.command_line` or `registry.path` evidence. Without ticketing or support rosters, require telemetry-only recurrence of the same command pattern, user-host pairing, consent mode, and quiet follow-on profile before closing as benign. +- Group Policy or endpoint management tooling can legitimately change `Shadow`. Confirm stable `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, exact `registry.path`, and resulting `registry.data.strings` match the host class. Without change records or GPO inventories, require quiet recurrence of the same process and registry pattern for the same management scope before closing. +- Before creating an exception, anchor it on the minimum confirmed workflow: `event.category`, exact `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, `registry.value`, or `Shadow` alone. + +### Response and remediation + +- If confirmed benign, reverse temporary containment and document the exact `event.category`, `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id` that proved the support, training, or policy workflow. Create an exception only after the same narrow pattern recurs. +- If suspicious but unconfirmed, preserve a case export with the process tree, `process.entity_id`, `process.command_line`, `process.parent.command_line`, `registry.path`, `registry.value`, `registry.data.strings`, affected `user.id`, affected `host.id`, and surrounding preparation or follow-on evidence before changing host state. +- Apply reversible containment next: restore the `Shadow` policy to the pre-change value, disable shadowing with `0`, require consent with `1` or `3`, or restrict the involved account on the affected `host.id`. Escalate to host isolation only when shadowing is part of broader session abuse and the host role can tolerate isolation. +- If confirmed malicious, isolate the host when feasible, then terminate active "mstsc.exe" or "RdpSa*" shadowing processes after recording their process identifiers and command lines. Revert unauthorized `Shadow` and related Terminal Services or RDP shadow permission changes after preservation. +- Scope other hosts and users tied to the same `user.id`, `process.command_line`, `registry.path`, or `registry.data.strings` before removing artifacts or resetting access. +- Remove malicious helper scripts or tooling found during scoping, revert unauthorized RDP service or policy changes, and reset credentials that may have been exposed in the shadowed session. +- Post-incident hardening: keep `Shadow` at the least permissive accepted setting, restrict who can shadow sessions, review RDP-Tcp shadow permissions, and retain process and registry telemetry needed to distinguish support use from no-consent shadowing.""" + +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) +- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.category", + "host.id", + "user.id", + "process.entity_id", + "process.pid", + "process.executable", + "process.command_line", + "process.args", + "process.parent.name", + "process.pe.original_file_name", + "process.code_signature.trusted", + "registry.path", + "registry.value", + "registry.data.strings", +] + +[transform] + +[[transform.investigate]] +label = "Process events for the same process" +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.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" } + ], + [ + { 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.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Registry events on the host near the alert" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "registry", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.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" + +[[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/lateral_movement_execution_from_tsclient_mup.toml b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml index 9db7bdce8e6..7c2ba8bf1e6 100644 --- a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml +++ b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/11" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -25,43 +25,8 @@ index = [ language = "eql" license = "Elastic License v2" name = "Execution via TSClient Mountpoint" -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 Execution via TSClient Mountpoint - -The TSClient mountpoint is a feature of the Remote Desktop Protocol (RDP) that allows users to access local drives from a remote session. Adversaries can exploit this by executing malicious files from the shared mountpoint, facilitating lateral movement within a network. The detection rule identifies such activities by monitoring for process executions originating from the TSClient path, signaling potential unauthorized access attempts. - -### Possible investigation steps - -- Review the alert details to confirm the process execution path matches the pattern "\\\\Device\\\\Mup\\\\tsclient\\\\*.exe" and verify the host operating system is Windows. -- Identify the user account associated with the RDP session and check for any unusual or unauthorized access patterns, such as logins from unexpected locations or at odd times. -- Examine the executed process's hash and compare it against known malicious hashes in threat intelligence databases to determine if the file is potentially harmful. -- Investigate the source system from which the RDP session originated to identify any signs of compromise or unauthorized access that could indicate lateral movement. -- Check for any additional suspicious activities on the target host, such as unexpected network connections or file modifications, that may correlate with the execution event. -- Review the security logs from data sources like Microsoft Defender XDR or Sysmon for any related alerts or anomalies that could provide further context on the incident. - -### False positive analysis - -- Legitimate software updates or installations may trigger the rule if they are executed from a local drive mapped through TSClient. To manage this, create exceptions for known update processes or installation paths that are frequently used in your environment. -- IT administrative tasks performed via RDP sessions can also cause false positives. Identify and exclude specific administrative tools or scripts that are regularly executed from TSClient paths by trusted personnel. -- Automated backup or synchronization software that accesses local drives through RDP might be flagged. Review and whitelist these processes if they are part of routine operations. -- Development or testing activities involving remote execution of scripts or applications from TSClient can be mistaken for threats. Establish a list of approved development tools and paths to exclude from monitoring. -- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration. -- Terminate any suspicious processes running from the TSClient path to halt any ongoing malicious activity. -- Conduct a thorough scan of the affected host using endpoint detection and response (EDR) tools to identify and remove any malicious files or artifacts. -- Review and analyze RDP logs and session details to identify unauthorized access attempts and determine the source of the intrusion. -- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. -- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for similar threats. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts.""" references = [ - "https://posts.specterops.io/revisiting-remote-desktop-lateral-movement-8fb905cb46c3", + "https://specterops.io/blog/2020/01/22/revisiting-remote-desktop-lateral-movement/", "https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language", ] risk_score = 73 @@ -88,6 +53,135 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.executable : "\\Device\\Mup\\tsclient\\*.exe" ''' +note = """## Triage and analysis + +### Investigating Execution via TSClient Mountpoint + +#### Possible investigation steps + +- What exact TSClient launch did the alert capture? + - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`. + - Implication: escalate when the redirected-drive executable is unsigned, untrusted, renamed, script-capable, or launched with command intent outside a recognized RDP support or deployment workflow; lower concern only when a vendor-signed installer or utility from the RDP client drive matches that exact session purpose. +- What launcher and Windows session produced the TSClient process? + - Focus: `process.parent.name`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.id`. + - Implication: escalate when the parent is "cmd.exe", "powershell.exe", "taskmgr.exe", or another remote-session launcher, when the session is remote-interactive for an unusual user, or when children show another TSClient-launched payload; lower concern when parent and session match a recognized support launcher or deployment tool. +- Which RDP source created the session, when authentication telemetry is available? + - Focus: bridge `process.Ext.authentication_id` to same-host authentication events through `winlog.event_data.TargetLogonId`; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`. $investigate_0 + - Implication: escalate when the recovered source or authentication package conflicts with recognized jump hosts, support workstations, or deployment sources. Missing authentication telemetry is unresolved, not benign. +- Did the TSClient process spawn shells, tools, or persistence helpers on the target? + - Focus: child starts from `process.entity_id` on `host.id`, especially `process.executable`, `process.command_line`, `process.parent.entity_id`. $investigate_1 + - Hint: if `process.entity_id` is absent, recover descendants with `host.id` + `process.pid` + a tight alert-time window and confirm the parent command line before interpreting results. + - Implication: escalate when descendants include shells, script hosts, remote-access tools, credential utilities, or persistence helpers; an isolated installer-like launch lowers urgency only if session and identity evidence also align. +- If local evidence remains suspicious or incomplete, do related alerts show the same user or host attempting RDP or remote execution elsewhere? + - Focus: same-user `user.id` and same-host `host.id` alerts sharing RDP, credential, remote-service, or execution patterns. + - Hint: user alert pivot. $investigate_2 + - Hint: host alert pivot. $investigate_3 + - Implication: expand scope only when related alerts reuse the same user, host, session pattern, or command family; unrelated alert noise does not change disposition. +- Escalate when suspicious identity, lineage, source, descendants, or related alerts support unauthorized redirected-drive execution; close only when process identity, parent/session, source when available, and descendants all match one recognized RDP support or deployment activity; preserve artifacts and escalate when authentication visibility is missing or evidence remains mixed. + +### False positive analysis + +- RDP helpdesk, break-fix, or software deployment workflows can legitimately run installers or utilities from a client drive redirected into the target session. Confirm all evidence converges on one exact activity: identity and intent (`process.executable`, `process.command_line`, signature), launch/session (`process.parent.name`, `user.id`, `host.id`, recovered `source.ip` when available), and outcome (no suspicious descendants or related alerts). Contradictory evidence keeps the case open. +- Use recurrence only to support a narrow exception candidate, not to close the current case by itself. Require the same stable executable path or signer, parent/session pattern, `user.id`, `host.id`, recovered source when available, and descendant-clean outcome across prior alerts from this rule; keep the case open when current telemetry is incomplete or contradictory. +- Before creating an exception, anchor it on the minimum confirmed pattern: specific `process.executable`, stable `process.command_line` or signer, `process.parent.name`, `user.id`, `host.id`, and recovered `source.ip` only when it was part of the confirmation. Avoid exceptions on the TSClient path wildcard or `process.name` alone. + +### Response and remediation + +- Preserve evidence before changing state: case export of the alert, process tree, command line, binary hash or sample when available, child-process events, and authentication-bridge records. +- If confirmed benign after preservation, reverse temporary containment and document the exact process identity, parent/session context, `user.id`, `host.id`, and recovered `source.ip` that established the redirected-drive workflow. Create an exception only after the same narrowly scoped pattern is stable across prior alerts. +- If suspicious but unconfirmed after preservation, use reversible containment only: terminate the active RDP session, restrict new RDP connections from the recovered source when available, disable drive redirection for the affected access path, or heighten monitoring on the affected `host.id`. Do not isolate the host, terminate processes, or suspend accounts unless follow-on execution or related alerts confirm broader abuse. +- If confirmed malicious, isolate the target host when feasible, terminate the TSClient-launched process and malicious descendants after evidence capture, and disable or suspend the account or RDP access path used for the session. +- Scope before cleanup by reviewing other hosts and users tied to the same recovered source, `user.id`, distinctive `process.command_line`, signer, or hash. +- Eradicate only the staged payloads, persistence artifacts, or tooling identified during the investigation, then review whether credentials exposed in the RDP session need reset or reissue. +- Post-incident hardening: limit RDP drive redirection, restrict RDP access to managed jump hosts, retain endpoint process and Windows Security telemetry for session bridging, and document any TSClient execution patterns that should become narrow exceptions.""" + +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.id", + "process.entity_id", + "process.executable", + "process.command_line", + "process.parent.name", + "process.parent.command_line", + "process.Ext.session_info.logon_type", + "process.Ext.authentication_id", + "process.hash.sha256", + "process.code_signature.subject_name", + "process.code_signature.trusted", +] + +[transform] + +[[transform.investigate]] +label = "Authentication events for the linked session" +description = "" +providers = [ + [ + { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{process.Ext.authentication_id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Child processes spawned by the TSClient launch" +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.entity_id}}", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/lateral_movement_rdp_sharprdp_target.toml b/rules/windows/lateral_movement_rdp_sharprdp_target.toml index a32563cd490..5e33ea57b03 100644 --- a/rules/windows/lateral_movement_rdp_sharprdp_target.toml +++ b/rules/windows/lateral_movement_rdp_sharprdp_target.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/11" integration = ["endpoint"] maturity = "production" -updated_date = "2026/03/24" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -52,41 +52,81 @@ sequence by host.id with maxspan=1m not process.name : "conhost.exe" ] ''' -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. +note = """## Triage and analysis ### Investigating Potential SharpRDP Behavior -Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement within a network. SharpRDP, a tool for executing commands on remote systems via RDP, can be misused for unauthorized access. The detection rule identifies suspicious RDP activity by monitoring network connections, registry changes, and process executions, flagging potential misuse indicative of SharpRDP behavior. - -### Possible investigation steps - -- Review the network logs to confirm the presence of incoming RDP connections on port 3389, specifically looking for connections initiated by IP addresses other than localhost (127.0.0.1 or ::1). -- Examine the registry changes to identify any new RunMRU string values set to cmd, powershell, taskmgr, or tsclient, which could indicate command execution attempts. -- Investigate the process execution logs to verify if any processes were started with parent processes like cmd.exe, powershell.exe, or taskmgr.exe, and ensure these are not legitimate administrative actions. -- Correlate the timestamps of the RDP connection, registry change, and process execution to determine if they align within the 1-minute window specified by the detection rule. -- Check the source IP address of the RDP connection against known threat intelligence feeds to assess if it is associated with any malicious activity. -- Analyze user account activity associated with the RDP session to determine if the account was compromised or if the actions were authorized. +#### Possible investigation steps + +- Do Timeline source events form one target-side SharpRDP chain? + - Focus: same-`host.id` events: inbound `source.ip`, RunMRU `registry.data.strings`, child `process.parent.name`, and child `process.command_line`. + - Hint: record the RunMRU time and child `process.entity_id`; the sequence alert may not preserve stage-specific process or registry fields. + - Implication: suspicious when non-loopback RDP to port 3389 is followed by a RunMRU shell, Task Manager, or "\\\\tsclient\\" command and child execution; lower suspicion only when all recovered members fit one recognized interactive RDP maintenance action. Missing member events are unresolved, not benign. +- Which RunMRU method launched execution? + - Focus: RunMRU `registry.path`, `registry.data.strings`, child `process.parent.name`, and child `process.command_line`. + - Implication: escalate when the RunMRU data selects a shell, Task Manager, or "\\\\tsclient\\" mapped-drive payload and the child process matches that method; normal Run-dialog use is lower risk only when it launches a bounded support utility or installer without shell staging. +- Does the source and user context fit legitimate RDP use on this target? + - Focus: inbound `source.ip`, launched-process `user.id`, and `user.name`. + - Implication: escalate when an unusual source uses an end-user or privileged account to start shells, Task Manager, or mapped-drive binaries over RDP; treat a recognized source-user pairing as context only until the RunMRU command and child identity also match the exact RDP task. +- What ran on the target, and does its identity fit the expected RDP workflow? + - Focus: child `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the command stages scripts, remote-admin tooling, credential access, or unsigned/user-writable payloads; lower suspicion only when binary identity and command line match the same bounded support or deployment workflow. A trusted signer does not clear suspicious command intent. +- Did the launched child or its descendants create follow-on activity? + - Focus: same-host endpoint events scoped to recovered child `process.entity_id`: descendant `process.parent.entity_id`, persistence `registry.path`, DNS-event `dns.question.name`, and connection-event `destination.ip`. + - Hint: query process and registry events tied to the child ID; review DNS and connection events separately because `dns.question.name` and `destination.ip` live on different network event subtypes. + - Implication: escalate when descendants, registry changes, DNS lookups, or outbound connections show staging, persistence, command-and-control, or more lateral movement; absence of process-scoped DNS or connection telemetry narrows the case only when other evidence is clean. Missing network telemetry is unresolved, not benign. +- Do related target-host alerts change scope? + - Focus: related RDP, remote-service, credential, and execution alerts for the same `host.id`. $investigate_0 + - Hint: if recovered `source.ip` maps to an enrolled internal asset, follow up on outbound RDP to `destination.port` 3389 from a non-standard RDP client; missing source-host telemetry is unresolved, not benign. + - Implication: broaden scope when target-host alerts or caveated source-host follow-up show lateral movement beyond one recovered session; keep local only when the suspicious pattern stays confined to this target and the recovered source workflow is otherwise clean. +- Using RDP source, RunMRU command, child lineage and identity, user context, follow-on process/registry/network evidence, and related alerts, escalate RDP-driven command execution or "\\\\tsclient\\" payload launch without a coherent benign workflow; close only when all categories align to one exact recognized RDP workflow and no contradictory host or source evidence remains; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. ### False positive analysis -- Legitimate administrative tasks using RDP may trigger the rule if they involve command execution through cmd, powershell, or taskmgr. To manage this, create exceptions for known administrative IP addresses or user accounts frequently performing these tasks. -- Automated scripts or software updates that modify the RunMRU registry key with benign commands can be mistaken for SharpRDP behavior. Identify and exclude these processes or scripts from the detection rule. -- Remote management tools that use RDP and execute commands as part of their normal operation might be flagged. Whitelist these tools by their process names or specific command patterns to prevent false positives. -- Internal network scanning or monitoring tools that simulate RDP connections for security assessments could be misinterpreted. Exclude these tools by their source IP addresses or network behavior signatures. +- Helpdesk or administrator RDP support can trigger when an operator uses Win+R, Task Manager, or a mapped drive to launch a diagnostic or installer. Confirm `source.ip`, `host.id`, `user.id`, `registry.data.strings`, `process.parent.name`, and `process.executable`/`process.command_line` match one task with no suspicious descendant activity. Without telemetry proof, require operator or ticket confirmation; do not close from historical pattern alone. +- TSClient drive-redirection deployment can explain `\\\\tsclient\\` execution only when a known installer or utility launches with stable `process.hash.sha256` or `process.code_signature.subject_name`, matching `process.parent.name`, `source.ip`, and `host.id`. Do not close if registry, DNS, connection, or descendant evidence contradicts it. +- Before creating an exception, anchor on: `source.ip`, `host.id`, `user.id`, exact `registry.data.strings`, `process.parent.name`, and `process.executable` or `process.hash.sha256`. Avoid exceptions on `destination.port`, `process.name`, or RunMRU path alone. ### Response and remediation -- Immediately isolate the affected host from the network to prevent further lateral movement and unauthorized access. -- Terminate any suspicious processes identified in the alert, such as those initiated by cmd.exe, powershell.exe, or taskmgr.exe, to halt any ongoing malicious activity. -- Review and revert any unauthorized registry changes, particularly those related to the RunMRU registry path, to restore system integrity. -- Conduct a thorough examination of the affected host for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any found. -- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent further 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 RDP connections and registry changes to detect and respond to similar threats more effectively in the future.""" +- If confirmed benign, reverse any temporary containment and document the exact `source.ip`, `user.id`, `registry.data.strings`, `process.executable`, and `host.id` that established the confirmed workflow. Create an exception only after the exact activity is confirmed and the exception can be pinned to the narrow workflow pattern. +- If suspicious but unconfirmed, export the Timeline source events, capture the launched child process record and parent command line, save the RunMRU value data, and collect staged payloads, persistence key/value snapshots, DNS names, and connection destinations before containment or cleanup. +- If suspicious but unconfirmed, after preservation apply reversible containment: end the active RDP session, temporarily restrict new RDP connections from the recovered `source.ip`, or increase monitoring on the affected `host.id`. Escalate to host isolation only when follow-on activity shows broader abuse and the host role can tolerate isolation. +- If confirmed malicious, isolate the host when feasible, suspend or block the RDP access path or account that established the session, and terminate the launched child process plus suspicious descendants only after preserving the process and command evidence. +- Review other hosts and users tied to the same `source.ip`, `user.id`, or distinctive `process.command_line` pattern before deleting artifacts or resetting credentials so scoping completes before evidence is destroyed. +- Remove staged payloads, persistence changes, or follow-on tooling identified during the investigation, then reset or reissue credentials only when the process, user, and source evidence shows likely account misuse or credential exposure. +- Post-incident hardening: restrict RDP access to controlled jump hosts, limit drive redirection where it is not required, retain process plus registry plus network telemetry on RDP targets, and document any adjacent detection gaps 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 +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "host.os.type", +] + +[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" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/lateral_movement_unusual_dns_service_children.toml b/rules/windows/lateral_movement_unusual_dns_service_children.toml index e6c4ac6225e..099e4eb211f 100644 --- a/rules/windows/lateral_movement_unusual_dns_service_children.toml +++ b/rules/windows/lateral_movement_unusual_dns_service_children.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/16" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -32,42 +32,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Unusual Child Process of dns.exe" -note = """## Triage and analysis - -### Investigating Unusual Child Process of dns.exe - -SIGRed (CVE-2020-1350) is a wormable, critical vulnerability in the Windows DNS server that affects Windows Server versions 2003 to 2019 and can be triggered by a malicious DNS response. Because the service is running in elevated privileges (SYSTEM), an attacker that successfully exploits it is granted Domain Administrator rights. This can effectively compromise the entire corporate infrastructure. - -This rule looks for unusual children of the `dns.exe` process, which can indicate the exploitation of the SIGRed or a similar remote code execution vulnerability in the DNS server. - -#### Possible investigation steps - -- Investigate the process execution chain (parent process tree) for unknown processes. - - Any suspicious or abnormal child process spawned from dns.exe should be carefully reviewed and investigated. It's impossible to predict what an adversary may deploy as the follow-on process after the exploit, but built-in discovery/enumeration utilities should be top of mind (`whoami.exe`, `netstat.exe`, `systeminfo.exe`, `tasklist.exe`). - - Built-in Windows programs that contain capabilities used to download and execute additional payloads should also be considered. This is not an exhaustive list, but ideal candidates to start out would be: `mshta.exe`, `powershell.exe`, `regsvr32.exe`, `rundll32.exe`, `wscript.exe`, `wmic.exe`. - - If a denial-of-service (DoS) exploit is successful and DNS Server service crashes, be mindful of potential child processes related to `werfault.exe` occurring. -- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. -- Investigate other alerts associated with the host during the past 48 hours. -- Check whether the server is vulnerable to CVE-2020-1350. -- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. - -### False positive analysis - -- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. - -### Response and remediation - -- Initiate the incident response process based on the outcome of the triage. -- Isolate the involved hosts to prevent further post-compromise behavior. -- 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. -- Reimage the host operating system or restore the compromised server to a clean state. -- Install the latest patches on systems that run Microsoft DNS Server. -- Consider the implementation of a patch management system, such as the Windows Server Update Services (WSUS). -- 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. -- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. -- 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://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/", "https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/", @@ -100,14 +64,171 @@ process where host.os.type == "windows" and event.type == "start" and process.parent.name : "dns.exe" and not process.executable : ( "?:\\Windows\\System32\\conhost.exe", + "?:\\Windows\\System32\\dns.exe", /* Crowdstrike specific exclusion as it uses NT Object paths */ "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\dns.exe", "\\Device\\HarddiskVolume*\\Program Files\\ReasonLabs\\*" ) and not ?process.parent.executable : "?:\\Program Files\\ReasonLabs\\DNS\\ui\\DNS.exe" ''' +note = """## Triage and analysis + +### Investigating Unusual Child Process of dns.exe +#### Possible investigation steps + +- What did "dns.exe" launch, and does that define a crash path or live execution path? + - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`. + - Implication: escalate quickly for shells, script hosts, downloaders, service tools, or non-Windows paths spawned by "dns.exe"; a bounded "WerFault.exe" crash-reporting child points toward DNS service fault or SIGRed DoS, but still needs follow-on checks. +- Is the child binary a recognized system or DNS-support component, or a disguised payload? + - 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 unsigned, renamed, user-writable, newly seen, or PE-mismatched; a recognized Microsoft or vendor identity lowers only identity concern and does not clear unexpected execution from "dns.exe". +- What intent does the child command line express? + - Focus: `process.command_line`, `process.name`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate for discovery, script interpretation, download, service change, credential, or persistence behavior under the DNS service token; crash-reporting or bounded diagnostic arguments support fault handling. +- Do lineage and session context fit the Windows DNS service? + - Focus: `process.parent.command_line`, `process.parent.entity_id`, `process.Ext.session_info.logon_type`, and `user.id`. + - Implication: escalate when parent, service, or user context does not fit a stable Windows DNS service launch; expected service lineage supports but does not prove a benign child. +- Did the child produce follow-on execution or artifacts after the spawn? + - Focus: recovered file, registry, network, DNS, and descendant process events for `host.id` + child `process.entity_id`, or `host.id` + `process.pid` in a tight alert window. + - $investigate_0 + - $investigate_1 + - $investigate_2 + - Hint: prioritize descendant `process.command_line`, `file.path`, `registry.path`, and `destination.ip`. Missing network telemetry is unresolved, not benign. + - Implication: escalate when recovered events show descendants, payload staging, persistence changes, or outbound activity; no follow-on activity supports a crash-only hypothesis but cannot clear the alert alone. +- If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern? + - Focus: same-parent process starts and related alerts on `host.id`, prioritizing `process.parent.name` of "dns.exe", the same child `process.executable`, or the same `process.hash.sha256`. + - $investigate_3 + - $investigate_4 + - Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete. + - Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower. +- Escalate for live execution intent, suspicious identity or lineage, or recovered post-exploitation artifacts; close only when evidence tightly binds one crash-handling or recognized DNS-support workflow on this host; preserve artifacts and escalate when evidence is mixed or incomplete. + +### False positive analysis + +- Crash handling can legitimately produce "WerFault.exe" after a DNS service fault or SIGRed DoS attempt. Confirm that child identity, `process.command_line`, signer, and `host.id` form a crash-reporting pattern and recovered follow-on endpoint activity does not contradict it. Use incident records only as corroboration; telemetry-only closure requires a crash-reporter-only pattern on the same `host.id` without payload descendants or artifact creation. +- Named DNS/security tooling, such as ReasonLabs DNS components in the rule exclusions, explains the alert only when exact `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, and `host.id` match that product workflow. Treat generic vendor claims, partial matches, or a trusted signer without matching behavior as unresolved. +- Before creating an exception, anchor it on exact child path, signer or certificate thumbprint when available, command line, parent DNS service path, and affected `host.id`. Avoid exceptions on `process.parent.name` of "dns.exe", `process.name` alone, or the entire host. + +### Response and remediation + +- If suspicious but unconfirmed, preserve the child `process.entity_id`, `process.executable`, `process.hash.sha256`, signer details, `process.command_line`, `process.parent.command_line`, crash dumps, recovered endpoint events, and any collected payload artifacts before containment. +- Apply reversible containment before destructive action: remove the server from DNS rotation, restrict external resolver exposure, or heighten monitoring on the affected `host.id`. Move to host isolation only when follow-on execution or broader compromise evidence shows the server cannot serve safely. +- If confirmed benign, reverse temporary containment and record the exact child path, signer, command line, parent DNS service path, and `host.id` that proved the crash-handling or DNS-support workflow. Create an exception only after the same pattern is stable across prior alerts. +- If confirmed malicious, weigh DNS/domain-controller criticality, then isolate the server when feasible, terminate the suspicious child and descendants after evidence capture, and block confirmed malicious domains, IPs, hashes, or payload paths identified during triage. +- Scope other DNS servers and domain controllers for the same child path, hash, command line, signer, or "dns.exe" child-process pattern before deleting artifacts or rebuilding systems. +- Eradicate only payloads, persistence changes, or malicious child processes identified during the investigation, restore DNS service configuration from known-good state, and reset credentials only if evidence shows credential exposure or lateral movement from the server. +- Post-incident hardening: apply the Microsoft DNS security update for CVE-2020-1350, remove temporary SIGRed workarounds only after patching is verified, and retain process plus file, registry, and network telemetry for DNS servers where gaps limited triage. +""" + +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.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.command_line", +] + +[transform] + +[[transform.investigate]] +label = "File and registry events for the same 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" } + ], + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "registry", 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 same 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 = "Child process events from the dns.exe child" +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.entity_id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process events from the same dns.exe parent" +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 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/lateral_movement_via_startup_folder_rdp_smb.toml b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml index 3897f215a21..9855dfb844a 100644 --- a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml +++ b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/19" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/05/03" [rule] author = ["Elastic"] @@ -22,40 +22,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Lateral Movement via Startup Folder" -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 Lateral Movement via Startup Folder - -The Windows Startup folder is a mechanism that allows programs to run automatically upon user logon or system reboot. Adversaries exploit this by placing malicious files in the Startup folder of remote systems, often accessed via RDP or SMB, to ensure persistence and facilitate lateral movement. The detection rule identifies suspicious file activities in these folders, focusing on processes like mstsc.exe, which may indicate unauthorized access and file creation, signaling potential lateral movement attempts. - -### Possible investigation steps - -- Review the alert details to confirm the file creation or change event in the specified Startup folder paths, focusing on the file path patterns: "?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*" and "?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*". -- Check the process information associated with the event, particularly if the process name is "mstsc.exe" or if the process ID is 4, to determine if the activity is linked to remote access via RDP or SMB. -- Investigate the origin of the remote connection by examining network logs or RDP session logs to identify the source IP address and user account involved in the connection. -- Analyze the newly created or modified file in the Startup folder for malicious characteristics, such as unusual file names, unexpected file types, or known malware signatures, using antivirus or sandbox analysis tools. -- Review user account activity and permissions to determine if the account associated with the process has been compromised or is being misused for unauthorized access. -- Correlate this event with other security alerts or logs from data sources like Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related suspicious activities or patterns indicating lateral movement attempts. - -### False positive analysis - -- Legitimate software installations or updates may create files in the Startup folder, triggering the rule. Users can manage this by maintaining a list of known software that typically modifies the Startup folder and creating exceptions for these processes. -- System administrators using remote desktop tools like mstsc.exe for legitimate purposes might inadvertently trigger the rule. To handle this, users can exclude specific administrator accounts or known IP addresses from the detection rule. -- Automated scripts or system management tools that deploy updates or configurations across multiple systems might cause false positives. Users should identify these tools and add them to an exclusion list to prevent unnecessary alerts. -- Some enterprise applications may use the Startup folder for legitimate operations, especially during system boot or user logon. Users should document these applications and configure the rule to ignore file changes associated with them. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further lateral movement and potential spread of the threat. -- Terminate any suspicious processes, particularly those related to mstsc.exe or any unauthorized processes with PID 4, to halt any ongoing malicious activities. -- Remove any unauthorized files or scripts found in the Startup folder paths specified in the detection query to prevent them from executing on reboot or user logon. -- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. -- Review and reset credentials for any accounts that were accessed or potentially compromised during the incident 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 RDP and SMB activities, focusing on unusual file creation events in Startup folders, to improve detection of similar threats in the future.""" references = [ "https://www.mdsec.co.uk/2017/06/rdpinception/", "https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language", @@ -88,6 +54,136 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*") ''' +note = """## Triage and analysis + +### Investigating Lateral Movement via Startup Folder + +#### Possible investigation steps + +- What remote Startup-folder write did the alert capture? + - Focus: `file.path`, `file.extension`, `process.name`, `process.pid`, and `process.executable`. + - Implication: escalate when a remote writer plants a scriptable or executable item, especially in ProgramData Startup; lower suspicion only when the Startup item, writer, user, and host identify one bounded deployment or support component. +- What does the planted Startup item contain or point to? + - Focus: `file.name`, `file.size`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. + - Implication: escalate on shortcuts, scripts, archives, executables, renamed payloads, or content/header mismatches that could run at logon; lower suspicion when a bounded installer or support shortcut has content and provenance matching the same named tool. +- Does writer and user context identify the same support or deployment component? + - Focus: `user.id`, `user.domain`, `process.command_line`, and `process.parent.name`. + - Hint: for PID 4 SMB writes, recover surrounding SMB connection events to identify `source.ip`; for "mstsc.exe" writes, validate the RDP drive-redirection source through Terminal Services or RDP session logs when available. Missing SMB/RDP telemetry is unresolved, not benign. $investigate_0 + - Implication: escalate when the account, host, parent, or command line does not explain remote RDP/SMB Startup persistence; lower suspicion when command line, parent, and user-host pairing point to the same bounded component. +- Did the same Startup directory show staging, renames, or cleanup? + - Focus: file events in the same Startup directory on `host.id`, especially `file.directory`, `file.path`, `file.name`, and `file.Ext.original.path`. $investigate_1 + - Hint: use the directory view to separate one bounded write from broader Startup-folder staging. + - Implication: escalate on multiple writes, renames, mixed payload types, or cleanup artifacts; a single stable artifact narrows scope but does not clear the alert until execution and workflow fit are resolved. +- Has the Startup item executed on the host? + - Focus: process starts on `host.id` where `process.executable` matches the written `file.path`, then review `process.command_line` and `user.id`. $investigate_2 + - Hint: for shortcuts or scripts, exact path matching may miss the launched target; inspect the artifact and search same-host process starts for the referenced interpreter or target path. + - Implication: escalate when the item or referenced target executes, especially under a different user than the writer; no execution yet lowers immediacy, but clears only when writer, artifact, and directory evidence already prove a benign tool. +- If local evidence is suspicious or incomplete, are there related same-host alerts? + - Focus: related alerts for the same `host.id` involving remote services, credentials, execution, discovery, or persistence. $investigate_3 + - Implication: related alerts broaden the case from one Startup write to an intrusion path; no related alerts or an unavailable pivot narrows scope only and cannot close contradictory artifact, writer, or execution evidence. +- Escalate for remotely planted Startup persistence or later execution; close only when writer mechanism, path, artifact, directory, execution, and alert pivots bind to one bounded benign component without contradiction; preserve artifacts and escalate when evidence is mixed or incomplete. + +### False positive analysis + +- Software deployment, break-fix support, enterprise agents, or line-of-business applications can place bounded installers, shortcuts, support utilities, or stable per-user/all-users components in Startup through RDP or SMB. Confirm that `file.path`, `file.name`, `file.extension`, writer process or command line, `user.id`, `host.id`, directory view, and later direct or shortcut-target execution all identify the same bounded component, with no extra staging files or suspicious same-host alerts. Do not close on a role, ticket, or partial field match when current telemetry does not bind writer, artifact, and execution behavior together. +- Build exceptions from the minimum confirmed workflow pattern: the specific `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and bounded later-execution or quiet-directory evidence that distinguishes the benign case. Avoid exceptions on the Startup folder path alone, on "mstsc.exe" alone, or on PID 4 alone. + +### Response and remediation + +- If confirmed benign, reverse temporary containment and document the exact `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and quiet-directory or later-execution evidence that established the bounded workflow. Create an exception only when that same evidence set distinguishes the benign workflow from remote Startup-folder abuse. +- If suspicious but unconfirmed, preserve a copy of the written Startup item, the Startup directory listing, and case exports for the relevant file events, writer process metadata, later execution records, user-host identifiers, and related-alert context before containment. +- Apply reversible containment before destructive action: quarantine the Startup item after preserving it, restrict further RDP or SMB administrative access to the host, or heighten monitoring on the affected `host.id`. Isolate the host only when later execution or related alerts show broader compromise and the host role can tolerate disruption. +- If confirmed malicious, record any later-executed process identifiers and command lines, preserve the Startup item and same-directory artifacts, then isolate the host when feasible, terminate malicious execution, and remove the Startup item, shortcuts, scripts, and staging artifacts identified during the investigation. +- Before deleting artifacts or resetting credentials, scope other hosts and accounts for the same `file.name`, `file.path`, writer `process.command_line`, or later `process.executable` pattern. Reset or reissue credentials only when related alerts or later execution indicate likely account misuse. +- Post-incident hardening: restrict unnecessary RDP drive redirection, tighten SMB administrative write access, monitor Startup folder changes on remote-access targets, and retain the file/process telemetry needed to distinguish repeat deployment workflows from repeat abuse.""" + +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) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.type", + "host.id", + "user.id", + "file.path", + "file.directory", + "file.name", + "file.extension", + "process.entity_id", + "process.pid", + "process.name", + "process.executable", + "process.command_line", + "process.parent.name", +] + +[transform] + +[[transform.investigate]] +label = "SMB connection events on the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }, + { excluded = false, field = "event.action", queryType = "phrase", value = "connection_accepted", valueType = "string" }, + { excluded = false, field = "destination.port", queryType = "phrase", value = "445", valueType = "string" }, + { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "File events in the same Startup directory" +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 = "file.directory", queryType = "phrase", value = "{{file.directory}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process events where the Startup item later executed" +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.executable", queryType = "phrase", value = "{{file.path}}", valueType = "string" } + ] +] +relativeFrom = "now-24h/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" From 03c445e9d9de72232ea65728af5cc3e9684d4f4b Mon Sep 17 00:00:00 2001 From: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> Date: Sun, 3 May 2026 17:56:41 -0300 Subject: [PATCH 2/4] Apply suggestion from @w0rk3r --- ...lateral_movement_credential_access_kerberos_correlation.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml b/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml index 2c0733c0568..7b0bd64d4dc 100644 --- a/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml +++ b/rules/windows/lateral_movement_credential_access_kerberos_correlation.toml @@ -34,7 +34,7 @@ tags = [ "Domain: Identity", "OS: Windows", "Use Case: Threat Detection", - "Tactic: Credential Access", + "Tactic: Lateral Movement", "Use Case: Active Directory Monitoring", "Data Source: Active Directory", "Data Source: Elastic Defend", From 9af17cc1dd59d405f4f8304a35df67628f1efb78 Mon Sep 17 00:00:00 2001 From: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> Date: Mon, 4 May 2026 11:41:01 -0300 Subject: [PATCH 3/4] ++ --- rules/macos/privilege_escalation_user_added_to_admin_group.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/macos/privilege_escalation_user_added_to_admin_group.toml b/rules/macos/privilege_escalation_user_added_to_admin_group.toml index 70e4595fc79..a010540314d 100644 --- a/rules/macos/privilege_escalation_user_added_to_admin_group.toml +++ b/rules/macos/privilege_escalation_user_added_to_admin_group.toml @@ -13,7 +13,7 @@ providers = [ ] ] relativeFrom = "now" -relativeTo = "now+30m" +relativeTo = "now" [[transform.investigate]] label = "Show events having the same reponsible process" From 926a12e3dcb7d3716e60f3967e4f1d5955536d6a Mon Sep 17 00:00:00 2001 From: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> Date: Mon, 4 May 2026 11:41:46 -0300 Subject: [PATCH 4/4] Revert "++" This reverts commit 9af17cc1dd59d405f4f8304a35df67628f1efb78. --- rules/macos/privilege_escalation_user_added_to_admin_group.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rules/macos/privilege_escalation_user_added_to_admin_group.toml b/rules/macos/privilege_escalation_user_added_to_admin_group.toml index a010540314d..70e4595fc79 100644 --- a/rules/macos/privilege_escalation_user_added_to_admin_group.toml +++ b/rules/macos/privilege_escalation_user_added_to_admin_group.toml @@ -13,7 +13,7 @@ providers = [ ] ] relativeFrom = "now" -relativeTo = "now" +relativeTo = "now+30m" [[transform.investigate]] label = "Show events having the same reponsible process"