EXPLORE
← Back to Explore
sigmalowHunting

Signed DLL Loaded With Missing PE Version Metadata

Detects the loading of a digitally signed DLL whose PE version-info resource is entirely missing. Legitimate signed DLLs from reputable vendors often carry populated metadata fields (Description, Company, Product, OriginalFileName, FileVersion). An attacker who signs a purpose-built or hollowed DLL with a stolen, mis-issued, or cheaply purchased code-signing certificate will often omit these fields, producing a valid signature with no accompanying version info. This pattern is observed in DLL side-loading, search-order hijacking, and certificate-abuse campaigns where signing is used purely to satisfy security-product trust checks. Hunting Hypothesis: - Investigate the signing certificate (issuer, subject, validity window, thumbprint) for disposable or recently issued CAs and cross-reference against known threat-actor certificates. - Examine the DLL's on-disk path relative to the loading process — paths outside standard system directories or inside application folders susceptible to search-order hijacking are high-priority leads. - Correlate with the parent process context; DLLs loaded into high-value targets such as lsass.exe, svchost.exe, or browser processes warrant immediate escalation. Note: The "selection_metadata_null" selection matches fields with a null value. Some backends may interpret null field conditions as "field does not exist" rather than "field has a null value", which would change the detection semantics. If your backend does not support or support null-value matching in different ways than expected, you may need to adjust the rule logic accordingly or remove the "selection_metadata_null" condition.

MITRE ATT&CK

execution

Detection Query

selection_signed:
  Signed: true
  SignatureStatus: Valid
selection_metadata_empty:
  Description:
    - "-"
    - ""
  Company:
    - "-"
    - ""
  Product:
    - "-"
    - ""
  OriginalFileName:
    - "-"
    - ""
  FileVersion:
    - "-"
    - ""
selection_metadata_null:
  Description: null
  Company: null
  Product: null
  OriginalFileName: null
  FileVersion: null
filter_main_legitimate_path:
  ImageLoaded|startswith:
    - C:\Windows\System32\
    - C:\Windows\SysWOW64\
    - C:\Program Files\
    - C:\Program Files (x86)\
filter_main_ms_signature:
  Signature|startswith: Microsoft
condition: selection_signed and 1 of selection_metadata_* and not 1 of filter_main_*

Author

Swachchhanda Shrawan Poudel (Nextron Systems)

Created

2026-05-21

Data Sources

windowsImage Load Events

Platforms

windows

Tags

attack.stealthattack.executionattack.t1574.001detection.threat-hunting
Raw Content
title: Signed DLL Loaded With Missing PE Version Metadata
id: 2a297820-04ce-41f2-b60d-5afe139aaab3
status: experimental
description: |
    Detects the loading of a digitally signed DLL whose PE version-info resource is entirely missing.
    Legitimate signed DLLs from reputable vendors often carry populated metadata fields (Description, Company, Product, OriginalFileName, FileVersion).
    An attacker who signs a purpose-built or hollowed DLL with a stolen, mis-issued, or cheaply purchased code-signing certificate will often omit these fields, producing a valid signature with no accompanying version info.
    This pattern is observed in DLL side-loading, search-order hijacking, and certificate-abuse campaigns where signing is used purely to satisfy security-product trust checks.

    Hunting Hypothesis:
        - Investigate the signing certificate (issuer, subject, validity window, thumbprint) for disposable or recently issued CAs and cross-reference against known threat-actor certificates.
        - Examine the DLL's on-disk path relative to the loading process — paths outside standard system directories or inside application folders susceptible to search-order hijacking are high-priority leads.
        - Correlate with the parent process context; DLLs loaded into high-value targets such as lsass.exe, svchost.exe, or browser processes warrant immediate escalation.

    Note:
        The "selection_metadata_null" selection matches fields with a null value.
        Some backends may interpret null field conditions as "field does not exist" rather than "field has a null value", which would change the detection semantics.
        If your backend does not support or support null-value matching in different ways than expected, you may need to adjust the rule logic accordingly or remove the "selection_metadata_null" condition.
references:
    - Internal Research
author: Swachchhanda Shrawan Poudel (Nextron Systems)
date: 2026-05-21
tags:
    - attack.stealth
    - attack.execution
    - attack.t1574.001
    - detection.threat-hunting
logsource:
    category: image_load
    product: windows
detection:
    selection_signed:
        Signed: true
        SignatureStatus: 'Valid'
    selection_metadata_empty:
        Description:
            - '-'
            - ''
        Company:
            - '-'
            - ''
        Product:
            - '-'
            - ''
        OriginalFileName:
            - '-'
            - ''
        FileVersion:
            - '-'
            - ''
    selection_metadata_null:
        Description: null
        Company: null
        Product: null
        OriginalFileName: null
        FileVersion: null
    filter_main_legitimate_path:
        ImageLoaded|startswith:
            - 'C:\Windows\System32\'
            - 'C:\Windows\SysWOW64\'
            - 'C:\Program Files\'
            - 'C:\Program Files (x86)\'
    filter_main_ms_signature:
        Signature|startswith: 'Microsoft'
    condition: selection_signed and 1 of selection_metadata_* and not 1 of filter_main_*
falsepositives:
    - Legitimate signed DLLs with incomplete or missing version metadata
level: low