MITRE ATT&CK® Mitigation

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.

EnterpriseM1045MitigationObject v1.2 Modified Dec 10, 2024, 18:52 UTC (UTC+00:00)

Discuss defensive coverage Back to ATT&CK

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.

Analyst 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.

Official MITRE ATT&CK definition

Code Signing

Enforce Signed Code Execution:

Vendor-Signed Driver Enforcement:

Certificate Revocation Management:

Third-Party Software Verification:

Script Integrity in CI/CD Pipelines:

**Key Components of Code Signing**

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

Filter related techniques 22 rows

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 Image Sub-technique	Utilize a trust model such as Docker Content Trust with digital signatures to ensure runtime verification of the integrity and publisher of specific image tags.CitationContent trust in DockerCitationContent trust in Azure Container Registry
Enterprise	T1525	Implant Internal Image	Several cloud service providers support content trust models that require container images be signed by trusted sources.CitationContent trust in Azure Container RegistryCitationContent trust in Docker
Enterprise	T1059.002	AppleScript Sub-technique	Require that all AppleScript be signed by a trusted developer ID before being executed - this will prevent random AppleScript code from executing.Citationapplescript signing 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 Location Sub-technique	Require signed binaries and images.
Enterprise	T1036.001	Invalid Code Signature Sub-technique	Require signed binaries.
Enterprise	T1546.013	PowerShell Profile Sub-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 Image Sub-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. CitationCisco IOS Software Integrity Assurance - Deploy Signed IOS
Enterprise	T1601.002	Downgrade System Image Sub-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. CitationCisco IOS Software Integrity Assurance - Deploy Signed IOS
Enterprise	T1543.003	Windows Service Sub-technique	Enforce registration and execution of only legitimately signed service drivers where possible.
Enterprise	T1059.001	PowerShell Sub-technique	Set PowerShell execution policy to execute only signed scripts.
Enterprise	T1505.001	SQL Stored Procedures Sub-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. CitationCisco IOS Software Integrity Assurance - Deploy Signed IOS
Enterprise	T1505.004	IIS Components Sub-technique	Ensure IIS DLLs and binaries are signed by the correct application developers.
Enterprise	T1546.006	LC_LOAD_DYLIB Addition Sub-technique	Enforce that all binaries be signed by the correct Apple Developer IDs.
Enterprise	T1505.006	vSphere Installation Bundles Sub-technique	Enabling the `execInstalledOnly` feature prevents unsigned binaries from being run on ESXi hosts.CitationGoogle Cloud Threat Intelligence ESXi Hardening 2023
Enterprise	T1505.002	Transport Agent Sub-technique	Ensure all application component binaries are signed by the correct application developers.
Enterprise	T1127.002	ClickOnce Sub-technique	Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing.CitationMicrosoft Learn ClickOnce and Authenticode

Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release: 19.1
Object version: 1.2
Created: Jun 11, 2019, 17:01 UTC (UTC+00:00)
Modified: Dec 10, 2024, 18:52 UTC (UTC+00:00)
Raw hash: c3d1de7054b90194...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.2	Dec 10, 2024, 18:52 UTC (UTC+00:00)	Current bundle	`c3d1de7054b9…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
mitre-attack M1045
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use