M1045: Code Signing
Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:
Enforce Signed Code Execution:
- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.
Vendor-Signed Driver Enforcement:
- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.
Certificate Revocation Management:
- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.
Third-Party Software Verification:
- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.
Script Integrity in CI/CD Pipelines:
- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.
**Key Components of Code Signing**
- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.
Security context for executives and security teams
Code Signing matters because it turns software trust into an enforceable control: only code, scripts, drivers, images, or components with trusted integrity evidence should be allowed into sensitive environments. For leaders, the value is not the signature itself, but reducing the chance that renamed, tampered, unsigned, or improperly sourced software becomes execution, persistence, or defense-impairment risk.
Executive priority
Prioritize code signing where unauthorized code would disrupt operations or weaken trust in software delivery: endpoints, servers, CI/CD pipelines, third-party software intake, drivers, cloud/container images, ESXi components, and network device images as applicable. Executives should ask whether signing is merely present or actually enforced, whether certificate revocation is operational, and whether exceptions are governed with audit evidence.
Technical view
ATT&CK maps this mitigation to techniques involving masquerading, invalid signatures, command/script execution, malicious or implanted images, server components, services, modified binaries, ESXi VIBs, and network device system images. SOC, IR, and engineering teams should validate policy enforcement for unsigned or untrusted binaries/scripts, driver loading, third-party package acceptance, CI/CD artifact signing, certificate trust chains, and revocation handling. Because ATT&CK provides no detection text for this mitigation, local validation should focus on whether enforcement events, signature validation failures, certificate status checks, and exception approvals are observable.
Likely telemetry
- Code-signature validation results for executables, scripts, drivers, packages, and artifacts
- Unsigned, invalidly signed, or untrusted-code execution attempts
- Operating system application-control or signed-code enforcement logs
- Driver load allow/block events and kernel-mode signing enforcement evidence
- Certificate trust-chain, expiration, OCSP, and CRL status evidence
Detection direction
- Confirm that enforcement failures are logged, not only blocked silently, so SOC and IR teams can investigate attempted unsigned or invalidly signed execution.
- Tune monitoring for invalid signatures and trusted-name abuse in the context of masquerading, because a legitimate-looking name or path is not sufficient evidence of trust.
- Correlate signature failures with script execution, service creation/modification, server component installation, image deployment, and modified binaries based on the related ATT&CK techniques.
- Review false positives from internal tools, legacy software, development builds, and emergency maintenance workflows; require documented exceptions rather than broad allowlisting.
- Validate visibility in non-endpoint areas represented by related techniques, including CI/CD, containers, IaaS images, ESXi bundles, and network device images where applicable.
Mitigation priorities
- Start by defining trusted signing authorities, certificate lifecycle ownership, and revocation processes.
- Enforce signed-code execution for high-risk script and binary paths before expanding broadly.
- Require signed and verified third-party software before deployment.
- Enable signed driver enforcement and certificate revocation checks where supported.
- Integrate signing and verification into CI/CD so production artifacts are signed before release and verified before deployment.
Additional notes and limits
This is a mitigation object, not an adversary behavior. Its defensive value is highest when treated as a control assurance program spanning policy, PKI, software supply chain, and operational logging. The relationship context shows relevance across execution, persistence, privilege escalation, stealth, and defense-impairment techniques, especially where adversaries rely on unsigned, tampered, renamed, or maliciously sourced code artifacts.
ATT&CK does not specify platforms or official detection guidance for M1045, so environment-specific implementation and telemetry requirements must be confirmed locally. Relationships indicate where the mitigation is relevant, but they do not prove coverage, deployment, or attempted activity in any organization.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Code Signing
Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:
Enforce Signed Code Execution:
- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.
Vendor-Signed Driver Enforcement:
- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.
Certificate Revocation Management:
- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.
Third-Party Software Verification:
- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.
Script Integrity in CI/CD Pipelines:
- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.
**Key Components of Code Signing**
- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1505 | Server Software Component | Ensure all application component binaries are signed by the correct application developers. |
| Enterprise | T1204.003 | Malicious ImageSub-technique | |
| Enterprise | T1525 | Implant Internal Image | |
| Enterprise | T1059.002 | AppleScriptSub-technique | Require that all AppleScript be signed by a trusted developer ID before being executed - this will prevent random AppleScript code from executing.[3] This subjects AppleScript code to the same scrutiny as other .app files passing through Gatekeeper. |
| Enterprise | T1059 | Command and Scripting Interpreter | Where possible, only permit execution of signed scripts. |
| Enterprise | T1036.005 | Match Legitimate Resource Name or LocationSub-technique | Require signed binaries and images. |
| Enterprise | T1036.001 | Invalid Code SignatureSub-technique | Require signed binaries. |
| Enterprise | T1546.013 | PowerShell ProfileSub-technique | Enforce execution of only signed PowerShell scripts. Sign profiles to avoid them from being modified. |
| Enterprise | T1036 | Masquerading | Require signed binaries. |
| Enterprise | T1554 | Compromise Host Software Binary | Ensure all application component binaries are signed by the correct application developers. |
| Enterprise | T1601.001 | Patch System ImageSub-technique | Many vendors provide digitally signed operating system images to validate the integrity of the software used on their platform. Make use of this feature where possible in order to prevent and/or detect attempts by adversaries to compromise the system image. [4] |
| Enterprise | T1601.002 | Downgrade System ImageSub-technique | Many vendors provide digitally signed operating system images to validate the integrity of the software used on their platform. Make use of this feature where possible in order to prevent and/or detect attempts by adversaries to compromise the system image. [4] |
| Enterprise | T1543.003 | Windows ServiceSub-technique | Enforce registration and execution of only legitimately signed service drivers where possible. |
| Enterprise | T1059.001 | PowerShellSub-technique | Set PowerShell execution policy to execute only signed scripts. |
| Enterprise | T1505.001 | SQL Stored ProceduresSub-technique | Ensure all application component binaries are signed by the correct application developers. |
| Enterprise | T1543 | Create or Modify System Process | Enforce registration and execution of only legitimately signed service drivers where possible. |
| Enterprise | T1601 | Modify System Image | Many vendors provide digitally signed operating system images to validate the integrity of the software used on their platform. Make use of this feature where possible in order to prevent and/or detect attempts by adversaries to compromise the system image. [4] |
| Enterprise | T1505.004 | IIS ComponentsSub-technique | Ensure IIS DLLs and binaries are signed by the correct application developers. |
| Enterprise | T1546.006 | LC_LOAD_DYLIB AdditionSub-technique | Enforce that all binaries be signed by the correct Apple Developer IDs. |
| Enterprise | T1505.006 | vSphere Installation BundlesSub-technique | Enabling the `execInstalledOnly` feature prevents unsigned binaries from being run on ESXi hosts.[5] |
| Enterprise | T1505.002 | Transport AgentSub-technique | Ensure all application component binaries are signed by the correct application developers. |
| Enterprise | T1127.002 | ClickOnceSub-technique | Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing.[6] |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | c3d1de7054b9… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]Content trust in Docker
Docker. (2019, October 10). Content trust in Docker. Retrieved October 16, 2019.
Open source URL - [2]Content trust in Azure Container Registry
Microsoft. (2019, September 5). Content trust in Azure Container Registry. Retrieved October 16, 2019.
Open source URL - [3]applescript signing
Steven Sande. (2013, December 23). AppleScript and Automator gain new features in OS X Mavericks. Retrieved September 21, 2018.
Open source URL - [4]Cisco IOS Software Integrity Assurance - Deploy Signed IOS
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Deploy Signed IOS. Retrieved October 21, 2020.
Open source URL - [5]Google Cloud Threat Intelligence ESXi Hardening 2023
Alex Marvi, Greg Blaum, and Ron Craft. (2023, June 28). Detection, Containment, and Hardening Opportunities for Privileged Guest Operations, Anomalous Behavior, and VMCI Backdoors on Compromised VMware Hosts. Retrieved March 26, 2025.
Open source URL - [6]Microsoft Learn ClickOnce and Authenticode
Microsoft. (2023, March 9). ClickOnce and Authenticode. Retrieved September 9, 2024.
Open source URL - [7]mitre-attackM1045Open source URL
- [8]mitre-attackM1045Open source URL
- [9]mitre-attackM1045Open source URL
- [10]Content trust in Azure Container Registry
Microsoft. (2019, September 5). Content trust in Azure Container Registry. Retrieved October 16, 2019.
Open source URL - [11]Content trust in Docker
Docker. (2019, October 10). Content trust in Docker. Retrieved October 16, 2019.
Open source URL - [12]Content trust in Azure Container Registry
Microsoft. (2019, September 5). Content trust in Azure Container Registry. Retrieved October 16, 2019.
Open source URL - [13]Content trust in Azure Container Registry
Microsoft. (2019, September 5). Content trust in Azure Container Registry. Retrieved October 16, 2019.
Open source URL - [14]Content trust in Docker
Docker. (2019, October 10). Content trust in Docker. Retrieved October 16, 2019.
Open source URL - [15]Content trust in Docker
Docker. (2019, October 10). Content trust in Docker. Retrieved October 16, 2019.
Open source URL - [16]applescript signing
Steven Sande. (2013, December 23). AppleScript and Automator gain new features in OS X Mavericks. Retrieved September 21, 2018.
Open source URL - [17]Cisco IOS Software Integrity Assurance - Deploy Signed IOS
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Deploy Signed IOS. Retrieved October 21, 2020.
Open source URL - [18]Cisco IOS Software Integrity Assurance - Deploy Signed IOS
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Deploy Signed IOS. Retrieved October 21, 2020.
Open source URL - [19]Cisco IOS Software Integrity Assurance - Deploy Signed IOS
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Deploy Signed IOS. Retrieved October 21, 2020.
Open source URL - [20]Cisco IOS Software Integrity Assurance - Deploy Signed IOS
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Deploy Signed IOS. Retrieved October 21, 2020.
Open source URL - [21]Cisco IOS Software Integrity Assurance - Deploy Signed IOS
Cisco. (n.d.). Cisco IOS Software Integrity Assurance - Deploy Signed IOS. Retrieved October 21, 2020.
Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.