sigma-rules/rules/windows/defense_evasion_amsienable_key_mod.toml

[metadata]
creation_date = "2021/06/01"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
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.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.registry-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Modification of AmsiEnable Registry Key"
references = [
    "https://hackinparis.com/data/slides/2019/talks/HIP2019-Dominic_Chell-Cracking_The_Perimeter_With_Sharpshooter.pdf",
    "https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal",
]
risk_score = 73
rule_id = "f874315d-5188-4b4a-8521-d1c73093a7e4"
severity = "high"
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",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
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"
  */
'''

note = """## 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\\<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_0
  - 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_1
  - 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_2
  - 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_3
  - Hint: query related alerts for the same `host.id` to find adjacent script execution, persistence, related registry tampering, or other AMSI-bypass alerts. $investigate_4
  - 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 = """## 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.name",
    "host.id",
    "user.name",
    "user.id",
    "process.executable",
    "process.command_line",
    "process.entity_id",
    "process.code_signature.subject_name",
    "process.code_signature.trusted",
    "process.parent.executable",
    "process.parent.command_line",
    "registry.path",
    "registry.value",
    "registry.data.strings",
]

[transform]

[[transform.investigate]]
label = "Process events for the 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" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Child process events for the writer"
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 = "Registry events for the 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 = "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 = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"