A signed file in an alert: verify the signature and continue the investigation
Separate the collected file, Authenticode verification, trust and observed behavior when investigating a suspicious Windows executable.
Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.
An alert concerns a Windows executable. Its details show a familiar publisher and a valid signature. That result is worth preserving, but which question does it answer? Before closing the alert, the SOC needs to connect the file examined, the checks actually performed and the activity that triggered detection.
Authenticode provides evidence about signer identity and the integrity of content covered by the signature, within a chain of trust. Interpret its result within that scope. The following method concerns investigation of a Windows file; it does not replace a malware analysis procedure. Source: Microsoft, Authenticode
1. Establish the identity of the file actually examined
Our recommendation: retain the alert reference, affected device, observation time and origin of the analyzed copy. Record its size and a cryptographic hash of the complete file, including the algorithm used. A matching name or location is insufficient to connect two observations.
Check whether the file was replaced between the alert and collection. A copy downloaded from the publisher's website may serve as a reference, but it does not establish what was on the device at the time. If the original copy is unavailable, state that limitation rather than silently substituting a recent version.
Check the type of hash as well. Microsoft distinguishes a flat file hash from the Authenticode hash of a PE image, whose calculation excludes certain areas, including signature-related data. Two values labeled with the same algorithm are not necessarily comparable. Source: Microsoft, hash types
Document the calculation method when comparing inventory, application control rules and incident evidence. Preserve the original under your evidence procedure and work on a copy. Examining a signature does not require launching the suspicious executable on an analyst's workstation.
2. Understand what the tool actually verified
SignTool distinguishes embedded signatures from catalog lookups, supports different validation policies and can verify multiple signatures. Its documentation also notes the importance of policy selection and that execution may finish with warnings. A summary reading “signed” loses those distinctions. Source: Microsoft, SignTool
We recommend retaining detailed output with the tool version, analysis system, applied policy and check time. Identify the signature selected, the signing certificate and any catalog used. Establish how multiple signatures were handled rather than assuming that one summary line covers them all.
A tool that finds no embedded signature has not necessarily searched for a catalog signature. Source: Microsoft, verifying a signature Conversely, displaying a certificate in a file's properties does not document every trust check. Before comparing two results, confirm that they concern the same file and validation method.
3. Preserve trust context and uncertainty
A valid Authenticode timestamp can allow verification after the signing certificate expires, subject to applicable trust checks. The displayed expiry date alone is therefore insufficient for a conclusion. Examine the timestamp and validation result without treating them as permission to execute the file. Source: Microsoft, Authenticode timestamping
Revocation checks and network retrieval also depend on verification settings. WinTrust documentation includes revocation checks and an option to use only the local cache. An offline analysis environment must be identified as such in the evidence. Source: Microsoft, WinTrust settings
Our recommendation: distinguish successful validation, an identified rejection and an incomplete check. When necessary information is unavailable, preserve that uncertainty and assign the follow-up verification. Do not disable a check or add a trusted certificate simply to obtain a favorable result.
If results differ between the affected device and the analysis environment, document the difference: system, policy, trust stores, time and available access. A fresh verification explains what was observed at that moment; it does not automatically recreate the result the device could have obtained during the incident.
4. Connect the file to the activity that triggered detection
MITRE ATT&CK describes adversaries using acquired or stolen signing material to sign malicious tools, potentially producing valid signatures. This possibility supports continued behavioral analysis; it does not establish that the signer of the file under examination was compromised. Source: MITRE ATT&CK, Code Signing
Return to the detection: which activity needs an explanation, on which device and at what time? We recommend connecting the file to available observations of its launch, user context, actions and communications. Verification of a copy on disk must remain distinct from evidence about the process actually observed.
Entirely fictional example: an administration tool signed by a familiar publisher appears in a file-transfer alert. Its valid signature helps identify the collected tool. The investigation still needs to establish who launched it, the destination, the relevant authorization and which data was involved. Confirmed legitimate use and unauthorized use remain different possible conclusions.
Avoid an exception covering every file from a publisher to explain this one occurrence. If expected activity is confirmed, limit the decision to the verified scope. If the behavior remains unexplained, keep the case open under your procedure even when the signature is valid.
5. Separate local analysis from third-party submissions
Sigcheck offers local checks, VirusTotal lookups by file hash and a separate option to upload files unknown to that service. Those functions have different data-sharing implications. Source: Microsoft Sysinternals, Sigcheck
Before external enrichment, check the data being sent, the recipient and applicable authorization. A hash lookup and uploading the file are separate decisions. An unsuccessful lookup must not automatically trigger submission of a binary containing internal information.
We recommend recording signature and reputation results separately, with their dates and sources. Specify what each service actually examined. Neither observation removes the need to explain the activity behind the alert.
6. Produce a conclusion the next team can verify
A decision record should bring together the collected file's identity, its connection to the alert, validation method, signer, any timestamp, detailed result and limits of the check. Add behavioral observations, the decision, its owner and anything still requiring confirmation.
Test the procedure using harmless test files in an authorized environment, with expected results written in advance:
- A signed file and a different copy with the same name.
- A catalog-signed file examined with and without a catalog lookup.
- A file with multiple signatures whose results must remain identifiable.
- A timestamped signature whose signing certificate has expired.
- A check for which required revocation information is unavailable.
- A signed tool whose authorized and unauthorized uses are described in two fictional scenarios.
Confirm that the method preserves warnings, allows an undetermined status and never turns technical validation into automatic closure. A useful conclusion states what the signature establishes, which behavior has been explained and which evidence is still needed to decide.