Renamed Automation Script Interpreter

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Renamed Automation Script Interpreter

edit

Identifies renamed automation script interpreter processes, including AutoIt, AutoHotkey, and KIX32. Malware operators may rename these executables to avoid detection.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.process-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-m365_defender.event-*
  • logs-crowdstrike.fdr*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Data Source: Elastic Endgame
  • Resources: Investigation Guide
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: Microsoft Defender XDR
  • Data Source: Crowdstrike

Version: 219

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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{"description":"","label":"File activity by the renamed interpreter","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"}}
  • 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{"description":"","label":"Child process activity from the renamed interpreter","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"}} !{investigate{"description":"","label":"Registry or network activity by the renamed interpreter","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"}}
  • 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{"description":"","label":"Alerts associated with the user","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"}}
  • Hint: compare host.id alerts for the same interpreter path, renamed binaries, or adjacent defense-evasion activity. !{investigate{"description":"","label":"Alerts associated with the host","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"}}
  • 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

edit

Setup

This rule is designed for data generated by Elastic Defend, 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:

Rule query

edit
process where host.os.type == "windows" and event.type == "start" and
  (
   (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"))
   )

Framework: MITRE ATT&CKTM