security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

[Rule Tuning] Windows High-Severity Rules Revamp - 7 (#6013)

Browse Source 
* [Rule Tuning] Windows High-Severity Rules Revamp - 7

* Apply suggestion from @w0rk3r
This commit is contained in:
Jonhnathan
2026-05-01 19:13:37 -03:00
committed by GitHub
parent c503e550b8
commit 748ee85339
10 changed files with 1527 additions and 429 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml
+160 -40
View File
@@ -2,7 +2,7 @@
creation_date = "2021/09/08"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic"]
@@ -25,41 +25,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Control Panel Process with Unusual Arguments"
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 Control Panel Process with Unusual Arguments
The Control Panel in Windows is a system utility that allows users to view and adjust system settings. Adversaries may exploit this by using control.exe to execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies in command-line arguments, such as unexpected file types or suspicious paths, which may indicate an attempt to evade defenses or execute unauthorized actions.
### Possible investigation steps
- Review the command line arguments of the control.exe process to identify any unusual file types or suspicious paths, such as image file extensions or paths like */AppData/Local/*.
- Check the parent process of control.exe to determine if it was spawned by a legitimate application or a potentially malicious one.
- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears suspicious.
- Examine recent file modifications or creations in directories like \\AppData\\Local\\ or \\Users\\Public\\ to identify any unauthorized or unexpected changes.
- Correlate the event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context on the potential threat.
- Assess the network activity of the host during the time of the alert to identify any unusual outbound connections that may indicate data exfiltration or command and control communication.
### False positive analysis
- Image file paths in command-line arguments may trigger false positives if users or applications are legitimately accessing image files through control.exe. To mitigate this, create exceptions for known applications or user activities that frequently access image files.
- Paths involving AppData or Users\\Public directories might be flagged if legitimate software installations or updates use these locations. Review and whitelist specific software processes that are known to use these directories for legitimate purposes.
- Relative path traversal patterns like ../../.. could be used by legitimate scripts or applications for configuration purposes. Identify and exclude these scripts or applications from the detection rule if they are verified as non-malicious.
- Frequent use of control.exe with specific command-line arguments by system administrators or IT personnel for legitimate system management tasks can be excluded by creating user-based exceptions for these roles.
- If certain security tools or monitoring software are known to trigger this rule due to their operational behavior, consider excluding these tools after confirming their legitimacy and necessity.
### Response and remediation
- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate the suspicious control.exe process to stop any ongoing malicious execution.
- 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 remnants.
- Review and clean up any unauthorized changes or files in the directories specified in the alert, such as AppData/Local or Users/Public, to ensure no persistence mechanisms remain.
- Restore any affected files or system settings from a known good backup to ensure system integrity.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
- Implement additional monitoring and alerting for similar command-line anomalies to enhance detection and prevent recurrence of this threat."""
references = ["https://www.joesandbox.com/analysis/476188/1/html"]
risk_score = 73
rule_id = "416697ae-e468-4093-a93d-59661fa619ec"
@@ -69,7 +34,6 @@ tags = [
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Tactic: Execution",
"Data Source: Elastic Endgame",
"Data Source: Elastic Defend",
"Data Source: Windows Security Event Logs",
@@ -97,6 +61,165 @@ process where host.os.type == "windows" and event.type == "start" and
)
'''
note = """## Triage and analysis
### Investigating Control Panel Process with Unusual Arguments
#### Possible investigation steps
- Which suspicious argument family did the alert preserve, and what does it imply?
- Focus: `process.command_line` and `@timestamp`, identifying image or INF targets, ".cpl:" indirection, traversal (".."), "AppData\\Local", or "Users\\Public" fragments.
- Implication: escalate when Control Panel points at non-applet content, user-writable paths, traversal, or URL-like ".cpl:" loading; lower suspicion only when the path and argument resolve to one recognized vendor applet, driver package, or support workflow.
- Is the alerting binary really the expected Control Panel executable?
- Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.hash.sha256`.
- Implication: escalate if "control.exe" is renamed, unsigned or untrusted, has an unfamiliar hash, or runs outside the Windows system path; Microsoft identity lowers masquerade risk but does not clear the arguments.
- Does the parent and user context fit this launch?
- Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, and `user.name`.
- Implication: Office, browser, script-host, archive-tool, remote-admin, or mismatched-user launches make the command abnormal; keep validating only when parent and user context fit the applet, driver, support, or lab workflow named by the command line.
- Did Control Panel hand off to follow-on execution?
- Focus: child starts on the same `host.id` where `process.parent.entity_id` equals the alert `process.entity_id`; review child `process.executable`, `process.command_line`, and `process.pe.original_file_name`. $investigate_0
- Implication: follow-on execution confirms proxy-abuse risk when the chain uses "rundll32.exe" or "Control_RunDLL", or spawns PowerShell, cmd, mshta, regsvr32, wscript, cscript, or another unexpected LOLBin; a clean stop at the expected applet or support component narrows scope.
- Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` near `@timestamp`; treat ambiguity as unresolved.
- Did the referenced path contain staged or renamed payload content?
- Focus: file events for `host.id` + `process.entity_id`, or `host.id` + `process.pid` near `@timestamp`; review `file.path`, `file.Ext.original.path`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. $investigate_1
- Implication: escalate when file events show executable or script content, mismatched headers, recent renames, internet provenance, or payloads under "AppData\\Local" or "Users\\Public"; artifacts confined to the same recognized vendor package layout reduce file concern. Missing file telemetry is unresolved, not benign.
- Did the process or host contact delivery or command-and-control infrastructure?
- Focus: DNS and connection events for `host.id` + `process.entity_id`, or `host.id` + `process.pid` near `@timestamp`; compare DNS `dns.question.name` and `dns.resolved_ip` with `destination.ip` and `destination.port`. $investigate_2
- Implication: escalate when network events show the same process or host reaching rare external domains, payload hosts, or mismatched service ports after launch; urgency drops only when traffic stays limited to the same recognized vendor or internal service. Missing network telemetry is unresolved, not benign.
- Hint: separate DNS events from connection events before correlating `dns.resolved_ip` to `destination.ip`.
- If local evidence is suspicious or unresolved, does related alert activity change the user or host scope?
- Focus: alerts for the same `user.id` showing delivery, persistence, defense evasion, suspicious children, or other proxy-execution utilities such as "rundll32.exe", "mshta.exe", or "regsvr32.exe". $investigate_3
- Hint: use the host pivot separately for the same patterns on `host.id`, especially when user context is absent or shared. $investigate_4
- Implication: broaden scope when either pivot shows related delivery, persistence, proxy execution, or repeated suspicious Control Panel launches; keep local only when local evidence is explained and related alerts do not contradict it.
- Escalate when command intent plus any meaningful corroborator indicates proxy execution, staged payloads, unexpected child execution, suspicious destinations, or spread; close only when alert-local process evidence and supported recovery bind the exact activity to one recognized workflow with no contradictions; if evidence is mixed or visibility is incomplete, preserve artifacts and escalate.
### False positive analysis
- Vendor applets, printer/display drivers, hardware-management packages, support troubleshooting, or lab validation can trigger unusual Control Panel paths. Confirm `process.command_line` names the expected CPL or INF target, `process.executable` is the Microsoft system binary, `process.parent.executable` and `process.parent.command_line` match the installer or support component, `user.id` and `host.id` fit the endpoint or lab cohort, artifacts stay inside the vendor package layout, and no suspicious child process or unexpected external destination follows. Use package, change, or lab records only as corroboration; without them, close only when this case's telemetry binds the exact workflow. Treat it as a candidate exception until records or recurrence confirm stability.
- Before creating an exception, validate that the same `process.executable`, `process.parent.executable`, stable `process.command_line` pattern, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on "control.exe" alone, on a file extension alone, or on a host alone.
### Response and remediation
- If confirmed benign, reverse any temporary containment and document the command, binary identity, parent workflow, account, host, artifact, and destination evidence that proved one recognized workflow. Create an exception only if that same workflow recurs across prior alerts from this rule.
- If suspicious but unconfirmed, preserve a case export with `process.command_line`, `process.entity_id`, parent and child lineage, referenced artifacts, and network indicators when available before containment. Apply reversible containment first, such as temporary egress restrictions or heightened monitoring on the affected `host.id` and `user.id`, and avoid deleting files or killing child processes until follow-on execution is scoped.
- Do not isolate or suspend based on the alert alone. Escalate suspicious-but-unconfirmed cases to host isolation or account action only when child-process, artifact, network, or related-alert evidence shows likely follow-on execution or broader exposure.
- If confirmed malicious, preserve the same process, artifact, and network evidence before destructive action. Isolate the endpoint to stop further execution while keeping telemetry available; if direct endpoint response is unavailable, hand off the preserved `host.id`, `user.id`, `process.entity_id`, and command-line evidence to the team that can isolate the host or suspend the account.
- After scoping related hosts, users, parent processes, command-line fragments, referenced paths, and follow-on children, quarantine or remove the malicious applets, DLLs, scripts, archives, or dropped artifacts identified during the investigation. Restore affected Control Panel or shell-association paths to the expected baseline and verify no persistence remains.
- Post-incident hardening: restrict document-, script-, and archive-driven launches of Control Panel on privileged or shared systems, retain any file or network telemetry that limited the case, and record the confirmed workflow or malicious artifact pattern 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 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.pid",
"process.executable",
"process.command_line",
"process.working_directory",
"process.pe.original_file_name",
"process.parent.entity_id",
"process.parent.name",
"process.parent.executable",
"process.parent.command_line",
]
[transform]
[[transform.investigate]]
label = "Child process events for Control Panel"
description = ""
providers = [
[
{ 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" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "File events for Control Panel"
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 = "Network events for Control Panel"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
],
[
{ 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" }
]
]
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"
@@ -109,10 +232,7 @@ id = "T1218.002"
name = "Control Panel"
reference = "https://attack.mitre.org/techniques/T1218/002/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/windows/defense_evasion_execution_msbuild_started_by_office_app.toml
+135 -60
View File
@@ -2,13 +2,13 @@
creation_date = "2020/03/25"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic"]
description = """
An instance of MSBuild, the Microsoft Build Engine, was started by Excel or Word. This is unusual behavior for the Build
Engine and could have been caused by an Excel or Word document executing a malicious script payload.
An instance of MSBuild, the Microsoft Build Engine, was started by an Office application. This is unusual behavior for
the Build Engine and could have been caused by a malicious document executing a script payload.
"""
false_positives = [
"""
@@ -31,57 +31,7 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Microsoft Build Engine Started by an Office Application"
note = """## Triage and analysis
### Investigating Microsoft Build Engine Started by an Office Application
Microsoft Office (MS Office) is a suite of applications designed to help with productivity and completing common tasks on a computer. You can create and edit documents containing text and images, work with data in spreadsheets and databases, and create presentations and posters. As it is some of the most-used software across companies, MS Office is frequently targeted for initial access. It also has a wide variety of capabilities that attackers can take advantage of.
The Microsoft Build Engine is a platform for building applications. This engine, also known as MSBuild, provides an XML schema for a project file that controls how the build platform processes and builds software, and can be abused to proxy execution of code.
This rule looks for the `Msbuild.exe` utility spawned by MS Office programs. This is generally the result of the execution of malicious documents.
#### 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 abnormal behaviors observed 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.
- Retrieve MS Office documents received and opened by the user that could cause this behavior. Common locations include, but are not limited to, the Downloads and Document folders and the folder configured at the email client.
- Determine if the collected files are malicious:
- Use a private sandboxed malware analysis system to perform analysis.
- Observe and collect information about the following activities:
- Attempts to contact external domains and addresses.
- File and registry access, modification, and creation activities.
- Service creation and launch activities.
- Scheduled task creation.
- Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values.
- 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.
### Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- 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.
- If the malicious file was delivered via phishing:
- Block the email sender from sending future emails.
- Block the malicious web pages.
- Remove emails from the sender from mailboxes.
- Consider improvements to the security awareness program.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = ["https://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html"]
references = ["https://blog.talosintelligence.com/building-bypass-with-msbuild/"]
risk_score = 73
rule_id = "c5dc3223-13a2-44a2-946c-e9dc0aa0449c"
severity = "high"
@@ -90,7 +40,6 @@ tags = [
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Tactic: Execution",
"Resources: Investigation Guide",
"Data Source: Elastic Endgame",
"Data Source: Elastic Defend",
@@ -116,15 +65,144 @@ process where host.os.type == "windows" and event.type == "start" and
"winword.exe" )
'''
note = """## Triage and analysis
### Investigating Microsoft Build Engine Started by an Office Application
#### Possible investigation steps
- What Office-to-MSBuild path did the alert capture?
- Focus: `process.parent.name`, `process.parent.executable`, `process.executable`, and `process.command_line`.
- Implication: escalate when Office launches MSBuild from a user-writable path or against a project, response, or import path unrelated to document work; lower suspicion only when the Office parent, working directory, project argument, and user-host pair align to one add-in, template-packaging, or test case.
- Is the MSBuild binary the expected Microsoft Build Engine instance?
- Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
- Implication: escalate when MSBuild is renamed, unsigned, recently introduced, user-writable, or not signed by the expected Microsoft publisher; lower suspicion when path, original name, signer, and hash history fit the installed Microsoft Build Engine. Identity alone does not clear the Office launch.
- Do the MSBuild arguments indicate inline-task or staged-project abuse?
- Why: MSBuild can execute project-defined tasks, making project or response-file paths the alert-local clue for developer tooling versus payload staging.
- Focus: `process.command_line` and same-process file activity for project or response artifacts. $investigate_0
- Implication: escalate when arguments point to XML, project, response, or imported files in temp, downloads, archive, cache, mail, or relative paths, or when targets do not fit user compilation; lower suspicion when the same project path, target set, and working directory match a recognized developer or packaging workflow.
- Does the parent and user context explain this Office-launched build?
- Focus: `process.parent.command_line`, `user.id`, `host.id`, and `host.name`.
- Implication: escalate when a standard Office user, shared workstation, or unusual parent command line triggers MSBuild without a matching project path and child helper pattern; lower suspicion when `user.id`, `host.id`, parent command line, project path, and child helpers converge on developer packaging or authorized testing.
- Did MSBuild spawn compiler helpers only, or did it hand off to payload tooling?
- Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, then child `process.executable` and `process.command_line`. $investigate_1
- Hint: if `process.entity_id` is absent, recover child starts with `host.id` + `process.pid` + a tight alert window; treat the result as weaker than exact lineage.
- Implication: escalate when MSBuild launches shells, scripting engines, browsers, LOLBins, installers, or children from unexpected paths; lower suspicion when telemetry shows no child starts or only expected compiler helpers such as csc.exe and cvtres.exe for the same recognized project path. Missing child-process telemetry is unresolved, not benign.
- If local evidence is suspicious or unresolved, is this part of a broader Office proxy-execution pattern?
- Focus: related alerts for the same `user.id`, especially Office-to-script, Office-to-LOLBin, persistence, or credential-access activity. $investigate_2
- Hint: check whether the same `host.id` shows Office-launched rundll32.exe, regsvr32.exe, mshta.exe, PowerShell, or suspicious child-process alerts. $investigate_3
- Implication: broaden scope and raise priority when either pivot shows related proxy execution or follow-on alerts; keep localized when related alerts are absent and local evidence points to one stable Office parent, MSBuild project path, child helper pattern, and user-host pair.
- Escalate when identity, arguments, parent context, child behavior, or related alerts show abnormal Office-launched MSBuild execution; close only when the same signer, parent command line, project path, child helper pattern, `host.id`, and `user.id` support a recognized workflow with no contradictory findings; preserve evidence and escalate when visibility or answers remain mixed.
### False positive analysis
- Office add-in, template, document-packaging, or controlled testing workflows can legitimately trigger this rule. Confirm from process evidence that `process.executable`, `process.code_signature.subject_name`, the project or response-file pattern in `process.command_line`, `process.parent.executable`, `process.parent.command_line`, child `process.executable`, and the `user.id` plus `host.id` pair align to the same workflow. When telemetry cannot prove purpose, require outside confirmation before closing; use recurrence only after confirmation to judge exception stability.
- Before creating an exception, validate that the same user-host cohort shows a stable recognized workflow across prior alerts. Keep `process.code_signature.subject_name`, `process.executable`, `process.parent.executable`, the project or response-file pattern in `process.command_line`, `user.id`, and `host.id` stable; allow `process.hash.sha256` changes only when signer, path, and workflow remain consistent with normal updates. Avoid exceptions on `process.name`, Office parent name, or `user.name` alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and record the evidence that validated the workflow: MSBuild signer and path, project-path pattern in `process.command_line`, Office parent context, child-process pattern, and the `user.id` plus `host.id` cohort. Create an exception only after the same pattern recurs consistently across prior alerts.
- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, recovered child entity IDs, `process.command_line`, Office parent command line, and project or response-file paths named in the command line before containment. Apply reversible controls first, such as heightened monitoring, temporary delivery blocks, or endpoint isolation when host criticality allows; avoid process termination or file deletion until lineage and scope are clearer.
- If confirmed malicious, preserve the same process and project evidence, then contain the affected `host.id` or `user.id` based on the child-process chain, payload handoff, or related alerts. Block confirmed malicious indicators recovered during the case, collect suspicious project or response files before deletion, and terminate malicious processes only after recording their entity IDs and command lines.
- Eradicate only artifacts tied to the investigated process chain: malicious Office content, MSBuild project or response files, scripts, build outputs, and follow-on payloads identified from child-process execution. Remediate the delivery path that let Office launch the build chain, then scope other `host.id` and `user.id` values for the same project-path pattern or child-process sequence before broader cleanup.
- Post-incident hardening: restrict Office macro, add-in, and template paths that can invoke developer utilities; retain the process evidence that supported the case; record adjacent Office-launched proxy-execution variants in the case notes 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 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.pid",
"process.executable",
"process.command_line",
"process.pe.original_file_name",
"process.working_directory",
"process.code_signature.subject_name",
"process.code_signature.trusted",
"process.parent.executable",
"process.parent.command_line",
]
[transform]
[[transform.investigate]]
label = "File events for MSBuild process"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Child process events for MSBuild"
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"
[[rule.threat.technique]]
id = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"
[[rule.threat.technique.subtechnique]]
id = "T1127.001"
name = "MSBuild"
@@ -134,15 +212,12 @@ reference = "https://attack.mitre.org/techniques/T1127/001/"
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[rule.threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
rules/windows/defense_evasion_execution_windefend_unusual_path.toml
+165 -35
View File
@@ -2,7 +2,7 @@
creation_date = "2021/07/07"
integration = ["endpoint", "windows", "m365_defender", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic", "Dennis Perto"]
@@ -24,39 +24,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Suspicious Microsoft Antimalware Service Execution"
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 Microsoft Antimalware Service Execution
The Microsoft Antimalware Service Executable, a core component of Windows Defender, is crucial for real-time protection against malware. Adversaries exploit its trust by renaming it or executing it from non-standard paths to load malicious DLLs, bypassing security measures. The detection rule identifies such anomalies by monitoring process names and paths, flagging deviations from expected behavior to uncover potential threats.
### Possible investigation steps
- Review the process details to confirm if the process name is MsMpEng.exe but is executing from a non-standard path. Check the process.executable field to identify the exact path and verify if it deviates from the expected directories.
- Investigate the parent process of the suspicious MsMpEng.exe instance to determine how it was initiated. This can provide insights into whether the process was started by a legitimate application or a potentially malicious one.
- Examine the system for any recent file modifications or creations in the directory where the suspicious MsMpEng.exe is located. This can help identify if a malicious DLL was recently placed in the same directory.
- Check for any network connections or communications initiated by the suspicious MsMpEng.exe process. This can help determine if the process is attempting to communicate with external servers, which may indicate malicious activity.
- Look for any other processes or activities on the host that may indicate compromise, such as unusual user account activity or other processes running from unexpected locations. This can help assess the broader impact of the potential threat.
### False positive analysis
- Legitimate software updates or installations may temporarily rename or relocate the Microsoft Antimalware Service Executable. Users should verify if any software updates or installations occurred around the time of the alert and consider excluding these paths if they are known and trusted.
- Custom security or IT management tools might execute the executable from non-standard paths for monitoring or testing purposes. Confirm with IT or security teams if such tools are in use and add these paths to the exclusion list if they are verified as safe.
- Virtualization or sandbox environments may replicate the executable in different locations for testing or analysis. Check if the environment is part of a controlled setup and exclude these paths if they are part of legitimate operations.
- Backup or recovery processes might involve copying the executable to alternate locations. Ensure these processes are legitimate and consider excluding these paths if they are part of routine operations.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further spread of the potential threat.
- Terminate any suspicious processes identified by the detection rule, specifically those involving MsMpEng.exe running from non-standard paths.
- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious DLLs or other malware.
- Review and restore any altered or deleted system files from a known good backup to ensure system integrity.
- Investigate the source of the DLL side-loading attempt to determine if it was part of a broader attack campaign, and gather forensic evidence for further analysis.
- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to assess the need for further containment measures.
- Implement additional monitoring and alerting for similar anomalies in process execution paths to enhance detection capabilities and prevent recurrence."""
references = [
"https://news.sophos.com/en-us/2021/07/04/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses/",
]
@@ -69,7 +36,6 @@ tags = [
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Data Source: Elastic Endgame",
"Tactic: Execution",
"Data Source: Elastic Defend",
"Data Source: Sysmon",
"Data Source: Microsoft Defender XDR",
@@ -103,6 +69,170 @@ process where host.os.type == "windows" and event.type == "start" and
)
'''
note = """## Triage and analysis
### Investigating Suspicious Microsoft Antimalware Service Execution
#### Possible investigation steps
- Which Defender identity anomaly did the alert capture?
- Focus: `process.name`, `process.pe.original_file_name`, `process.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
- Implication: escalate when `process.pe.original_file_name` is "MsMpEng.exe" under renamed `process.name`, or `process.name` is "MsMpEng.exe" outside Defender/Microsoft Security Client paths, even with trusted Microsoft signing; lower suspicion only when exact path, signer, and name pattern fit controlled packaging, recovery, or malware-analysis copy.
- Does the path, file timing, and parent context look like staged Defender abuse?
- Why: unusual-path Defender binaries can load same-folder DLLs through search-order behavior, so path and parent context separate masquerading or side-loading from controlled copies.
- Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, `process.parent.executable`, and `process.parent.command_line`.
- Implication: escalate when the binary is fresh, recently renamed, or launched from user-writable, temp, share, archive, agent working, or Windows staging paths by a script, archive tool, RMM agent, or dropper parent; path age and parent context support benign closure only if later side-loading and launcher checks do not contradict them.
- Does the user, token, and session context fit Defender service execution?
- Focus: `user.id`, `user.name`, `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`.
- Implication: escalate when the process runs under an interactive/domain user, a non-service logon, or a user-level token that does not fit antimalware service startup; SYSTEM or service context lowers only the session concern and does not clear the unusual path by itself.
- If file or library telemetry is available, is there same-directory staging or DLL side-loading evidence?
- Focus: recover file and library events with `host.id` plus `process.entity_id` when present, or `host.id` plus `process.pid` and a tight alert window; inspect `file.path`, `dll.path`, `dll.name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. $investigate_0
- Hint: missing file or library telemetry is unresolved, not benign; prioritize same-folder DLLs whose path, signer, or creation time does not fit the product layout, plus artifacts created before `process.executable` started.
- Implication: escalate when the unusual Defender copy loads a recent, unsigned/untrusted same-folder DLL or the directory contains newly staged executables, DLLs, scripts, archives, or renamed files; complete recovery with only expected Microsoft components lowers side-loading concern.
- Does the process act as a launcher rather than a passive service component?
- Focus: child process events where `process.parent.entity_id` matches suspicious `process.entity_id`, repeated starts from `process.executable` on `host.id`, and child `process.name`, `process.executable`, and `process.command_line`.
- $investigate_1
- $investigate_2
- Implication: escalate when it starts shells, PowerShell, certutil, netsh, installers, encryption tooling, or other hands-on-keyboard utilities, or when repeated launches suggest staged execution; no child or repeat behavior lowers launcher concern but does not clear the path anomaly.
- If local findings stay suspicious or unresolved, do related alerts show path reuse or host compromise?
- Focus: related alerts for `process.executable`, especially unusual-path Defender, masquerading, or side-loading detections.
- $investigate_3
- Hint: also review related alerts for `host.id` or `user.id`, especially staging, persistence, credential-access, ransomware, or other masquerading detections.
- $investigate_4
- $investigate_5
- Implication: broaden scope when the same path appears on unrelated hosts or the host has precursor or follow-on alerts; keep the case local only when related alerts show no reuse or follow-on activity and all local evidence is clean.
- Escalate when Defender identity/path evidence plus one meaningful corroborator supports masquerading or DLL side-loading; close only when exact path, signer, parent, session, host/user scope, and optional outside confirmation tie to one controlled workflow with no contradictory telemetry; preserve artifacts and escalate when findings stay mixed or visibility is incomplete.
### False positive analysis
- A non-default Defender installation, controlled security packaging, recovery, or malware-analysis validation can stage Microsoft antimalware binaries outside default paths. Confirm the same workflow by matching exact `process.executable`, `process.hash.sha256` or `process.code_signature.thumbprint_sha256`, Microsoft `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, `process.parent.command_line`, `user.id`, `host.id`, and session pattern; without outside records, require recurrence across prior rule alerts without side-loading, launcher, or related-alert contradictions.
- Treat production execution from temp, user-writable, share, archive, agent working, or Windows staging paths as an operational anti-pattern unless a controlled workflow proves why the copy exists. Do not close as benign when same-folder DLLs, child tooling, recent rename timing, or unrelated related alerts contradict it.
- Build exceptions only from the minimum confirmed workflow pattern; avoid exceptions on `process.name`, `process.pe.original_file_name`, signer subject alone, or host alone.
### Response and remediation
- If confirmed benign, reverse any temporary containment and document the exact workflow: executable path, Microsoft signer or hash, parent process, session context, user/host scope, and any controlled packaging, recovery, or lab record that corroborated the telemetry. Create an exception only after the same narrow workflow pattern is stable across prior alerts.
- If suspicious but unconfirmed, preserve the alert details, process tree, command line, binary copy and hash, parent context, directory listing, same-folder DLLs, and related-alert timeline before containment. Apply reversible containment first, such as execution prevention on the suspicious path or temporary host isolation when active launcher behavior or side-loading creates continuing risk and the host role can tolerate interruption.
- If confirmed malicious, preserve process and artifact evidence first, including the suspicious Defender copy, same-folder DLLs, support files, launcher context, and related-alert timeline. Then isolate the host or apply an equivalent endpoint containment control, terminate only the suspicious non-default-path or renamed Defender instance, quarantine the suspicious executable and supporting files, remove launcher or persistence artifacts found during scoping, and restore the legitimate security product from known-good media if the masquerading copy replaced or shadowed a trusted component.
- After containment, restrict execution from user-writable, temporary, share, archive, and agent working directories where feasible, retain process/file/library telemetry that affected this case, and document the confirmed benign workflow or malicious artifact set 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)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.name",
"host.id",
"user.name",
"user.id",
"process.entity_id",
"process.pid",
"process.name",
"process.executable",
"process.command_line",
"process.pe.original_file_name",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.subject_name",
"process.code_signature.trusted",
]
[transform]
[[transform.investigate]]
label = "File and library events for the suspicious 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" }
],
[
{ 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 = "library", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Child process events for the suspicious process"
description = ""
providers = [
[
{ 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" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Process events for the suspicious executable path"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.executable", queryType = "phrase", value = "{{process.executable}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the suspicious executable path"
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 = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/defense_evasion_iis_httplogging_disabled.toml
+121 -37
View File
@@ -2,7 +2,7 @@
creation_date = "2020/04/14"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic"]
@@ -25,40 +25,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "IIS HTTP Logging Disabled"
note = """## Triage and analysis
### Investigating IIS HTTP Logging Disabled
IIS (Internet Information Services) is a Microsoft web server software used to host websites and web applications on Windows. It provides features for serving dynamic and static content, and can be managed through a graphical interface or command-line tools.
IIS logging is a data source that can be used for security monitoring, forensics, and incident response. It contains mainly information related to requests done to the web server, and can be used to spot malicious activities like webshells. Adversaries can tamper, clear, and delete this data to evade detection, cover their tracks, and slow down incident response.
This rule monitors commands that disable IIS logging.
#### 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.
- Verify whether the logs stored in the `C:\\inetpub\\logs\\logfiles\\w3svc1` directory were deleted after this action.
- Check if this operation is done under change management and approved according to the organization's policy.
### 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.
- 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 = "ebf1adea-ccf2-4943-8b96-7ab11ca173a5"
severity = "high"
@@ -86,15 +52,133 @@ process where host.os.type == "windows" and event.type == "start" and
not process.parent.name : "iissetup.exe"
'''
note = """## Triage and analysis
### Investigating IIS HTTP Logging Disabled
#### Possible investigation steps
- What IIS HTTP logging scope did AppCmd disable?
- Focus: `process.command_line`: "dontLog" value, site/application target, "system.webServer/httpLogging", and apphost commit.
- Implication: escalate when production-site or server-wide successful-request logging is disabled, because webshell traffic may leave no IIS log trail; lower suspicion when scope and timing fit a narrow non-production logging test, migration, or recovery action.
- Is this the expected IIS AppCmd utility?
- Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`.
- Implication: escalate when AppCmd is renamed, unsigned, or outside the IIS administration path; lower suspicion when trusted Microsoft AppCmd runs from that path. Identity alone never clears disablement.
- Does the operator and session context fit IIS administration on this host?
- Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`.
- Hint: if session enrichment is absent, keep session unresolved and rely on operator plus parent-lineage evidence; absence is not benign.
- Implication: escalate when a rare operator, service-account misuse, unexpected remote-interactive/network session, or newly elevated token made the change; lower suspicion when the operator/session pattern is recognized for this IIS host.
- What launched AppCmd?
- Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.entity_id`.
- Implication: escalate when the launcher includes web workers, shells, script hosts, archive tools, or web-content chains; lower suspicion when lineage stays inside one recognized IIS management/deployment workflow.
- Do surrounding process commands show cleanup or adjacent IIS anti-forensics?
- Focus: process starts from the same AppCmd parent on the same `host.id`, reading `process.command_line`. $investigate_2
- Hint: prefer `process.entity_id` or `process.parent.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window and treat the join as weaker.
- Implication: escalate for log deletion, "applicationHost.config"/"web.config" rewrites, PowerShell IIS configuration changes, or no re-enable command after a temporary-change explanation; lower suspicion when commands only re-enable logging or stay inside the same recognized IIS workflow.
- If local evidence remains suspicious or unresolved, do related alerts change scope or urgency?
- Focus: related alerts for the same `user.id`, emphasizing webshell, archive, persistence, anti-forensics, or suspicious IIS tooling. $investigate_0
- Hint: the host-scoped alert view for the same `host.id` separates one operator's history from server activity. $investigate_1
- Implication: broaden response when either scope shows precursor webshell access, staging, persistence, or repeated anti-forensics; keep the case local only when related alerts stay limited to the same recognized maintenance window.
- Escalate on unauthorized logging disablement, suspicious lineage, missing re-enable evidence, or adjacent IIS compromise; close only when scope, identity, operator/session, lineage, surrounding activity, and related alerts match one recognized workflow and external confirmation verifies exact activity telemetry cannot prove; preserve evidence and escalate when evidence is mixed or incomplete.
### False positive analysis
- IIS migration, recovery, short troubleshooting, or controlled logging tests can trigger this rule. Confirm trusted Microsoft AppCmd from the IIS administration path, intended site/application scope in `process.command_line`, recognized `user.id`, matching parent workflow, and re-enable process evidence for temporary changes. Use change records or owner confirmation only after process evidence matches; conflicting process evidence blocks benign closure. If records are unavailable, require the same AppCmd path, signer, parent workflow, targeted IIS scope, operator, session type, and `host.id` to recur across prior alerts. A different target, operator, lineage, or missing re-enable command keeps the alert unresolved.
- Before creating an exception, validate the same AppCmd identity (`process.executable` plus `process.code_signature.subject_name`), parent executable, command scope, `user.id`, and `host.id` across prior alerts. Avoid exceptions on AppCmd alone, "/dontLog" alone, or the host alone.
### Response and remediation
- If suspicious but unconfirmed, preserve the alert record, `process.entity_id`, `process.command_line`, targeted IIS scope, parent lineage, operator/session fields, related-alert context, remaining IIS logs, and current IIS configuration before containment. Apply reversible containment first, and weigh host criticality before isolating internet-facing or revenue-bearing IIS servers.
- If confirmed benign, reverse temporary containment and document the AppCmd path, targeted IIS scope, operator, session type, parent lineage, re-enable evidence, and external confirmation that justified closure. Create an exception only after the same pattern recurs.
- If confirmed malicious, contain the host or administrative session when command scope, lineage, operator context, or related alerts show unauthorized anti-forensics. Record the same evidence set before terminating processes, killing sessions, deleting artifacts, or changing IIS configuration.
- Re-enable IIS HTTP logging at the affected site or server scope, export remaining IIS logs before rotation, restore deleted logs from backups or snapshots when possible, and compare "applicationHost.config" or "web.config" changes tied to the same activity.
- Eradicate only the webshells, scripts, archives, persistence artifacts, and configuration changes uncovered during the investigation. Rotate credentials when the operator/session evidence suggests account compromise, then remediate the initial access or administrative-control failure that allowed logging to be disabled.
- After containment, scope other hosts for the same AppCmd arguments, IIS configuration-edit commands, log-cleanup commands, and adjacent IIS anti-forensics variants. Retain the process and case-export evidence that supported the final disposition.
"""
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.parent.entity_id",
"process.parent.executable",
"process.parent.command_line",
"process.pe.original_file_name",
"process.code_signature.subject_name",
"process.code_signature.trusted",
"process.Ext.session_info.logon_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"
[[transform.investigate]]
label = "Process starts from the same AppCmd parent"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" },
{ 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"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.002"
name = "Disable Windows Event Logging"
rules/windows/defense_evasion_indirect_exec_conhost.toml
+168 -27
View File
@@ -2,7 +2,7 @@
creation_date = "2025/08/21"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic"]
@@ -25,31 +25,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Proxy Execution via Console Window Host"
note = """## Triage and analysis
### Investigating Proxy Execution via Console Window Host
### Possible investigation steps
- Review the conhost child processes and the parent process to identify the initial vector.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
### False positive analysis
- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified.
### 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.
- 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://lolbas-project.github.io/lolbas/Binaries/Conhost/"]
risk_score = 73
rule_id = "fcd16fe8-eb29-42b3-8aee-6c9ad777a2f6"
@@ -74,9 +49,175 @@ type = "eql"
query = '''
process where host.os.type == "windows" and event.type == "start" and
process.name : "conhost.exe" and process.args : "--headless" and
process.command_line : ("*powershell*", "*cmd *", "*cmd.exe *", "*script*", "*mshta*", "*curl *", "*curl.exe *", "*^*^*^*", "*.bat*", "*.cmd*", "*schtasks*", "*@SSL*", "*http*", "* \\\\*", "*.vbs*", "*.js*", "*mhsta*")
process.command_line : (
"*powershell*", "*cmd *", "*cmd.exe *", "*script*", "*mshta*", "*curl *", "*curl.exe *", "*^*^*^*",
"*.bat*", "*.cmd*", "*schtasks*", "*@SSL*", "*http*", "* \\\\*", "*.vbs*", "*.js*", "*mhsta*"
) and
not (
/* Winget-AutoUpdate via ServiceUI */
process.parent.executable : "?:\\Program Files\\winget-autoupdate*\\serviceui.exe" or
/* Winget-AutoUpdate notification via Task Scheduler */
(
process.parent.executable : "?:\\Windows\\System32\\svchost.exe" and process.parent.args : "-s" and
process.parent.args : "Schedule" and process.command_line : "*WAU-Notify.ps1*"
) or
/* Windows OpenSSH console host — SSH-specific detection handled by 8cd49fbc-a35a-4418-8688-133cc3a1e548 */
process.parent.executable : (
"?:\\Windows\\System32\\OpenSSH\\sshd.exe",
"?:\\Windows\\System32\\OpenSSH\\sshd-session.exe",
"?:\\Program Files\\OpenSSH*\\sshd.exe",
"?:\\Program Files\\OpenSSH*\\sshd-session.exe"
)
)
'''
note = """## Triage and analysis
### Investigating Proxy Execution via Console Window Host
#### Possible investigation steps
- What command did the headless conhost instance proxy?
- Why: `--headless` can hide the child window behind conhost, so command intent and child-process evidence outweigh conhost identity alone.
- Focus: `process.command_line` for `--headless` and the proxied family: shell, script host, retrieval, UNC, caret-escaped, batch, or scheduled-task action.
- Implication: escalate when headless conhost proxies script execution, remote retrieval, scheduled-task changes, or lateral-path commands; lower suspicion only when command, launcher, user, and host match remote-admin console management, deployment automation, or installer/update helper use and later process evidence does not contradict it.
- Is this the native conhost binary or a masqueraded copy?
- Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; compare the path with `C:\\Windows\\System32\\conhost.exe`.
- Implication: escalate when conhost is renamed, unsigned, user-writable, host-new by hash, or signed by an unexpected publisher; native signed identity lowers masquerade concern but not suspicious `--headless` proxy execution.
- Which launcher produced headless conhost?
- Focus: `process.parent.executable`, `process.parent.command_line`, and `process.parent.entity_id`.
- Implication: escalate when the launcher is Office, a browser, a script host, a temp or user-writable binary, another LOLBin, or a remote-management tool outside its console-management pattern; lower suspicion when the same parent is a stable console, deployment, or update path for the same `user.id` and `host.id`.
- Do the user and session context fit the same admin or deployment use?
- Focus: `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`.
- Implication: escalate when session type, account, or authentication ID is unusual for that `host.id` and user cohort or ties to unrelated suspicious processes; lower suspicion when user, host cohort, session type, command, and lineage match the same remote-admin, deployment, or update use.
- Did headless conhost spawn the command family named in the alert?
- Focus: child process starts on `host.id` where `process.parent.entity_id` matches alert `process.entity_id`; read `process.name`, `process.executable`, and `process.command_line`. $investigate_0
- Hint: if `process.entity_id` is absent, query the same `host.id` with alert `process.pid` in a tight alert-time window; treat matches as weaker because PID reuse is possible.
- Implication: escalate when conhost spawns shell, script-host, downloader, scheduled-task, or payload-like children; keep scope local only when no child execution appears and earlier evidence fits the same named admin, deployment, or update use.
- If local evidence is suspicious or unresolved, is this isolated or broader proxy execution?
- Focus: process-start history for the same `host.id` and, if needed, `user.id`; compare `process.command_line`, `process.parent.executable`, and child-process patterns.
- $investigate_1
- $investigate_2
- Hint: review related alerts for the same `host.id` and `user.id`, especially script execution, downloader, scheduled-task, credential-tool, or other proxy-execution activity.
- $investigate_3
- $investigate_4
- Implication: escalate scope when the same host or user shows repeated headless conhost proxy execution, suspicious launchers, or related script, downloader, scheduled-task, or credential-tool processes; lack of history does not clear suspicious command, lineage, session, or child-process evidence.
- Escalate on unauthorized headless proxy execution plus suspicious identity, launcher, session, child-process, or repeat-alert corroboration; close only when command, identity, lineage, session, and child-process evidence bind to one named benign use case below; preserve evidence and escalate when evidence is mixed or incomplete.
### False positive analysis
- Remote-administration, console-management, deployment automation, installer, or update agents can launch headless conhost when a named tool uses console helpers. Confirm that native `process.executable`, stable `process.parent.executable`, `process.parent.code_signature.subject_name`, `process.parent.code_signature.trusted`, parent and child `process.command_line`, `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and child-process pattern all align with that tool or product path. Tool inventories, change records, or owner confirmation can corroborate telemetry-backed use, but should not replace missing or contradictory process evidence. If command, parent, session, or child evidence diverges, or the first cohort event includes retrieval, UNC, script-host, or scheduled-task behavior outside that path, treat it as unresolved or suspicious.
- Before creating an exception, verify that native `process.executable`, parent identity, exact `process.command_line`, `user.id`, `host.id`, and session type recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern; avoid exceptions on `process.name`, the conhost filename, or `--headless` alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and record the command intent, native conhost identity, parent lineage, `user.id`, `host.id`, session type, and child-process evidence that justified closure. Create an exception only when that same admin, deployment, or update pattern recurs consistently across prior alerts.
- If suspicious but unconfirmed, preserve the alert, process tree export, command lines, hash and signer details, `process.entity_id`, `process.parent.entity_id`, `process.Ext.authentication_id`, child-process events, and any scripts or task definitions named in the command line before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected `user.id`, `host.id`, or parent tool, and avoid process termination until scope is clearer.
- If confirmed malicious, contain the host or affected account when command intent, launcher lineage, session context, or child-process evidence establishes unauthorized proxy execution. Record the process identifiers, command lines, signer and hash evidence, user and host anchors, and child-process chain before terminating processes, deleting scripts, disabling scheduled tasks, or isolating accounts.
- Eradicate only the scripts, task definitions, copied tools, or persistence mechanisms identified during the investigation, then remediate the launcher, automation path, or access path that allowed headless conhost to proxy the command.
- Rotate credentials only when the user and session evidence or adjacent case evidence confirms account misuse, remote abuse, or privileged account compromise; otherwise keep identity action proportional to the confirmed process evidence.
- After containment, scope other hosts and users for the same `process.command_line`, `process.parent.executable`, `process.hash.sha256`, parent signer, or child-process pattern. Retain the process telemetry and response notes needed to distinguish repeat benign console automation from repeat proxy execution.
"""
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.pid",
"process.executable",
"process.pe.original_file_name",
"process.command_line",
"process.Ext.authentication_id",
"process.Ext.session_info.logon_type",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.trusted",
]
[transform]
[[transform.investigate]]
label = "Child process starts from the same conhost 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 = "Process history on the same 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" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Process history for the same user"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", 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 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"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/defense_evasion_indirect_exec_openssh.toml
+161 -31
View File
@@ -2,13 +2,13 @@
creation_date = "2025/08/21"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic"]
description = """
Identifies attempts to execute commands via proxy using the Windows OpenSSH client. This may indicate an attempt to bypass
application control via trusted windows binaries.
Identifies attempts to execute commands via proxy using the Windows OpenSSH client. This may indicate an attempt
to bypass application control via trusted Windows binaries.
"""
from = "now-9m"
index = [
@@ -25,31 +25,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Proxy Execution via Windows OpenSSH"
note = """## Triage and analysis
### Investigating Proxy Execution via Windows OpenSSH
### Possible investigation steps
- Review the ssh child processes and the parent process to identify the initial vector.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
### False positive analysis
- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified.
### 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.
- 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://lolbas-project.github.io/lolbas/Binaries/Ssh/"]
risk_score = 73
rule_id = "8cd49fbc-a35a-4418-8688-133cc3a1e548"
@@ -73,14 +48,169 @@ type = "eql"
query = '''
process where host.os.type == "windows" and event.type == "start" and process.name : ("ssh.exe", "sftp.exe") and
process.command_line : ("*Command=*powershell*", "*schtasks*", "*Command=*@echo off*", "*Command=*http*", "*Command=*mshta*", "*Command=*msiexec*",
"*Command=*cmd /c*", "*Command=*cmd.exe*", "*Command=\"cmd /c*", "*LocalCommand=scp*&&*", "*LocalCommand=?scp*&&*", "*Command=*script*")
process.command_line : (
"*Command=*powershell*", "*schtasks*", "*Command=*@echo off*", "*Command=*http*",
"*Command=*mshta*", "*Command=*msiexec*", "*Command=*cmd /c*", "*Command=*cmd.exe*",
"*Command=\"cmd /c*", "*LocalCommand=scp*&&*", "*LocalCommand=?scp*&&*", "*Command=*script*"
)
'''
note = """## Triage and analysis
### Investigating Proxy Execution via Windows OpenSSH
#### Possible investigation steps
- What OpenSSH execution path did the alert capture?
- Why: "ProxyCommand" launches a local helper through the user's shell, "LocalCommand" runs locally after connection only when "PermitLocalCommand" is enabled, and remote command options shift the action to the SSH target.
- Focus: `process.name` and `process.command_line`, separating "ProxyCommand", "LocalCommand", "RemoteCommand", chained "scp"/"sftp", shell/LOLBIN helpers, and loopback targets like "localhost" or "127.0.0.1".
- Implication: escalate when the option runs "cmd.exe", "powershell.exe", "mshta.exe", "msiexec.exe", "schtasks.exe", a downloader, script, or chained copy/execution command; close is plausible only when it stays inside a recognized bastion, transfer, or deployment pattern with no execution-oriented helper.
- Is the OpenSSH client and launcher context expected for that behavior?
- Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`, checking native "C:\\Windows\\System32\\OpenSSH\\" use versus renamed or user-writable copies.
- Implication: escalate when identity or lineage is inconsistent, such as an unsigned or renamed client, a user-writable path, Office/browser/script-host ancestry, or another LOLBin as the launcher; a native signed client lowers only masquerade risk and does not clear proxy execution.
- Does the user and logon session fit recognized SSH automation on this host?
- Focus: `user.id`, `user.name`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`.
- Hint: if session origin matters, pivot on `host.id` from `process.Ext.authentication_id` to Windows Security `winlog.event_data.TargetLogonId`, then read `source.ip` and `winlog.event_data.AuthenticationPackageName`; search `winlog.event_data.SubjectLogonId` for explicit-credential event 4648. Missing Windows Security telemetry is unresolved, not benign. $investigate_4
- Implication: escalate when the session is remote-interactive, network-origin, explicit-credential, or tied to a user/host pair that does not normally run this SSH pattern; lower concern only when the same identity, launcher, and command profile are recurrent for this host and no other evidence conflicts.
- Did the client reach the destination implied by the SSH option path?
- Focus: process-scoped DNS and connections for `host.id` and `process.entity_id`; read `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.port`. $investigate_2
- Hint: if `process.entity_id` is unavailable, rerun with `host.id` + `process.pid` in the alert window. Interpret DNS lookups separately from connections. Missing network or DNS telemetry is unresolved, not benign; loopback `destination.ip` supports proxy-execution when the command targets localhost.
- Implication: escalate when the process reaches loopback listeners, rare public infrastructure, unrelated internal systems, or admin ports outside the expected SSH workflow; bounded destinations matching the same operator and command pattern reduce scope but do not override suspicious local execution.
- Did the proxied path create local child execution or transfer artifacts?
- Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, plus manually queried file events scoped to the same process; read child `process.command_line`, staged `file.path`, and rename context from `file.Ext.original.path`. $investigate_3
- Hint: if process-scoped pivots are unavailable, repeat with `host.id` + `process.pid` in a tight alert window and compare child commands or file writes to the OpenSSH option string. Missing file telemetry limits artifact review; it is not benign.
- Implication: escalate when OpenSSH spawns shells, script hosts, scheduled-task helpers, or drops/copies executable, archive, or script content into new paths; absence of child/file evidence keeps the case process-local only when earlier command, lineage, and destination evidence fit.
- If local evidence remains suspicious or unresolved, does the pattern recur beyond this event?
- Focus: recent alerts for `host.id`, keyed to OpenSSH proxy execution, script hosts, downloaders, scheduled tasks, credential access, or the suspicious `process.command_line` fragment. $investigate_1
- Hint: if host scope stays unresolved, pivot to `user.id` for the same launcher, command fragment, or recovered destination pattern across other hosts. $investigate_0
- Implication: broaden scope when the same proxy-execution pattern, destination, or follow-on artifact appears on unrelated hosts or sessions; a single event supports closure only when the local evidence already binds to one exact recognized workflow and outside confirmation covers any legitimacy gap.
- What disposition do command intent, identity, lineage, session, destination, artifacts, and recurrence support?
- Implication: escalate for unauthorized local proxy execution, suspicious launcher/session context, rare or loopback destinations, staging, child shells, or repeated indirect execution; close only when alert-local evidence and recovery bind one recognized workflow on this host and outside confirmation verifies any telemetry gap; preserve evidence and escalate when evidence is mixed or incomplete.
### False positive analysis
- Recognized jump-host or bastion wrappers can use the native OpenSSH client with "ProxyCommand" for a fixed proxy helper or "RemoteCommand" for a bounded admin task. Confirm binary identity, launcher, option string, `user.id`, `host.id`, recovered destination, and child/file evidence all align with one workflow. Shell or LOLBin-bearing "ProxyCommand" and "LocalCommand" remain suspicious unless a controlled test or deployment wrapper is confirmed by telemetry and outside context.
- Recognized transfer or sync jobs can use "sftp.exe" or chained "scp" from a fixed automation account or host. Confirm `process.parent.executable`, transfer-oriented `process.command_line`, recovered `file.path`, destination evidence, `user.id`, and `host.id` stay inside that product workflow. Keep the alert suspicious if child `process.command_line` activity, scheduled-task helpers, executable staging, or SSH configuration changes diverge from the transfer pattern.
- Before creating an exception, validate recurrence for the same `process.executable`, `process.parent.executable`, option-bearing `process.command_line`, `user.id`, `host.id`, and recovered destination or transfer path. Avoid exceptions on "ssh.exe", "sftp.exe", or "Command=" alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the exact command, launcher, user, host, destination or transfer path, and session evidence that justified closure. Create an exception only for the minimum recurring workflow pattern, not for OpenSSH use in general.
- If suspicious but unconfirmed, preserve the alert, Timeline view, command line, parent/child process tree, recovered destination or DNS evidence, staged/copied files, relevant authentication records, and SSH client/server configuration files before containment or cleanup. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring for the affected user and host, and avoid process termination until scope is clearer.
- If confirmed malicious, isolate the host or contain the account when command intent, launcher lineage, destination, authentication, or artifact evidence shows unauthorized proxy execution. Weigh host criticality before isolation, block confirmed malicious destinations or hashes, and record the process instance and artifact identifiers before killing processes or deleting files.
- Eradicate only the artifacts and settings found during the investigation: copied payloads, scripts, scheduled tasks, downloaded content, unauthorized "ProxyCommand", "LocalCommand", or "PermitLocalCommand" settings, and any malicious key material such as unexpected ".ssh\\authorized_keys" or "%PROGRAMDATA%\\ssh\\administrators_authorized_keys" entries. Then remediate the launcher or access path that allowed the OpenSSH proxy launch.
- Rotate credentials, tokens, and SSH keys when authentication records, session origin, transferred files, or key artifacts show explicit-credential abuse, privileged account misuse, or unauthorized key-based access. Review adjacent admin sessions for the same `source.ip`, `host.id`, or `user.id` before restoring normal access.
- Post-incident hardening: restrict OpenSSH client use to recognized bastion, deployment, or transfer hosts where feasible; disable "PermitLocalCommand" unless required; review "%PROGRAMDATA%\\ssh\\ssh_config" and affected users' ".ssh\\config" for unauthorized command options; retain the confirmed command, parent, destination, and user pattern for future triage and exception review.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [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.executable",
"process.pe.original_file_name",
"process.command_line",
"process.pid",
"process.entity_id",
"process.Ext.authentication_id",
"process.Ext.session_info.logon_type",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.trusted",
]
[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 = "Network activity for the alerting OpenSSH process"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Child process starts from the same OpenSSH 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 = "Windows Security events for the OpenSSH session"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{process.Ext.authentication_id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{process.Ext.authentication_id}}", valueType = "string" },
{ excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" }
]
]
relativeFrom = "now-24h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1202"
name = "Indirect Command Execution"
rules/windows/defense_evasion_lsass_ppl_disabled_registry.toml
+143 -37
View File
@@ -2,7 +2,7 @@
creation_date = "2025/05/27"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic"]
@@ -24,42 +24,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Disabling Lsa Protection via Registry Modification"
note = """## Triage and analysis
### Investigating Disabling Lsa Protection via Registry Modification
For more information about the Lsa Protection and how it works, check the [official Microsoft docs page](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection).
Attackers may disable Lsa protection to access Lsass memory for credentals. This rule identifies RunAsPPL registry value modifications.
#### Possible investigation steps
- Verify the context of the change and if it's related to a planned system administration activity.
- 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.
- Inspect the host for suspicious or abnormal behaviors in the alert timeframe.
- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file modifications, and any spawned child processes.
### False positive analysis
- Approved changes to relax the Lsa protection for compatibility with third party solutions such as authentication plugins or alike.
### 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.
- Restore UAC settings to the desired state.
- 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://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection"]
risk_score = 73
rule_id = "37cb6756-8892-4af3-a6bd-ddc56db0069d"
@@ -89,6 +53,148 @@ registry where host.os.type == "windows" and event.type == "change" and
not process.executable : "?:\\Windows\\System32\\SecurityHealthService.exe"
'''
note = """## Triage and analysis
### Investigating Disabling Lsa Protection via Registry Modification
#### Possible investigation steps
- Does the alert-local registry write attempt to lower LSA protection?
- Why: RunAsPPL values 1 and 2 enable protected LSASS modes; a non-enabling value under the LSA control path weakens credential protection even when live-state effect is unresolved.
- Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`, confirming the RunAsPPL LSA control path and non-enabling data.
- Implication: escalate or keep investigating when RunAsPPL receives a non-enabling value; treat numbered-ControlSet effect as unresolved, not benign. Lower suspicion only when verified as controlled compatibility testing on a non-production host.
- Which process and parent made the RunAsPPL change?
- Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`.
- Implication: escalate when a user-writable binary, script host, renamed tool, unexpected signer, or unexplained parent changed RunAsPPL; lower suspicion when writer identity and parent workflow match a recognized validation, image-engineering, or compatibility toolchain. Identity alone does not clear the weakening change.
- Does the account and session context fit a controlled LSA protection change?
- Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.token.elevation_level`.
- Implication: escalate when the change comes from an unexpected administrator, service account, remote shell, Office lineage, or token/session context that does not fit the expected task; lower suspicion only when account, session type, and privilege context fit the same recognized host-management workflow.
- Did the same process modify adjacent credential-protection or authentication settings?
- Focus: registry events on the same `host.id` and `process.entity_id`, especially `registry.path`, `registry.value`, and `registry.data.strings` under LSA, WDigest, security provider, or Credential Guard families. $investigate_2
- Hint: filter surrounding registry events by `host.id` plus `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight event-time window.
- Implication: escalate when the writer also touches RunAsPPLBoot, LsaCfgFlags, UseLogonCredential, security packages, or similar credential-protection settings; keep scope narrower when the RunAsPPL write is isolated and registry context fits the same recognized test or build workflow.
- Did process activity prepare to exploit the weakened setting?
- Why: a registry-only disable generally matters after reboot, so restart staging and LSASS-access preparation change urgency.
- Focus: registry-writer and child process activity on the same `host.id`, checking `process.name`, `process.executable`, and `process.command_line`; broaden to the same `user.id` only if writer-scoped activity is unresolved. $investigate_3
- Implication: escalate when the same lineage or user queues a reboot, launches LSASS dump tooling, invokes memory-access utilities, or stages archive commands; absence of follow-on process evidence does not close the alert because the weakened setting can be used after a later reboot.
- If local findings remain suspicious or unresolved, does the same host show broader defense weakening or credential-access activity?
- Focus: related alerts for the same `host.id`, especially LSA-protection, LSASS-access, reboot, persistence, privilege-escalation, or credential-access alerts. $investigate_0
- Hint: review related alerts for the same `user.id` to see whether the account is changing LSA protection or staging credential access elsewhere. $investigate_1
- Implication: broaden scope when the same host has aligned defense-evasion or credential-access alerts; keep handling local when related host alerts are absent and registry, writer, session, and follow-on process evidence all support one recognized workflow.
- Escalate when registry meaning plus writer, session, adjacent-registry, reboot/LSASS-prep, or related-alert evidence shows unauthorized LSA-protection weakening; close only when telemetry proves one verified compatibility, validation, or image-engineering workflow with no contradictions; preserve evidence and escalate when telemetry is mixed or incomplete.
### False positive analysis
- Controlled compatibility testing, security validation, image engineering, or break-fix work can lower RunAsPPL on lab, pre-production, build, or troubleshooting systems. Confirm the exact expected test value in `registry.path`, `registry.value`, and `registry.data.strings`; a matching validation or build toolchain in `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.parent.executable`, and `user.id`; and a bounded `host.id` / `host.name` cohort. If registry meaning, writer context, session context, or host pattern is missing or contradictory, do not close as benign.
- Before creating an exception, validate recurrence of the same `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `user.id`, `host.id`, and specific `registry.path` family across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern; avoid exceptions on RunAsPPL alone, `user.name` alone, or a host alone.
### Response and remediation
- If confirmed benign, record which evidence proved the workflow: `registry.path`, `registry.data.strings`, writer identity, parent context, `user.id`, `host.id`, host cohort, and change window. Then reverse any temporary containment. Create an exception only when the same narrow pattern recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the alert, registry timeline, modified RunAsPPL value (`registry.path`, `registry.data.strings`), writer command context (`process.entity_id`, `process.command_line`), parent context, account context, and any reboot or LSASS-prep command evidence before containment or cleanup. Apply reversible containment first: heightened monitoring, temporary access restrictions for the affected `user.id`, or host isolation only when dump or reboot evidence raises risk and isolation will not disrupt critical service.
- If confirmed malicious, record process and registry evidence first, then isolate the host through endpoint response when registry, writer, session, and follow-on evidence establish unauthorized protection weakening. Restore RunAsPPL to the expected enabled value, usually 1 or 2, verify adjacent LSA and security-provider settings, and confirm LSASS starts protected after the required reboot.
- If reboot or LSASS-access preparation occurred, treat resident credentials as potentially exposed, scope privileged or service accounts active on the host, and perform credential hygiene based on their exposure.
- Eradicate only the scripts, binaries, persistence changes, registry values, and dump or archive artifacts identified during the investigation, then remediate the access path that allowed the protection change.
- Retain registry and process telemetry, the final RunAsPPL state, and reboot timing so future cases can separate recurring controlled testing from repeated abuse.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.id",
"user.id",
"process.entity_id",
"process.executable",
"process.command_line",
"process.parent.executable",
"process.parent.command_line",
"process.code_signature.subject_name",
"process.Ext.session_info.logon_type",
"process.Ext.token.elevation_level",
"registry.path",
"registry.value",
"registry.data.type",
"registry.data.strings",
]
[transform]
[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[transform.investigate]]
label = "Registry activity by the same writer"
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 = "registry", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Process activity for the registry writer"
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" }
],
[
{ 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" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/windows/defense_evasion_masquerading_as_svchost.toml
+133 -44
View File
@@ -2,56 +2,20 @@
creation_date = "2025/11/12"
integration = ["endpoint", "windows", "system"]
maturity = "production"
updated_date = "2026/04/29"
min_stack_comments = "Changing min stack to 9.2.0, the latest minimum supported version for 9.X releases."
min_stack_version = "9.2.0"
updated_date = "2026/04/22"
[rule]
author = ["Elastic"]
description = """
Identifies attempts to masquerade as the Service Host process `svchost.exe` to evade detection and blend in with normal system activity.
Identifies attempts to masquerade as the Service Host process `svchost.exe` to evade detection and blend in with
normal system activity.
"""
from = "now-9m"
interval = "8m"
language = "esql"
license = "Elastic License v2"
name = "Potential Masquerading as Svchost"
note = """ ## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential Masquerading as Svchost
svchost.exe is a legitimate Windows system process responsible for hosting multiple Windows services. Adversaries may attempt to masquerade as svchost.exe to evade detection and blend in with normal system activity. This is often achieved by renaming a malicious executable to svchost.exe, placing it outside of standard Windows directories or running it with unusual parent processes or command-line arguments.
### Possible investigation steps
- Review the process.executable and process.parent.executable fields to confirm the location and unexpected parents..
- Check the process.command_line field for unusual arguments. Legitimate svchost.exe instances typically use the -k parameter followed by a valid service group name.
- Investigate the process.code_signature field to determine if the binary is signed by Microsoft. Unsigned or invalid signatures are strong indicators of masquerading.
- Correlate the event with other telemetry from the same host to identify additional indicators such as file creation, network connections, or registry modifications related to the suspicious process.
- Review related file creation events to determine how and when the fake svchost.exe was introduced to the system (e.g. dropped by another malware component or downloaded from the network).
### False positive analysis
- Some legitimate third-party applications may use executables named svchost.exe within their own installation paths. Verify the vendor, file hash, and digital signature to determine legitimacy.
- In virtualized or sandboxed environments, custom service hosts may appear with similar naming conventions. Validate these against known baseline configurations.
- Ensure that system recovery or diagnostic tools using temporary binaries are not misidentified as malicious. Review event timing and system logs to confirm.
- Regularly maintain an inventory of known legitimate `svchost.exe` locations and hashes to minimize false positives across managed hosts.
### Response and remediation
- Isolate the affected host immediately to prevent lateral movement or further compromise.
- Terminate any suspicious svchost.exe processes executing from non-standard locations.
- Quarantine and remove the rogue binary after verification through hash reputation or sandbox analysis.
- Perform a full system scan to identify additional malicious files or persistence mechanisms associated with the masqueraded process.
- Review and reset any credentials used by the compromised process if credential theft or impersonation is suspected.
- Analyze recent network activity from the affected host for potential data exfiltration or commandand-control communication.
- Escalate the incident to the security operations or incident response team for deeper investigation and forensic analysis.
- Implement detections to monitor for future attempts of process masquerading, and update security baselines and EDR exclusions accordingly.
"""
risk_score = 73
rule_id = "32f95776-6498-4f3c-a90c-d4f6083e3901"
severity = "high"
@@ -60,7 +24,7 @@ tags = [
"OS: Windows",
"Use Case: Threat Detection",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
"Resources: Investigation Guide",
"Data Source: Elastic Defend",
"Data Source: Windows Security Event Logs",
"Data Source: Sysmon"
@@ -75,9 +39,137 @@ FROM logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-sys
not to_lower(process.executable) in ("c:\\windows\\syswow64\\svchost.exe", "c:\\windows\\system32\\svchost.exe") and
not to_lower(process.executable) like """\\device\\harddiskvolume*\\windows\\system32\\svchost.exe""" and
not to_lower(process.executable) like """\\device\\harddiskvolume*\\windows\\syswow64\\svchost.exe"""
| keep data_stream.dataset, host.name, host.id, user.id, user.name, process.executable, process.parent.executable, process.command_line, _id, _version, _index
| keep *
'''
note = """## Triage and analysis
### Investigating Potential Masquerading as Svchost
#### Possible investigation steps
- Does the alert confirm a service-host-like name running from a noncanonical path?
- Focus: `process.name`, `process.executable`, `process.command_line`, `process.parent.executable`, and `host.id`, comparing the path with `C:\\Windows\\System32\\svchost.exe` and `C:\\Windows\\SysWOW64\\svchost.exe`.
- Hint: use `process.entity_id`, hash, and signer fields where present; if enrichments are missing, keep the gap unresolved and scope by `host.id`, path, and alert time.
- Implication: escalate when svchost.exe or a near-match runs from a user-writable, temp, share-backed, or product-mismatched path; lower concern only when a recognized lab, build-test, or recovery workflow also fits later evidence.
- Is the file identity or rename timing consistent with Microsoft Service Host?
- Focus: `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.*`, rename timing, and file events for the same path. $investigate_0
- Implication: escalate for an unfamiliar hash, unsigned/untrusted or non-Microsoft signer, recent rename, or original filename conflict; Microsoft identity and stable name timing reduce identity concern but do not clear the noncanonical path.
- Does the launch context fit service-controlled svchost.exe behavior?
- Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.command_line`, and session context, checking for services.exe and service grouping arguments such as `-k <group>` or `-s <service>`.
- Implication: escalate when the parent is a shell, script engine, Office process, archive tool, or user-run utility, when service-group arguments are absent, or when context is interactive; services.exe plus service grouping lowers launch-context concern, but the noncanonical path still needs explanation.
- Does this process instance behave like a launcher rather than a passive service host?
- Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, especially child `process.name`, `process.executable`, and `process.command_line`. $investigate_1
- Hint: use `process.Ext.ancestry` only as a deeper fallback when direct parent-child lineage is missing or incomplete.
- Implication: escalate when it spawns shells, script engines, admin tools, installers, additional lookalikes, or short-lived command chains; absent or service-like child activity narrows launcher risk but does not close the name/path anomaly.
- If local findings remain suspicious or unresolved, does related alert scope show reuse of the same masquerading path?
- Focus: related alerts for the same `process.executable` or `process.hash.sha256`, comparing `host.id` and `user.id` where available. $investigate_2 $investigate_3
- Implication: broaden scope and raise urgency when the same path or hash appears on other hosts, users, or alert types; keep local only when related alerts are absent and all local evidence supports one recognized lab, build, or recovery workflow.
- Escalate when the path anomaly plus identity, lineage, timing, child-process, or scope evidence points to masquerading or broader compromise; close only when path, identity, launch context, and bounded host/user scope prove one recognized lab, build, or recovery workflow; if telemetry cannot prove legitimacy, preserve artifacts and escalate.
### False positive analysis
- Controlled malware-analysis, image-build, or recovery testing can stage a service-host-like file outside canonical Windows paths. Confirm by aligning identity (`process.hash.sha256`, `process.pe.original_file_name`, signer trust/subject), launch context (`process.parent.executable`, `process.parent.command_line`, `process.command_line`), and scope (`host.id`, `host.name`, `user.id`). Without outside records, close only when process fields prove the controlled workflow.
- Treat a noncanonical svchost.exe name as suspicious until process evidence proves one complete benign workflow; a trusted Microsoft signer, familiar parent, or single quiet execution is not enough when the path or name still mimics Service Host.
- Before creating an exception, require recurring `process.executable`, `process.hash.sha256`, signer subject, parent executable, command-line shape, and `host.id` or controlled host cohort across prior alerts from this rule. Avoid exceptions on `process.name`, svchost.exe, `user.name`, or a host alone.
### Response and remediation
- If confirmed benign, reverse any temporary containment and record the exact workflow evidence: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, `process.command_line`, `host.id`, and the controlled lab, build, or recovery scope. Create an exception only after the same evidence pattern recurs.
- If suspicious but unconfirmed, preserve the alert, source process event, recovered `process.entity_id`, `process.executable`, `process.hash.sha256`, signature metadata, parent context, command line, and related-alert results before containment. Apply reversible controls first, such as heightened monitoring or temporary network restrictions for the affected `host.id`, and avoid termination or deletion until scope is clearer.
- If confirmed malicious, first preserve the recovered `process.entity_id`, command line, child-process list, path evidence, and forensic package for `process.executable`. Finish same-path and same-hash scoping, then isolate the endpoint when host criticality allows, terminate only the suspicious noncanonical service-host process, and remove the masquerading executable or launcher artifacts. Do not stop canonical Service Host instances unless that exact instance is proven malicious.
- After containment, restore any affected service-host component from known-good media if a legitimate file was replaced, restrict execution from user-writable or share-backed paths where feasible, and document the recovered command-line and parent-chain pattern that separated this fake service host from normal services.exe-launched instances.
"""
setup = """## Setup
This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
Setup instructions: https://ela.st/install-elastic-defend
### Additional data sources
This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [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.name",
"process.entity_id",
"process.executable",
"process.command_line",
"process.hash.sha256",
"process.pe.original_file_name",
"process.code_signature.subject_name",
"process.code_signature.trusted",
"process.parent.executable",
"process.parent.command_line",
]
[transform]
[[transform.investigate]]
label = "File events for the masquerading 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-24h"
relativeTo = "now"
[[transform.investigate]]
label = "Child process starts from the masquerading svchost 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 same executable path"
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 = "Alerts associated with the same executable hash"
description = ""
providers = [
[
{ excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
{ excluded = false, field = "process.hash.sha256", queryType = "phrase", value = "{{process.hash.sha256}}", valueType = "string" }
]
]
relativeFrom = "now-48h/h"
relativeTo = "now"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -90,10 +182,7 @@ id = "T1036.005"
name = "Match Legitimate Resource Name or Location"
reference = "https://attack.mitre.org/techniques/T1036/005/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/windows/defense_evasion_masquerading_renamed_autoit.toml
+158 -79
View File
@@ -2,39 +2,13 @@
creation_date = "2020/09/01"
integration = ["endpoint", "windows", "m365_defender", "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/29"
[rule]
author = ["Elastic"]
description = """
Identifies renamed Automation Script Interpreter process. Malware written as an AutoIt/AutoHotKey script tends to rename
the main executable to avoid detection.
Identifies renamed automation script interpreter processes, including AutoIt, AutoHotkey, and KIX32. Malware operators
may rename these executables to avoid detection.
"""
from = "now-9m"
index = [
@@ -48,56 +22,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Renamed Automation Script Interpreter"
note = """## Triage and analysis
### Investigating Renamed Automation Script Interpreter
The OriginalFileName attribute of a PE (Portable Executable) file is a metadata field that contains the original name of the executable file when compiled or linked. By using this attribute, analysts can identify renamed instances that attackers can use with the intent of evading detections, application allowlists, and other security protections.
AutoIt is a scripting language and tool for automating tasks on Microsoft Windows operating systems. Due to its capabilities, malicious threat actors can abuse it to create malicious scripts and distribute malware.
This rule checks for renamed instances of AutoIt, which can indicate an attempt of evading detections, application allowlists, and other security protections.
> **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.
### 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 = "2e1e835d-01e5-48ca-b9fc-7a61f7f11902"
severity = "high"
@@ -125,6 +49,161 @@ process where host.os.type == "windows" and event.type == "start" and
)
'''
note = """## Triage and analysis
### Investigating Renamed Automation Script Interpreter
#### Possible investigation steps
- Which interpreter family and masquerade path did the alert capture?
- Why: the PE original-name/runtime-name mismatch is decisive, and AutoIt, AutoHotkey, and KIX32 have different normal baselines.
- Focus: `process.pe.original_file_name`, `process.name`, `process.executable`, and `process.command_line`.
- Implication: escalate when AutoIt, AutoHotkey, or KIX32 identity is hidden by a misleading name, recent rename, or user-writable path, especially KIX32 under Users or ProgramData; lower suspicion when family, path, and command line fit one stable packaged automation or logon-script bundle.
- Hint: variants may strip PE original-name metadata or run under the expected interpreter name; if path or command line still points to AutoIt, AutoHotkey, or KIX content, keep reviewing lineage and artifacts.
- Is the binary identity consistent with a recognized interpreter package or a repackaged copy?
- Focus: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.executable`.
- Implication: escalate when signer, hash, or path is unknown, untrusted, or inconsistent with AutoIt, AutoHotkey, or KIX32 packaging; lower suspicion only when identity, path, parent, and command line fit one recognized package. Trusted identity does not clear suspicious use.
- Does the launch context explain why the interpreter ran under this name?
- Focus: `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, and `host.id`.
- Implication: escalate when Office, browsers, archive tools, LOLBins, or unusual admin or service contexts launch it, or when arguments point to hidden A3X, AHK, KIX, or payload execution; lower suspicion when parent, user, host, and arguments match recurring deployment, logon-script, or packaging workflow.
- Did the same process stage or touch script or payload artifacts?
- Focus: file events from `host.id` plus `process.entity_id`, and script or payload paths in `process.command_line`. $investigate_0
- Implication: escalate when the process writes, extracts, renames, or runs scriptable or executable content from temp, downloads, user-profile, or share-backed paths, or with internet provenance; lower suspicion when artifacts stay inside one recognized package tree. Missing file telemetry is unresolved, not benign.
- Hint: if `process.entity_id` is absent, recover with `host.id`, `process.pid`, and the tight alert window.
- Did the renamed interpreter produce follow-on execution, persistence, or egress?
- Focus: child process events from `process.entity_id`; same-process registry or network activity. $investigate_1 $investigate_2
- Implication: escalate when it spawns shells or script engines, writes autorun or service state, or contacts rare external destinations; lower suspicion when follow-on activity stays inside the same bounded automation task. Missing registry or network telemetry is unresolved, not benign.
- Hint: if `process.entity_id` is absent, recover with `host.id`, `process.pid`, and the tight alert window.
- If local findings remain suspicious or unresolved, do related alerts show broader compromise?
- Focus: related alerts for `user.id`, especially masquerading, script-interpreter, persistence, or credential-access activity. $investigate_3
- Hint: compare `host.id` alerts for the same interpreter path, renamed binaries, or adjacent defense-evasion activity. $investigate_4
- Implication: broaden scope when either view shows related masquerading, staging, persistence, or post-compromise behavior; keep local when related alerts are absent and all local evidence fits one stable automation workflow.
- Escalate on PE/name mismatch plus suspicious lineage, staging, persistence, egress, or related alerts; close only when path, parent, user, host, artifacts, and activity bind to one stable benign workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete.
### False positive analysis
- Software packaging, endpoint automation, KIX logon-script deployment, or authorized testing can rename AutoIt, AutoHotkey, or KIX32 interpreters inside a stable bundle. Confirm `process.pe.original_file_name`, `process.hash.sha256` or `process.code_signature.subject_name`, `process.executable`, `process.parent.executable`, `process.command_line`, `user.id`, and `host.id` align with one workflow; recovered artifacts or destinations should stay bounded to it, and missing telemetry is not benign evidence.
- Before creating an exception, validate the workflow locally and check recurrence for stable anchors: `process.executable`, `process.hash.sha256` or `process.code_signature.subject_name`, `process.parent.executable`, `user.id`, and `host.id`. Build the minimum pattern and avoid exceptions on `process.pe.original_file_name`, `process.name`, or `host.id` alone.
### Response and remediation
- If confirmed benign, reverse temporary containment and document the exact workflow evidence: interpreter family, executable path, hash or signer, parent executable, user, host, and artifact scope. Create an exception only after that same pattern recurs across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the process event, executable copy or hash, parent and child lineage, referenced scripts or payloads, and any recovered registry or destination indicators before containment or cleanup. Apply reversible containment tied to the finding, such as temporary destination restrictions, heightened monitoring, or host isolation only when payload delivery, persistence, or egress risk is meaningful.
- If confirmed malicious, preserve the renamed interpreter `process.entity_id`, command line, executable hash or signer, child processes, and recovered artifacts first. Then isolate the affected host when identity, lineage, artifact, persistence, or egress evidence shows active compromise, weighing host criticality before isolation.
- Before eradication, scope related users and hosts for the same executable path, parent, script or payload paths, persistence keys, and destinations so cleanup does not destroy evidence needed to understand spread.
- Quarantine the renamed interpreter, associated scripts, and extracted support files identified during triage; remove only persistence or launcher artifacts confirmed in this case; block confirmed malicious hashes or destinations tied to the same activity.
- After containment, retain the confirmed workflow or malicious artifact set for future triage and avoid suppressing the broader AutoIt, AutoHotkey, or KIX32 interpreter families.
"""
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)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
"""
[rule.investigation_fields]
field_names = [
"@timestamp",
"host.id",
"user.id",
"process.entity_id",
"process.pid",
"process.name",
"process.executable",
"process.command_line",
"process.pe.original_file_name",
"process.hash.sha256",
"process.code_signature.trusted",
"process.code_signature.subject_name",
"process.parent.entity_id",
"process.parent.executable",
"process.parent.command_line",
]
[transform]
[[transform.investigate]]
label = "File activity by the renamed interpreter"
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 = "Child process activity from the renamed interpreter"
description = ""
providers = [
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
{ excluded = false, field = "event.type", queryType = "phrase", value = "start", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Registry or network activity by the renamed interpreter"
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 = "registry", valueType = "string" }
],
[
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
{ excluded = false, field = "event.category", queryType = "phrase", value = "network", 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"
rules/windows/defense_evasion_mshta_susp_child.toml
+183 -39
View File
@@ -2,7 +2,7 @@
creation_date = "2025/08/19"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/07"
updated_date = "2026/04/29"
[rule]
author = ["Elastic"]
@@ -25,39 +25,6 @@ index = [
language = "eql"
license = "Elastic License v2"
name = "Suspicious Microsoft HTML Application Child 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 Microsoft HTML Application Child Process
Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, leveraging its trusted status to bypass security measures. The detection rule identifies suspicious network activity by Mshta.exe, excluding known benign processes, to flag potential threats. This approach helps in identifying unauthorized network connections indicative of malicious intent.
### Possible investigation steps
- Review the process tree to understand the parent-child relationship of mshta.exe, focusing on any unusual or unexpected parent processes that are not excluded by the rule, such as Microsoft.ConfigurationManagement.exe or known benign executables.
- Analyze the command-line arguments used by mshta.exe to identify any suspicious or unexpected scripts being executed, especially those not matching the excluded ADSelfService_Enroll.hta.
- Examine the network connections initiated by mshta.exe, including destination IP addresses, domains, and ports, to identify any connections to known malicious or suspicious endpoints.
- Check for any related alerts or logs from the same host around the time of the mshta.exe activity to identify potential lateral movement or additional malicious behavior.
- Investigate the user account associated with the mshta.exe process to determine if it has been compromised or is exhibiting unusual activity patterns.
### False positive analysis
- Mshta.exe may be triggered by legitimate software updates or installations, such as those from Microsoft Configuration Management. To handle this, add exceptions for processes with parent names like Microsoft.ConfigurationManagement.exe.
- Certain applications like Amazon Assistant and TeamViewer may use Mshta.exe for legitimate purposes. Exclude these by specifying their executable paths, such as C:\\Amazon\\Amazon Assistant\\amazonAssistantService.exe and C:\\TeamViewer\\TeamViewer.exe.
- Custom scripts or internal tools that utilize HTA files for automation might cause false positives. Identify these scripts and exclude them by their specific arguments, such as ADSelfService_Enroll.hta.
- Regularly review and update the list of exceptions to ensure that only verified benign activities are excluded, minimizing the risk of overlooking genuine threats.
### Response and remediation
- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate the mshta.exe process if it is confirmed to be making unauthorized network connections.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files.
- Review and analyze the process tree and network connections associated with mshta.exe to identify any additional compromised processes or systems.
- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
- Implement application whitelisting to prevent unauthorized execution of mshta.exe and similar system binaries.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
references = [
"https://lolbas-project.github.io/lolbas/Binaries/Mshta/",
]
@@ -83,13 +50,190 @@ type = "eql"
query = '''
process where host.os.type == "windows" and event.type == "start" and
process.parent.name : "mshta.exe" and
(
process.name : ("cmd.exe", "powershell.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "msiexec.exe", "schtasks.exe", "reg.exe", "wscript.exe", "rundll32.exe") or
process.executable : ("C:\\Users\\*\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\*.exe")
)
process.parent.name : "mshta.exe" and process.command_line != null and
(
process.name : (
"cmd.exe", "powershell.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "msiexec.exe",
"schtasks.exe", "reg.exe", "wscript.exe", "rundll32.exe"
) or
process.executable : ("C:\\Users\\*\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\*.exe")
) and
not (process.name : "cmd.exe" and process.command_line : "*\\HP\\HP*HPUDC*") and
not ?process.parent.command_line : "*\\HP\\*\\HPSolutionsPortal.hta*"
'''
note = """## Triage and analysis
### Investigating Suspicious Microsoft HTML Application Child Process
#### Possible investigation steps
- What did mshta broker into the child process?
- Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.command_line`, separating interpreters, script engines, transfer tools, installers, persistence utilities, DLL proxy loaders, and user-profile binaries; for transfer, installer, or user-profile children, recover same-child file and network/DNS events. $investigate_0 $investigate_1
- Implication: treat download, staging, persistence, scripting, or arbitrary user-space execution as high-risk proxy execution; narrow only when child arguments and mshta command line identify one recognized HTA-driven deployment, enrollment, support, or internal-portal flow. Missing file, network, or DNS telemetry is unresolved, not benign.
- Is the child binary identity consistent with its claimed role?
- Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
- Implication: renamed, unsigned/untrusted, user-writable, newly seen, or PE-mismatched children strengthen proxy-execution; a trusted signer identifies the binary but does not clear the mshta chain.
- What source did mshta execute?
- Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and `process.parent.code_signature.trusted`, checking expected System32/SysWOW64 mshta plus inline "vbscript:"/"javascript:", "script:" monikers, remote URLs, ADS syntax, UNC paths, temp/downloads, or "INetCache" sources.
- Implication: inline scriptlets, remote/ADS-backed content, user-writable sources, obfuscation, or unexpected signer/path make mshta the likely delivery mechanism; internal HTAs, vendor packages, or deployment sources must still match the child workflow.
- What process launched mshta?
- Why: recovering the mshta start event shows whether a browser, document, archive tool, installer, or management process initiated the chain.
- Focus: process-start events on `host.id` where recovered `process.entity_id` equals alert `process.parent.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert window, then inspect recovered `process.parent.executable` and `process.parent.command_line`. $investigate_2
- Implication: Office, browser, archive, chat, script-host, or unexpected-service launchers indicate delivery or user-execution risk; software-distribution, support, enrollment, or portal launchers explain the chain only when they start the same flow on the same host cohort.
- Did the same mshta instance launch more suspicious children?
- Focus: process-start events on `host.id` where `process.parent.entity_id` matches alert `process.parent.entity_id`; fall back to `host.id`, `process.parent.pid`, and a tight alert window; inspect child `process.name`, `process.executable`, and `process.command_line`. $investigate_3
- Implication: same-instance fan-out into shells, transfer tools, schedulers, configuration changes, script hosts, or multiple user-space binaries widens response beyond one child; a single child stays narrow only if it matches the recovered benign workflow.
- Does the user, session, and host cohort fit that workflow?
- Focus: `user.id`, `host.name`, `process.Ext.session_info.logon_type`, and recovered launcher `process.parent.executable`, using `host.id` as the stable host anchor.
- Implication: standard-user, shared-workstation, unusual remote/service-session, or non-management-host context raises priority without matching workflow history; cohort fit is reassuring only when session type and launcher match the deployment, support, enrollment, or portal pattern.
- If local evidence is suspicious or unresolved, does alert history show broader proxy execution?
- Focus: related alerts for `user.id` in 48 hours where the same child `process.executable` or mshta command pattern (`process.command_line`, `process.parent.command_line`) recurs in proxy-execution alerts. $investigate_4
- Hint: if the user view is quiet or ambiguous, compare related alerts for `host.id` in 48 hours; quiet history does not clear unresolved local evidence. $investigate_5
- Implication: escalate scope when the same delivery path or child-command pattern recurs across proxy-execution alerts; stay local only when the chain is resolved and related history fits the same recognized workflow.
- Escalate on suspicious child intent, identity mismatch, inline/remote/ADS mshta source, abnormal launcher, same-mshta fan-out, or broader proxy-execution history; close only when process evidence binds one exact recognized workflow on this host and no contradictions remain; preserve the process tree and escalate mixed or incomplete evidence.
### False positive analysis
- HP printer software (HPSolutionsPortal.hta) uses mshta to run a vendor portal that spawns cmd.exe for UDC telemetry cleanup and rundll32.exe for printui operations. The rule excludes the UDC cmd.exe pattern cross-source and the parent HTA path when `process.parent.command_line` is available. On sources without parent command_line (CrowdStrike, SecurityLog), these alerts still fire; confirm by matching `process.command_line` to HP ProgramData paths or printui.dll printer-name arguments before closing.
- Treat software distribution, device enrollment, remote support, or internal HTA portals as benign candidates only after process telemetry proves the same chain. Confirm child `process.executable`, `process.command_line`, `process.hash.sha256`, signer, mshta `process.parent.command_line`, recovered launcher executable/command line, and `user.id` plus `host.id` cohort. Use change records, support tickets, asset-role inventories, or prior alerts only as corroboration; never close unresolved local process evidence on recurrence or workflow labels alone.
- Do not close on partial matches. Inline scriptlets, remote URLs, ADS syntax, user-profile child executables, unexpected launchers, or same-mshta fan-out contradict a benign HTA workflow unless process telemetry and outside confirmation verify that exact activity.
- Build exceptions from the minimum confirmed pattern: recovered launcher `process.parent.executable`, mshta `process.parent.command_line`, child `process.executable` plus `process.command_line`, and stable `user.id` or `host.id` cohort. Avoid exceptions on mshta alone, `process.name` alone, or `user.name` alone.
### Response and remediation
- If confirmed benign, record the child `process.command_line`, mshta `process.parent.command_line`, recovered launcher `process.parent.executable`, `user.id`, and `host.id` evidence that validated the workflow, then reverse temporary containment. Create an exception only for that narrow process pattern, using prior alerts as stability evidence when available.
- If suspicious but unconfirmed, preserve the alert record, process tree, child `process.entity_id`, alert `process.parent.entity_id`, child and mshta command lines, child `process.hash.sha256`, signer evidence, recovered launcher, `process.Ext.session_info.logon_type`, and related-alert results before containment. Apply reversible controls first, such as blocking the exact HTA URL or share visible in `process.parent.command_line`, restricting the child hash or path, or increasing monitoring on the affected `host.id` and `user.id`.
- If confirmed malicious, isolate the host or terminate the mshta/child process only after recording the child and mshta entity IDs, command lines, launcher, hash, signer, user, and host evidence. If endpoint response is unavailable, hand off that preserved evidence to the team that can contain the endpoint or affected account.
- After containment, block confirmed malicious child hashes, child executable paths, and exact mshta command-line sources, then remove only scripts, binaries, scheduled tasks, or persistence changes proven to belong to this chain. Remediate the delivery vector that started mshta, such as browser download, attachment, archive extraction, remote share, software package, or compromised management workflow.
- Post-incident hardening: restrict mshta use for users and hosts that do not need HTA execution, package legitimate HTA workflows through signed deployment tooling, and record adjacent variants such as inline "vbscript:" / "javascript:", remote "script:" monikers, ADS-backed HTAs, and INetCache retrievals 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 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.pid",
"process.executable",
"process.command_line",
"process.Ext.session_info.logon_type",
"process.pe.original_file_name",
"process.hash.sha256",
"process.code_signature.trusted",
"process.parent.entity_id",
"process.parent.command_line",
]
[transform]
[[transform.investigate]]
label = "File events for the child process"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Network and DNS events for the child process"
description = ""
providers = [
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
{ excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
{ excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
],
[
{ excluded = false, field = "event.category", queryType = "phrase", value = "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 = "Mshta parent process event"
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.parent.entity_id}}", valueType = "string" }
]
]
relativeFrom = "now-1h"
relativeTo = "now"
[[transform.investigate]]
label = "Process events launched by the same mshta 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.parent.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"