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

T1553.006: Code Signing Policy Modification

Adversaries may modify code signing policies to enable execution of unsigned or self-signed code. Code signing provides a level of authenticity on a program from a developer and a guarantee that the program has not been tampered with. Security controls can include enforcement mechanisms to ensure that only valid, signed code can be run on an operating system.

Some of these security controls may be enabled by default, such as Driver Signature Enforcement (DSE) on Windows or System Integrity Protection (SIP) on macOS.[1][2] Other such controls may be disabled by default but are configurable through application controls, such as only allowing signed Dynamic-Link Libraries (DLLs) to execute on a system. Since it can be useful for developers to modify default signature enforcement policies during the development and testing of applications, disabling of these features may be possible with elevated permissions.[3][2]

Adversaries may modify code signing policies in a number of ways, including through use of command-line or GUI utilities, Modify Registry, rebooting the computer in a debug/recovery mode, or by altering the value of variables in kernel memory.[4][2][5][6] Examples of commands that can modify the code signing policy of a system include bcdedit.exe -set TESTSIGNING ON on Windows and csrutil disable on macOS.[4][2] Depending on the implementation, successful modification of a signing policy may require reboot of the compromised system. Additionally, some implementations can introduce visible artifacts for the user (ex: a watermark in the corner of the screen stating the system is in Test Mode). Adversaries may attempt to remove such artifacts.[7]

To gain access to kernel memory to modify variables related to signature checks, such as modifying g_CiOptions to disable Driver Signature Enforcement, adversaries may conduct Exploitation for Privilege Escalation using a signed, but vulnerable driver.[8][6]

EnterpriseT1553.006Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Code signing policy modification matters because it turns a core trust control into a bypass. On Windows and macOS, controls such as Driver Signature Enforcement and System Integrity Protection help prevent unsigned, self-signed, or tampered code from running. If an adversary with elevated permissions can weaken those policies, they may make later malware, drivers, rootkits, or persistence mechanisms look acceptable to the operating system.

Executive priority

Treat this as a high-value control-integrity issue, not just an endpoint alert. Leaders should ask whether Windows and macOS fleets can prove that code signing, boot integrity, privileged access, and sensitive registry permissions remain in their approved state. This technique is especially relevant to resilience and audit readiness because it may require elevated privileges, boot or recovery-mode activity, registry or boot configuration changes, and in some cases abuse of signed but vulnerable drivers. Coverage decisions should prioritize privileged systems, developer/test exceptions, and systems where unsigned driver or test-signing behavior may be legitimate but risky.

Technical view

For SOC, detection engineering, and IR teams, validate monitoring around Windows and macOS policy state changes that affect code signing enforcement. On Windows, focus on boot configuration and registry changes associated with test signing or driver signature enforcement changes, plus driver load activity and evidence of vulnerable signed driver abuse where available. On macOS, validate visibility into System Integrity Protection state changes and recovery-mode administrative activity. Because the ATT&CK object has no official detection text, use the related detection strategy DET0523 as directional context and build local analytics from policy-state changes, privileged command execution, reboot correlation, and unexpected unsigned or self-signed code execution attempts.

Likely telemetry

  • Endpoint process creation and command-line telemetry for administrative utilities that change signing or integrity policy state
  • Windows registry auditing for sensitive keys and hives tied to code signing or boot policy behavior
  • Windows boot configuration and test-signing state evidence
  • Driver load telemetry, especially signed-but-unusual or vulnerable driver activity
  • macOS System Integrity Protection status evidence and recovery-mode administrative changes where available

Detection direction

  • Baseline approved code signing, boot integrity, and SIP/DSE policy states for Windows and macOS systems, then alert on drift.
  • Correlate policy modifications with privileged account activity, reboot events, and subsequent driver or unsigned-code execution.
  • Separate legitimate developer/test workflows from production systems; test-signing and unsigned driver activity may be authorized in limited environments but should be tightly scoped.
  • Tune for registry and boot configuration changes rather than relying only on malware signatures, because this behavior modifies trust settings used by the operating system.
  • Review detections for attempts to hide visible artifacts, such as test-mode indicators, when host telemetry supports it.

Mitigation priorities

  • Prioritize privileged account management: restrict who can change signing, boot, registry, and integrity policy settings; log and review elevated use.
  • Enforce boot integrity controls where supported so changes to boot and OS integrity paths are harder to make silently.
  • Restrict registry permissions on sensitive Windows keys and hives related to security control behavior and boot/signing configuration.
  • Define approved exceptions for development and testing systems, and keep those exceptions separate from production enforcement policy.
  • Include signed-but-vulnerable driver risk in vulnerability and exposure management, since the ATT&CK description notes this path can be used to reach kernel memory and alter signature checks.
Analyst notes and limits

This is a defense-impairment sub-technique of Subvert Trust Controls for Windows and macOS. The supplied relationships include mitigation mappings for Restrict Registry Permissions, Privileged Account Management, and Boot Integrity, plus a related detection strategy named Detect Code Signing Policy Modification (Windows & macOS). ATT&CK also links use by Turla, APT39, Hikit, BlackEnergy, and Pandora, which supports threat-informed prioritization but not attribution in any individual incident.

Official ATT&CK detection guidance is not provided for this object, so telemetry and analytics must be validated against local endpoint, registry, boot, privileged access, and macOS management data. The supplied fields do not prove active exploitation in any environment or guarantee detection coverage. Legitimate development and testing workflows can resemble this behavior and require environment-specific allowlisting and review.

Official MITRE ATT&CK definition

Code Signing Policy Modification

Adversaries may modify code signing policies to enable execution of unsigned or self-signed code. Code signing provides a level of authenticity on a program from a developer and a guarantee that the program has not been tampered with. Security controls can include enforcement mechanisms to ensure that only valid, signed code can be run on an operating system.

Some of these security controls may be enabled by default, such as Driver Signature Enforcement (DSE) on Windows or System Integrity Protection (SIP) on macOS.[1][2] Other such controls may be disabled by default but are configurable through application controls, such as only allowing signed Dynamic-Link Libraries (DLLs) to execute on a system. Since it can be useful for developers to modify default signature enforcement policies during the development and testing of applications, disabling of these features may be possible with elevated permissions.[3][2]

Adversaries may modify code signing policies in a number of ways, including through use of command-line or GUI utilities, Modify Registry, rebooting the computer in a debug/recovery mode, or by altering the value of variables in kernel memory.[4][2][5][6] Examples of commands that can modify the code signing policy of a system include bcdedit.exe -set TESTSIGNING ON on Windows and csrutil disable on macOS.[4][2] Depending on the implementation, successful modification of a signing policy may require reboot of the compromised system. Additionally, some implementations can introduce visible artifacts for the user (ex: a watermark in the corner of the screen stating the system is in Test Mode). Adversaries may attempt to remove such artifacts.[7]

To gain access to kernel memory to modify variables related to signature checks, such as modifying g_CiOptions to disable Driver Signature Enforcement, adversaries may conduct Exploitation for Privilege Escalation using a signed, but vulnerable driver.[8][6]

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

Related techniques

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
Enterprise T1553 Subvert Trust Controls This object subtechnique of Subvert Trust Controls.
Associated objects

Groups, software, and campaigns

Group Enterprise

G0087: APT39

APT39 is one of several names for cyber espionage activity conducted by the Iranian Ministry of Intelligence and Security (MOIS) through the front company Rana Intelligence Computing since at least 2014. APT39 has primarily targeted the travel, hospitality, academic, and telecommunications industries in Iran and across Asia, Africa, Europe, and North America to track individuals and entities considered to be a threat by the MOIS.[1][2][3][4][5]

Group Enterprise

G0010: Turla

Turla is a cyber espionage threat group that has been attributed to Russia's Federal Security Service (FSB). They have compromised victims in over 50 countries since at least 2004, spanning a range of industries including government, embassies, military, education, research and pharmaceutical companies. Turla is known for conducting watering hole and spearphishing campaigns, and leveraging in-house tools and malware, such as Uroburos.[1][2][3][4][5]

Malware Enterprise

S0089: BlackEnergy

BlackEnergy is a malware toolkit that has been used by both criminal and APT actors. It dates back to at least 2007 and was originally designed to create botnets for use in conducting Distributed Denial of Service (DDoS) attacks, but its use has evolved to support various plug-ins. It is well known for being used during the confrontation between Georgia and Russia in 2008, as well as in targeting Ukrainian institutions. Variants include BlackEnergy 2 and BlackEnergy 3. [1]

Windows
Relationship explorer

All related ATT&CK context

uses · Group G0087: APT39 Enterprise uses · Malware S0089: BlackEnergy Enterprise uses · Malware S0009: Hikit Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise mitigates · Mitigation M1046: Boot Integrity Enterprise subtechnique of · Technique T1553: Subvert Trust Controls Enterprise detects · Detection Strategy DET0523: Detect Code Signing Policy Modification (Windows & macOS) Enterprise uses · Malware S0664: Pandora Enterprise uses · Group G0010: Turla Enterprise mitigates · Mitigation M1024: Restrict Registry Permissions Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1046: Boot Integrity

Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:

Implementation of Secure Boot:

- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.

Utilization of TPMs:

- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.

Enable Bootloader Passwords:

- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.

Runtime Integrity Monitoring:

- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.

Mitigation Enterprise

M1024: Restrict Registry Permissions

Restricting registry permissions involves configuring access control settings for sensitive registry keys and hives to ensure that only authorized users or processes can make modifications. By limiting access, organizations can prevent unauthorized changes that adversaries might use for persistence, privilege escalation, or defense evasion. This mitigation can be implemented through the following measures:

Review and Adjust Permissions on Critical Keys

- Regularly review permissions on keys such as `Run`, `RunOnce`, and `Services` to ensure only authorized users have write access. - Use tools like `icacls` or `PowerShell` to automate permission adjustments.

Enable Registry Auditing

- Enable auditing on sensitive keys to log access attempts. - Use Event Viewer or SIEM solutions to analyze logs and detect suspicious activity. - Example Audit Policy: `auditpol /set /subcategory:"Registry" /success:enable /failure:enable`

Protect Credential-Related Hives

- Limit access to hives like `SAM`,`SECURITY`, and `SYSTEM` to prevent credential dumping or other unauthorized access. - Use LSA Protection to add an additional security layer for credential storage.

Restrict Registry Editor Usage

- Use Group Policy to restrict access to regedit.exe for non-administrative users. - Block execution of registry editing tools on endpoints where they are unnecessary.

Deploy Baseline Configuration Tools

- Use tools like Microsoft Security Compliance Toolkit or CIS Benchmarks to apply and maintain secure registry configurations.

*Tools for Implementation*

Registry Permission Tools:

- Registry Editor (regedit): Built-in tool to manage registry permissions. - PowerShell: Automate permissions and manage keys. `Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "KeyName" -Value "Value"` - icacls: Command-line tool to modify ACLs.

Monitoring Tools:

- Sysmon: Monitor and log registry events. - Event Viewer: View registry access logs.

Policy Management Tools:

- Group Policy Management Console (GPMC): Enforce registry permissions via GPOs. - Microsoft Endpoint Manager: Deploy configuration baselines for registry permissions.

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
2.0
Created
Modified
Raw hash
8ee011f22eb26b81...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 8ee011f22eb2…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    Microsoft DSE June 2017

    Microsoft. (2017, June 1). Digital Signatures for Kernel Modules on Windows. Retrieved April 22, 2021.

    Open source URL
  2. [2]
    Apple Disable SIP

    Apple. (n.d.). Disabling and Enabling System Integrity Protection. Retrieved April 22, 2021.

    Open source URL
  3. [3]
    Microsoft Unsigned Driver Apr 2017

    Microsoft. (2017, April 20). Installing an Unsigned Driver during Development and Test. Retrieved April 22, 2021.

    Open source URL
  4. [4]
    Microsoft TESTSIGNING Feb 2021

    Microsoft. (2021, February 15). Enable Loading of Test Signed Drivers. Retrieved April 22, 2021.

    Open source URL
  5. [5]
    FireEye HIKIT Rootkit Part 2

    Glyer, C., Kazanciyan, R. (2012, August 22). The “Hikit” Rootkit: Advanced and Persistent Attack Techniques (Part 2). Retrieved November 17, 2024.

    Open source URL
  6. [6]
    GitHub Turla Driver Loader

    TDL Project. (2016, February 4). TDL (Turla Driver Loader). Retrieved April 22, 2021.

    Open source URL
  7. [7]
    F-Secure BlackEnergy 2014

    F-Secure Labs. (2014). BlackEnergy & Quedagh: The convergence of crimeware and APT attacks. Retrieved March 24, 2016.

    Open source URL
  8. [8]
    Unit42 AcidBox June 2020

    Reichel, D. and Idrizovic, E. (2020, June 17). AcidBox: Rare Malware Repurposing Turla Group Exploit Targeted Russian Organizations. Retrieved March 16, 2021.

    Open source URL
  9. [9]
    mitre-attack T1553.006
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use