Investigating a Mysteriously Malformed Authenticode Signature

Investigating a Mysteriously Malformed Authenticode Signature

Elastic Security Labs diagnosed a Windows signature validation failure caused by an internal heuristic that flags certain byte-pattern “invalid markers” inside PE signature blocks, which in their case produced a false positive due to an EGGA marker collision. Re-signing with signtool.exe /rmc fixed validation, and the root cause was traced to imagehlp.dll’s ImageGetCertificateDataEx using IsBufferCleanOfInvalidMarkers and a hardcoded marker list (registry override at PECertInvalidMarkers). #ImageGetCertificateDataEx #PECertInvalidMarkers

Keypoints

  • Elastic encountered TRUST_E_MALFORMED_SIGNATURE when validating a signed Windows binary despite no obvious signing changes.
  • Debugging WinVerifyTrust revealed psSipSubjectInfo->dwReserved1 was set, causing a call to I_GetRelaxedMarkerCheckFlags which returned no data and triggered the error.
  • I_GetRelaxedMarkerCheckFlags looks for the OID 1.3.6.1.4.1.311.2.6.1 (SpcRelaxedPEMarkerCheck); signing with signtool /rmc added this attribute and restored validation.
  • The dwReserved1 flag originates from imagehlp.dll’s ImageGetCertificateDataEx, which returns an extra output indicating invalid marker detection via IsBufferCleanOfInvalidMarkers.
  • imagehlp.dll contains a hardcoded list of “invalid markers” (archive/installers magic values) and optionally a registry override at HKEY_LOCAL_MACHINESoftwareMicrosoftCryptographyWintrustConfigPECertInvalidMarkers.
  • The problematic binary contained the EGGA marker inside its signature block (a benign collision), causing a false positive when page hashing increased signature block size.
  • Root cause: Microsoft heuristics (introduced circa 2012) detect embedded archives in signature data to mitigate abuse; collisions can create undocumented validation failures—re-sign with /rmc or avoid marker collisions.

MITRE Techniques

  • [T1609 ] Indicator Removal on Host – The article describes how signature blocks can be manipulated or used to embed additional data without breaking signatures; Microsoft added heuristics to detect such abuse. Quote: ‘…additional data can be embedded in a PE file without breaking its signature by appending it to the security block.’
  • [T1496 ] Resource Hijacking – The analysis discusses how self-extracting executables or embedded archives in PE signature regions could be abused to store malicious data that a binary might read; Microsoft scans for markers to prevent this. Quote: ‘…an executable reads itself from disk and scans its own data for an embedded archive…an attacker could potentially append malicious data to the signature section…’

Indicators of Compromise

  • [Registry ] Wintrust configuration key controlling invalid markers – HKEY_LOCAL_MACHINESoftwareMicrosoftCryptographyWintrustConfigPECertInvalidMarkers (used to override default list)
  • [Function/Export ] imagehlp.dll export used in detection – ImageGetCertificateDataEx (extra output indicates invalid markers)
  • [Marker signature ] Marker found in signature block causing false positive – “EGGA” (ALZip header) and examples of other markers like “PKx01x02”, “Rar!x1Ax07x00” (and many archive/installer magic strings)


Read more: https://www.elastic.co/security-labs/malformed-authenticode-signature