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

M0924: Restrict Registry Permissions

Restrict the ability to modify certain hives or keys in the Windows Registry.

ICSM0924MitigationObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Restrict Registry Permissions is an ICS ATT&CK mitigation focused on limiting who or what can modify sensitive Windows Registry hives or keys. Its practical value is reducing the chance that unauthorized changes can weaken system behavior, including changes that support stopping or disabling services. For leaders, this is a control-hardening item: it helps preserve operational availability and strengthens evidence for least-privilege expectations in standards such as IEC 62443 and NIST SP 800-53 AC-6.

Executive priority

Prioritize this where registry changes could affect critical services or incident response capability. The business question is not only whether permissions are configured, but whether the organization can prove that sensitive registry areas are restricted, reviewed, and monitored. This supports operational resilience, compliance readiness, and incident decision-making in ICS environments where service disruption can have safety, production, or availability consequences.

Technical view

SOC, IR, and engineering teams should validate which registry hives or keys are security- or service-critical in the local environment and confirm that modification rights are limited to authorized administrators or service accounts. Because this mitigation is related to Service Stop (T0881), defenders should pay particular attention to registry locations that influence service configuration, startup behavior, or controls that could make services unavailable. ATT&CK does not provide detection guidance for this mitigation, so detection engineering should be based on local asset criticality, approved change processes, and observed registry modification telemetry.

Likely telemetry

  • Registry key and value modification events for sensitive hives or keys
  • Windows security audit events tied to permission or policy changes
  • Service configuration and service state change records relevant to Service Stop context
  • Endpoint detection or host monitoring records showing registry write activity
  • Change management records documenting approved registry permission changes

Detection direction

  • Confirm that registry auditing or endpoint telemetry is actually enabled for the sensitive hives or keys the organization depends on; do not assume coverage from policy alone.
  • Tune detections around unauthorized or unexpected registry permission changes, especially where changes affect services or service availability.
  • Correlate registry modifications with service stop or disable events to support investigation of T0881-related behavior.
  • Account for legitimate administrative activity, patching, and engineering maintenance windows to reduce false positives.
  • Identify blind spots where legacy systems, unmanaged endpoints, or restricted ICS monitoring prevent collection of registry modification evidence.

Mitigation priorities

  • Inventory registry locations that influence critical services, security controls, and operational availability.
  • Apply least-privilege permissions so only authorized users, groups, or service accounts can modify selected hives or keys.
  • Align permission settings and review evidence with IEC 62443 SR/CR 2.1 and NIST SP 800-53 AC-6 expectations where applicable.
  • Require change control for registry permission changes on critical systems.
  • Validate periodically that permissions have not drifted and that monitoring can show attempted or successful unauthorized modification.
Analyst notes and limits

This object is a mitigation, not a technique, and the official ATT&CK description is concise. The strongest relationship context supplied is that it mitigates Service Stop (T0881), where stopping or disabling services can make systems unavailable or interfere with incident response. Glexia should treat this as a hardening and assurance topic for ICS environments rather than as evidence of any specific adversary activity.

ATT&CK does not specify platforms, tactics, or detection guidance for this object beyond the Windows Registry reference in the description. Local engineering knowledge is required to identify which registry hives or keys are critical, what permissions are appropriate, and what telemetry is available without disrupting operations.

Official MITRE ATT&CK definition

Restrict Registry Permissions

Restrict the ability to modify certain hives or keys in the Windows Registry.

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
ICS T0881 Service Stop

Ensure proper registry permissions are in place to inhibit adversaries from disabling or interfering with critical services.

Relationship explorer

All related ATT&CK context

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
948de682eb57dc0f...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 948de682eb57…
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 M0924
    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.