CAPEC-206
Signing Malicious Code
The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing.
On this page
Ask an AI about this attack pattern
Show the prompt
Explain the attack pattern CAPEC-206: Signing Malicious Code: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/206.html and https://cve.bz/cve/capec/206?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.
How the attack unfolds
Explore
The attacker looks for a way in.
The adversary first attempts to obtain a digital certificate in order to sign their malware or tools. This certificate could be stolen, created by the adversary, or acquired normally through a certificate authority.
Based on the type of certificate obtained, the adversary will create a goal for their attack. This is either a broad or targeted attack. If an adversary was able to steal a certificate from a targeted organization, they could target this organization by pretending to have legitimate code signed by them. In other cases, the adversary would simply sign their malware and pose as legitimate software such that any user might trust it. This is the more broad approach
Experiment
They probe what they found.
The adversary creates their malware and signs it with the obtained digital certificate. The adversary then checks if the code that they signed is valid either through downloading from the targeted source or testing locally.
Exploit
They carry out the attack.
Once the malware has been signed, it is then deployed to the desired location. They wait for a trusting user to run their malware, thinking that it is legitimate software. This malware could do a variety of things based on the motivation of the adversary.
Prerequisites
The targeted developer must use a signing key to sign code bundles. (Note that not doing this is not a defense - it only means that the adversary does not need to steal the signing key before forging code bundles in the developer's name.)
Resources required
None: No specialized resources are required to execute this type of attack.
Mitigations
Ensure digital certificates are protected and inaccessible by unauthorized uses.
If a digital certificate has been compromised it should be revoked and regenerated.
Even if a piece of software has a valid and trusted digital signature, it should be assessed for any weaknesses and vulnerabilities.
Weaknesses it exploits
- CWE-732 Incorrect Permission Assignment for Critical Resource
Recent CVEs with these weaknesses
- 3.9CVE-2026-14543
The VAPIX Edge storage API, enabling the escalation of user privileges by circumventing filesystem isolation, granting unauthorized access to protected system resources. This flaw can only be exploited after authenticating with an admin-pr…
- 7.4CVE-2026-12963
A vulnerability that could allow a viewer account to gain unauthorized access to network attached storage devices on the server.
- 7.3CVE-2026-112125
Incorrect Permission Assignment for Critical Resource Vulnerability in HA Monitor. This issue affects HA Monitor: from 01-00 before 01-83-01.
- 7.8CVE-2026-114031
Incorrect permission assignment allows local privilege escalation to SYSTEM on affected releases of the Illumio VEN for Windows. Code execution as NT AUTHORITY\LOCAL SERVICE on the Windows host is required to exploit this vulnerability. Th…
- 7.8CVE-2026-119474
Incorrect Permission Assignment for Critical Resource vulnerability in HAVELSAN Inc. Liman Render Engine allows Privilege Escalation. This issue affects Liman Render Engine: before 1.2-81.
- 4.8CVE-2026-124039
Gitleaks through 8.30.1 contains an incorrect permission assignment vulnerability that allows local users to read scan reports because cmd/root.go creates the --report-path file with os.Create and default permissions. Unless --redact is pa…
- 5.3CVE-2026-112910
filelock is a platform-independent file lock for Python. From 3.10.0 until 4.2.1, filelock on Windows ignores the mode argument for WindowsFileLock files and the ReadWriteLock SQLite database. A lock created with mode=0o600 receives the pa…
- 5.3CVE-2026-112908
filelock is a platform-independent file lock for Python. From version 3.30.0 until version 4.2.1, StrictSoftFileLock and AsyncStrictSoftFileLock on POSIX systems create coordination and claim directories without applying the caller’s r…
The newest records naming one of them. Each weakness's page lists them all.
Related attack patterns
- Part of
- CAPEC-444 Development Alteration
Examples
In the famous Stuxnet malware incident, two digital certificates were compromised in order to sign malicious …
In the famous Stuxnet malware incident, two digital certificates were compromised in order to sign malicious device drivers with legitimate credentials. The signing resulted in the malware appearing as trusted by the system it was running on, which facilitated the installation of the malware in kernel mode. This further resulted in Stuxnet remaining undetected for a significant amount of time. [REF-699]
The cyber espionage group CyberKittens leveraged a stolen certificate from AI Squared that allowed them to le…
The cyber espionage group CyberKittens leveraged a stolen certificate from AI Squared that allowed them to leverage a signed executable within Operation Wilted Tulip. This ultimately allowed the executable to run as trusted on the system, allowing a Crowd Strike stager to be loaded within the system's memory. [REF-714]
MITRE's words, unchanged: CAPEC-206 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.