(process.pe.original_file_name : "AutoIt*.exe" and not process.name : "AutoIt*.exe") or
(process.pe.original_file_name == "AutoHotkey.exe" and not process.name : ("AutoHotkey*.exe", "InternalAHK.exe")) or
(process.pe.original_file_name == "KIX32.EXE" and not process.name : "KIX*.exe" and process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe"))
- 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.
