Code-Signing — CraftedSignal Threat Feed

Code Signing Policy Modification Through Built-in Tools

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

Attackers may attempt to subvert trust controls by disabling or modifying the code signing policy. This allows them to execute unsigned or self-signed malicious code. This can be achieved by modifying boot configuration data (BCD) settings using the built-in bcdedit.exe utility on Windows. Disabling Driver Signature Enforcement (DSE) allows the loading of untrusted drivers, which can compromise system integrity. The rule identifies commands that can disable the Driver Signature Enforcement feature. The scope of the targeting is broad, as it can affect any Windows system where an attacker gains sufficient privileges to modify the BCD settings. This activity is detected by analyzing process execution events for specific command-line arguments used with bcdedit.exe. The detection rule was last updated on 2026-05-04.

Attack Chain

The attacker gains administrative privileges on a Windows system.
The attacker executes bcdedit.exe with arguments to disable driver signature enforcement. Example: bcdedit.exe /set testsigning on or bcdedit.exe /set nointegritychecks on.
The bcdedit.exe modifies the Boot Configuration Data (BCD) store.
The system is restarted to apply the changes made to the BCD.
The attacker loads an unsigned or self-signed malicious driver.
The malicious driver executes with kernel-level privileges.
The attacker performs malicious activities such as installing rootkits, bypassing security controls, or stealing sensitive data.
The attacker maintains persistence by ensuring the malicious driver is loaded on subsequent system reboots.

Impact

Successful modification of the code signing policy can lead to the execution of unsigned or self-signed malicious code, which can compromise the integrity and security of the system. Attackers can install rootkits, bypass security controls, or steal sensitive data. The impact can range from individual system compromise to broader network-wide attacks, depending on the attacker’s objectives.

Recommendation

Deploy the Sigma rule “Code Signing Policy Modification Through Built-in Tools” to your SIEM to detect the execution of bcdedit.exe with arguments used to disable code signing (process.args).
Enable process creation logging with command line arguments on Windows systems to ensure the Sigma rule can capture the relevant events (logsource).
Investigate any detected instances of code signing policy modification, as this activity is typically not legitimate and can indicate malicious activity. The rule First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9 can be used to detect suspicious drivers loaded into the system after the command was executed.
Ensure that Driver Signature Enforcement is enabled on all systems.

osslsigncode Stack Buffer Overflow Vulnerability (CVE-2026-39853)

hello@craftedsignal.io — Thu, 09 Apr 2026 16:16:31 +0000

A stack buffer overflow vulnerability has been identified in osslsigncode, a tool used for Authenticode signing and timestamping. Specifically, versions prior to 2.12 are susceptible to CVE-2026-39853. The vulnerability occurs during the verification of PKCS#7 signatures in PE, MSI, CAB, and script files. The code copies the digest value from a parsed SpcIndirectDataContent structure into a fixed-size stack buffer (64 bytes) without proper length validation. This allows an attacker to craft a malicious signed file containing an oversized digest field within the SpcIndirectDataContent structure. When a user attempts to verify this malicious file using a vulnerable version of osslsigncode, the resulting unbounded memcpy operation overflows the stack buffer, potentially corrupting adjacent stack state and leading to arbitrary code execution. This vulnerability has been addressed in osslsigncode version 2.12.

Attack Chain

Attacker crafts a malicious signed file (PE, MSI, CAB, or script) with an oversized digest field within the SpcIndirectDataContent structure of the PKCS#7 signature.
The malicious file is distributed to a target user or system.
The target system uses a vulnerable version of osslsigncode (prior to 2.12) to verify the signature of the malicious file using the command osslsigncode verify.
During the signature verification process, osslsigncode parses the SpcIndirectDataContent structure.
The vulnerable code attempts to copy the digest value from the parsed SpcIndirectDataContent into a fixed-size stack buffer (64 bytes) without proper length validation.
Due to the oversized digest field, the memcpy operation overflows the stack buffer.
The stack buffer overflow corrupts adjacent stack state, potentially overwriting return addresses or other critical data.
The corrupted stack state leads to arbitrary code execution under the context of the osslsigncode process, granting the attacker control of the system.

Impact

Successful exploitation of CVE-2026-39853 allows an attacker to execute arbitrary code on a system running a vulnerable version of osslsigncode. This can lead to complete system compromise, data exfiltration, or further malicious activities. While the specific number of affected systems is unknown, any system using osslsigncode for signature verification prior to version 2.12 is potentially vulnerable. The impact is significant, as it can undermine the trust placed in Authenticode signatures.

Recommendation

Upgrade osslsigncode to version 2.12 or later to patch CVE-2026-39853 and prevent stack buffer overflows.
Monitor systems for unexpected crashes or unusual behavior associated with osslsigncode, which could indicate exploitation attempts.
Implement input validation and sanitization on digest lengths during signature verification to prevent similar vulnerabilities in other applications.

Code Signing Policy Modification Through Registry

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

Attackers can modify the BehaviorOnFailedVerify registry key to disable code signing enforcement, allowing the execution of unsigned or self-signed code. This subverts trust controls and enables attackers to load and execute malicious drivers or other executables without proper validation. The targeted registry value controls how the system behaves when a driver’s signature verification fails, and altering this value can weaken system security. This technique is a common method to bypass security measures that rely on code signing to ensure the integrity and authenticity of software. This activity has been observed across various environments where endpoint detection and response solutions are deployed. The rule identifies registry modifications that can disable DSE.

Attack Chain

The attacker gains initial access to the target system through methods such as phishing, exploiting vulnerabilities, or social engineering.
The attacker escalates privileges to obtain administrative rights, which are required to modify the registry.
The attacker uses a command-line tool, such as reg.exe or PowerShell, to modify the BehaviorOnFailedVerify registry value.
The registry value is changed to either “0” or “1”, effectively disabling or weakening code signing enforcement.
The attacker loads an unsigned or self-signed malicious driver or executable.
The malicious code executes without proper validation, allowing the attacker to perform malicious activities on the system.
The attacker may then establish persistence, move laterally within the network, or exfiltrate sensitive data.
The final objective could be data theft, ransomware deployment, or establishing a long-term foothold within the compromised environment.

Impact

Successful modification of the code signing policy can lead to the execution of arbitrary code without proper validation, potentially compromising the entire system. Attackers can use this technique to install rootkits, bypass security software, and perform other malicious activities. Depending on the attacker’s objectives, this can result in data theft, system instability, or complete system compromise. While no specific victim count or sector is mentioned, any Windows system where code signing is relied upon for security is potentially at risk.

Recommendation

Deploy the Sigma rule Code Signing Policy Modification Through Registry to your SIEM to detect suspicious registry modifications (rule.name). Tune the rule to exclude legitimate software installers or system administration tools that may temporarily modify these settings.
Monitor registry events, specifically changes to the BehaviorOnFailedVerify value, to identify potential attempts to disable code signing policy (event.type, registry.value, registry.data.strings).
Investigate any alerts generated by the detection rule, focusing on the process execution chain and the legitimacy of the user account performing the action (rule.note).
Enable Sysmon registry event logging to gain better visibility into registry modifications (setup).
Ensure that Driver Signature Enforcement (DSE) is enabled on all systems to prevent the loading of unsigned drivers (rule.description).
Deploy the Sigma rule Suspicious Process Modifying Code Signing Policy Registry to identify potentially malicious processes attempting to disable code signing (rule.name).