Code signing tells you who published a binary and that it was not changed afterward. MITRE ATT&CK technique T1553.002, Code Signing, covers adversaries who create, acquire or steal code signing material to sign their own malware or tools. It sits under defense impairment and applies to macOS and Windows.
How attackers use it
MITRE is direct about the key point: unlike an invalid code signature (T1036.001), this activity results in a valid signature. The certificates may be created, acquired or stolen by the adversary.
Signing to verify software on first run is used on modern Windows and macOS. MITRE notes it is not used on Linux because of the decentralized nature of the platform. Signed code can then slip past security policies that require signed code to execute.
How to detect it
MITRE lists no data sources for this technique, which tells you something: a signature check alone cannot catch it, because the signature is valid. Look at who signed instead. New publishers or certificates in your environment, signed binaries in unusual paths, and signed software with no matching approved change request are all worth a review.
How to reduce the risk
MITRE does not list mitigations for this technique. A sensible approach is to move from "is it signed" to "is it signed by someone we expect, and can we trace where it came from". Allowlist by publisher and by hash for sensitive systems, and for software you build, record provenance so you can later prove what produced an artifact.
The demo shows how attestation and provenance records work.
Click through it at your own pace, or open it full screen.
Quick check
If a binary has a valid signature, is it safe to run?
No. Signing proves the signer and integrity, not intent. An adversary with created, acquired or stolen signing material produces a valid signature.
