Malware Signed With Newly Seen Low-Prevalence Code-Signing Certificate Executing From User-Writable Path
Operators who cannot keep malware from being flagged as unsigned buy or steal code-signing certificates (Extended Validation certificates issued to shell companies, stolen vendor keys, or abused Trusted Signing accounts) and sign loaders, stealers, and trojanised installers with them. A valid Authenticode signature lets the payload pass SmartScreen, application-control allowlists that trust 'signed' code, and many EDR reputation shortcuts. The resource-development step (T1588.003 Obtain Capabilities: Code Signing Certificates) happens off-network, but it leaves a consistent victim-side fingerprint: an executable or DLL whose signature validates yet whose signer subject has never been seen in the estate before, is carried by very few hosts, and runs from a user-writable location such as Downloads, AppData, Temp, or ProgramData. This rule surfaces that fingerprint by baselining signer subjects over 30 days and alerting on first-seen, low-prevalence signers on user-writable-path execution, with signer certificates freshly issued (under 90 days old) raised in priority because campaign certificates are typically used within weeks of issuance and revoked soon after.
What is THREAT-ResourceDev-AbusedCodeSigningCertLowPrevalenceSigner Malware Signed With Newly Seen Low-Prevalence Code-Signing Certificate Executing From User-Writable Path?
Malware Signed With Newly Seen Low-Prevalence Code-Signing Certificate Executing From User-Writable Path (THREAT-ResourceDev-AbusedCodeSigningCertLowPrevalenceSigner) maps to the Resource Development tactic — the adversary is trying to establish resources they can use to support operations in MITRE ATT&CK.
This page provides production-ready detection logic for Malware Signed With Newly Seen Low-Prevalence Code-Signing Certificate Executing From User-Writable Path, covering the data sources and telemetry it touches: File: File Metadata, Process: Process Creation, Microsoft Defender for Endpoint (DeviceFileCertificateInfo, DeviceProcessEvents). The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Resource Development
let Lookback = 1d;
let BaselineWindow = 30d;
let UserWritable = dynamic(["\\users\\", "\\appdata\\", "\\temp\\", "\\downloads\\", "\\programdata\\", "\\users\\public\\"]);
// Signers already seen on process executions in the baseline window (excluded from alert window)
let KnownSigners =
DeviceFileCertificateInfo
| where Timestamp between (ago(BaselineWindow) .. ago(Lookback))
| where IsSigned == 1 and IsTrusted == 1
| summarize by Signer;
// Signer prevalence across the estate in the alert window
let SignerPrevalence =
DeviceFileCertificateInfo
| where Timestamp > ago(Lookback)
| where IsSigned == 1 and IsTrusted == 1
| summarize DeviceCount = dcount(DeviceId), FileCount = dcount(SHA1) by Signer;
DeviceFileCertificateInfo
| where Timestamp > ago(Lookback)
| where IsSigned == 1 and IsTrusted == 1
| where Signer !in (KnownSigners)
| join kind=inner (SignerPrevalence | where DeviceCount <= 3) on Signer
| join kind=inner (
DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where tolower(FolderPath) has_any (UserWritable)
| project DeviceId, SHA1, ProcTime = Timestamp, FileName, FolderPath, ProcessCommandLine,
InitiatingProcessFileName, AccountName
) on DeviceId, SHA1
| extend CertAgeDays = datetime_diff('day', Timestamp, CertificateCreationTime)
| extend FreshCert = iff(CertAgeDays between (0 .. 90), true, false)
| project ProcTime, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine,
InitiatingProcessFileName, Signer, Issuer, CertificateSerialNumber, CertAgeDays, FreshCert,
DeviceCount, SHA1
| order by FreshCert desc, ProcTime descBaseline-and-diff query over Defender for Endpoint DeviceFileCertificateInfo (signature metadata for files observed on endpoints). It removes every signer subject seen in the prior 30 days, keeps signers carried by at most three devices in the last day, and joins to DeviceProcessEvents on DeviceId and SHA1 to require that the signed binary actually executed from a user-writable path. Certificate age is computed from CertificateCreationTime and certs issued within 90 days are flagged FreshCert, which is the strongest prioritisation signal because campaign certificates are burned within weeks.
Data Sources
Required Tables
False Positives
- Legitimate new software vendors or new vendor signing certificates introduced by an application rollout, which present a first-seen signer until the baseline catches up
- Vendor certificate renewals where the signer subject string changes (company rename, new legal entity, or new EV subject format)
- Developer or QA workstations running freshly built internally signed test binaries from Downloads or Temp
- Per-user installers (Electron apps, updaters) from small vendors that unpack signed helpers into AppData and are only present on one or two devices
Sigma rule & cross-platform mapping
The detection logic for Malware Signed With Newly Seen Low-Prevalence Code-Signing Certificate Executing From User-Writable Path (THREAT-ResourceDev-AbusedCodeSigningCertLowPrevalenceSigner) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windowsBrowse the community-maintained Sigma rules for this technique:
Platform-specific guides for THREAT-ResourceDev-AbusedCodeSigningCertLowPrevalenceSigner
References (7)
- https://attack.mitre.org/techniques/T1588/003/
- https://attack.mitre.org/techniques/T1553/002/
- https://attack.mitre.org/tactics/TA0042/
- https://www.microsoft.com/en-us/security/blog/2025/09/04/dissecting-pipemagic-inside-the-architecture-of-a-modular-backdoor-framework/
- https://www.microsoft.com/en-us/security/blog/2025/05/21/lumma-stealer-breaking-down-the-delivery-techniques-and-capabilities-of-a-prolific-infostealer/
- https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-devicefilecertificateinfo-table
- https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/select-types-of-rules-to-create
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1 Execute Self-Signed Test Binary From User Download Path
Expected signal: Sysmon Event ID 1 for atomic_t1588_003.exe under Downloads; Event ID 7 with Signature 'Atomic Test Software LLC'; DeviceFileCertificateInfo row with that Signer and a CertificateCreationTime within the last day.
- Test 2 Inspect Signer Metadata For Executable In Temp
Expected signal: Sysmon Event ID 1 and Event ID 7 for atomic_t1588_003_b.exe in %TEMP% with a Microsoft signer; DeviceFileCertificateInfo row with Signer Microsoft Windows.
- Test 3 Enumerate Authenticode Signer Of Downloaded Files
Expected signal: Sysmon Event ID 1 for powershell.exe with Get-AuthenticodeSignature in the command line; PowerShell Script Block Logging Event ID 4104.
Response Playbook
Triage
- Pull the signer subject, issuer, serial number, and certificate validity dates. A certificate issued within the last 90 days to an unfamiliar company name (especially a generic LLC, a one-person firm, or a name that mimics a known vendor) is a strong indicator of a purchased campaign certificate.
- Identify who launched the binary and from where: check the parent process and whether the file arrived via browser download, an archive extracted from email, or a USB device. SocGholish and malvertising chains typically deliver signed installers named after a browser or document update.
- Look up the file SHA256 and the certificate thumbprint in VirusTotal, MalwareBazaar, and the CCADB/SSLBL-style revoked-certificate feeds. Many abused certificates are already reported and revoked but remain trusted on hosts that do not check revocation.
- Check whether the same signer subject or serial number appears on other hosts in the estate, using the signer as a hunt key rather than the hash — operators re-sign each build, so hashes differ while the certificate stays constant.
- Review what the binary did after launch: child processes, outbound connections to new domains, persistence (run keys, scheduled tasks, services), and credential-store access.
- Confirm the vendor identity out of band. If the signer claims to be a legitimate vendor, verify with the application owner that this publisher and installer are expected before dismissing.
Containment
- Isolate the endpoint via EDR network isolation if the binary executed and shows follow-on behavior (persistence, new C2 connections, credential access).
- Add the certificate thumbprint and serial to the EDR/application-control block list as a certificate-based indicator so every re-signed build by that operator is blocked, and submit the certificate to the issuing CA for revocation.
- Quarantine the file and its SHA256 across the fleet, and hunt for the same signer subject on other hosts before they execute it.
- If the binary executed, reset credentials and revoke sessions for the logged-on user, and rotate any secrets stored in browser profiles on the host.
- Where application control trusts 'any valid signature', tighten policy to publisher allowlisting (WDAC publisher rules) so a purchased certificate alone no longer confers trust.
Evidence Collection
- Collect the binary and its full Authenticode chain (signer, countersigner/timestamp, issuer, serial, thumbprint) using sigcheck or Get-AuthenticodeSignature.
- Capture DeviceFileCertificateInfo or Sysmon Event ID 7 rows for the signer across all hosts for the past 30 days.
- Preserve the browser download history and Mark-of-the-Web Zone.Identifier stream to establish the delivery URL.
- Acquire process tree, network connections, and autoruns output from the host before isolation changes state.
Escalation Criteria
- ! Escalate to incident response if the signer certificate is under 90 days old and the binary was delivered via browser or email and executed.
- ! Escalate if the same unfamiliar signer appears on two or more hosts or the binary shows persistence, C2, or credential access.
- ! Escalate if the certificate matches a known abused or revoked certificate in threat intelligence, or if a legitimate vendor's own signing key appears compromised (supply-chain scenario).
Investigation Guide
Forensic Artifacts
- >
Authenticode signature block of the PE: signer subject, issuer, serial, thumbprint, and timestamp countersignature. - >
DeviceFileCertificateInfo rows (Signer, Issuer, CertificateSerialNumber, CertificateCreationTime, CertificateExpirationTime, IsTrusted). - >
Sysmon Event ID 7 (Image Loaded) with Signature and SignatureStatus fields, and Event ID 1 for the launch command line. - >
Zone.Identifier alternate data stream on the downloaded file and browser download history. - >
Windows CAPI2 operational log (Event ID 11/70) showing certificate chain build and revocation checks.
Tuning Guidance
Run the baseline for at least 30 days before alerting, then allowlist signer subjects (not file hashes) that belong to approved vendors. Keep the prevalence threshold (<=3 devices) small in large estates and raise it in small ones. Prioritise on certificate age: a signer under 90 days old, executing from Downloads or AppData, delivered via browser, is the high-fidelity case. Do not allowlist by 'IsTrusted' alone, since the attack premise is that the certificate is valid.
Hunting Queries
Lists trusted signers carried by two or fewer devices over 30 days.
// Hunt: trusted signers carried by very few devices in 30 days
DeviceFileCertificateInfo
| where Timestamp > ago(30d)
| where IsTrusted == 1
| summarize Devices = dcount(DeviceId), FirstSeen = min(Timestamp) by Signer, CertificateSerialNumber
| where Devices <= 2
| order by FirstSeen descindex=sysmon EventCode=7 Signed=true SignatureStatus=Valid earliest=-30d | stats dc(host) as Devices min(_time) as FirstSeen by Signature | where Devices<=2 | sort - FirstSeenSurfaces recently issued trusted certificates; SPL variant lists signers by host prevalence since Sysmon lacks certificate dates.
// Hunt: freshly issued trusted certificates seen on endpoints
DeviceFileCertificateInfo
| where Timestamp > ago(7d)
| extend AgeDays = datetime_diff('day', Timestamp, CertificateCreationTime)
| where AgeDays between (0 .. 30) and IsTrusted == 1
| summarize Devices = dcount(DeviceId) by Signer, Issuer, CertificateSerialNumberindex=sysmon EventCode=7 Signed=true SignatureStatus=Valid earliest=-7d | stats dc(host) as Devices values(ImageLoaded) as Files by Signature | sort DevicesAtomic Red Team Tests
Creates a self-signed code-signing certificate, signs a copy of a benign binary with it, and executes it from the Downloads folder to reproduce the user-writable-path signed-execution pattern. The self-signed cert will not be IsTrusted unless added to the trusted store, so the test adds it to CurrentUser Root to simulate a trusted unfamiliar signer.
Command
$c = New-SelfSignedCertificate -Type CodeSigningCert -Subject 'CN=Atomic Test Software LLC' -CertStoreLocation Cert:\CurrentUser\My; $root = New-Object System.Security.Cryptography.X509Certificates.X509Store('Root','CurrentUser'); $root.Open('ReadWrite'); $root.Add($c); $root.Close(); Copy-Item $env:SystemRoot\System32\whoami.exe $env:USERPROFILE\Downloads\atomic_t1588_003.exe; Set-AuthenticodeSignature -FilePath $env:USERPROFILE\Downloads\atomic_t1588_003.exe -Certificate $c; & $env:USERPROFILE\Downloads\atomic_t1588_003.exeCleanup
Remove-Item $env:USERPROFILE\Downloads\atomic_t1588_003.exe -Force -ErrorAction SilentlyContinue; Get-ChildItem Cert:\CurrentUser\My,Cert:\CurrentUser\Root | Where-Object { $_.Subject -eq 'CN=Atomic Test Software LLC' } | Remove-Item -ForceExpected Telemetry
Sysmon Event ID 1 for atomic_t1588_003.exe under Downloads; Event ID 7 with Signature 'Atomic Test Software LLC'; DeviceFileCertificateInfo row with that Signer and a CertificateCreationTime within the last day.
Expected Detection
KQL fires on first-seen signer 'Atomic Test Software LLC' with DeviceCount=1, executing from \downloads\, FreshCert=true. SPL fires on the first-seen signer in the Sysmon image-load stream. IsTrusted=1 requires the root-store step to be honored; if the host reports IsTrusted=0, add the cert to TrustedPublisher as well.
Copies a Microsoft-signed binary to %TEMP% and runs it, generating a user-writable-path signed execution baseline row so analysts can confirm the Signer field populates and that the vendor exclusions suppress it.
Command
Copy-Item $env:SystemRoot\System32\hostname.exe $env:TEMP\atomic_t1588_003_b.exe; & $env:TEMP\atomic_t1588_003_b.exeCleanup
Remove-Item $env:TEMP\atomic_t1588_003_b.exe -Force -ErrorAction SilentlyContinueExpected Telemetry
Sysmon Event ID 1 and Event ID 7 for atomic_t1588_003_b.exe in %TEMP% with a Microsoft signer; DeviceFileCertificateInfo row with Signer Microsoft Windows.
Expected Detection
Should NOT fire: Microsoft signer is excluded or already in the 30-day baseline. Serves as the negative control for the tuning exclusions.
Lists signer subject, status, and certificate NotBefore date for executables in Downloads, mirroring the analyst triage step of checking certificate age and subject.
Command
Get-ChildItem $env:USERPROFILE\Downloads -Include *.exe,*.dll -Recurse -ErrorAction SilentlyContinue | ForEach-Object { $s = Get-AuthenticodeSignature $_.FullName; [pscustomobject]@{File=$_.Name; Status=$s.Status; Subject=$s.SignerCertificate.Subject; NotBefore=$s.SignerCertificate.NotBefore} }Cleanup
# read-only; nothing to clean upExpected Telemetry
Sysmon Event ID 1 for powershell.exe with Get-AuthenticodeSignature in the command line; PowerShell Script Block Logging Event ID 4104.
Expected Detection
Does not trigger the main rule; validates the triage procedure and produces script block logging evidence.