Subvert Trust Controls: 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]

ID: T1553.006
Sub-technique of:  T1553
Tactic: Defense Evasion
Platforms: Windows, macOS
Permissions Required: Administrator
Data Sources: Command: Command Execution, Process: Process Creation, Windows Registry: Windows Registry Key Modification
Defense Bypassed: Application control, Digital Certificate Validation, User Mode Signature Validation
Contributors: Abel Morales, Exabeam
Version: 1.0
Created: 23 April 2021
Last Modified: 26 April 2021

Procedure Examples

ID Name Description
G0087 APT39

APT39 has used malware to turn off the RequireSigned feature which ensures only signed DLLs can be run on Windows.[9]

S0089 BlackEnergy

BlackEnergy has enabled the TESTSIGNING boot configuration option to facilitate loading of a driver component.[7]

S0009 Hikit

Hikit has attempted to disable driver signing verification by tampering with several Registry keys prior to the loading of a rootkit driver component.[5]

G0010 Turla

Turla has modified variables in kernel memory to turn off Driver Signature Enforcement after exploiting vulnerabilities that obtained kernel mode privileges.[8][6]

Mitigations

ID Mitigation Description
M1046 Boot Integrity

Use of Secure Boot may prevent some implementations of modification to code signing policies.[4]

M1026 Privileged Account Management

Limit the usage of local administrator and domain administrator accounts to be used for day-to-day operations that may expose them to potential adversaries.

M1024 Restrict Registry Permissions

Ensure proper permissions are set for the Registry to prevent users from modifying keys related to code signing policies.

Detection

Monitor processes and command-line arguments for actions that could be taken to modify the code signing policy of a system, such as bcdedit.exe -set TESTSIGNING ON.[4] Consider monitoring for modifications made to Registry keys associated with code signing policies, such as HKCU\Software\Policies\Microsoft\Windows NT\Driver Signing. Modifications to the code signing policy of a system are likely to be rare.

References