Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1446: Analytic 1446

Monitors execution of administrative utilities (e.g., bcdedit.exe) or registry modifications that disable Driver Signature Enforcement (DSE) or enable Test Signing. Correlates command-line activity, registry changes, and subsequent process executions that bypass signing enforcement.

EnterpriseAN1446AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic is about watching for Windows configuration changes that weaken driver signing protections, such as disabling Driver Signature Enforcement or enabling test signing. For security leaders, the practical issue is control integrity: if these settings are changed without authorization, Windows systems may be more exposed to untrusted or improperly signed driver execution, which can complicate incident response and undermine endpoint assurance.

Executive priority

Prioritize this as a Windows endpoint hardening and monitoring validation item. Leaders should ask whether administrative utility execution and relevant registry changes are logged, reviewed, and tied to change-management evidence. The business value is strongest for environments where endpoint trust, audit readiness, privileged administration, and rapid incident scoping matter. Because ATT&CK provides no tactic, technique relationship, or threat context here, this should be treated as a defensive coverage check rather than evidence of a specific campaign or actor behavior.

Technical view

For SOC, detection engineering, and IR teams, validate visibility into execution of administrative utilities such as bcdedit.exe, command-line arguments, registry modifications related to Driver Signature Enforcement or test signing, and follow-on process execution after those changes. The analytic description specifically calls for correlation across command-line activity, registry changes, and subsequent process executions that bypass signing enforcement. Since no official detection logic is supplied, teams should implement and tune detections based on local Windows logging sources, administrative baselines, and approved change windows.

Likely telemetry

  • Windows process creation events with command-line detail
  • Execution records for administrative utilities such as bcdedit.exe
  • Windows registry modification events related to driver signing or test signing configuration
  • Subsequent process execution telemetry after signing enforcement changes
  • Endpoint administrative activity and change-management records for correlation

Detection direction

  • Confirm that Windows endpoints collect process creation telemetry with full command-line visibility; without command-line detail, this analytic will be materially weaker.
  • Correlate administrative utility execution with registry changes affecting Driver Signature Enforcement or test signing rather than alerting on utility execution alone.
  • Compare observed changes against approved administrative maintenance or testing activity to reduce false positives.
  • Look for follow-on process execution after signing enforcement changes, as specified in the analytic description.
  • Document blind spots where registry auditing, endpoint telemetry, or centralized log retention is incomplete.

Mitigation priorities

  • Restrict and monitor privileged access capable of changing Windows boot or driver-signing configuration.
  • Maintain change-management approval and evidence for legitimate driver-signing or test-signing changes.
  • Harden Windows endpoint logging so process creation, command-line, registry modification, and follow-on execution events are retained centrally.
  • Review administrative baselines so unusual use of utilities such as bcdedit.exe can be distinguished from approved operational activity.
  • Use incident response procedures to scope systems where signing enforcement settings changed unexpectedly.
Analyst notes and limits

This is a detection analytic object, not a full ATT&CK technique. The supplied ATT&CK fields identify Windows as the platform and describe monitoring for administrative utility execution, registry changes, and subsequent process execution related to disabling Driver Signature Enforcement or enabling Test Signing. No relationship context, tactic, or official detection logic is provided, so local engineering decisions are required.

The source object does not provide an official detection query, ATT&CK tactic mapping, related techniques, data components, mitigations, adversary usage, or impact claims. This take therefore avoids attribution and assumes no detection coverage without validation in the local environment.

Official MITRE ATT&CK definition

Analytic 1446

Monitors execution of administrative utilities (e.g., bcdedit.exe) or registry modifications that disable Driver Signature Enforcement (DSE) or enable Test Signing. Correlates command-line activity, registry changes, and subsequent process executions that bypass signing enforcement.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
30d094420ba1093f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 30d094420ba1…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1446
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.