Signed code enforcement is one of the strongest controls on a modern desktop, and it can be turned off by someone with enough privilege. MITRE ATT&CK technique T1553.006, Code Signing Policy Modification, covers adversaries who change code signing policy so unsigned or self-signed code runs. The tactic is defense impairment and the platforms are macOS and Windows.
How attackers use it
Some enforcement is on by default, such as Driver Signature Enforcement (DSE) on Windows or System Integrity Protection (SIP) on macOS. Other controls are off by default but configurable, for example allowing only signed DLLs to execute. Developers legitimately change these settings while testing, so with elevated permissions they can be disabled.
MITRE lists several ways adversaries change policy: command line or GUI utilities, Modify Registry, rebooting into a debug or recovery mode, or altering variables in kernel memory. It names two example commands: bcdedit.exe -set TESTSIGNING ON on Windows and csrutil disable on macOS.
Some changes need a reboot. Some leave visible artifacts, such as a watermark in the corner of the screen saying the system is in Test Mode, and MITRE notes adversaries may try to remove that artifact. To reach kernel memory and change variables like g_CiOptions to disable Driver Signature Enforcement, adversaries may exploit a signed but vulnerable driver.
How to detect it
MITRE lists no data sources here. These signals come straight from the description:
- Process creation events where
bcdeditsets test signing or related boot options. Sysmon event 1 and Windows event 4688 with command line auditing both capture this. - Registry changes to keys controlling code signing policy.
- A reboot into recovery or debug mode on a machine that has no reason to do so.
- Any endpoint reporting Test Mode, or a macOS host where SIP status changed from enabled.
- Loading of known vulnerable signed drivers, which can precede kernel memory changes.
How to reduce the risk
MITRE lists three mitigations.
- Privileged account management. Limit use of local and domain administrator accounts for day to day work, so there is less exposure to adversaries.
- Boot integrity. Use Secure Boot, which may prevent some implementations of code signing policy modification.
- Restrict registry permissions. Set proper permissions so users cannot modify keys related to code signing policies.
Check your own environment
# Windows (elevated): show boot configuration and look for testsigning
bcdedit /enum
# Windows: is Secure Boot enabled?
Confirm-SecureBootUEFI
# macOS: report System Integrity Protection state
csrutil status
Run these through your management tooling across the fleet and flag any machine where test signing is on, Secure Boot is off, or SIP is disabled. Developer machines may differ on purpose, so keep them in a separate group with a documented exception.
Quick check
What visible clue can indicate Windows is in Test Mode?
A watermark in the corner of the screen saying the system is in Test Mode. MITRE notes adversaries may try to remove it.
