« Potential Antimalware Scan Interface Bypass via PowerShell Clearing Windows Console History »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Modification of AmsiEnable Registry Key

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

Modification of AmsiEnable Registry Key

edit

Identifies modifications of the AmsiEnable registry key to 0, which disables Windows Script AMSI scanning for the affected user. Adversaries can modify this key to bypass AMSI protections for Windows Script Host or JScript execution.

Rule type: eql

Rule indices:

  • winlogbeat-*
  • logs-endpoint.events.registry-*
  • logs-windows.sysmon_operational-*
  • endgame-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • 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:

Tags:

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

Version: 317

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Modification of AmsiEnable Registry Key

Possible investigation steps

  • Does the registry event prove Windows Script AMSI was disabled for a user hive?
  • Focus: registry.path, registry.value, registry.data.type, and registry.data.strings for "Software\Microsoft\Windows Script\Settings\AmsiEnable" under "HKEY_USERS

    Focus: registry.path, registry.value, registry.data.type, and registry.data.strings for "Software\Microsoft\Windows Script\Settings\AmsiEnable" under "HKEY_USERS\<SID>".

    lt;SID>".
  • Implication: escalate true disablement when registry.path resolves to that user-hive value and registry.data.strings is "0" or "0x00000000"; lower suspicion only when the path or data does not disable AMSI, or same-host evidence proves controlled validation or image-build deliberately toggled Windows Script AMSI.
  • Is the writing process a recognized validation tool or an abuse launcher?
  • Focus: writer identity: process.entity_id, process.executable, process.command_line, process.code_signature.subject_name, and process.code_signature.trusted. !{investigate{"description":"","label":"Process events for the writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Hint: reconstruct activity with host.id plus process.entity_id; if missing, use host.id, process.pid, and a tight time window.
  • Implication: escalate when the writer is unsigned, untrusted, user-writable, renamed, script-launched, or writes "AmsiEnable" outside a recognized validation or image-build command line. Identity alone never clears the registry change.
  • Does lineage and session explain the AMSI disablement?
  • Focus: process.parent.executable, process.parent.command_line, process.Ext.session_info.logon_type, and user.id.
  • Implication: escalate when lineage involves Office, a browser, script host, remote shell, scheduled task, unexpected service account, or a standard user context that does not fit script-control testing; lower suspicion only when parent, session, and user.id match controlled validation or image-build launch context.
  • Did follow-on process activity use the disablement path?
  • Focus: post-write process activity in the recovered process scope, especially process.executable, process.command_line, and process.parent.command_line. !{investigate{"description":"","label":"Child process events for the writer","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"}}
  • Implication: escalate when the same lineage later launches or reopens "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "wmic.exe", "regsvr32.exe", or Office-child script execution. A write followed by a second script open matches SharpShooter-style AMSI-stub behavior; activity confined to recognized validation is lower risk.
  • Did the same process change related registry state for evasion, persistence, or cleanup?
  • Focus: same-process registry activity in the recovered process scope, with registry.path, registry.value, and registry.data.strings. !{investigate{"description":"","label":"Registry events for the writer","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"}}
  • Implication: escalate when the process also weakens script policy, security-control, Run, Startup, COM, or other persistence-relevant keys, or quickly restores registry.path after script execution. Risk is narrower when surrounding registry writes stay limited to the Windows Script validation task and return to baseline.
  • If local evidence stays suspicious or unresolved, do related alerts broaden scope?
  • Focus: related alerts for the same user.id that show execution, persistence, delivery, or defense evasion. !{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: query related alerts for the same host.id to find adjacent script execution, persistence, related registry tampering, or other AMSI-bypass alerts. !{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 and urgency when either pivot shows related execution, persistence, or defense evasion; quiet related-alert pivots only lower urgency when local registry, process, and user evidence already supports one exact benign workflow.
  • Escalate when true AMSI disablement combines with suspicious writer, lineage, script follow-on, related registry weakening, or related alerts; close only when same-host registry and process evidence proves one controlled workflow, with outside confirmation when telemetry cannot prove legitimacy; preserve and escalate mixed or incomplete evidence.

False positive analysis

  • Controlled security validation or golden-image build validation can legitimately toggle AMSI on lab, build, or pre-production assets. Confirm registry.path, registry.value, and registry.data.strings match the intended user hive; process.executable, process.code_signature.subject_name, process.code_signature.trusted, process.command_line, process.parent.command_line, user.id, and host.id align with that workflow; and surrounding process plus registry activity stays inside the task. Use change records, testing plans, owner confirmation, or toolchain confirmation only to verify telemetry-proven workflow, not override unresolved telemetry.
  • Base exceptions on the minimum confirmed workflow pattern: process.executable, process.code_signature.subject_name, process.command_line, process.parent.executable, registry.path, user.id, and host.id. Use prior alerts, when available, to validate stability. Avoid exceptions on the AmsiEnable value alone, on user.name alone, or on a host alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the exact registry, process, parent, user, and host evidence that justified closure. Create an exception only when that confirmed pattern is specific enough to avoid suppressing lookalike AMSI tampering; use recurrence as supporting evidence when it exists.
  • If suspicious but unconfirmed, preserve the registry event, same-host process timeline, parent command line, related registry changes, and affected user and host before containment. Apply reversible containment first, such as heightened monitoring, temporary network restriction, or carefully scoped endpoint isolation based on host role; escalate to account action or stronger host isolation only if follow-on execution, related registry tampering, or broader alert scope is confirmed.
  • If confirmed malicious, preserve the registry, process, user, host, and related-alert evidence plus any recovered script or payload identifiers before destructive action. Use endpoint isolation to stop follow-on execution while retaining telemetry, then terminate malicious processes or suspend accounts only after recording the process and user evidence needed for follow-up.
  • After scoping related host.id, user.id, process.executable, and registry.path evidence across affected assets, restore registry.value to the expected baseline and remove only the scripts, binaries, Run keys, COM changes, scheduled tasks, or other persistence artifacts identified during the investigation.
  • Post-incident hardening: restrict who can modify the Windows Script settings path, review controls around script hosts and Office macro execution, and retain the registry and process telemetry that proved the case.

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
registry where host.os.type == "windows" and event.type in ("creation", "change") and
  registry.value : "AmsiEnable" and registry.data.strings: ("0", "0x00000000")

  /*
    Full registry key path omitted due to data source variations:
    HKEY_USERS\\*\\Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable"
  */

Framework: MITRE ATT&CKTM

« Potential Antimalware Scan Interface Bypass via PowerShell Clearing Windows Console History »