The Rise of LNK Files (T1547.009) and Ways To Detect Them
In what follows, I will first provide a brief introduction to why and how macros were blocked as well as how to bypass the protections that were put in place. I will then give an overview of LNK files, one common alternative to macros, show how they are used in the wild, and finally discuss various ways for detection.
Microsoft's decision to block macros
In October 2021, Microsoft announced to disable Excel 4.0 macros (also known as XLM or XL4 macros), one of the most abused Office features, introduced in 1992. Despite the release of Excel 5.0 that introduced VBA-based macros, they are still supported inside the Office Excel software to this day. In February 2022, Microsoft then also announced to block by default the execution of VBA macros inside five Office applications (i.e., Access, Excel, PowerPoint, Visio, and Word). Some confusion came up when Microsoft rolled back their decision in July based on "feedback" but then resumed the roll out shortly after.
How are macro's blocked?
VBA macros are blocked based on a so-called Mark-of-the-Web (MOTW), which indicates whether a file was downloaded from the web. Practically speaking, if a file is downloaded from the web, most software on Windows handling attachments or downloaded files (e.g., Internet Explorer, Edge, FireFox) generate an alternative data stream (ADS) called Zone.Identifier and populate this stream with a ZoneID in order to show which zone the file originates. This information is then used by various programmes such as MS Office to activate security features like Windows Defender SmartScreen, MS Office Protected View, or Blocked View, among others. For more details and the exact evaluation flow, check out Figure 1.
Bypassing MOTW protections
While Microsoft’s decision to block macros poses a challenge to threat actors, there are ways to bypass MOTW-based protections (T1553.005):
Option 1: For example, provided a suboptimal group policy, someone may (possibly through social engineering) manually alter the macro’s security properties (i.e., right-click on a file > select Properties > tick Unblock under Security > click on Apply).
Option 2: Another option is to deliver macro-enabled documents within container files (e.g., .iso). While the container file itself will have a MOTW, it will not propagate to the file within the container (e.g., Macro-enabled Excel). After extracting the file from the container file, the macro still needs to be enabled in order to execute the malicious code, but it will not be recognised as originating from the web and thus not trigger specific security features. It is important to keep in mind that ISO and IMG files can be prevented from automatically being mounted when the user double-clicks.
Option 3: Threat actors may also drop macros completely and deliver payloads directly within container files (through attachments or download links within an email). One example are LNK files (also Shell Link files), which have recently seen a significant increase in malicious use. At the same time, there are still not as well understood as they should. So how do they work, and most importantly, how to detect their malicious use?
How do LNK files work?
LNK files are Windows shortcuts that point to and are utilized to open other files, folders, or applications. For example, they may be placed on the desktop (manually or by software installers) to enable users to quickly access or start files instead of having to navigate somewhere else.
Technically, LNK files are best understood in the context of the Windows Shell: The Windows Shell (essentially the GUI of the Windows operating system) manages and provides access to the objects that make up the system. The Shell implements a namespace that structures the file system and other objects (e.g., networked systems) managed by the Shell into a single tree-structured hierarchy (with Desktop object at the top) and enables programs running to access the resources of the computer.
When a shortcut is created to another object (known as shortcut target) (e.g., through manually creating it), the Windows Shell establishes two things: a so-called Shell Link object and an LNK file with the latter containing all information that is necessary for Windows to open or execute the shortcut target (i.e., absolute and relative filesystem paths, path to the shortcut icon, and additional parameters). For a more in-depth analysis of the LNK file’s data structure, check out Syed Hasan’s write-up.
LNK files in the wild
Shortcuts are abused to achieve various goals. In most cases, they are used for persistence and initial access, among others. In what follows some example techniques to achieve these goals are described.
Persistence
- Activation or trigger keys: LNK files can be placed on the user’s desktop and be activated through a (common) key sequence (e.g., Control+C). This works because shortcuts can be registered with a shortcut key, which will cause the shortcut to execute when the specified key sequence is invocated. Execution and thus persistence depends on the user utilizing the key sequence.
- Credential harvesting: Default Windows functionality allows LNK file icons to be loaded from a local or remote Windows repository, defined in the LNK file format’s string value “icon location”. Attackers (e.g., DragonFly) may exploit this by setting the icon path to a remote, attacker-controlled server. When the user navigates to the directory that contains the LNK file, Windows automatically tries to load the icon (if the HasIconLocation flag is set) and initiates an SMB authentication session. During this authentication process, the credentials of the active user are passed through the attempted SMB connection allowing the attacker to collect password hashes (which may be helpful for attackers even in cases where they have been ejected). Check out this write up for more details.
- Startup folder and Registry keys: Attackers can achieve persistence by writing shortcuts (e.g., to itself) to the Windows Startup folder or by referencing them with a Registry key. Adding an entry to the startup folder or to the “run keys” in the Registry will cause the program referenced to be executed when a user logs in. There is a startup folder location for individual user accounts as well as a system-wide startup folder that will be checked regardless of which user account logs in. Attackers may edit existing or create their own shortcuts.
- "Social engineering": LNK files tend to be delivered through attachments or download links within emails broadly summarized under T1204. They are often embedded in container files (e.g., password-protected .zip). This is because LNK files themselves are often blocked as attachments (see Microsoft Outlook). Victims are lured into executing the LNK files, which execute additional payloads and often open decoy documents (e.g., PowerDuke, Konni) to make victims believe the file is authentic.
- Exploitation: While LNK files usually require victims to click on the file to execute the payload, a vulnerability in the Windows Shell (CVE-2010-2568) allowed attackers to execute arbitrary code embedded in LNK files without user interaction (i.e., “zero click”) (e.g., enabling worm-like distribution in Sality or Stuxnet). In other words, malware exploiting this vulnerability were capable of infecting Windows 7 systems if a user viewed the contents of an infected USB drive (or SMB file share) using a common file explorer.
How to detect them?
LNK files are generally used for benign purposes and created all the time (e.g., by Windows when users access a file from a supported application), which complicates detection. However, there are various layers in which malicious LNK files can be detected:
Layer 1: Detection before delivery
When delivered as email attachments, LNK files are usually blocked based on their file extension (e.g., Microsoft 365, Gmail). Therefore, LNK files are often delivered within container files, which are usually allowed but scanned. While attackers put efforts into making detection through scanning more difficult by pretending to be as legitimate as possible (e.g., by increasing container size by adding hidden folders), adding more layers of compression (e.g., .zip in .zip), or by protecting them with a password. Scanners have followed suit by improving heuristic scanning for both known (signature match) and unknown (suspicious) files, implementing recursive scanning, or possibly extracting passwords contained in the email body to open password-protected containers.
Layer 2: Pattern-based detection
While detecting malicious LNK files before delivery is ideal, endpoint detections also need to be in place. Pattern-based detection is one approach and can be roughly split into generic and specific detections:
Generic (i.e., campaign or attacker agnostic, relatively broad, and stable) detections include generic Yara rules that detect LNK files that run double extraction and launch routines with autoruns or contain suspicious content, among others. They may also help to detect suspicious LinkFlags or “whitespace”/”paddings” commonly used by attackers to hide the malicious part of the command from visual inspection. Sifting through large amounts of past malicious LNK files can be extremely insightful, for example, by revealing file naming trends, file extension spoofing, string obfuscation or the use of special characters, among others.
Specific (i.e., campaign or attacker specific) detections are particularly useful when trying to find other samples by the same actors (e.g., for threat hunting) or when dealing with questions around attribution (e.g., APT29). Such rules make use of metadata from the LNK file’s TrackerDataBlock and PropertyStoreDataBlock structures, containing the NetBIOS name, MAC address, volume serial number, or SID. It is important to keep in mind that this information depends on where the LNK file is created: If the LNK file was created on the victim system, commonly seen as a stealthy approach, the metadata will be victim-specific and barely helpful to find other samples. However, if LNK files are delivered to the victim system, they have been described as “free money” by Harlan Carvey due to all the attacker information they may reveal.
Layer 3: Behavioural detection
Shortcomings of signature-based detections are obvious: they are reactive in nature and unable to detect unknown attacks for which there are no signatures. Signature also constantly changes. Behavioural detections in turn focus on malicious or unusual patterns of behaviour, and are often based on statistical correlations. This blog is not going into the details of how behavioural detections are implemented, but in essence they evaluate an object based on its intended actions before it can actually execute that behaviour (e.g., attempts to discover a sandbox).
Conclusion
As it has become more challenging to exploit macros, this blog post provides an overview of LNK files, one common alternative, shows how they are used by attackers, and discusses different levels on which they can be detected. One core challenge is that LNK files are mostly used for benign purposes, making it hard to separate the wheat from the chaff. Once detections are in place, one should not leave it at that, but also take further measures such as performing proactive threat hunting, ensuring defense in depth, increasing awareness, and monitoring tool development (e.g., LNK builders), which might leave traces such as ”toolmarks” behind useful for detection.
.png)
