Subvert Trust Controls: Code Signing
Process Execute File — Execute a file carrying a cryptographically valid digital signature produced with a stolen, fraudulently issued, or otherwise illegitimately obtained code-signing certificate, so that operating system and security controls trust it as though it came from the certificate's legitimate owner.
Detect
No field observable at the only onsite event (process launch) is invariant in a useful sense. A validly-chained certificate is a necessary precondition, but it is also true of nearly all legitimate signed software on a modern fleet, so gating on it alone has no discriminating power. The only fields that actually separate this technique's instances from the general population — file hash, certificate serial number, certificate subject — are all freely rotated by the attacker once burned, the same way a C2 domain or tool hash is. STP 1–2 is the ceiling, not a practical shortfall from an achievable STP 5: the signing event that would carry the real invariant happens off the defender's monitored environment entirely.
Treat this as IOC-driven detection, not definitional detection: block on certificate serial number / subject once a theft or misuse is disclosed (e.g. via the issuing CA's revocation bulletin), combine with file hash and first-seen/rarity of the signer across the fleet, and expect all of it to be burned the moment the certificate is revoked. There is no rule shape here that survives the attacker acquiring a new certificate.
Mitigate
The only endpoint-side lever is application allowlisting by publisher, capped at STP 2 for the same reason detection is: the attacker controls which certificate/publisher identity is presented, and a stolen certificate from an already-allowlisted publisher still passes. No high-STP mitigation exists at the endpoint — the technique works precisely because the OS cannot distinguish a certificate used by its rightful owner from the same certificate used by a thief.
No STP 5 mitigation exists. Detection is the primary defensive lever.
Endpoint allowlisting restricted to an explicit set of previously-seen publisher/serial pairs reduces blast radius but does not eliminate risk. The durable control sits upstream, at the signing infrastructure itself: hardware-backed (HSM) signing key custody, time-boxed signing approvals, and monitoring of signing-console access — precisely the control gap DigiCert's support-portal abuse exploited. Certificate Transparency monitoring for unexpected certificates issued to your organisation is a useful detective, not preventive, complement.
Respond
A new artifact was created and may persist beyond this session. Delete it immediately. Check for related persistence entries, scheduled tasks, and outbound callbacks originating from it.
actor.processactor.userfile.signature.certificatefiled3f:ProcessTerminationd3f:AccountLockingd3f:CredentialRevokingd3f:FileEvictiond3f:NetworkIsolationOCSF event model▼
Event class: Process Activity (1007)
· activity_id: Launch
%%{init: {"theme": "dark", "themeVariables": {"edgeLabelBackground": "#18181b", "lineColor": "#52525b"}}}%%
graph TD
classDef attacker fill:#7c2d12,stroke:#ea580c,color:#fed7aa
classDef victim fill:#1e3a5f,stroke:#3b82f6,color:#bfdbfe
classDef postSuccess fill:#78350f,stroke:#d97706,color:#fde68a
classDef tainted fill:#18181b,stroke:#52525b,color:#a1a1aa
EVENT(["Process Activity\n· Launch"])
actor_process["Launching Process\nactor.process\nd3f:Process"]:::attacker
actor_user["Running Identity\nactor.user\nd3f:UserAccount"]:::attacker
certificate["Code-Signing Certificate\nfile.signature.certificate\nd3f:Certificate"]:::attacker
signed_file["Signed Executable\nfile\nd3f:ExecutableFile"]:::attacker
device["Host\ndevice\nd3f:Host\n⚠ tainted"]:::tainted
EVENT --> actor_process
actor_process --> actor_user
EVENT --> certificate
EVENT --> signed_file
EVENT --> device
actor_process -.->|"launches"| signed_file
signed_file -.->|"carries signature from"| certificateactor.process·d3f:Processactor.process.file.path | attacker_controlled | Process launching the signed executable (a dropper, loader, or the victim's own shell executing a delivered file) — Execution Medium, attacker-chosen |
d3f:ProcessTerminationactor.user·d3f:UserAccountd3f:AccountLockingfile.signature.certificate·d3f:Certificatefile.signature.certificate.trust_chain_valid | attacker_controlled | Whether the presented chain validates — the attacker's choice to obtain and use a validly-chained certificate (rather than going unsigned or self-signed) is itself the evasion move, and is freely swapped for a different stolen or fraudulently-issued certificate without changing the technique. True for the overwhelming majority of benign software on any fleet, so on its own this field has no discriminating power |
file.signature.certificate.serial_number | attacker_controlled | Serial number of whichever certificate the attacker obtains — rotated between campaigns the same way a hash or C2 domain is, once the previous one is revoked or burned |
file.signature.certificate.subject | attacker_controlled | Publisher identity presented — determined entirely by which certificate the attacker manages to steal or fraudulently acquire, not fixed or predictable |
d3f:CredentialRevokingfile·d3f:ExecutableFilefile.hash.sha256 | attacker_controlled | Malware content hash — freely changed by recompiling; irrelevant to whether the technique applies |
file.path | attacker_controlled | Destination path once delivered — attacker-chosen |
file.name | attacker_controlled | File name — attacker-chosen, trivially renamed without affecting the signature |
d3f:FileEvictiondevice·d3f:Hostd3f:NetworkIsolationDefinitional Sigma rule▼
Broad by design — defines the technique, not an operational alert. Gate on variable or attacker-controlled field conditions to narrow for production use.
title: Subvert Trust Controls: Code Signing (T1553.002)
status: experimental
description: >
Definitional rule — broad by design. Defines the technique independent of
medium, tool, or attacker-controlled variables. Narrow with variable and
attacker-controlled field conditions for operational use.
logsource:
product: ocsf
category: Process Activity (1007)
detection:
selection:
activity_id: 'Launch'
condition: selectionExecution Medium–scoped detectionSTP 3 ceiling▼
Sample rules — not canonical definitions. Each constrains detection to a specific Execution Medium and has a hard STP 3 ceiling. The attacker switches Execution Medium; the rule misses. Compare with the definitional rule above.
Doubly capped: scoped to Windows Authenticode verification surfaced via image-load telemetry (Sysmon Event ID 7) — evaded entirely by any non-Windows code-signing mechanism (macOS codesign/notarization, Android APK signing, Linux package or container signing) — and, even within that channel, still gated on attacker-controlled fields (signer identity, drop path), so it does not exceed the technique's own STP 2 ceiling. Included as the concrete, operational form of the IOC-driven guidance above, not as a higher-STP alternative to it.
title: Subvert Trust Controls: Code Signing — Windows Authenticode medium (sample)
status: experimental
description: >
Sample — STP 2 ceiling, same as the canonical rule. Detects a validly-signed
executable loaded from a user-writable or temporary directory where the
signer is not on a known-good allowlist. Evaded by using any non-Windows
code-signing mechanism, a publisher identity already on the allowlist, or a
freshly-stolen certificate from an unlisted publisher.
logsource:
product: ocsf
category: Process Activity (1007)
detection:
selection_signed:
file.signature.state: 'Verified'
selection_ext:
file.name|endswith: '.exe'
selection_path:
file.path|contains:
- '\\Downloads\\'
- '\\AppData\\Local\\Temp\\'
- '\\Users\\Public\\'
- '\\Desktop\\'
filter_common_signers:
file.signature.certificate.subject|contains:
- 'Microsoft'
- 'Google LLC'
- 'Mozilla Corporation'
- 'Adobe'
- 'Amazon.com'
condition: all of selection_* and not filter_common_signersSeen in the wild1report▼
CylindricalCanine, a GoldenEyeDog subgroup, compromised DigiCert's support portal to activate stolen EV code-signing certificates and used them to sign "Golden Gh0st" loader/RAT malware — a validly-chained Certificate used to sign a File specifically to bypass SmartScreen trust checks.