Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1036.001: Invalid Code Signature

Adversaries may attempt to mimic features of valid code signatures to increase the chance of deceiving a user, analyst, or tool. Code signing provides a level of authenticity on a binary from the developer and a guarantee that the binary has not been tampered with. Adversaries can copy the metadata and signature information from a signed program, then use it as a template for an unsigned program. Files with invalid code signatures will fail digital signature validation checks, but they may appear more legitimate to users and security tools may improperly handle these files.[1]

Unlike Code Signing, this activity will not result in a valid signature.

EnterpriseT1036.001Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Invalid Code Signature is a masquerading behavior where an executable may look like it carries trusted signing metadata, but the signature does not actually validate. The business issue is misplaced trust: users, analysts, or tools may treat a file as legitimate based on appearance rather than verification. For Windows and macOS environments, this is material to SOC triage, software trust decisions, and incident response because signature status can separate genuinely trusted code from code attempting to borrow legitimacy.

Executive priority

Leaders should verify whether code-signing checks are used as enforceable control evidence or only as a visual cue during investigation. This technique matters for operational resilience and audit readiness because an invalid signature can expose gaps between policy, endpoint enforcement, and SOC workflow. Priority should be placed on validating that security tools, analysts, and software approval processes distinguish between trusted signed code, unsigned code, and code with copied or invalid signature metadata.

Technical view

For SOC and IR teams, treat this as a metadata-plus-behavior problem on macOS and Windows. ATT&CK provides no official detection text, but the related detection strategy DET0031 points toward detecting invalid code signature execution using metadata and behavioral context. Detection engineering should validate that file execution events include signature validation outcome, signer or publisher metadata, file path, hash, parent process, and subsequent behavior. Because this is a sub-technique of Masquerading, do not alert only on familiar-looking vendor names or file descriptions; confirm cryptographic validation status.

Likely telemetry

  • Executable file metadata and digital signature validation results
  • Process execution records with file path, hash, parent process, and command context
  • File creation, download, or quarantine events for newly introduced binaries
  • Endpoint security alerts that distinguish valid, invalid, and unsigned signatures
  • macOS and Windows software trust or code-signing assessment results

Detection direction

  • Confirm telemetry records the result of signature validation, not just signer-looking metadata such as product name, company name, or file description.
  • Prioritize alerts where a file presents trusted-looking metadata but fails signature validation, especially when executed from user-writable or unusual locations.
  • Tune for false positives from internally developed, test, or poorly packaged software that may have invalid signatures; require local allow decisions to be documented.
  • Correlate invalid signature execution with masquerading context such as unusual file names, locations, parent processes, or post-execution behavior.
  • Use related threat and software relationships as intelligence context only; do not infer attribution from the presence of this behavior.

Mitigation priorities

  • Implement and enforce code-signing validation policies where operationally feasible, aligned to mitigation M1045 Code Signing.
  • Require software approval workflows to verify signature validity rather than relying on displayed metadata or apparent publisher names.
  • Reduce exceptions for unsigned or invalidly signed executables, and document business owners for any required exceptions.
  • Use endpoint controls to block or challenge execution of code that fails trust validation in high-risk locations or workflows.
  • Train SOC and IR teams to treat invalid signatures as a trust failure requiring behavioral review, not as proof of benign or malicious status by itself.
Analyst notes and limits

ATT&CK links this behavior to APT37, Windshift, and multiple software entries including Regin, BADNEWS, NETWIRE, WindTail, Gelsemium, PcShare, and SplatCloak. These relationships show observed use across Windows and macOS-related contexts, but they should be used for enrichment rather than attribution. The supplied detection relationship supports a strategy based on metadata and behavioral context; local telemetry quality will determine practical coverage.

The official ATT&CK object does not provide detection text, and the supplied mitigation description is truncated. This take is therefore limited to the official description, listed platforms, tactics, external reference, and relationships. Organizations must validate exact event sources, enforcement capability, exception handling, and false-positive rates in their own Windows and macOS environments.

Official MITRE ATT&CK definition

Invalid Code Signature

Adversaries may attempt to mimic features of valid code signatures to increase the chance of deceiving a user, analyst, or tool. Code signing provides a level of authenticity on a binary from the developer and a guarantee that the binary has not been tampered with. Adversaries can copy the metadata and signature information from a signed program, then use it as a template for an unsigned program. Files with invalid code signatures will fail digital signature validation checks, but they may appear more legitimate to users and security tools may improperly handle these files.[1]

Unlike Code Signing, this activity will not result in a valid signature.

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

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1036 Masquerading This object subtechnique of Masquerading.
Associated objects

Groups, software, and campaigns

Group Enterprise

G0067: APT37

APT37 is a North Korean state-sponsored cyber espionage group that has been active since at least 2012. The group has targeted victims primarily in South Korea, but also in Japan, Vietnam, Russia, Nepal, China, India, Romania, Kuwait, and other parts of the Middle East. APT37 has also been linked to the following campaigns between 2016-2018: Operation Daybreak, Operation Erebus, Golden Time, Evil New Year, Are you Happy?, FreeMilk, North Korean Human Rights, and Evil New Year 2018.[1][2][3]

North Korean group definitions are known to have significant overlap, and some security researchers report all North Korean state-sponsored cyber activity under the name Lazarus Group instead of tracking clusters or subgroups.

Group Enterprise

G0112: Windshift

Windshift is a threat group that has been active since at least 2017, targeting specific individuals for surveillance in government departments and critical infrastructure across the Middle East.[1][2][3]

Malware Enterprise

S0128: BADNEWS

BADNEWS is malware that has been used by the actors responsible for the Patchwork campaign. Its name was given due to its use of RSS feeds, forums, and blogs for command and control. [1] [2]

Windows
Malware Enterprise

S0019: Regin

Regin is a malware platform that has targeted victims in a range of industries, including telecom, government, and financial institutions. Some Regin timestamps date back to 2003. [1]

Windows
Malware Enterprise

S0198: NETWIRE

NETWIRE is a publicly available, multiplatform remote administration tool (RAT) that has been used by criminal and APT groups since at least 2012.[1][2][3]

WindowsLinuxmacOS
Tool Enterprise

S1050: PcShare

PcShare is an open source remote access tool that has been modified and used by Chinese threat actors, most notably during the FunnyDream campaign since late 2018.[1][2]

Windows
Malware Enterprise

S0666: Gelsemium

Gelsemium is a modular malware comprised of a dropper (Gelsemine), a loader (Gelsenicine), and main (Gelsevirine) plug-ins written using the Microsoft Foundation Class (MFC) framework. Gelsemium has been used by the Gelsemium group since at least 2014.[1]

Windows
Relationship explorer

All related ATT&CK context

uses · Malware S0466: WindTail Enterprise mitigates · Mitigation M1045: Code Signing Enterprise uses · Malware S0128: BADNEWS Enterprise uses · Malware S0019: Regin Enterprise uses · Group G0067: APT37 Enterprise uses · Group G0112: Windshift Enterprise uses · Malware S1234: SplatCloak Enterprise uses · Malware S0198: NETWIRE Enterprise subtechnique of · Technique T1036: Masquerading Enterprise uses · Tool S1050: PcShare Enterprise detects · Detection Strategy DET0031: Invalid Code Signature Execution Detection via Metadata and Behavioral Context Enterprise uses · Malware S0666: Gelsemium Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

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.

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
2.0
Created
Modified
Raw hash
c6524144e91f7599...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle c6524144e91f…
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. [1]
    Threatexpress MetaTwin 2017

    Vest, J. (2017, October 9). Borrowing Microsoft MetaData and Signatures to Hide Binary Payloads. Retrieved September 10, 2019.

    Open source URL
  2. [2]
    mitre-attack T1036.001
    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