Real-world case: Relic revealed an unusual PKCS#7 structure anomaly in a signed Windows executable #57
Description
During daily malware sample analysis, I encountered an interesting case where a legitimate NVIDIA executable was abused in a sideloading scenario. The file had been modified, yet it still appeared to be signed when checked with Windows’ own tools such as signtool.exe and PowerShell’s Get-AuthenticodeSignature.
However, when we processed the same file through our internal analysis chain — which includes Relic as one of the signature/PKCS#7 inspection tools — we discovered that the PKCS#7 structure itself contained trailing data beyond the declared ASN.1 length. Relic’s strict parsing exposed this structural inconsistency, which immediately drew our attention to the file.
In short:
- The PE file’s WIN_CERTIFICATE section length equals “valid PKCS#7 signature length + extra appended data.”
- From a PE format perspective, the file is structurally valid and runs normally.
- But when parsed as ASN.1/PKCS#7, the declared length covers only the actual signature data — the appended bytes are outside of it, triggering an error such as:
pkcs7: trailing garbage after PKCS#7 structure
- Windows’ verification logic appears to be more lenient, focusing only on the main signature validation, so it still treats the file as “validly signed.”
- The extra bytes at the end include a clear marker sequence like
FE ED FA CE FE ED FA CE. Their total size is small — unlikely to be shellcode — more likely an embedded marker or identifier.
This was a surprising and delightful finding: Relic helped surface a subtle structural anomaly that Windows itself silently ignored, and it turned out to be a useful clue during malware attribution.
I will attach the following to the Issue:
- Two file hashes (so others can reproduce or fetch the exact files):
- Modified / exploited NVIDIA file (the one observed in this incident) — SHA256: 13842116F927E3A652DB1ED1ECDF28E59F033120FA35903A3AEDE1258EA456DD
- Original NVIDIA file (the known-good binary) — SHA256: FAF8CEE3884BE9B2FC007DF63CC5B9ABAA3490EEB1D014E0BCF8A5A78332AD84
- A few comparison screenshots showing how
signtool.exe,Get-AuthenticodeSignature, and Relic each report/handle the same sample.
Thanks to the Relic team for creating such a transparent tool — this is a great example of how it can reveal hidden details even in “validly signed” executables.
Interestingly, after I uploaded the sample to VirusTotal, I noticed that VT marks the file as “File is not signed.”
However, several other online sandbox and analysis platforms — similar to Windows’ own verification tools — still report it as validly signed.
This further highlights how different verification implementations handle the PKCS#7 structure with varying levels of strictness.