New to CAPEC? Start Here
Home > CAPEC List > CAPEC-206: Signing Malicious Code (Version 3.9)  

CAPEC-206: Signing Malicious Code

Attack Pattern ID: 206
Abstraction: Detailed
View customized information:
+ Description
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.
+ Typical Severity

Very High

+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.444Development Alteration
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Execution Flow
  1. 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.
  2. 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
  1. 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.
  1. 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.
+ Example Instances

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 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]

+ Taxonomy Mappings
Section HelpCAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping
Entry IDEntry Name
1553.002Subvert Trust Controls:Code Signing
+ References
[REF-699] Nicolas Falliere, Liam O Murchu and Eric Chien. "W32.Stuxnet Dossier". Symantec. 2010-11. <>. URL validated: 2022-02-17.
[REF-700] Cristin Goodwin and Joram Borenstein. "Guarding against supply chain attacks—Part 3: How software becomes compromised". Microsoft. 2020-03-11. <>. URL validated: 2022-02-17.
[REF-714] "Operation Wilted Tulip: Exposing a cyber espionage apparatus". ClearSky cyber security and Trend Micro. 2017-07. <>. URL validated: 2022-02-17.
+ Content History
Submission DateSubmitterOrganization
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modification DateModifierOrganization
(Version 2.11)
CAPEC Content TeamThe MITRE Corporation
Updated Resources_Required
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated Description Summary, Related_Weaknesses
(Version 3.1)
CAPEC Content TeamThe MITRE Corporation
Updated Taxonomy_Mappings
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns, Taxonomy_Mappings
(Version 3.4)
CAPEC Content TeamThe MITRE Corporation
Updated Execution_Flow
(Version 3.5)
CAPEC Content TeamThe MITRE Corporation
Updated Description, Prerequisites, Related_Attack_Patterns
(Version 3.7)
CAPEC Content TeamThe MITRE Corporation
Updated Example_Instances, Execution_Flow, Mitigations, References
Previous Entry Names
Change DatePrevious Entry Name
(Version 2.12)
Lifting signing key and signing malicious code from a production environment
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018