{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/code-signing/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["M365 Defender","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","code-signing","windows"],"_cs_type":"advisory","_cs_vendors":["Microsoft","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eAttackers 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains administrative privileges on a Windows system.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003ebcdedit.exe\u003c/code\u003e with arguments to disable driver signature enforcement. Example: \u003ccode\u003ebcdedit.exe /set testsigning on\u003c/code\u003e or \u003ccode\u003ebcdedit.exe /set nointegritychecks on\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ebcdedit.exe\u003c/code\u003e modifies the Boot Configuration Data (BCD) store.\u003c/li\u003e\n\u003cli\u003eThe system is restarted to apply the changes made to the BCD.\u003c/li\u003e\n\u003cli\u003eThe attacker loads an unsigned or self-signed malicious driver.\u003c/li\u003e\n\u003cli\u003eThe malicious driver executes with kernel-level privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker performs malicious activities such as installing rootkits, bypassing security controls, or stealing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring the malicious driver is loaded on subsequent system reboots.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Code Signing Policy Modification Through Built-in Tools\u0026rdquo; to your SIEM to detect the execution of \u003ccode\u003ebcdedit.exe\u003c/code\u003e with arguments used to disable code signing (process.args).\u003c/li\u003e\n\u003cli\u003eEnable process creation logging with command line arguments on Windows systems to ensure the Sigma rule can capture the relevant events (logsource).\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of code signing policy modification, as this activity is typically not legitimate and can indicate malicious activity. The rule \u003ccode\u003eFirst Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9\u003c/code\u003e can be used to detect suspicious drivers loaded into the system after the command was executed.\u003c/li\u003e\n\u003cli\u003eEnsure that Driver Signature Enforcement is enabled on all systems.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T14:17:05Z","date_published":"2026-05-04T14:17:05Z","id":"/briefs/2024-01-09-code-signing-policy-modification/","summary":"Attackers may attempt to disable or modify code signing policies on Windows systems by using built-in tools like bcdedit.exe in order to execute unsigned or self-signed malicious code.","title":"Code Signing Policy Modification Through Built-in Tools","url":"https://feed.craftedsignal.io/briefs/2024-01-09-code-signing-policy-modification/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.8,"id":"CVE-2026-39853"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["osslsigncode","buffer-overflow","authenticode","code-signing","CVE-2026-39853"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker crafts a malicious signed file (PE, MSI, CAB, or script) with an oversized digest field within the SpcIndirectDataContent structure of the PKCS#7 signature.\u003c/li\u003e\n\u003cli\u003eThe malicious file is distributed to a target user or system.\u003c/li\u003e\n\u003cli\u003eThe target system uses a vulnerable version of osslsigncode (prior to 2.12) to verify the signature of the malicious file using the command \u003ccode\u003eosslsigncode verify\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDuring the signature verification process, osslsigncode parses the SpcIndirectDataContent structure.\u003c/li\u003e\n\u003cli\u003eThe vulnerable code attempts to copy the digest value from the parsed SpcIndirectDataContent into a fixed-size stack buffer (64 bytes) without proper length validation.\u003c/li\u003e\n\u003cli\u003eDue to the oversized digest field, the \u003ccode\u003ememcpy\u003c/code\u003e operation overflows the stack buffer.\u003c/li\u003e\n\u003cli\u003eThe stack buffer overflow corrupts adjacent stack state, potentially overwriting return addresses or other critical data.\u003c/li\u003e\n\u003cli\u003eThe corrupted stack state leads to arbitrary code execution under the context of the osslsigncode process, granting the attacker control of the system.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade osslsigncode to version 2.12 or later to patch CVE-2026-39853 and prevent stack buffer overflows.\u003c/li\u003e\n\u003cli\u003eMonitor systems for unexpected crashes or unusual behavior associated with osslsigncode, which could indicate exploitation attempts.\u003c/li\u003e\n\u003cli\u003eImplement input validation and sanitization on digest lengths during signature verification to prevent similar vulnerabilities in other applications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-09T16:16:31Z","date_published":"2026-04-09T16:16:31Z","id":"/briefs/2026-04-osslsigncode-overflow/","summary":"A stack buffer overflow vulnerability (CVE-2026-39853) exists in osslsigncode versions prior to 2.12 due to insufficient validation of digest length during PKCS#7 signature verification, potentially leading to arbitrary code execution.","title":"osslsigncode Stack Buffer Overflow Vulnerability (CVE-2026-39853)","url":"https://feed.craftedsignal.io/briefs/2026-04-osslsigncode-overflow/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Microsoft Defender XDR","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["defense-evasion","registry-modification","code-signing"],"_cs_type":"advisory","_cs_vendors":["Microsoft","Elastic","Crowdstrike","SentinelOne"],"content_html":"\u003cp\u003eAttackers can modify the \u003ccode\u003eBehaviorOnFailedVerify\u003c/code\u003e 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the target system through methods such as phishing, exploiting vulnerabilities, or social engineering.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to obtain administrative rights, which are required to modify the registry.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a command-line tool, such as \u003ccode\u003ereg.exe\u003c/code\u003e or PowerShell, to modify the \u003ccode\u003eBehaviorOnFailedVerify\u003c/code\u003e registry value.\u003c/li\u003e\n\u003cli\u003eThe registry value is changed to either \u0026ldquo;0\u0026rdquo; or \u0026ldquo;1\u0026rdquo;, effectively disabling or weakening code signing enforcement.\u003c/li\u003e\n\u003cli\u003eThe attacker loads an unsigned or self-signed malicious driver or executable.\u003c/li\u003e\n\u003cli\u003eThe malicious code executes without proper validation, allowing the attacker to perform malicious activities on the system.\u003c/li\u003e\n\u003cli\u003eThe attacker may then establish persistence, move laterally within the network, or exfiltrate sensitive data.\u003c/li\u003e\n\u003cli\u003eThe final objective could be data theft, ransomware deployment, or establishing a long-term foothold within the compromised environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eCode Signing Policy Modification Through Registry\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eMonitor registry events, specifically changes to the \u003ccode\u003eBehaviorOnFailedVerify\u003c/code\u003e value, to identify potential attempts to disable code signing policy (event.type, registry.value, registry.data.strings).\u003c/li\u003e\n\u003cli\u003eInvestigate 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).\u003c/li\u003e\n\u003cli\u003eEnable Sysmon registry event logging to gain better visibility into registry modifications (setup).\u003c/li\u003e\n\u003cli\u003eEnsure that Driver Signature Enforcement (DSE) is enabled on all systems to prevent the loading of unsigned drivers (rule.description).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eSuspicious Process Modifying Code Signing Policy Registry\u003c/code\u003e to identify potentially malicious processes attempting to disable code signing (rule.name).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-code-signing-policy-modification/","summary":"Attackers may modify the Windows registry to disable code signing policy, allowing the execution of unsigned or self-signed malicious code, thereby bypassing security controls and enabling defense evasion.","title":"Code Signing Policy Modification Through Registry","url":"https://feed.craftedsignal.io/briefs/2024-01-code-signing-policy-modification/"}],"language":"en","title":"CraftedSignal Threat Feed — Code-Signing","version":"https://jsonfeed.org/version/1.1"}