diff --git a/rules/windows/defense_evasion_rundll32_no_arguments.toml b/rules/windows/defense_evasion_rundll32_no_arguments.toml index 42ea3a75f..fadb86ccf 100644 --- a/rules/windows/defense_evasion_rundll32_no_arguments.toml +++ b/rules/windows/defense_evasion_rundll32_no_arguments.toml @@ -2,39 +2,13 @@ creation_date = "2020/09/02" integration = ["endpoint", "windows", "crowdstrike"] maturity = "production" -updated_date = "2025/08/26" - -[transform] -[[transform.osquery]] -label = "Osquery - Retrieve DNS Cache" -query = "SELECT * FROM dns_cache" - -[[transform.osquery]] -label = "Osquery - Retrieve All Services" -query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services" - -[[transform.osquery]] -label = "Osquery - Retrieve Services Running on User Accounts" -query = """ -SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE -NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR -user_account == null) -""" - -[[transform.osquery]] -label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link" -query = """ -SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid, -services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path = -authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted' -""" - +updated_date = "2026/04/30" [rule] author = ["Elastic"] description = """ -Identifies child processes of unusual instances of RunDLL32 where the command line parameters were suspicious. Misuse of -RunDLL32 could indicate malicious activity. +Identifies a no-argument or malformed Rundll32 launch followed by child process execution. This unusual sequence can +indicate Rundll32 abuse for proxy execution or payload handoff. """ from = "now-60m" index = ["logs-endpoint.events.process-*", "winlogbeat-*", "logs-windows.sysmon_operational-*", "logs-crowdstrike.fdr*"] @@ -42,62 +16,6 @@ interval = "30m" language = "eql" license = "Elastic License v2" name = "Unusual Child Processes of RunDLL32" -note = """## Triage and analysis - -### Investigating Unusual Child Processes of RunDLL32 - -By examining the specific traits of Windows binaries -- such as process trees, command lines, network connections, registry modifications, and so on -- it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading and deserve further investigation. - -RunDLL32 is a legitimate Windows utility used to load and execute functions within dynamic-link libraries (DLLs). However, adversaries may abuse RunDLL32 to execute malicious code, bypassing security measures and evading detection. This rule identifies potential abuse by looking for an unusual process creation with no arguments followed by the creation of a child process. - -> **Note**: -> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. - -### 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. -- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. -- Investigate the behavior of child processes, such as network connections, registry or file modifications, and any spawned processes. -- Inspect the host for suspicious or abnormal behavior in the alert timeframe. -- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. -- Examine the host for derived artifacts that indicate suspicious activities: - - Analyze the process executable using a private sandboxed analysis system. - - Observe and collect information about the following activities in both the sandbox and the subject host: - - Attempts to contact external domains and addresses. - - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. - - Examine the DNS cache for suspicious or anomalous entries. - - $osquery_0 - - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. - - Examine the host services for suspicious or anomalous entries. - - $osquery_1 - - $osquery_2 - - $osquery_3 - - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. - -### False positive analysis - -- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. - -### Related Rules - -- Unusual Network Connection via RunDLL32 - 52aaab7b-b51c-441a-89ce-4387b3aea886 - -### 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. -- 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. -- 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. -- 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). -""" risk_score = 73 rule_id = "f036953a-4615-4707-a1ca-dc53bf69dcd5" severity = "high" @@ -125,6 +43,120 @@ sequence with maxspan=1h ] by process.parent.entity_id ''' +note = """## Triage and analysis + +### Investigating Unusual Child Processes of RunDLL32 + +#### Possible investigation steps + +- Which source events define the no-argument "rundll32.exe" parent and the spawned child? + - Why: this asymmetric sequence has no single safe process identity; recover source events before interpreting grouped meaning or pivoting. + - Focus: Timeline source events for the sequence, recording parent and child `process.entity_id`, child `process.parent.entity_id`, `host.id`, and `user.id`. + - Implication: escalate when recovered events show one no-argument "rundll32.exe" handing off to an unexpected child; lower suspicion only when recovery shows a parser/quoting artifact and the child is signed, stable, and path-consistent for the same user and host. + +- Does the recovered "rundll32.exe" event truly lack a DLL, export, or Control_RunDLL-style target? + - Why: normal Rundll32 proxy execution names a DLL/export, ordinal, script target, or Control Panel handler; this rule covers empty or malformed invocation that still spawns a child. + - Focus: parent `process.command_line`, `process.args_count`, `process.executable`, and `process.pe.original_file_name`. + - Implication: escalate when `process.args_count` and `process.command_line` confirm only the image path or a malformed target; lower suspicion only when source recovery proves a quoting/parser artifact and the exact parent-child command pattern is stable. + +- What did the recovered child process do, and does its identity fit that parent chain? + - Focus: child `process.executable`, `process.command_line`, `process.pe.original_file_name`, code signature, and descendant process starts. + - Hint: after recovering the child `process.entity_id` from source events, pivot manually on that ID for descendants; the final sequence alert may not preserve a child-specific entity ID. + - Implication: escalate when the child is a shell, script host, network utility, unsigned payload, user-writable binary, or mismatched original file name; lower suspicion when the child is signed, path-consistent, and matches the exact recovered wrapper pattern. Identity alone does not clear the behavior. + +- What launched "rundll32.exe", and does the user-host context explain the handoff? + - Focus: parent `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, `user.name`, and `user.domain`. + - Implication: escalate when the launcher is Office, a browser, archive utility, script host, temp-path executable, or a lineage unusual for that `user.id` and `host.id`; lower suspicion only when the same parent executable, command line, child path, signer, and host/user scope recur without artifact or network contradictions. + +- If library telemetry is available after source-event recovery, did the recovered process load a hidden or recently staged DLL? + - Focus: library events for recovered `host.id` and each `process.entity_id`, checking `dll.path`, `dll.hash.sha256`, signer, trust, and `dll.Ext.relative_file_creation_time`. + - Hint: query library events separately for the recovered parent and child IDs; missing library telemetry limits DLL corroboration but does not clear the process evidence. + - Implication: escalate when a DLL loads from a user-writable, unrelated, unsigned, or recently created path; lower suspicion when library identity, signer, and path relationship fit the recovered parent-child workflow. + +- If file or network telemetry is available after source-event recovery, did the chain stage payloads or reach suspicious infrastructure? + - Focus: file and network events for recovered `host.id` and each `process.entity_id`, checking `file.path`, `file.Ext.windows.zone_identifier`, DNS `dns.question.name`, connection `destination.ip`, and `destination.port`. + - Hint: separate DNS lookup events from connection events before interpreting them. Missing network telemetry is unresolved, not benign. + - Implication: escalate when the chain writes executable or scriptable artifacts, carries internet provenance, or connects to rare external infrastructure; lower suspicion when optional activity stays inside the recovered parent-child workflow. + +- If local evidence remains suspicious or unresolved, do related alerts show the same user, host, or child-process pattern? + - Focus: recent alerts for `user.id`, `host.id`, child `process.executable`, child `process.hash.sha256`, or a distinctive `process.command_line` fragment. + - Hint: use only after source recovery keeps the case suspicious or unresolved. + - $investigate_0 + - $investigate_1 + - Implication: broaden response when the same user or host repeats Rundll32 proxy-execution, child payload, or related defense-evasion alerts; keep scope local when the suspicious pattern remains isolated and the recovered workflow is tightly explained. + +- Escalate when source recovery, invocation shape, child identity, launcher lineage, DLL/file/network evidence, or recurrence shows "rundll32.exe" proxying unauthorized child execution or payload delivery; close only when recovered process evidence and corroborators tightly bind one exact signed workflow on this host; if evidence is mixed or incomplete, preserve artifacts and escalate. + +### False positive analysis + +- No-argument "rundll32.exe" spawning a child is an operational anti-pattern. Close as benign only when source recovery proves a parser/quoting artifact or authorized reproduction, the child is signed and path-consistent, and no DLL, file, or network evidence contradicts that workflow. Align available inventory, vendor, or test records; otherwise treat prior recurrence for the same `host.id` and stable parent-child anchors as supporting evidence only. +- Build exceptions from the minimum confirmed workflow: parent `process.parent.executable`, child `process.executable`, stable `process.code_signature.subject_name`, command-line shape, host/user scope, and recovered artifact anchors when present. Do not except a first occurrence, unresolved source recovery, missing contradictory-telemetry checks, or "rundll32.exe" alone. + +### Response and remediation + +- If confirmed benign: + - Reverse temporary containment and document the recovered parent-child workflow, source-event IDs, signer, command-line pattern, and corroborating inventory, vendor record, or recurrence that established it. +- If suspicious but unconfirmed: + - Preserve a case export of Timeline source events, recovered process identifiers and command lines, child binary hash, and any recovered DLL, file, or network artifacts before cleanup. + - Apply reversible containment such as temporary network restrictions or heightened monitoring on the affected `host.id` and `user.id`; use host isolation only when child-process or artifact evidence indicates active payload execution and the host role can tolerate isolation. +- If confirmed malicious: + - Preserve the recovered source events, process IDs, command lines, child hashes, DLL or file artifacts, and network indicators, then isolate the host or restrict the account based on the child execution, launcher lineage, artifact, or network evidence. + - Block confirmed malicious child hashes, DLL hashes, staged payload paths, domains, and destination IPs, then review other hosts and users for the same parent-child or artifact pattern before eradication. + - Remove only the malicious DLLs, scripts, or child payloads identified during investigation, remediate the parent launcher or delivery path that invoked "rundll32.exe", and investigate credential exposure if follow-on behavior suggests collection or lateral movement. +- Post-incident hardening: + - Keep process telemetry for "rundll32.exe" and child processes enabled, and enable file, network, or library telemetry where missing evidence limited the case. + - Restrict unusual "rundll32.exe" child-process patterns where the business does not require them, and record any adjacent DLL/export, ordinal, Control Panel, or script-target variants observed in the case. +""" + +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) +- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "user.id", + "event.category", + "event.type", +] + +[transform] + +[[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" @@ -137,10 +169,7 @@ id = "T1218.011" name = "Rundll32" reference = "https://attack.mitre.org/techniques/T1218/011/" - - [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - diff --git a/rules/windows/defense_evasion_script_via_html_app.toml b/rules/windows/defense_evasion_script_via_html_app.toml index eb937d05a..06f0dc1d6 100644 --- a/rules/windows/defense_evasion_script_via_html_app.toml +++ b/rules/windows/defense_evasion_script_via_html_app.toml @@ -2,8 +2,7 @@ creation_date = "2020/09/09" integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" - +updated_date = "2026/04/30" [rule] author = ["Elastic"] @@ -26,39 +25,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Script Execution via Microsoft HTML Application" -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 Script Execution via Microsoft HTML Application - -Microsoft HTML Applications (HTA) allow scripts to run in a trusted environment, often using utilities like `rundll32.exe` or `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns, such as unusual command lines or execution from common download locations, to flag potential abuse. - -### Possible investigation steps - -- Review the process command line details to identify any suspicious patterns or indicators of malicious activity, such as the presence of script execution commands like "eval", "GetObject", or "WScript.Shell". -- Check the parent process executable path to determine if the process was spawned by a known legitimate application or if it deviates from expected behavior, especially if it is not from the specified exceptions like Citrix, Microsoft Office, or Quokka.Works GTInstaller. -- Investigate the origin of the HTA file, particularly if it was executed from common download locations like the Downloads folder or temporary archive extraction paths, to assess if it was downloaded from the internet or extracted from an archive. -- Analyze the process arguments and count to identify any unusual or unexpected parameters that could indicate malicious intent, especially if the process name is "mshta.exe" and the command line does not include typical HTA or HTM file references. -- Correlate the event with other security logs and alerts from data sources like Sysmon, SentinelOne, or Microsoft Defender XDR to gather additional context and determine if this activity is part of a broader attack pattern. - -### False positive analysis - -- Execution of legitimate scripts by enterprise applications like Citrix, Microsoft Office, or Quokka.Works GTInstaller can trigger false positives. Users can mitigate this by adding these applications to the exclusion list in the detection rule. -- Scripts executed by mshta.exe that do not involve malicious intent, such as internal web applications or administrative scripts, may be flagged. Users should review these scripts and, if deemed safe, exclude them based on specific command line patterns or parent processes. -- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users can create exceptions for these sources by specifying trusted download paths or file hashes. -- Temporary files created by legitimate software installations or updates in user temp directories can be misinterpreted as malicious. Users should monitor these activities and exclude known safe processes or directories from the detection rule. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further spread of the malicious script or unauthorized access. -- Terminate any suspicious processes identified by the detection rule, specifically those involving `rundll32.exe` or `mshta.exe` with unusual command lines. -- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts. -- Review and analyze the command lines and scripts executed to understand the scope and intent of the attack, and identify any additional compromised systems. -- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated. -- Implement network segmentation to limit the ability of similar threats to propagate across 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 systems or data have been compromised.""" risk_score = 73 rule_id = "181f6b23-3799-445e-9589-0018328a9e46" severity = "high" @@ -118,6 +84,166 @@ process where host.os.type == "windows" and event.type == "start" and ) ''' +note = """## Triage and analysis + +### Investigating Script Execution via Microsoft HTML Application + +#### Possible investigation steps + +- Which HTML-application proxy path did the alert capture? + - Why: proxy path determines the containment target. + - Focus: `process.name`, `process.command_line`, and `process.args_count`: ".hta", ".htm", "vbscript:", "javascript:", "GetObject("script:")", "mshtml,RunHTMLApplication", "mshtml,#135", "http", "WScript.Shell", "StrReverse", "window.close(", or "Chr(". + - Implication: escalate on inline script, remote retrieval, obfuscation, "RunHTMLApplication", archive/temp execution, or non-HTA "mshta.exe"; lower concern only for one stable internal HTA/HTM path with no inline script, remote locator, or obfuscation. + +- Is the proxy binary a genuine Microsoft LOLBin or a masqueraded executable? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when "mshta.exe" or "rundll32.exe" runs from a user-writable or non-Windows path, has a mismatched original filename, or lacks a trusted Microsoft signature; canonical Microsoft identity lowers masquerade risk but does not clear suspicious arguments. + +- What parent and user context explain the launch? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, and `host.id`. + - Implication: escalate when the parent is Office, a browser, archive utility, script host, user-writable executable, or a chain outside the rule's excluded parents; lower concern when the same parent, user cohort, and host cohort repeatedly launch the same recognized HTA workflow. + +- What referenced HTA, scriptlet, URL, or path can be recovered? + - Focus: `process.command_line`, `process.args`, and `process.working_directory`: literal HTA/HTM path, scriptlet URL, remote locator, archive/temp marker, or relative path; recover same-process file and network/DNS events when artifact or remote locator evidence exists. $investigate_0 $investigate_1 + - Implication: escalate when the locator points to Downloads, Temp, archive extraction, external URLs, scriptlet retrieval, alternate data stream-like syntax, or a single-user path; lower concern only for the same stable internal path from the same recognized workflow. Missing file, network, or DNS telemetry is unresolved, not benign. + +- Did the proxy spawn follow-on code or payload execution? + - Focus: child starts on `host.id` where `process.parent.entity_id` equals alert `process.entity_id`; inspect child `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_2 + - Hint: if `process.entity_id` is absent, use `host.id` + `process.pid` + the tight alert window as a weaker fallback; treat PID reuse as unresolved ambiguity. + - Implication: escalate when the proxy spawns shells, PowerShell, script hosts, "regsvr32.exe", another "rundll32.exe", unsigned payloads, or tooling unrelated to the parent workflow; lower concern when child activity stays within the same recognized signed application flow. + +- If evidence remains suspicious or incomplete, is it isolated? + - Focus: `user.id`, `host.id`, stable `process.command_line` fragments, child `process.executable`, and child `process.command_line` recovered above. $investigate_3 $investigate_4 + - Implication: broaden scope when the same user, host, command fragment, or child process repeats across alerts or other hosts; keep scope local only when isolated and aligned with one recognized workflow. + +- Escalate on proxy script execution, masquerade, suspicious lineage, external/temporary sourcing, follow-on payloads, or recurrence; close only when command intent, binary identity, lineage, locator, child behavior, and scope align with one recognized internal HTA/HTM workflow; preserve artifacts and escalate when evidence is mixed or incomplete. + +### False positive analysis + +- Legacy internal HTA applications or support tools may use "mshta.exe" when identity, intent, and context align: canonical Microsoft `process.executable`, stable `process.parent.executable`, repeated `process.command_line` for one internal HTA/HTM path, consistent `user.id`/`host.id` cohort, and no child branching into shells or script hosts. If inventory, owner, or change records exist, require alignment with this telemetry; otherwise require recurrence of the same stable process pattern across prior alerts from this rule for the same cohort. +- Vendor installers or deployment tools can trigger archive/temp HTA patterns when parent executable, signer context, command line, and bounded child chain match the same recognized package workflow. Do not close on parent name alone; contradictory locator, child process, user/host scope, or signer evidence stays suspicious. Exceptions should use the minimum confirmed pattern, such as `process.parent.executable` + stable `process.command_line` fragment + `host.id` or `user.id`, not `process.name`. + +### Response and remediation + +- If confirmed benign: + - Reverse temporary containment and record the parent workflow, `process.command_line`, extracted locator/path, `user.id`, `host.id`, and recurrence or business records that confirmed the recognized application path. Build exceptions only from the minimum stable workflow pattern, not from "mshta.exe" or "rundll32.exe" alone. +- If suspicious but unconfirmed: + - Preserve the alert event export, process tree, `process.entity_id`, `process.pid`, `process.command_line`, `process.args`, parent lineage, user/host context, recovered child process events, and literal URLs or paths extracted from the command line before cleanup. + - Apply reversible containment tied to the findings, such as temporary destination restrictions for remote locators, child-process blocking, or heightened monitoring on the affected `host.id` and `user.id`; use host isolation only when child-process or staging evidence indicates active payload execution and host criticality permits it. +- If confirmed malicious: + - Isolate the host or contain the affected identity after preserving the process and child-process evidence that established malicious execution. Terminate the proxy and spawned payload processes only after recording their identifiers and command lines. + - Block confirmed malicious command-line locators, child binaries, domains, and addresses identified during triage, then review other hosts and users for the same command fragment or child-process pattern before eradication. + - Remove the malicious HTA, scriptlet, archive-extracted payload, or staged child artifacts identified during investigation; remediate the parent document, browser, archive, or script delivery path; investigate credential exposure if follow-on behavior suggests collection or lateral movement. +- Post-incident hardening: + - Restrict or monitor "mshta.exe" and unusual "rundll32.exe" script-execution paths where the business does not require them. + - Retain process telemetry for these binaries and record any missing artifact, library, or destination visibility that limited the case so future triage can account for the gap. +""" + +setup = """## Setup + +This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + +### Additional data sources + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- [CrowdStrike](https://ela.st/crowdstrike-integration) +- [Microsoft Defender XDR](https://ela.st/m365-defender) +- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel) +- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup) +- [Windows Process Creation Logs](https://ela.st/audit-process-creation) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "user.name", + "user.id", + "process.entity_id", + "process.code_signature.subject_name", + "process.executable", + "process.command_line", + "process.args", + "process.pe.original_file_name", + "process.code_signature.trusted", + "process.parent.entity_id", + "process.parent.executable", + "process.parent.command_line", +] + +[transform] + +[[transform.investigate]] +label = "File events for the same proxy instance" +description = "" +providers = [ + [ + { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Network and DNS events for the same proxy instance" +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 = "dns", 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 for the same proxy instance" +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 = "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/defense_evasion_suspicious_managedcode_host_process.toml b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml index 6f467ccb2..1eba2eb24 100644 --- a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml +++ b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/21" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/04/30" [rule] author = ["Elastic"] @@ -23,41 +23,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Suspicious Managed Code Hosting Process" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Suspicious Managed Code Hosting Process - -Managed code hosting processes like wscript.exe, cscript.exe, and others are integral to executing scripts and managing code in Windows environments. Adversaries exploit these processes for code injection or executing malicious scripts, often evading detection. The detection rule identifies anomalies by monitoring specific process logs, flagging high-risk activities that deviate from normal operations, thus alerting analysts to potential threats. - -### Possible investigation steps - -- Review the process logs for the specific file names flagged in the alert, such as wscript.exe.log or cscript.exe.log, to identify any unusual or unauthorized script executions. -- Correlate the suspicious process activity with user account activity to determine if the actions were performed by a legitimate user or potentially compromised account. -- Examine the parent process of the flagged managed code hosting process to identify if it was spawned by a legitimate application or a known malicious process. -- Check for any recent changes or modifications to the scripts or executables associated with the flagged process to identify potential tampering or unauthorized updates. -- Investigate network connections initiated by the suspicious process to detect any communication with known malicious IP addresses or domains. -- Utilize threat intelligence sources to cross-reference any identified indicators of compromise (IOCs) such as file hashes or IP addresses associated with the suspicious process. - -### False positive analysis - -- Legitimate administrative scripts may trigger alerts when executed by IT personnel using wscript.exe or cscript.exe. To manage this, create exceptions for known scripts and trusted user accounts. -- Automated system maintenance tasks using mshta.exe or wmic.exe can be flagged as suspicious. Identify and whitelist these tasks if they are part of regular system operations. -- Software updates or installations might use svchost.exe or dllhost.exe, leading to false positives. Monitor and document these activities, then exclude them from alerts if they are verified as safe. -- Custom applications that rely on cmstp.exe or regsvr32.exe for legitimate purposes can be mistaken for threats. Validate these applications and add them to an exception list to prevent unnecessary alerts. -- Regularly review and update the exception list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. -- Terminate the suspicious process identified in the alert, such as wscript.exe, cscript.exe, or any other flagged process, to stop any ongoing malicious activity. -- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or scripts. -- Review and restore any system or application configurations that may have been altered by the malicious process to ensure system integrity. -- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope and impact of the incident. -- Notify the security operations center (SOC) or incident response team to escalate the incident for further investigation and to determine if additional systems are affected. -- Implement additional monitoring and detection rules to enhance visibility and prevent similar threats in the future, focusing on the specific processes and behaviors identified in the alert.""" references = [ "http://web.archive.org/web/20230329154538/https://blog.menasec.net/2019/07/interesting-difr-traces-of-net-clr.html", ] @@ -92,6 +57,187 @@ file where host.os.type == "windows" and event.type != "deletion" and "regsvr32.exe.log") ''' +note = """## Triage and analysis + +### Investigating Suspicious Managed Code Hosting Process + +#### Possible investigation steps + +- What CLR UsageLog behavior did the alert preserve? + - Focus: `file.path`, `file.name`, `event.type`, and acting `process.name` / `process.executable`. + - Implication: escalate when the UsageLog host has no stable process/user pattern; lower suspicion only as an initial read when the same path and process recur for the same product, deployment, login-script, COM, or service-host context. +- Is the managed host the genuine Windows binary rather than a lookalike? + - Focus: same-process start evidence for `host.id` and `process.entity_id`: `process.executable`, hash, original file name, signer, and trust. $investigate_0 + - Hint: if a source lacks `process.entity_id`, fall back to `process.pid` plus `host.id` in a tight alert-time window to avoid PID reuse. $investigate_3 + - Implication: escalate when the host binary runs from a user-writable path, has a mismatched original file name, or has an unexpected signer; lower suspicion only when identity, signer, path, and the UsageLog host name all point to the same genuine Windows host. +- Does the launch chain explain why this host loaded managed code? + - Focus: `process.command_line`, parent executable/command line, `user.id`, and session context. + - Implication: escalate when Office, browsers, archive tools, remote sessions, or user-writable scripts drive mshta, wscript, cscript, wmic, regsvr32, or cmstp; lower suspicion when the same command line, parent, user, and session match a recognized installer, scheduled task, management agent, COM component, or login script. +- Does this UsageLog path recur with the same process and user pattern? + - Focus: historical file and process events for the same `host.id`, comparing `file.path`, `event.type`, process/parent executable, and `user.id`. $investigate_4 + - Implication: escalate when a first create, new `process.executable`, new parent, new user, or unusual update appears for a process that normally should not host managed code; lower suspicion when prior events show the same path, process identity, parent, and user with no follow-on artifacts. +- Does the UsageLog artifact or same-process activity expose payload staging? + - Why: HTA/JS managed-code hosting and repeat UsageLog updates can hide intent in process text, so preserve the UsageLog while using same-process file/process telemetry for the decision. + - Focus: preserve `file.path`, then query file and process events for the same `host.id` and `process.entity_id`, comparing name, extension, size, and later `process.executable` reuse of written paths. $investigate_5 $investigate_6 + - Hint: if only `process.pid` is available, keep the file/process correlation tightly scoped to the alert time and host; empty or multiple PID matches are unresolved, not benign. + - Implication: escalate when the process writes scriptable or executable content to user-writable paths, creates unusual payload-sized files, or later executes a written artifact; lower suspicion when artifacts stay inside the same recognized product or deployment path with no follow-on execution. +- If local evidence remains suspicious or unresolved, does the same user or host show related managed-host abuse? + - Focus: related alerts for `user.id` and `host.id`: repeated UsageLog paths, script-host execution, payload staging, injection, or persistence. + - Hint: same-user alert view: $investigate_1 + - Hint: same-host alert view: $investigate_2 + - Implication: broaden scope only when UsageLog, identity, launch, recurrence, or artifact evidence remains suspicious or incomplete; keep local when the alert is isolated and all supported evidence resolves to one recognized workflow. +- Escalate for unauthorized managed-code execution through a script host or LOLBin; close only when UsageLog, identity, launch, recurrence, artifact, and related-alert evidence bind to one recognized workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete. + +### False positive analysis + +- Packaging, deployment, login-script, management-agent, product, COM, and service-hosted workflows can legitimately update CLR UsageLogs for wscript.exe, cscript.exe, mshta.exe, wmic.exe, cmstp.exe, svchost.exe, dllhost.exe, or regsvr32.exe. Confirm `file.path`, process identity, signer or hash history, parent or service/COM launch context, user/session context, artifact behavior, and same-process file/process activity all point to one workflow. If inventories are unavailable, require stable UsageLog path, parent chain, process identity, and user-host pairing across prior alerts before closing as benign. +- Build exceptions only from the minimum confirmed workflow pattern: `file.path`, `process.executable`, `process.parent.executable`, stable signer or hash, and the relevant `host.id` or `user.id` scope. Avoid exceptions on `file.name`, process name, or host name alone. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and document the UsageLog path, process identity, launch chain, user/session context, recurrence pattern, and artifact evidence that proved the workflow. Create an exception only after the same pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve the UsageLog artifact, process start event, command line, parent chain, same-process file/process timeline, written artifacts, related alerts, and case notes before containment or cleanup. +- If suspicious but unconfirmed, apply reversible containment tied to the findings, such as heightened monitoring or temporary isolation of the affected `host.id` when process/file evidence suggests payload execution. Avoid process termination or file deletion until the artifact set is preserved. +- If confirmed malicious, isolate the endpoint when process identity, launch context, artifact behavior, or related alerts establish unauthorized managed-code execution. Before suspending or terminating the host process, record the recovered `process.entity_id`, command line, parent chain, UsageLog path, and staged files. +- Scope related hosts and users for the same UsageLog path, parent process, process identity, and staged artifacts before deleting files or terminating additional processes. +- Remove only malicious scripts, HTA/JS payloads, assemblies, staged binaries, or persistence artifacts identified during the investigation, then remediate the delivery path or launcher that caused the managed host to load CLR. +- Post-incident hardening: restrict script-host and LOLBin execution through application control where feasible, keep endpoint file/process telemetry for CLR UsageLog triage, and document the confirmed benign workflow or malicious artifact set for future analysts.""" + +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 11 - File Create](https://ela.st/sysmon-event-11-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.type", + "host.name", + "host.id", + "user.id", + "process.entity_id", + "process.pid", + "process.executable", + "process.command_line", + "process.parent.executable", + "process.parent.command_line", + "process.pe.original_file_name", + "process.code_signature.subject_name", + "process.code_signature.trusted", + "file.path", +] + +[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" } + ] +] +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" + +[[transform.investigate]] +label = "Process events for the same PID" +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.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "File events for the same UsageLog path" +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.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" } + ] +] +relativeFrom = "now-7d/d" +relativeTo = "now" + +[[transform.investigate]] +label = "File events for the same process or PID" +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 = "Child process events for the managed 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.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.parent.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/defense_evasion_suspicious_process_access_direct_syscall.toml b/rules/windows/defense_evasion_suspicious_process_access_direct_syscall.toml index 319f6d4e7..3bfde4639 100644 --- a/rules/windows/defense_evasion_suspicious_process_access_direct_syscall.toml +++ b/rules/windows/defense_evasion_suspicious_process_access_direct_syscall.toml @@ -2,33 +2,7 @@ creation_date = "2021/10/11" integration = ["windows"] maturity = "production" -updated_date = "2026/03/19" - -[transform] -[[transform.osquery]] -label = "Osquery - Retrieve DNS Cache" -query = "SELECT * FROM dns_cache" - -[[transform.osquery]] -label = "Osquery - Retrieve All Services" -query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services" - -[[transform.osquery]] -label = "Osquery - Retrieve Services Running on User Accounts" -query = """ -SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE -NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR -user_account == null) -""" - -[[transform.osquery]] -label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link" -query = """ -SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid, -services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path = -authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted' -""" - +updated_date = "2026/04/30" [rule] author = ["Elastic"] @@ -42,60 +16,6 @@ index = ["winlogbeat-*", "logs-windows.sysmon_operational-*"] language = "eql" license = "Elastic License v2" name = "Suspicious Process Access via Direct System Call" -note = """## Triage and analysis - -### Investigating Suspicious Process Access via Direct System Call - -Endpoint security solutions usually hook userland Windows APIs in order to decide if the code that is being executed is malicious or not. It's possible to bypass hooked functions by writing malicious functions that call syscalls directly. - -More context and technical details can be found in this [research blog](https://outflank.nl/blog/2019/06/19/red-team-tactics-combining-direct-system-calls-and-srdi-to-bypass-av-edr/). - -This rule identifies suspicious process access events from an unknown memory region. Attackers can use direct system calls to bypass security solutions that rely on hooks. - -> **Note**: -> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. - -#### 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. -- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. -- Examine the host for derived artifacts that indicate suspicious activities: - - Analyze the process executable using a private sandboxed analysis system. - - Observe and collect information about the following activities in both the sandbox and the alert subject host: - - Attempts to contact external domains and addresses. - - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. - - Examine the DNS cache for suspicious or anomalous entries. - - $osquery_0 - - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. - - Examine the host services for suspicious or anomalous entries. - - $osquery_1 - - $osquery_2 - - $osquery_3 - - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. -- 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 - -- This detection may be triggered by certain applications that install root certificates for the purpose of inspecting SSL traffic. 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 host to prevent further post-compromise behavior. -- 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 the malicious certificate from the root certificate store. -- 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. -- 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. -- 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://twitter.com/SBousseaden/status/1278013896440324096", "https://www.ired.team/offensive-security/defense-evasion/using-syscalls-directly-from-visual-studio-to-bypass-avs-edrs", @@ -123,7 +43,7 @@ process where host.os.type == "windows" and event.code == "10" and not winlog.event_data.CallTrace : ("?:\\WINDOWS\\SYSTEM32\\ntdll.dll*", "?:\\WINDOWS\\SysWOW64\\ntdll.dll*", - "?:\\WINDOWS\\System32\\sysfer.dll*", + "?:\\Windows\\System32\\sysfer.dll*", "?:\\Windows\\System32\\wow64cpu.dll*", "?:\\WINDOWS\\System32\\wow64win.dll*", "?:\\Windows\\System32\\win32u.dll*", @@ -140,6 +60,161 @@ process where host.os.type == "windows" and event.code == "10" and not winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe") ''' +note = """## Triage and analysis + +### Investigating Suspicious Process Access via Direct System Call + +#### Possible investigation steps + +- What did the Sysmon process-access event prove? + - Focus: `winlog.event_data.SourceImage`, `winlog.event_data.SourceProcessGUID`, `winlog.event_data.TargetImage`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`. + - Implication: escalate when the call trace starts in UNKNOWN or unbacked memory before the Windows syscall layer and the source opens lsass.exe, a browser, or a security process with memory-read, memory-write, thread, duplicate-handle, or all-access rights; lower concern only when the same source-target-access pattern matches recognized EDR, anti-exploit, debugger, accessibility, anti-cheat, or browser instrumentation. +- Which source process instance made the access? + - Focus: recover the source process start on `host.id` using `process.entity_id`, or `winlog.event_data.SourceProcessGUID` plus `process.pid` and alert-time proximity as a weaker fallback; review `process.executable`, `process.hash.sha256`, PE metadata, and code signature. $investigate_0 + - Hint: hash, PE metadata, and signature fields are optional; if absent, keep disposition tied to source path, GUID/PID recovery, parent or command context, and target/access evidence rather than closing. + - Implication: escalate when the source is unsigned, recently dropped, user-writable, renamed, or mismatched to PE metadata; lower concern only when identity, signer or hash, path, and recovery context fit the same recognized security, debugger, accessibility, anti-cheat, or instrumentation workflow. +- Did launch and user context fit that workflow? + - Focus: recovered `process.command_line`, parent executable/command line, alert `user.id`, and session context. + - Hint: join `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId` only when session origin changes severity; if absent, keep origin unresolved and rely on alert user plus recovered session context. + - Implication: escalate when Office, browsers, script hosts, archive tools, LOLBins, or remote-interactive sessions launch the accessor; lower concern when parent, command line, account, and session type fit the same recognized low-level tool. If process/session fields cannot be recovered, treat the gap as unresolved, not benign. +- Did the same source process create dumping, injection, or staging artifacts? + - Focus: same-source child starts and file events where `file.path` shows dump output, temp staging, payload drops, or renamed executable content. $investigate_1 $investigate_2 + - Hint: use the transform when `process.entity_id` is present; otherwise repeat the `host.id` plus `process.pid` alert-time fallback from source recovery. + - Implication: escalate when the source writes dumps, stages payloads, or spawns tooling after access; missing process or file telemetry is unresolved, not benign. +- Did the same source process communicate after access? + - Focus: process-scoped DNS `dns.question.name` and connections to `destination.ip`. + - Hint: correlate DNS to destination IP only after matching the same recovered process, `host.id`, and surrounding time window. $investigate_3 + - Implication: escalate when the source reaches rare or misaligned destinations, connects directly to public IPs, or talks outbound after accessing a sensitive process; missing network telemetry is unresolved, not benign. +- If local evidence remains suspicious or unresolved, is there related activity for the same user, host, or source binary? + - Focus: related alerts for `user.id`, `host.id`, and recovered `process.hash.sha256` when available, especially process-access, dump-file, injection, credential-access, or persistence alerts. + - Hint: start with user-scoped alerts when the alert user is meaningful. $investigate_4 + - Hint: use host-scoped alerts when the source runs as a service identity or user context is sparse. $investigate_5 + - Implication: broaden scope only when local source, target, access, identity, or follow-on evidence remains suspicious or unresolved; expand containment and credential scoping when related alerts show the same access pattern beyond one process. +- Escalate unauthorized direct-syscall access to credential-bearing, browser, or security processes when source-target-access-call-trace, recovered identity, launch/session context, or follow-on evidence remain suspicious; close only when those categories bind to one recognized workflow with outside confirmation for any legitimacy gap; preserve and escalate mixed evidence or visibility gaps. + +### False positive analysis + +- Security agents, anti-exploit tools, debuggers, accessibility tools, anti-cheat systems, browser or PDF instrumentation, backup, and virtualization tools can perform low-level process access. Confirm source executable, signer or hash history, parent workflow, target cohort, access mask, call-trace shape, user/session context, recurrence, and quiet follow-on telemetry all align with one exact product workflow; require owner, inventory, vendor, or change evidence for legitimacy gaps. Recurrence is only corroboration: require the same stable source identity, parent/session context, target cohort, access pattern, and lack of dump or staging artifacts for the same `host.id` and `user.id`. +- Build exceptions from the minimum confirmed pattern: recovered source executable or signer, recovered parent workflow, `winlog.event_data.TargetImage`, access-mask class, first-frame call-trace shape, and relevant `host.id` or `user.id` scope. Avoid exceptions on `winlog.event_data.GrantedAccess`, `winlog.event_data.CallTrace`, process name, or target image alone. + +### Response and remediation + +- If confirmed benign, reverse temporary containment and document the source identity, launch/session context, source-target-access-call-trace tuple, target cohort, and evidence that confirmed the product workflow. Create an exception only for the exact recurring pattern. +- If suspicious but unconfirmed, preserve the alert record, Sysmon Event ID 10 details, source and target process GUIDs, call trace string, recovered process start, relevant authentication records, dump files, staged payloads, and network indicators before containment or cleanup. +- Apply reversible containment first: heightened monitoring, temporary outbound restrictions, or response-tool policy on the affected `host.id`. Escalate to host isolation or process suspension only when the target sensitivity, access rights, identity evidence, or follow-on artifacts indicate likely dumping, injection, or credential theft. +- If confirmed malicious, isolate the endpoint and suspend or terminate the recovered source process after recording its identity, command line, parent chain, source-target pair, access mask, call trace, staged files, and network indicators. If direct response is unavailable, hand off that evidence set to the team that can isolate the host or account. +- If the target process held credentials, browser secrets, or security-product context, scope related users, sessions, tokens, and hosts before credential resets or broad process termination so evidence and blast radius are not lost. +- Eradicate only the dump files, injectors, loaders, persistence artifacts, or staged payloads identified during the investigation, then remediate the launcher, delivery path, or exposed credential path that enabled the direct-syscall process access. +- Post-incident hardening: retain Sysmon Event ID 10 plus supporting process, file, network, and Windows Security telemetry, and document direct NtOpenProcess, unhooking, or call-stack-spoofing variants observed in the case for future detection review.""" + +setup = """## Setup + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.code", + "host.name", + "host.id", + "user.id", + "process.entity_id", + "process.pid", + "process.name", + "process.executable", + "winlog.event_data.SourceProcessGUID", + "winlog.event_data.SourceImage", + "winlog.event_data.TargetProcessGUID", + "winlog.event_data.TargetImage", + "winlog.event_data.GrantedAccess", + "winlog.event_data.CallTrace", +] + +[transform] + +[[transform.investigate]] +label = "Events for the same source process on this host" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Child process starts from the source process" +description = "" +providers = [ + [ + { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "File events for the source process" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Network and DNS events for the source process" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" } + ], + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "dns", 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" @@ -148,7 +223,6 @@ id = "T1055" name = "Process Injection" reference = "https://attack.mitre.org/techniques/T1055/" - [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" @@ -160,9 +234,7 @@ id = "T1106" name = "Native API" reference = "https://attack.mitre.org/techniques/T1106/" - [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - diff --git a/rules/windows/defense_evasion_system_critical_proc_abnormal_file_activity.toml b/rules/windows/defense_evasion_system_critical_proc_abnormal_file_activity.toml index 31d0dd3c1..93091c265 100644 --- a/rules/windows/defense_evasion_system_critical_proc_abnormal_file_activity.toml +++ b/rules/windows/defense_evasion_system_critical_proc_abnormal_file_activity.toml @@ -2,33 +2,7 @@ creation_date = "2020/08/19" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" - -[transform] -[[transform.osquery]] -label = "Osquery - Retrieve DNS Cache" -query = "SELECT * FROM dns_cache" - -[[transform.osquery]] -label = "Osquery - Retrieve All Services" -query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services" - -[[transform.osquery]] -label = "Osquery - Retrieve Services Running on User Accounts" -query = """ -SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE -NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR -user_account == null) -""" - -[[transform.osquery]] -label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link" -query = """ -SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid, -services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path = -authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted' -""" - +updated_date = "2026/04/30" [rule] author = ["Elastic"] @@ -49,56 +23,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Unusual Executable File Creation by a System Critical Process" -note = """## Triage and analysis - -### Investigating Unusual Executable File Creation by a System Critical Process - -Windows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these characteristics is file operations. - -This rule looks for the creation of executable files done by system-critical processes. This can indicate the exploitation of a vulnerability or a malicious process masquerading as a system-critical process. - -> **Note**: -> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. - -#### 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. -- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. -- Examine the host for derived artifacts that indicate suspicious activities: - - Analyze the process executable using a private sandboxed analysis system. - - Observe and collect information about the following activities in both the sandbox and the alert subject host: - - Attempts to contact external domains and addresses. - - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. - - Examine the DNS cache for suspicious or anomalous entries. - - $osquery_0 - - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. - - Examine the host services for suspicious or anomalous entries. - - $osquery_1 - - $osquery_2 - - $osquery_3 - - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. -- 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 - -- 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 host to prevent further post-compromise behavior. -- 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). -""" risk_score = 73 rule_id = "e94262f2-c1e9-4d3f-a907-aeab16712e1a" severity = "high" @@ -130,9 +54,185 @@ file where host.os.type == "windows" and event.type != "deletion" and "lsass.exe", "winlogon.exe", "userinit.exe", - "LogonUI.exe") + "LogonUI.exe") and + not ( + process.name : "smss.exe" and + file.path : ( + "?:\\Windows\\System32\\wpbbin.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\wpbbin.exe" + ) + ) and + not ( + process.name : "lsass.exe" and + file.path : ( + "?:\\Windows\\System32\\eac_usermode_*.dll", + "\\Device\\HarddiskVolume*\\Windows\\System32\\eac_usermode_*.dll" + ) + ) ''' +note = """## Triage and analysis + +### Investigating Unusual Executable File Creation by a System Critical Process + +#### Possible investigation steps + +- What exact critical-process write did the alert preserve? + - Focus: `process.name`, `process.executable`, `file.path`, `file.extension`, and `event.action`; writer should match a critical-process name in the query. + - Implication: escalate faster when it writes an EXE or DLL in user-writable, startup, temp, or other non-servicing paths; lower concern only for protected OS servicing paths or a repaired vendor product tree. +- Is the writer the expected protected Windows binary, not a masquerade or tampered copy? + - Why: exploitation for defense evasion can preserve a genuine protected-process identity while changing what that process writes. + - Focus: `process.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; recover `process.hash.sha256` and `process.pe.original_file_name` from matching process-start events on `host.id` and `process.entity_id` when absent. $investigate_1 + - Implication: escalate when path, signer, hash, or original file name conflicts with the expected critical process; if identity is the expected Microsoft binary, continue because exploitation can still force a genuine process to write attacker-controlled content. +- What launch and user context led to the write? + - Why: client-side or service exploitation often appears as Office, browser, script, archive, or user-profile ancestry before an abnormal critical-process file write. + - Focus: matching process-start event: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `user.id`. + - Implication: escalate when the chain traces to Office, browser, script, archive, LOLBin, or user-profile activity before the critical-process write; lower concern only when parentage and user context align with OS servicing or one bounded product repair. +- Does the written artifact look staged or renamed rather than serviced? + - Focus: `file.path`, `file.Ext.original.path`, `file.Ext.original.extension`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. $investigate_2 + - Implication: escalate when content is renamed into an executable extension, lands in a deceptive or writable path, carries internet provenance, or header bytes do not fit the file name. +- Did the written file become an execution target or command-line dependency? + - Focus: same-writer file activity on `host.id` and `process.entity_id`, plus later process starts from `file.path`. $investigate_0 + - Hint: for EXE reuse, inspect later process starts where `process.executable` equals `file.path`; for DLL writes, search `process.command_line` for the path and treat a quiet result as unresolved, not benign. $investigate_5 + - Implication: escalate when the artifact executes or is referenced by follow-on commands; if the same-process file view is quiet, use the EXE or DLL recovery cue before lowering urgency. +- If local evidence remains suspicious or unresolved, does the artifact pattern recur on this host or other hosts? + - Focus: related alerts for the same written `file.path`; add writer `process.executable` only after alert or identity confirms it. $investigate_3 + - Hint: compare related alerts for the same `host.id` and `host.name` before broadening to other assets. $investigate_4 + - Implication: broaden scope when the same artifact path, writer identity, or follow-on execution appears on multiple hosts or repeats on the same host; localize when evidence stays limited to one short-lived, well-bounded servicing chain. +- Escalate for abnormal identity, exploit-like lineage, staged content, execution/reference, or recurrence; close only when identity, lineage, artifact, and scope bind one servicing or vendor-maintenance workflow with no contradictions; preserve artifacts and escalate when evidence stays mixed or incomplete. + +### False positive analysis + +- Windows servicing/component repair or product/security-agent upgrade can replace binaries in protected OS or vendor paths. Confirm writer identity (`process.executable`, `process.code_signature.subject_name`, `process.hash.sha256`, `process.pe.original_file_name`), lineage (`process.parent.executable`, `process.Ext.ancestry`), and `file.path` all match one servicing or product workflow on the same `host.id`; for vendor repair, also require the path to stay inside the vendor directory and no user-writable staging, staged rename, or later execution from that path. If maintenance records are unavailable, use prior alerts from this rule for the same host and require the same protected path pattern without staged rename or later execution. +- Before creating an exception, require recurrence for the same `host.id` plus stable `process.executable`, `process.code_signature.subject_name`, parent context, and protected `file.path` pattern. Avoid exceptions on `process.name`, `file.extension`, or the whole critical-process list alone. + +### Response and remediation + +- If confirmed benign, reverse temporary containment and document the servicing or vendor-maintenance evidence: writer identity, parent context, written path, content indicators, and host scope. Create an exception only after the bounded pattern recurs. +- If suspicious but unconfirmed, export the alert file event and matching process-start event, preserve a copy of the written file when safe, and record the writer `process.entity_id`, `process.command_line`, `process.parent.executable`, `file.path`, and recovered `process.hash.sha256` before containment. Apply reversible containment first, such as heightened monitoring or temporary host isolation when host criticality allows, and avoid deleting the artifact until scope is clearer. +- If confirmed malicious, isolate the host when writer identity, lineage, artifact, or execution evidence establishes unauthorized activity. Record `process.entity_id`, `process.executable`, `process.command_line`, `file.path`, and recovered hashes before killing processes or deleting files; then terminate the offending process if still active and quarantine only the executable or DLL artifacts identified during investigation. +- Post-incident hardening should verify why a critical process could write executable content, restore affected files from trusted media when replacement occurred, retain process and file telemetry that supported the case, and document artifact-path or lineage variants in the incident record 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: + +- [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 11 - File Create](https://ela.st/sysmon-event-11-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "user.id", + "process.entity_id", + "process.name", + "process.executable", + "process.code_signature.subject_name", + "process.code_signature.trusted", + "file.path", + "file.extension", + "file.Ext.original.path", + "file.Ext.header_bytes", + "file.Ext.windows.zone_identifier", + "event.action", +] + +[transform] + +[[transform.investigate]] +label = "Events for the writing process on this host" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process start for the writing process" +description = "" +providers = [ + [ + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "File activity for the written path on this host" +description = "" +providers = [ + [ + { excluded = false, field = "file.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the written file path" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "file.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process starts from the written file path on this host" +description = "" +providers = [ + [ + { excluded = false, field = "process.executable", queryType = "phrase", value = "{{file.path}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ], + [ + { excluded = false, field = "process.command_line", queryType = "phrase", value = "{{file.path}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/defense_evasion_unusual_ads_file_creation.toml b/rules/windows/defense_evasion_unusual_ads_file_creation.toml index 9f15b3b44..3906d65b4 100644 --- a/rules/windows/defense_evasion_unusual_ads_file_creation.toml +++ b/rules/windows/defense_evasion_unusual_ads_file_creation.toml @@ -2,33 +2,7 @@ creation_date = "2021/01/21" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2026/04/07" - -[transform] -[[transform.osquery]] -label = "Osquery - Retrieve DNS Cache" -query = "SELECT * FROM dns_cache" - -[[transform.osquery]] -label = "Osquery - Retrieve All Services" -query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services" - -[[transform.osquery]] -label = "Osquery - Retrieve Services Running on User Accounts" -query = """ -SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE -NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR -user_account == null) -""" - -[[transform.osquery]] -label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link" -query = """ -SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid, -services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path = -authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted' -""" - +updated_date = "2026/04/30" [rule] author = ["Elastic"] @@ -48,62 +22,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Unusual File Creation - Alternate Data Stream" -note = """## Triage and analysis - -### Investigating Unusual File Creation - Alternate Data Stream - -Alternate Data Streams (ADS) are file attributes only found on the NTFS file system. In this file system, files are built up from a couple of attributes; one of them is $Data, also known as the data attribute. - -The regular data stream, also referred to as the unnamed data stream since the name string of this attribute is empty, contains the data inside the file. So any data stream that has a name is considered an alternate data stream. - -Attackers can abuse these alternate data streams to hide malicious files, string payloads, etc. This rule detects the creation of alternate data streams on highly targeted file types. - -> **Note**: -> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. - -#### Possible investigation steps - -- Retrieve the contents of the alternate data stream, and analyze it for potential maliciousness. Analysts can use the following PowerShell cmdlet to accomplish this: - - `Get-Content C:\\Path\\To\\file.exe -stream SampleAlternateDataStreamName` -- 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 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 user/host during the past 48 hours. -- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. -- Examine the host for derived artifacts that indicate suspicious activities: - - Analyze the process executable using a private sandboxed analysis system. - - Observe and collect information about the following activities in both the sandbox and the alert subject host: - - Attempts to contact external domains and addresses. - - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. - - Examine the DNS cache for suspicious or anomalous entries. - - $osquery_0 - - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. - - Examine the host services for suspicious or anomalous entries. - - $osquery_1 - - $osquery_2 - - $osquery_3 - - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. -- 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 - -- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of process executable and file conditions. - -### 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. -- 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. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. -- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. -- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. -- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). -""" risk_score = 73 rule_id = "71bccb61-e19b-452f-b104-79a60e546a95" severity = "high" @@ -124,7 +42,7 @@ type = "eql" query = ''' file where host.os.type == "windows" and event.type == "creation" and - process.name : ("cmd.exe", "powershell.exe", "mshta.exe", "wscript.exe", "node.exe", "python*.exe") and + process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "wscript.exe", "cscript.exe", "node.exe", "python*.exe") and file.extension in~ ( "pdf", "dll", "exe", "dat", "com", "bat", "cmd", "sys", "vbs", "vbe", "ps1", "hta", "txt", "js", "jse", "wsh", "wsf", "sct", "docx", "doc", "xlsx", "xls", "pptx", "ppt", "rtf", "gif", "jpg", "png", "bmp", "img", "iso" @@ -133,6 +51,162 @@ file where host.os.type == "windows" and event.type == "creation" and not file.name :("*:$DATA", "*PG$Secure", "*Zone.Identifier", "*com.apple.lastuseddate#PS", "*com.apple.provenance") ''' +note = """## Triage and analysis + +### Investigating Unusual File Creation - Alternate Data Stream +#### Possible investigation steps + +- What ADS target did the alert create? + - Focus: `file.path`, `file.extension`, `file.size`, and the stream suffix after the base file. + - Implication: escalate when a command or script interpreter writes ADS on an executable, script, user document, or disk-image host file with a payload-like, DLL-like, or config-like stream name; lower concern only when stream name and file class match a narrow classification, tagging, or packaging marker. + +- Does stream metadata or collected content look like payload material? + - Focus: `file.size`, `file.Ext.header_bytes`, `file.Ext.entropy`, and collected ADS content when available. + - Hint: retrieve raw ADS content with "Get-Content -Path -Stream " or collect the host file before cleanup; without content, do not close from absence. + - Implication: escalate for script text, encoded blobs, PE bytes, launcher syntax, or execution configuration; if content cannot be recovered, keep unresolved unless lineage, staging, or reuse proves the answer. Lower concern requires small, readable classification, package, validation, or test metadata. + +- How was the creating interpreter launched? + - Focus: `process.executable`, `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.code_signature.subject_name`. $investigate_2 + - Implication: escalate when launched by a document, browser, user-writable binary, unusual parent command, or command line that writes hidden content; lower concern when identity, parent, command line, and user-host scope match a recognized tagging, packaging, or validation workflow. + +- Did the creating process stage, rename, or clean up supporting files? + - Focus: same-process file events on `host.id` and `process.entity_id`: `file.path`, `file.extension`, and `file.size`. $investigate_3 + - Implication: escalate when the same process drops executables or scripts, renames content into a deceptive path, deletes staging material, or writes related ADS artifacts; lower concern when file activity stays limited to the expected file set and stream metadata pattern. + +- Did later commands reuse the ADS path or base file? + - Why: ADS creation becomes decisive when a later command uses file:path:stream syntax or a helper consumes hidden content. + - Focus: later process events on `host.id` and `user.id` where `process.command_line` references the ADS path, base path, or stream name; include `process.executable` and `process.parent.executable`. $investigate_4 + - Hint: search first for the literal ADS path, then the base path and stream name separately if quoting or escaping differs. + - Implication: escalate when later commands read, execute, copy, extract, or persist from ADS; if no reuse appears, keep unresolved unless content and lineage prove benign metadata use. + +- Does the ADS pattern recur broadly enough to change scope? + - Focus: smallest stable suspicious indicator, such as stream name, `file.path` pattern, `process.executable`, or `process.command_line`, plus `host.id` and `user.id` scope. + - Hint: review host-related alerts for matching ADS or interpreter patterns. $investigate_1 + - Hint: review user-related alerts before treating activity as one-host. $investigate_0 + - Implication: broaden containment and scoping when unrelated hosts or users share the ADS pattern; keep scope local only when local content, lineage, and reuse are resolved or the pattern remains confined to one unresolved host. + +- Escalate for hidden payload staging, ADS execution, suspicious cleanup, or spread beyond the first host; close only when ADS path/content, command lines, parent lineage, same-process file activity, and `host.id`/`user.id` scope prove one exact marker-writing or lab workflow with no contradictory reuse; preserve artifacts and escalate when answers stay mixed or incomplete. + +### False positive analysis + +- Data-classification, packaging, or validation tools can legitimately create small ADS markers on fixed file classes. Confirm identity (`process.executable`, `process.code_signature.subject_name`, parent command line), artifacts (`file.path`, stream name, readable marker content), and scope (`host.id`, `user.id`, host cohort) all align with one exact workflow; if workflow records are unavailable, require prior alerts with the same process identity, parent command line, stream name, file class, and host cohort. +- Controlled security testing or forensic labs can place samples or markers in ADS on isolated systems. Confirm the same `process.executable`, `process.command_line`, `file.path`, stream name, and lab host cohort, and no later execution or persistence from ADS; if test plans are unavailable, require repeated bounded testing patterns. Do not create exceptions on `process.name` or `file.extension` alone. + +### Response and remediation + +- If confirmed benign: + - Document the evidence that established the workflow before changing response state: `process.executable`, `process.command_line`, parent command line, `file.path` pattern, stream name, stream content type, and the `host.id` or `host.name` cohort. Then reverse temporary containment. Build exceptions only from the minimum confirmed pattern, not from a generic interpreter or file-extension condition. +- If suspicious but unconfirmed: + - Preserve the exact ADS path, base host file, recovered stream content or computed hash, process timeline, `process.entity_id`, `process.pid`, `process.command_line`, `process.parent.command_line`, and same-process file events before cleanup. + - Apply reversible containment tied to the findings, such as heightened monitoring, execution restrictions for the affected interpreter, or temporary containment of the affected `host.id`; avoid deleting the stream or base file until evidence is collected. + - Escalate to host isolation only if ADS reuse, payload-like content, suspicious cleanup, or continued staging shows active risk and the asset can tolerate isolation. +- If confirmed malicious: + - Use endpoint response to isolate the host after preserving the ADS path, base file, stream content, process timeline, command lines, parent lineage, and related file artifacts. If direct endpoint response is unavailable, hand off that evidence set to the team that can contain the host. + - Review other hosts and users for the same stream name, ADS path pattern, `process.executable`, or `process.command_line` before deleting the stream, removing the base file, or terminating related processes. + - Remove the malicious stream, launched payloads, staging files, and the entry vector that created them, then remediate any persistence or delivery path identified during the investigation. +- Post-incident hardening: + - Keep process and file telemetry enabled for the affected host class, and record recurring ADS naming or interpreter patterns for future triage. + - Restrict or monitor interpreter workflows that create ADS on high-value file types when that behavior is not required for the host role. +""" + +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 15 - FileCreateStreamHash](https://ela.st/sysmon-event-15-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "user.name", + "user.id", + "process.parent.executable", + "process.entity_id", + "process.pid", + "process.name", + "process.executable", + "process.command_line", + "file.path", + "file.name", + "file.extension", + "file.size", +] + +[transform] + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process events for the same process" +description = "" +providers = [ + [ + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "File events for the same process" +description = "" +providers = [ + [ + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process events for the same host and user" +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 = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" @@ -145,10 +219,7 @@ id = "T1564.004" name = "NTFS File Attributes" reference = "https://attack.mitre.org/techniques/T1564/004/" - - [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - diff --git a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml index a5e0af41b..1176fe81d 100644 --- a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml +++ b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/19" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/04/30" [rule] author = ["Elastic"] @@ -21,42 +21,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "Unusual Child Process from a System Virtual Process" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Unusual Child Process from a System Virtual Process - -In Windows environments, the System process (PID 4) is a critical component responsible for managing system-level operations. Adversaries may exploit this by injecting malicious code to spawn unauthorized child processes, evading detection. The detection rule identifies anomalies by flagging unexpected child processes originating from the System process, excluding known legitimate executables, thus highlighting potential threats. - -### Possible investigation steps - -- Review the process details of the suspicious child process, including the executable path and command line arguments, to determine if it matches known malicious patterns or anomalies. -- Check the parent process (PID 4) to confirm it is indeed the System process and verify if any legitimate processes are excluded as per the rule (e.g., Registry, MemCompression, smss.exe). -- Investigate the timeline of events leading up to the process start event to identify any preceding suspicious activities or anomalies that might indicate process injection or exploitation. -- Correlate the alert with other security telemetry from data sources like Microsoft Defender XDR or Sysmon to identify any related alerts or indicators of compromise. -- Examine the network activity associated with the suspicious process to detect any unauthorized connections or data exfiltration attempts. -- Consult threat intelligence sources to determine if the process executable or its behavior is associated with known malware or threat actor techniques. -- If necessary, isolate the affected system to prevent further potential malicious activity and conduct a deeper forensic analysis. - -### False positive analysis - -- Legitimate system maintenance tools may occasionally spawn child processes from the System process. Users should monitor and verify these tools and add them to the exclusion list if they are confirmed to be safe. -- Some security software might create child processes from the System process as part of their normal operation. Identify these processes and configure exceptions to prevent unnecessary alerts. -- Windows updates or system patches can sometimes trigger unexpected child processes. Ensure that these processes are part of a legitimate update cycle and exclude them if they are verified. -- Custom scripts or administrative tools used for system management might also cause false positives. Review these scripts and tools, and if they are deemed safe, add them to the exclusion list. -- Virtualization software or sandbox environments may mimic or interact with the System process in ways that trigger alerts. Validate these interactions and exclude them if they are part of normal operations. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further spread of the potential threat. -- Terminate any suspicious child processes identified as originating from the System process (PID 4) that are not part of the known legitimate executables. -- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code. -- Review recent system changes and installed software to identify any unauthorized modifications or installations that could have facilitated the process injection. -- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through other means. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Implement enhanced monitoring and logging for the affected system and similar environments to detect any recurrence of the threat, focusing on process creation events and anomalies related to the System process.""" risk_score = 73 rule_id = "de9bd7e0-49e9-4e92-a64d-53ade2e66af1" severity = "high" @@ -82,6 +46,139 @@ process where host.os.type == "windows" and event.type == "start" and not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe", "HotPatch") ''' +note = """## Triage and analysis + +### Investigating Unusual Child Process from a System Virtual Process + +#### Possible investigation steps + +- Does the alert prove a real PID 4 child outside normal System-process exclusions? + - Focus: alert-local `process.parent.pid`, `process.parent.name`, `process.parent.executable`, `process.executable`, and `process.command_line`. + - Implication: escalate when PID 4 spawned a non-standard user-mode child whose path or command does not fit a signed system helper; lower suspicion only when identity and context fit one recognized boot, servicing, driver, security, or virtualization helper. +- Is the child binary identity consistent with the claimed system component? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when path, hash, original file name, or signer conflicts with the claimed binary, especially from user-writable or unusual system paths; lower suspicion only when signer, hash history, and path converge on one recognized product. +- Does the child show drop, rename, or hollowing clues at start? + - Focus: `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, `process.Ext.created_suspended`, and `process.command_line`. $investigate_3 + - Implication: escalate when the executable is newly created or renamed, starts suspended, or invokes script/LOLBins; older stable timing and a product-consistent command lower concern but do not clear abnormal parentage alone. +- Which account, session, and token context owned the child? + - Focus: `user.id`, `process.Ext.authentication_id`, `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when a PID 4 child appears in an interactive, remote, or unexpected user context, or carries a token that does not fit the helper role; service or boot context lowers concern only when identity and behavior align. +- Did the child launch follow-on processes that reveal intent? + - Why: injected code can use a trusted or privileged process as a launcher, so the child process's descendants may be the first visible operator action. + - Focus: child process events from `process.entity_id`, reading `process.executable`, `process.command_line`, and `process.Ext.ancestry`. $investigate_1 + - Implication: escalate when descendants are scripting engines, admin tools, renamed binaries, or commands that do not fit the child identity; no descendants lowers urgency but does not clear abnormal identity, session, or timing. +- If local evidence remains suspicious or unresolved, does the same child identity appear outside this host? + - Focus: same-host related alerts plus process starts for `process.hash.sha256`, `process.executable`, and `process.code_signature.subject_name`. $investigate_2 $investigate_0 + - Implication: broaden scope when the same child identity, signer mismatch, or descendant pattern appears on unrelated hosts; keep localized only when confined to one clean workflow on one host. +- Escalate on abnormal or contradictory parentage, identity, start-state, session/token, descendant, or scope evidence; close only when all support one signed workflow; preserve and escalate when mixed or incomplete. + +### False positive analysis + +- Endpoint security, virtualization, hardware, driver, servicing, or boot workflows can legitimately spawn signed helpers from PID 4. Confirm `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, session/token context, command line, start-state timing, and descendants all align with the same product or Microsoft servicing sequence. Use inventory or change records only after telemetry matches; if unavailable, require the same stable child identity and bounded descendant pattern to recur for the same `host.id` across prior alerts from this rule before exceptioning. +- Before creating an exception, require recurrence for the same `host.id` plus stable `process.hash.sha256`, `process.executable`, `process.code_signature.subject_name`, and command or descendant pattern. Avoid exceptions on `process.parent.pid`, `process.name`, or the System parent condition alone. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and document the signed maintenance, security, driver, virtualization, or servicing workflow that matched the child identity, session/token context, command line, and descendant process pattern. Create an exception only after the same bounded pattern recurs. +- If suspicious but unconfirmed, preserve the alert event, child and parent entity IDs, binary identity, command line, signer, session/token context, and descendant process events before containment. Apply reversible containment first; isolate only if the host role can tolerate it and the child or descendants show active suspicious behavior. +- If confirmed malicious, isolate the host when process identity, session/token context, start-state clues, or descendant behavior establish unauthorized activity. Before termination, record the child and descendant process identifiers, command lines, hashes, signer details, and timeline evidence. Terminate the malicious child and descendants only after preservation, then remove only confirmed malicious artifacts or persistence changes identified during response and scope other hosts for the same child identity. +- Post-incident hardening should determine why the System process spawned the child, review the responsible driver, service, security product, or exploit path, retain process telemetry needed for PID 4 parentage and descendant analysis, and document any adjacent blind spots for follow-up. +""" + +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) +- [Windows Process Creation Logs](https://ela.st/audit-process-creation) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.id", + "user.id", + "process.entity_id", + "process.parent.pid", + "process.executable", + "process.command_line", + "process.hash.sha256", + "process.pe.original_file_name", + "process.code_signature.subject_name", + "process.code_signature.trusted", + "process.Ext.relative_file_creation_time", + "process.Ext.created_suspended", + "process.Ext.session_info.logon_type", + "process.Ext.token.integrity_level_name", +] + +[transform] + +[[transform.investigate]] +label = "Alerts associated with the host in the last 48h" +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 = "Process descendants spawned by the System-spawned 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" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process starts for the same child identity" +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 = "process.hash.sha256", queryType = "phrase", value = "{{process.hash.sha256}}", 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 = "process.executable", queryType = "phrase", value = "{{process.executable}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "File events for the child executable path" +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.path", queryType = "phrase", value = "{{process.executable}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" @@ -90,9 +187,7 @@ id = "T1055" name = "Process Injection" reference = "https://attack.mitre.org/techniques/T1055/" - [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - diff --git a/rules/windows/defense_evasion_wdac_policy_by_unusual_process.toml b/rules/windows/defense_evasion_wdac_policy_by_unusual_process.toml index 5347f7437..9f08f0be1 100644 --- a/rules/windows/defense_evasion_wdac_policy_by_unusual_process.toml +++ b/rules/windows/defense_evasion_wdac_policy_by_unusual_process.toml @@ -2,13 +2,13 @@ creation_date = "2025/02/28" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/04/30" [rule] author = ["Elastic"] description = """ Identifies the creation of a Windows Defender Application Control (WDAC) policy file by an unusual process. Adversaries -may use a secially crafted WDAC policy to restrict the execution of security products. +may use a specially crafted WDAC policy to restrict the execution of security products. """ from = "now-9m" index = [ @@ -23,33 +23,6 @@ index = [ language = "eql" license = "Elastic License v2" name = "WDAC Policy File by an Unusual Process" -note = """## Triage and analysis - -### Investigating WDAC Policy File by an Unusual Process - -#### Possible investigation steps - -- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. -- Identify the user account that performed the action and whether it should perform this kind of action. -- Contact the account owner and confirm whether they are aware of this activity. -- Investigate other alerts associated with the user/host during the past 48 hours. - - Verify if any other anti-forensics behaviors were observed. -- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up. - -### 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 host to prevent further post-compromise behavior. -- Re-enable affected logging components, services, and security monitoring. -- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. -- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. -- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. -- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). -""" references = [ "https://github.com/logangoins/Krueger/tree/main", "https://beierle.win/2024-12-20-Weaponizing-WDAC-Killing-the-Dreams-of-EDR/", @@ -84,10 +57,169 @@ file where host.os.type == "windows" and event.action != "deletion" and ) and not process.executable : ( "C:\\Windows\\System32\\poqexec.exe", - "\\Device\\HarddiskVolume*\\Windows\\System32\\poqexec.exe" - ) + "\\Device\\HarddiskVolume*\\Windows\\System32\\poqexec.exe", + "?:\\Windows\\WinSxS\\*\\TiWorker.exe", + "?:\\Windows\\System32\\omadmclient.exe" + ) and + /* System / ntoskrnl.exe (PID 4) */ + not process.pid == 4 ''' +note = """## Triage and analysis + +### Investigating WDAC Policy File by an Unusual Process + +#### Possible investigation steps + +- Does the alert show active WDAC policy placement by a non-servicing writer? + - Focus: `file.path`, `file.extension`, optional rename source `file.Ext.original.path`, writer `process.executable`, and `process.entity_id`. Separate "CodeIntegrity\\SiPolicy.p7b" base-policy placement from "CodeIntegrity\\CiPolicies\\Active\\*.cip" activation. + - Implication: escalate when an active WDAC path is written or renamed by anything other than a recognized WDAC or Windows servicing component such as "poqexec.exe"; lower suspicion only when active path, original path when present, and writer align with one recognized WDAC rollout or servicing package. +- Is the writer a recognized deployment component or suspicious execution host? + - Focus: `process.executable`, `process.command_line`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when a script host, LOLBin, remote administration tool, or custom .NET assembly writes the policy, especially from temp, user, or share-backed paths; lower suspicion when the signer, hash, executable path, and command line all match a recognized WDAC deployment component. +- Does the launch chain and user context fit WDAC administration? + - Focus: `process.parent.executable`, `process.parent.command_line`, and `user.id`. + - Implication: escalate when the parent chain suggests in-memory tooling, service-control abuse, remote execution, or an unexpected admin/service identity; lower suspicion when parent context and `user.id` match the same recognized WDAC workflow for this host. +- Was the policy staged, renamed, or rapidly replaced before activation? + - Focus: same-writer file events on `host.id` and `process.entity_id`: `file.path`, optional `file.Ext.original.path`, `file.size`, and `file.Ext.header_bytes` when populated. $investigate_3 + - Hint: file telemetry does not decode WDAC policy intent; preserve the written policy artifact for offline review before cleanup. + - Implication: escalate when rename evidence shows the policy moving from a temp, user-writable, or share-backed location into the active Code Integrity path, or when repeated writes suggest last-minute replacement; lower suspicion when file movement stays inside one recognized rollout cache path and preserves the same writer. Missing rename or header detail is unresolved, not benign. +- Was the write followed by reboot preparation or activation behavior? + - Why: Krueger-style WDAC abuse relies on the next boot to make the malicious policy block security tooling, so reboot preparation changes response urgency. + - Focus: later process activity from the writer or its children on `host.id`: `process.name`, `process.executable`, and `process.command_line` for "shutdown.exe", restart tooling, service-control utilities, or custom reboot helpers. $investigate_4 $investigate_5 + - Implication: escalate when the writer or parent chain quickly prepares a reboot; absence of a visible reboot helper leaves activation timing unresolved, not benign. +- If local evidence is suspicious or unresolved, does the same writer or host pattern repeat? + - Focus: related alerts for `user.id` and `host.id`, compared against `process.executable`, `process.hash.sha256`, active-policy `file.path`, and any staging `file.Ext.original.path`. + - Hint: review Alerts associated with the user, host, and writer process. $investigate_0 $investigate_1 $investigate_2 + - Implication: broaden scope when the same writer, hash, user, or host pattern repeats across active WDAC placements; keep scope local only when the activity is confined to one host and one bounded change window. +- Based on active placement, writer identity, launch context, staging, reboot behavior, and recurrence, what disposition is supported? + - Implication: escalate on suspicious writer identity, lineage, staging, reboot, or recurrence; close only when active path, writer, lineage, and any observed staging or reboot evidence bind one recognized WDAC rollout or servicing workflow; preserve the policy artifact and escalate when evidence stays mixed or incomplete. + +### False positive analysis + +- WDAC management, servicing, security management, OEM device-control, or endpoint-hardening products can legitimately place active "SiPolicy.p7b" or "*.cip" policies. Confirm writer identity (`process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`), launch context (`process.parent.executable`, `process.parent.command_line`, `user.id`), artifact path (`file.path`, and `file.Ext.original.path` when present), cache location, and reboot behavior all align with the same rollout or product writer. External change records or product inventory can corroborate only after those telemetry anchors align; contradictory identity, lineage, staging, or reboot evidence should not close as benign. +- Bootable media creation, disk imaging, and backup tools (e.g., Rufus, Acronis, Windows Backup Engine) writing to non-system drives or volumes can trigger the rule when copying or restoring Windows installations that include CodeIntegrity policies. Check `file.path` drive letter or volume number against the host's system drive; writes to removable, secondary, or high-numbered volumes do not affect the host's WDAC protection. +- Before creating an exception, require recurrence for the same stable writer identity, signer, parent workflow, `user.id`, `host.id`, and bounded active `file.path`. Avoid exceptions on `file.extension`, `file.name`, or the broad "CodeIntegrity" prefix alone because those conditions would suppress malicious lookalike policies. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and document the evidence that justified closure: writer identity, parent workflow, `user.id`, `file.path`, staging path, and reboot behavior all pointed to one recognized WDAC rollout or maintenance path. Create an exception only after that bounded pattern recurs. +- If suspicious but unconfirmed, preserve the alert file event, the written "SiPolicy.p7b" or "*.cip" artifact, any rename-source evidence, the writer identity bundle, parent command context, `user.id`, and reboot-command evidence before destructive action. Apply reversible containment first, such as delaying an imminent reboot when operationally safe or temporarily restricting the writer, `user.id`, or management channel that introduced the policy. +- If confirmed malicious, first export the preserved policy artifact and process/file evidence set. Then isolate the host when active policy placement by an unauthorized writer, repeated placement, or reboot preparation makes containment necessary. After evidence export and containment decisions, remove only the malicious WDAC policy artifacts, restore the known-good WDAC state, and review other hosts and users for the same writer, hash, active `file.path`, or staging pattern. +- Post-incident hardening should restrict who can write to active Code Integrity paths, limit management channels that can copy policy files and reboot hosts, require controlled WDAC deployment records, and retain process and file telemetry around "CodeIntegrity" changes. +""" + +setup = """## Setup + +This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + +### 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 11 - File Create](https://ela.st/sysmon-event-11-setup) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "event.action", + "host.name", + "host.id", + "user.name", + "user.id", + "process.entity_id", + "process.executable", + "process.command_line", + "process.hash.sha256", + "process.code_signature.subject_name", + "process.code_signature.trusted", + "process.parent.executable", + "process.parent.command_line", + "file.path", +] + +[transform] + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the writer process" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "process.executable", queryType = "phrase", value = "{{process.executable}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "File events for the writer 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 = "Process events for the writer 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" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Child process events for the writer 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.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/defense_evasion_wsl_kalilinux.toml b/rules/windows/defense_evasion_wsl_kalilinux.toml index cac107a18..183b2aabe 100644 --- a/rules/windows/defense_evasion_wsl_kalilinux.toml +++ b/rules/windows/defense_evasion_wsl_kalilinux.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/12" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/04/07" +updated_date = "2026/04/30" [rule] author = ["Elastic"] @@ -24,42 +24,11 @@ index = [ ] language = "eql" license = "Elastic License v2" -name = "Attempt to Install Kali Linux via WSL" -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 Attempt to Install Kali Linux via WSL - -Windows Subsystem for Linux (WSL) allows users to run Linux distributions on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to install Kali Linux, a penetration testing distribution, to evade detection by traditional Windows security tools. The detection rule identifies suspicious processes and file paths associated with Kali Linux installations, flagging potential misuse for defense evasion. - -### Possible investigation steps - -- Review the process details to confirm the presence of "wsl.exe" with arguments indicating an attempt to install or use Kali Linux, such as "-d", "--distribution", "-i", or "--install". -- Check the file paths associated with the Kali Linux installation, such as "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*" or "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe", to verify if the installation files exist on the system. -- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. -- Correlate the event with other security logs or alerts from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. -- Assess the risk and impact of the detected activity by considering the context of the environment and any potential threats posed by the use of Kali Linux on the system. - -### False positive analysis - -- Legitimate use of Kali Linux for development or educational purposes may trigger the rule. Users can create exceptions for specific user accounts or groups known to use Kali Linux for authorized activities. -- Automated scripts or deployment tools that install or configure Kali Linux as part of a legitimate IT process might be flagged. Consider whitelisting these scripts or processes by their hash or path. -- Security researchers or IT professionals conducting penetration testing on a Windows machine may cause false positives. Implement user-based exclusions for these professionals to prevent unnecessary alerts. -- System administrators testing WSL features with various Linux distributions, including Kali, could inadvertently trigger the rule. Establish a policy to document and approve such activities, then exclude them from detection. -- Training environments where Kali Linux is used to teach cybersecurity skills might be mistakenly flagged. Set up environment-specific exclusions to avoid disrupting educational activities. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent any potential lateral movement or data exfiltration. -- Terminate any suspicious processes related to the Kali Linux installation attempt, specifically those involving `wsl.exe` with arguments indicating a Kali distribution. -- Remove any unauthorized installations of Kali Linux by deleting associated files and directories, such as those found in `AppData\\\\Local\\\\packages\\\\kalilinux*` or `Program Files*\\\\WindowsApps\\\\KaliLinux.*`. -- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. -- 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 additional monitoring and alerting for similar activities across the network, focusing on WSL usage and installation attempts of known penetration testing tools. -- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats, leveraging data sources like Microsoft Defender XDR and Sysmon.""" -references = ["https://learn.microsoft.com/en-us/windows/wsl/wsl-config"] +name = "Attempt to Install or Run Kali Linux via WSL" +references = [ + "https://learn.microsoft.com/en-us/windows/wsl/basic-commands", + "https://learn.microsoft.com/en-us/windows/wsl/wsl-config", +] risk_score = 73 rule_id = "dd34b062-b9e3-4a6b-8c0c-6c8ca6dd450e" severity = "high" @@ -97,6 +66,153 @@ process where host.os.type == "windows" and event.type == "start" and ) ''' +note = """## Triage and analysis + +### Investigating Attempt to Install or Run Kali Linux via WSL + +#### Possible investigation steps + +- What Kali/WSL behavior path did the alert prove? + - Focus: alert-local `process.name`, `process.executable`, and `process.args`, separating "wsl.exe" Kali install or distro arguments from direct Kali package-path execution. + - Hint: do not require install flags before escalating; an installed Kali distro may appear only as direct package-path launcher execution. + - Implication: escalate when "wsl.exe" selects or installs Kali with "-d", "--distribution", "-i", or "--install", or when `process.executable` runs from KaliLinux package or WindowsApps paths without a confirmed endpoint exception; lower suspicion only when exact user, host, parent, and command path match the same previously confirmed Kali/WSL workflow. +- Is the launcher identity and parent chain credible, or does it suggest masquerading or hands-on abuse? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.command_line`. + - Implication: escalate when unsigned, renamed, running from a user-writable non-package path, or launched by Office, browser, script, or unexpected remote-admin tooling; lower suspicion when signed Microsoft or Store WSL identity and parent workflow both fit recognized Kali/WSL use. Identity alone does not clear the behavior. +- Which account and Windows session started Kali or "wsl.exe", and does that fit the endpoint cohort? + - Focus: `user.id`, `user.name`, `host.id`, and `process.Ext.session_info.logon_type`. + - Implication: escalate when a non-admin user, service account, or remote/service logon starts Kali on a workstation or server cohort that does not normally run WSL; lower suspicion when account, logon type, and endpoint cohort align with a recognized developer, lab, training, or image-build pattern. +- Did process telemetry show WSL lifecycle or configuration intent around the alert? + - Focus: surrounding process starts on `host.id`, using `process.Ext.ancestry`, `process.command_line`, and `process.parent.command_line`. + - Hint: prefer `host.id` plus `process.entity_id`; if unavailable, use `host.id`, `process.pid`, and a tight alert-time window because PID reuse can mislead process recovery. $investigate_2 $investigate_4 + - Implication: escalate when `process.command_line` shows WSL install, shutdown, terminate, configuration editing, or stop/relaunch in the same lineage; lower suspicion when surrounding starts show only one previously confirmed distro launch and no lifecycle or configuration intent. +- Did Kali/WSL lead to Windows-visible follow-on execution? + - Focus: child or descendant starts tied by `process.parent.entity_id` or `process.Ext.ancestry` to the alert process, reviewing `process.executable` and `process.command_line`. + - Hint: direct child starts are high-confidence pivots; manually expand ancestry when WSL launches through intermediate hosts. $investigate_3 + - Implication: escalate for shells, archivers, credential tools, scanners, tunneling clients, Windows interop launches, or repeated distro starts; lower suspicion when visible follow-on activity stays limited to recognized setup or status commands. +- If local evidence remains suspicious or unresolved, is the same user or host repeating Kali/WSL activity elsewhere? + - Focus: related alerts and recent process starts scoped by `user.id` or `host.id`, compared with the suspicious `process.executable` and `process.parent.command_line` pattern. + - Hint: review user or host alerts only after local Kali/WSL evidence stays suspicious or unresolved. $investigate_0 $investigate_1 + - Implication: expand scope when the same user, host, parent chain, or Kali/WSL argument pattern appears on other endpoints or repeats outside the recognized workflow; keep scope local when exact activity stays confined to one recognized endpoint and bounded window, but do not close a suspicious local alert from recurrence alone. +- Escalate for unsupported user/host, suspicious launcher, masqueraded binary, lifecycle/configuration activity, offensive follow-on process, or spread; close only when process evidence binds to one exact recognized workflow with no contradictions; preserve evidence and escalate when mixed or incomplete. + +### False positive analysis + +- Developer, security-lab, training, red-team, provisioning, or image-build systems can legitimately run or install Kali under WSL. First confirm process telemetry ties `user.id` or `host.id` cohort, `process.executable`, `process.args` or package path, `process.parent.command_line`, and signer or hash identity to the same recognized workflow, with no unexpected WSL stop/relaunch, tooling, or follow-on activity. Use rosters, training, build records, owner confirmation, or inventory only as corroboration after process evidence matches; if they conflict or telemetry is incomplete, do not close as benign. +- If workflow context is missing, keep the alert unresolved unless process telemetry proves the exact same bounded user/host, parent, binary identity, and Kali argument or package-path pattern with no contradictory lifecycle or follow-on evidence. +- Before creating an exception, require recurrence for the minimum confirmed pattern: `user.id` or `host.id` cohort, `process.executable`, `process.code_signature.subject_name` or `process.hash.sha256`, `process.parent.command_line`, and the Kali-specific `process.args` or package-path `process.executable`. Avoid exceptions on `process.name`, the substring "kali", or "kali.exe" alone. + +### Response and remediation + +- If confirmed benign, reverse temporary containment and document the exact workflow evidence: user and host cohort, launcher path, signer or hash identity, parent command line, and Kali argument or package-path pattern. Create an exception only after the same bounded pattern recurs without contradictory follow-on behavior. +- If suspicious but unconfirmed, export the alert and surrounding process timeline, preserve process instance IDs, command lines, binary identity, user/host/session anchors, and any WSL configuration or package paths visible in process telemetry before containment. Apply reversible containment first, such as terminating the active Kali or "wsl.exe" process, disabling the initiating account's WSL access, or running "wsl --shutdown" when operationally safe. Escalate to host isolation only if the activity spreads, reconfigures WSL, or launches offensive tooling. +- If confirmed malicious, isolate the endpoint when the identity, lineage, lifecycle, or follow-on process evidence shows active abuse. Before cleanup, record the Kali/WSL process identity, parent chain, affected `user.id` and `host.id`, package paths, and WSL configuration paths seen in command lines. Then stop active WSL instances, remove the unauthorized Kali distribution and WSL configuration changes, reset credentials exposed to the Kali environment, and scope other endpoints for the same user, launcher identity, or package-path pattern. +- Post-incident hardening should decide whether WSL is permitted for the affected endpoint cohort, restrict who can install or run WSL distributions, and retain process telemetry for Kali package paths, ".wslconfig", "wsl.conf", and "wsl.exe" lifecycle commands. +""" + +setup = """## Setup + +This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + +### Additional data sources + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- [CrowdStrike](https://ela.st/crowdstrike-integration) +- [Microsoft Defender XDR](https://ela.st/m365-defender) +- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel) +- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup) +- [Windows Process Creation Logs](https://ela.st/audit-process-creation) +""" + +[rule.investigation_fields] +field_names = [ + "@timestamp", + "host.name", + "host.id", + "user.name", + "user.id", + "process.entity_id", + "process.executable", + "process.command_line", + "process.args", + "process.pe.original_file_name", + "process.code_signature.trusted", + "process.code_signature.subject_name", + "process.Ext.session_info.logon_type", + "process.parent.entity_id", + "process.parent.command_line", +] + +[transform] + +[[transform.investigate]] +label = "Alerts associated with the user" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Alerts associated with the host" +description = "" +providers = [ + [ + { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-48h/h" +relativeTo = "now" + +[[transform.investigate]] +label = "Same-parent process starts on this host" +description = "" +providers = [ + [ + { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Child process starts from the Kali or WSL process" +description = "" +providers = [ + [ + { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "WSL lifecycle commands on this host" +description = "" +providers = [ + [ + { excluded = false, field = "process.name", queryType = "phrase", value = "wsl.exe", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/discovery_posh_invoke_sharefinder.toml b/rules/windows/discovery_posh_invoke_sharefinder.toml index 713012656..004ffe7ea 100644 --- a/rules/windows/discovery_posh_invoke_sharefinder.toml +++ b/rules/windows/discovery_posh_invoke_sharefinder.toml @@ -2,105 +2,20 @@ creation_date = "2022/08/17" integration = ["windows"] maturity = "production" -updated_date = "2026/02/09" +updated_date = "2026/04/30" [rule] author = ["Elastic"] description = """ -Detects PowerShell scripts that uses ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows +Detects PowerShell scripts that use ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows share enumeration APIs (shi1_netname/shi1_remark with NetShareEnum/NetApiBufferFree). Attackers use share enumeration to map accessible network shares for collection, lateral movement, or ransomware targeting. """ from = "now-9m" -index = ["winlogbeat-*", "logs-windows.powershell*"] +index = ["logs-windows.powershell*", "winlogbeat-*"] language = "kuery" license = "Elastic License v2" name = "PowerShell Share Enumeration Script" -note = """## Triage and analysis - -> **Disclaimer**: -> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. - -### Investigating PowerShell Share Enumeration Script - -This alert indicates PowerShell script block content consistent with Windows network share enumeration. The matched text includes ShareFinder functions (for example, `Invoke-ShareFinder` or `Invoke-ShareFinderThreaded`) and/or native share enumeration API references (for example, `NetShareEnum` / `NetApiBufferFree` and `shi1_netname` / `shi1_remark`). Share discovery can be a normal administrative activity, but in attacks it is frequently used to map accessible shares prior to data collection, lateral movement, or impact activity. - -#### Key alert fields to review - -- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. -- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. -- `powershell.file.script_block_text`: Script block content that matched the detection logic. -- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. -- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. -- `powershell.file.script_block_length`: Script block length (size) context. - -#### Possible investigation steps - -- Establish context and triage priority: - - Use `@timestamp` as the activity anchor and note the executing `user.name` / `user.domain` / `user.id` and affected `host.name` / `host.id`. - - Determine whether the account and host are expected to perform share inventory (for example, administrative workstation or management server vs. a standard user endpoint). - - Check whether similar share enumeration activity has occurred recently for the same `user.id` or on the same `host.id` to identify repeated scanning or automation. - -- Review the script block content and classify the activity: - - Inspect `powershell.file.script_block_text` and capture relevant excerpts for the case record (function names, API calls, and any referenced hosts/shares). - - Differentiate between a function definition/import and an actual invocation: - - Function definition or module load (lower confidence): the text contains the function name as part of a definition or import logic. - - Function invocation (higher confidence): the text shows parameters, target lists, or loops that initiate enumeration. - - Identify which pattern is present and what it implies about scope: - - `Invoke-ShareFinder`: share discovery logic implemented in PowerShell. - - `Invoke-ShareFinderThreaded`: broader or faster discovery due to concurrent enumeration. - - `NetShareEnum` / `NetApiBufferFree` with `shi1_netname` / `shi1_remark`: direct use of Windows share enumeration APIs and may reflect customized scripting. - - Extract scoping and intent details from the text when available: - - Target hostnames/IPs, server lists, domain-related identifiers, or UNC paths. - - Filters for share names and remarks, or include/exclude logic that focuses discovery on specific systems or shares. - - Use of alternate credentials or explicit authentication material embedded in the script (if present). - - Any output handling (formatting, writing results to disk, or staging). - -- Reconstruct full content when script blocks are split: - - Pivot on `powershell.file.script_block_id` to collect all related fragments for the same execution context. - - Use `powershell.sequence` and `powershell.total` to order fragments and identify missing pieces (if populated). - - Review adjacent script blocks for the same `host.id` and `user.id` near `@timestamp` to capture supporting functions or follow-on actions that may not appear in the triggering fragment. - -- Determine whether the activity originated from an on-disk script: - - If present, use `file.path` / `file.directory` / `file.name` to identify the script source. - - Assess whether the script location and name align with approved administrative tooling. Scripts originating from user-writable or temporary locations are higher risk than centrally managed locations. - - If an on-disk script is involved, preserve the file for further analysis and determine whether it appears on additional hosts (pivot on `file.name` where applicable). - -- Scope across users and hosts: - - Look for additional events containing the same discovery keywords in `powershell.file.script_block_text` to identify other affected endpoints. - - Check whether the same `user.id` performed similar activity from multiple `host.id` values in a short period, which can indicate automation or credential misuse. - - Identify whether multiple users are performing similar enumeration from the same host, which can indicate a shared jump box or a compromised administrative endpoint. - -- Correlate with adjacent telemetry (as available) to confirm intent and detect follow-on behavior: - - Process execution telemetry on the same `host.id` around `@timestamp` to determine how PowerShell was launched and whether the initiating process and execution pattern are consistent with expected activity for `user.id`. - - Network telemetry around `@timestamp` for access to multiple remote hosts consistent with share enumeration and subsequent SMB activity. - - Authentication telemetry for `user.id` around `@timestamp` for unusual access to file servers or multiple servers, especially if the behavior is new for the account. - - File activity telemetry (endpoint and/or file server) for unusual access patterns to shared locations following the enumeration (for example, rapid directory traversal or access to sensitive paths). - -- Assess risk and impact: - - Prioritize investigation if the script targets high-value systems (for example, file servers) or if the discovery appears broad (large target lists, threading, repeated runs). - - If the executing `user.id` is privileged or the host is sensitive, treat the alert as higher risk and expand scoping to additional related activity. - -### False positive analysis - -- Legitimate administrative share inventory, auditing, or documentation activity performed by IT or infrastructure teams. -- Approved operational scripts used for backup validation, migration planning, access reviews, or troubleshooting that enumerate shares across servers. - -### Response and remediation - -- If the activity is unauthorized or suspicious: - - Contain the affected endpoint (`host.id`) following your incident response procedures to reduce the risk of further discovery and lateral movement. - - Preserve evidence by retaining the complete `powershell.file.script_block_text` content and all fragments linked by `powershell.file.script_block_id` (including ordered reconstruction using `powershell.sequence` / `powershell.total` when available). - - Identify and prioritize potential targets referenced in the script content (servers and shares) and coordinate review of access patterns to those resources. - - Investigate the executing account (`user.name` / `user.id`) for compromise, including recent authentication activity and unexpected resource access, and take appropriate containment actions (credential reset, privilege review, and session invalidation where applicable). - - Expand hunting for additional share enumeration and subsequent access attempts associated with the same `user.id` or originating from the same `host.id`. - - If an on-disk script was used (`file.path` / `file.name` present), remove or quarantine the artifact per your response process and check for the same file on other systems. - -- If the activity is confirmed benign: - - Document the owner, purpose, expected timing, and expected scope (accounts and endpoints) of the share enumeration. - - If tuning is required, scope it narrowly to stable identifiers present in the alert (for example, specific `user.id` values and known management `host.id` endpoints) and continue to monitor for deviations from the expected pattern. - - Consider establishing a documented allowlist of approved share inventory scripts and their expected execution locations to reduce future triage time. -""" references = [ "https://www.advintel.io/post/hunting-for-corporate-insurance-policies-indicators-of-ransom-exfiltrations", "https://thedfirreport.com/2022/04/04/stolen-images-campaign-ends-in-conti-ransomware/", @@ -108,19 +23,12 @@ references = [ ] risk_score = 73 rule_id = "4c59cff1-b78a-41b8-a9f1-4231984d1fb6" -setup = """## Setup - -PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). -Setup instructions: https://ela.st/powershell-logging-setup -""" severity = "high" tags = [ "Domain: Endpoint", "OS: Windows", "Use Case: Threat Detection", "Tactic: Discovery", - "Tactic: Collection", - "Tactic: Execution", "Resources: Investigation Guide", "Data Source: PowerShell Logs", ] @@ -138,58 +46,65 @@ event.category:process and host.os.type:windows and ) or ( "NetShareEnum" and - "NetApiBufferFree" + "NetApiBufferFree" ) ) and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1135" -name = "Network Share Discovery" -reference = "https://attack.mitre.org/techniques/T1135/" +### Investigating PowerShell Share Enumeration Script +#### Possible investigation steps -[rule.threat.tactic] -id = "TA0007" -name = "Discovery" -reference = "https://attack.mitre.org/tactics/TA0007/" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1059" -name = "Command and Scripting Interpreter" -reference = "https://attack.mitre.org/techniques/T1059/" -[[rule.threat.technique.subtechnique]] -id = "T1059.001" -name = "PowerShell" -reference = "https://attack.mitre.org/techniques/T1059/001/" +- Does the reconstructed script block show active share enumeration or only helper code loading? + - Why: PowerView-style modules can define functions before invocation, so a function name alone is weaker than target selection, loops, output handling, or access checks. + - Focus: reconstruct the script with `powershell.file.script_block_id` + `powershell.sequence` + `powershell.total` on the same `host.id`, then inspect `powershell.file.script_block_text` for ShareFinder calls, NetShareEnum wrappers, and share result fields such as "shi1_netname" or "shi1_remark". $investigate_0 + - Implication: escalate when reconstruction shows active enumeration, target lists, loops, share output, or access testing; lower concern when it only defines helper code and no later invocation appears. Missing fragments keep intent unresolved, not benign. +- Can the PowerShell launch context be recovered? + - Why: script block events preserve code; command line and parentage require a matching process event. + - Focus: when endpoint process telemetry exists, recover the matching process via `host.id` + `process.pid` before using `process.*` or `process.parent.*`; review `process.command_line`, `process.parent.executable`, and session type. $investigate_1 + - Hint: anchor returned process starts to `@timestamp`; empty, multiple, or distant PID matches keep launch context unresolved. + - Implication: escalate when the launcher is a document, script host, remote session, scheduled task, or user-writable path; lower concern when launcher, arguments, and session type match the same script path, target scope, and user/host anchors for a recurring inventory or storage-audit job. If endpoint process telemetry is missing, continue with script content, source path, user/host anchors, and related-alert scope instead of closing. -[[rule.threat.technique]] -id = "T1106" -name = "Native API" -reference = "https://attack.mitre.org/techniques/T1106/" +- Does the script widen discovery with broad targets, threading, or access checks? + - Focus: reconstructed `powershell.file.script_block_text` for threading, host/domain lists, access-check options, ADMIN$ testing, ping suppression, delay/jitter, credential objects, or loops over many hosts or shares. + - Implication: escalate when the script uses threading, access checks, alternate credentials, broad domain or host-list discovery, or ADMIN$ testing; lower concern when the target set is tightly bounded to one recognized inventory, access-review, or storage-audit task. +- Are source or output artifacts risky? + - Focus: source path when present, fileless execution, output redirection/export, target/share arrays or excluded-share logic, and same-host/user file events for surrounding output or staging artifacts. $investigate_4 + - Implication: escalate when execution is fileless or sourced from temp, downloads, mounted shares, or user-writable paths; also escalate when the script writes reusable share results, prioritizes ADMIN$ or accessible shares, or builds target lists for collection or ransomware staging. Lower concern only when a stable admin repository path, transient output, script content, and user/host anchors all match one bounded recurring workflow. Path alone does not clear the behavior. -[rule.threat.tactic] -id = "TA0002" -name = "Execution" -reference = "https://attack.mitre.org/tactics/TA0002/" -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1039" -name = "Data from Network Shared Drive" -reference = "https://attack.mitre.org/techniques/T1039/" +- Do the user and host anchors fit the expected administrative scope? + - Focus: user identity, host identity, reconstructed target scope, and recovered launch context. + - Implication: escalate when a non-admin user, unusual service account, workstation, or unexpected host performs broad share discovery; lower concern when the same user and host anchors match the bounded management cohort, script path, and target set shown by local evidence. +- If local findings stay suspicious or unresolved, does the same share-discovery pattern change scope? + - Focus: related alerts for `user.id` carrying the same ShareFinder/API-wrapper, access-check, or target-list pattern, plus same-host/user network events for SMB or file-server activity when script content suggests access testing or follow-on collection. $investigate_2 $investigate_5 + - Hint: if user scope is inconclusive, check related alerts for the same `host.id` before widening beyond this host. $investigate_3 + - Hint: network events need destination or share corroboration before they prove access or collection; missing network telemetry is unresolved, not benign. + - Implication: broaden when the same script pattern, operator account, or host appears in unrelated share-discovery alerts; keep the case local when it stays confined to one `host.id`, one `user.id`, one script/source pattern, and one bounded target set. -[rule.threat.tactic] -id = "TA0009" -name = "Collection" -reference = "https://attack.mitre.org/tactics/TA0009/" +- Escalate when reconstructed content, discovery breadth, access-check markers, source/output pattern, recovered launcher context, or user/host scope show unauthorized share discovery; close only when those categories bind to one recognized workflow with no contradictory evidence; preserve and escalate when evidence is mixed or incomplete. + +### False positive analysis + +- PowerView's Invoke-ShareFinder and raw P/Invoke NetShareEnum wrappers with shi1_netname/shi1_remark are offensive tooling patterns with near-zero legitimate administrative use. Legitimate share inventory uses built-in cmdlets (Get-SmbShare, net share) or management platforms, not these APIs. Close as benign true positive only for confirmed authorized red-team, penetration testing, or security validation where reconstructed script content, `user.id`, `host.id`, test-engagement scope, and recovered launch context all align. Do not close on an IT-administration claim when the script uses these specific offensive patterns. + +### Response and remediation + +- If confirmed benign, reverse any temporary containment and record the script owner, source path or recurring fileless content, expected `user.id`, expected `host.id`, target scope, and recovered launch context when available. Create a narrow exception only after the local evidence is confirmed and prior alerts, when present, show the same stable workflow. +- If suspicious but unconfirmed, preserve the reconstructed `powershell.file.script_block_text`, all fragments linked by `powershell.file.script_block_id`, alert process PID, recovered process record when available, source path, output or target/share list, `user.id`, and `host.id` before containment. Apply reversible containment first: heightened monitoring, temporary SMB restrictions from the affected host to named servers/shares, or temporary restrictions for the implicated account when access testing or credential misuse is indicated. Escalate to host isolation or stronger credential actions only if access testing, staging, or credential misuse is confirmed and host criticality permits it. +- If confirmed malicious, isolate the host or restrict the account only after preserving the reconstructed script, recovered launch context, source/output artifacts, and target/share list. Review the named servers, shares, accounts, and related alerts for the same indicators before deleting scripts, killing processes, or resetting credentials; remove malicious scripts, scheduled tasks, or credential material only after scope is complete. +- Post-incident hardening: keep PowerShell script block logging enabled, restrict unsigned or user-writable PowerShell execution on management hosts where feasible, retain endpoint and file-server telemetry needed to confirm share access, and record the confirmed workflow or malicious server/share list for future triage. +""" + +setup = """## Setup + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup +""" [rule.investigation_fields] field_names = [ @@ -210,3 +125,123 @@ field_names = [ "powershell.file.script_block_length" ] +[transform] + +[[transform.investigate]] +label = "Script block fragments for the same script" +description = "" +providers = [ + [ + { excluded = false, field = "powershell.file.script_block_id", queryType = "phrase", value = "{{powershell.file.script_block_id}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Process events for the PowerShell instance" +description = "" +providers = [ + [ + { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }, + { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }, + { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }, + { 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" + +[[transform.investigate]] +label = "Same host and user file events" +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 = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[transform.investigate]] +label = "Same host and user network events" +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 = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" } + ] +] +relativeFrom = "now-1h" +relativeTo = "now" + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1135" +name = "Network Share Discovery" +reference = "https://attack.mitre.org/techniques/T1135/" + +[rule.threat.tactic] +id = "TA0007" +name = "Discovery" +reference = "https://attack.mitre.org/tactics/TA0007/" +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" +[[rule.threat.technique.subtechnique]] +id = "T1059.001" +name = "PowerShell" +reference = "https://attack.mitre.org/techniques/T1059/001/" + +[[rule.threat.technique]] +id = "T1106" +name = "Native API" +reference = "https://attack.mitre.org/techniques/T1106/" + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1039" +name = "Data from Network Shared Drive" +reference = "https://attack.mitre.org/techniques/T1039/" + +[rule.threat.tactic] +id = "TA0009" +name = "Collection" +reference = "https://attack.mitre.org/tactics/TA0009/"