TCM Security delivers a precise and actionable deep dive into one of Windows' most revealing forensic artifacts. It is an essential resource for any investigator looking to turn routine system shortcuts into a comprehensive timeline of user activity.
Approfondir
Prérequis
- Pas de données disponibles.
Prochaines étapes
- Pas de données disponibles.
Approfondir
A Guide to LNK File ForensicsAjouté :
All right, today we're going to be looking at Windows LNK files and why they're useful piece of evidence when you're piecing together what a user was doing on a system. Now, we're not going to cover every little detail about the artifact because there are a ton of nuances, but this should be enough to get you started and understanding its relevance. So, LNK files are a Windows shell item. Now, shell items actually encompass a number of different artifacts that all kind of share a common underlying data structure. Um that shared structure is what we refer to as a shell item. One of the most popular and well-known shell items is the shortcut or the LNK file, which is what we're going to be focused on today.
So, an LNK file is a Windows shortcut.
Uh you'll hear, you know, it called different things like link files or LNK files or shortcut files, all kind of referring to the similar kind of data structure. Um and this format goes all the way back to Windows 95, and so it's uh been incrementally extended over the years, but it's well understood and well-supported by different parsing tools, which we'll look at later.
You likely already know the obvious side of LNK files, right? Those those little icons sitting on your desktop or entries in your start menu. Uh you know, apps that are pinned to your taskbar. Uh maybe you've gone in and created your own shortcut file before. Well, each of those examples is an LNK file pointing to the executable that actually launches.
What's less obvious is that Windows generates LNK files on its own, automatically all the time. Uh in most cases, when a user opens a document or, you know, interacts with an image or video, pretty much any file that goes through, uh you know, the standard explorer or the open dialogue, Windows quietly drops a corresponding LNK file into the user's recent folder.
Now, the user doesn't see it, right? It kind of happens in the background. So, so that things like the recent list in Office applications or uh you know, the recent items menu in Explorer, all of those things have something to populate from. That's really the general user experience purpose of LNK files. Uh they're kind of the plumbing behind features like the recent items list or uh things like jump lists, which maybe we'll talk about in a future video. Um and, you know, shortcuts that users rely on every day to get back to files and applications that they've used before.
All right, Windows leans on uh these kind of artifacts constantly to make navigation feel seamless. And that automatic behind-the-scenes kind of generation is what makes LNK files so valuable to us from a forensics perspective because they exhibit strong evidence that a file was accessed or interacted with in some way by a user.
And it's not just the file itself. Uh when a user opens a document, Windows will typically generate an LNK file for the parent folder of that document as well. So, you end up with evidence of both file access and the directory the user navigated to in order to get there, which is a really good for reconstructing user activity.
The really useful property is that, like with many file system artifacts, LNK files outlive their targets. And so, what I mean by that is if the target file that the LNK file is pointing to gets deleted, well, the link file is generally still going to be sitting there in the recent folder. Uh if the target was on a thumb drive that's been, you know, pocketed and walked off, the link file stays behind along with all of its shell item metadata.
Uh you know, if it was on a network share that the user no longer has access to, same deal. We can still glean a ton of user activity data long after the fact.
And the metadata stored inside is much richer than just a file name. Uh remember, these are shell items, so a parsed LNK file can give us things like the full path to the original target, uh that target's file timestamps, right?
The created, modified, accessed, all captured at the moment that the link file was generated. Uh we can get the size of the target file, uh the volume serial number of the drive that the file lived on, uh the volume label, the drive type, right? Is it a fixed disk or removable media or, you know, a network path, right? In fact, we can get the UNC path and the share name if it came from a remote location. Uh and in some cases, we have this idea of the distributed link tracker data block, which can include identifiers like the machine ID or, you know, values derived from network interfaces. Uh those these these aren't always present or always reliable, but they can be a fantastic set of additional metadata for us to parse through.
Now, as always, there are a handful of caveats to keep in mind with these artifacts. Uh the recent folder isn't unbounded, right? And so, uh what I mean by that is older entries get aged out as new ones come in. And so, a missing link file isn't always proof that nothing happened.
Uh historically, that limitation was capped at around 149 files in the recent directory, uh but in more recent versions of Windows, we've started to see well above that number, which is a great benefit to us.
Uh also remember, just like with prefetch files, users can clear the recent folder manually. And in, you know, some cleanup or anti-forensic utilities will target it specifically.
Uh and in those cases, we can turn to things like uh you know, carving for link file headers in unallocated space or turning to volume shadow copies. Uh both are worth a look for recovering historical artifacts. Uh it's also important to remember that shell items are generally a graphic user interface or a GUI feature, and they don't typically get created during command line activity. Uh we also occasionally see some odd edge cases around shortcut files, and so, as always, in your forensic methodology, treat them as one source of evidence among several rather than a single source of truth. Uh we're also now seeing that in later versions of Windows 10 and above, uh when a file is created, a link file will also be created in the recent folder as well.
And so, you know, if you use the save as feature in an application to create a new file, or in some cases, even downloading a file, a corresponding LNK file is created. So, keep that in mind when we think about date created timestamps as well.
Interestingly enough, link files can also be created through different means.
For example, um you know, opening a web page through the run dialogue box or uh even from the explorer window itself, which is something you can do as quick little trick. Um or from opening a URL in, say, Slack or Teams, you know, a different kind of application. Uh for example, if I type in the URL to my blog into the Windows run dialogue box here, well, it's going to open up in my default browser of choice. And when it did that, it created a link file uh with the name of that link file corresponding to the website that I accessed. So, very interesting there. We even sometimes get protocol-level information as well, sort of embedded into the file name of the LNK file, which is super interesting.
So, these LNK files can generally be found in two common locations. Uh the main location where we'll find the bulk of these automatically created LNK files is in the user's recent folder. All right, so for example, C: Users, then the username, we go under AppData, Roaming, Microsoft, Windows, and Recent. This is sort of that catch-all for the automatically generated LNK files uh that are sort of tied to user file access.
There's also an Office-specific equivalent that only kind of targets files interacted with using Office applications, and that can also be found under AppData, under Microsoft, Office, and Recent.
Now, in saying that, LNK files can technically be found all throughout the operating system. And so, typically, when we run a triage collection on a system, uh you know, we might want to glob or or kind of wildcard any LNK files or.lnk files that can be found for us to later analyze.
And if you're not seeing any LNK files when you navigate to these directories, um there could be a few reasons why. In In some cases, Windows likes to hide them from us, and so you'll sometimes have better luck opening up a command prompt and then listing out the directory that way. But that's only really going to be a problem if you're doing this live.
Uh the other thing is there's a chance that your system's not even recording this artifact at all. Um in which case, you can check by going to Settings, Personalization, and then under Start, if we scroll down, we'll see this setting, Show recommended files in Start, recent items in File Explorer, and items in jump list. And so, if that's toggled off, these link files are not going to be recorded.
Now, if we hop back into that Windows recent directory, uh we can almost do a quick triage pass, just kind of like we can with prefetch files as well, right?
Just pointing File Explorer at the folder and adding the date created and date modified columns, uh gets us somewhere immediately, right? Because we can rely on these source file system timestamps to give us some indication and some important details here.
Because with artifacts like these, we're often dealing with two distinct things.
We have the source, which is the forensic artifact itself, right? The LNK file.
We also have the target, which is the actual file that caused the artifact to be generated. And it's it's really easy to get these two confused, but just remember that source refers to the source of your forensic analysis. In other words, the artifact that you're actually examining.
And so, when we're thinking about the timestamps here, the date created timestamp of an LNK file reflects when that specific link file was first created, which often corresponds to the first time a file or target with that exact name has been interacted with. Uh but reuse and duplication behavior can vary, so again, we always need to be careful and double-check. Um we will sometimes see link files appended with a number uh in parentheses to highlight subsequent interactions, right?
Recording multiple link files uh for some folders, but it's not a guarantee, and you really never know what you're going to find until you take a look. Um because the update is generally in place, the LNK files on disk date created stays anchored to that very first open of any file with that name, while the body of the LNK file, right?
The actual content gets updated or rewritten uh to point to the most recent target or the new path or the new target MAC times, the new volume information, right? So, these things get updated as the user interacts with the target. And so by the same logic, the LNK's last modification time tracks the last time a file with that exact name was opened.
And so all that is to say, sorting by either timestamp gives us a very quick usable timeline that even before we run any kind of parser against these files or against this directory.
And on Windows 10 and above, you'll see here that we're actually seeing the file extension as part of the LNK file name, which is information that we could easily find as we start parsing these artifacts, but it's nice to be able to do so at a high level here even just in File Explorer or in our command prompt.
So to actually parse one of these out and pull all of that metadata and detail, we'll use Eric Zimmerman's Link Explorer command line utility or LECMD.
And it comes from the same family of tools as Prefetch Explorer, you know, PECMD and many others, for example, and so they all offer very similar syntax.
And so for a single file, if we want to target one, we can provide the F argument and point it to a specific {dot} LNK file itself.
All right, so if I call LECMD, point it to this budget plan Excel file here with the {dot} link extension, we're going to get an immediate output in our console, right? And this output is going to be grouped into a few logical sections. And so if we scroll up to the top, we're going to get information about the link file as it sits on our local system, right? We're going to see all these timestamps here for the source file, uh when it was created, modified, accessed. And if we open up the header here, we can see the target file timestamps, right? The created, modified, accessed for the actual file on disk. And if we look under the local path here, we can see exactly where that file was located.
And also under the header, we can see things like the file size. We can see different flags associated with it, the attributes, right? So a ton of information as we keep scrolling through this single parsed LNK file.
Right, we can see the volume information, the drive type, the volume serial number, the volume label. And this is where things get interesting in cross artifact analysis.
All right, if the drive type comes back as removable, for example, you know, we're looking at evidence of external media use. And that volume serial number can be matched up against things like artifacts in USB store in the registry, for example, or mounted devices and and different related registry keys to identify the specific device.
If the target lived on a remote share instead, we might see the network share details in place, right? The UNC path, the share name, the network provider type. All of these things can be useful for tracking activity across SMB shares.
At the bottom here, there's also this tracker block, which can include identifying information about the system that the LNK file was originally created on. Right, so we see this kind of NetBIOS style machine identifier. Uh we get a MAC address. Uh this can be particularly useful in trying to attribute or scope out an intrusion when we have malicious LNK files being used.
Cuz as a quick aside here, it's hard to talk about LNK files without talking about malicious LNK files.
Attackers have long abused shortcuts as a way of execution. And the very nature of how these files are shown to the user makes them easy to appear benign. And so there are many cases of malicious payloads being dropped as LNK or link files through email attachments or downloaded on the web as sort of these client-side attacks.
Now we can investigate malicious link files in the same way. And in fact, its metadata can be leveraged for our own threat intelligence, specifically when trying to attribute things like the machine ID, right, in these different tracker database blocks, or when we're looking at, you know, malicious command lines or payloads embedded inside of an LNK file.
For example, if I head over to a nice malware database here, I can do a search for any kind of LNK file extension as a submission. And when I do that, we're going to get a ton of different malware samples that use LNK or link files or shortcut files to their advantage. So let me try to find a good example here.
I'm sure any of these would be good, but I'm going to try to find one related to Cobalt Strike. Those are usually good examples to showcase. So I'm going to grab this one here, and then download it to my system so I can then parse it using LECMD. And I'll just rename this to something shorter like malware.
Rename the file here.
Interestingly enough, we take a look at the properties, we're already giving away some of the some of the magic here in the target.
But if you look, it looks like it's pointing to what is that?
An Excel icon, right? So that's the icon that it's using again to try to, you know, coerce a user into thinking this is benign. Right, so you can imagine if I rename this to something like malware.xlsx, it's still a shortcut file, right? So if I open that this up in the command prompt, just do a DIR here, it's actually a {dot} LNK file, but it appears even when I have the what is it?
If I go under show, file name extensions, even when I'm showing file name extensions, it is not showing me that it's a {dot} LNK file. I actually have to go under type here where it says shortcut, right? And so this is why, you know, from a client-side attack perspective, these can be pretty nasty. And so we can see malware.xlsx.lnk.
And so what I'm going to do is point LECMD over to this file here with the file argument. I just auto correct that there. And there we go, right? So we've parsed this file. And what do we have, right? Well, we have the source created, source modified, and accessed. We have, you know, the different header information.
Interestingly, it's hard to avoid it now, but if we look under arguments here, this is where the malware is actually embedded itself into, right? And so we can see what it's doing here. Well, we can sort of make out what it's doing. It's running some PowerShell, right? So it's calling the arguments here.
We can see it's opening up PowerShell in that Windows style hidden. We have a ton of like obfuscation and, you know, hidden kind of kind of ways to mask static analysis or mitigate static analysis. So it's using some of those different PowerShell encoding and obfuscation tricks. And so if we want to do, we could really go through and try to figure out what it's doing here. We see a reference to gamehook.exe.
Um And we can see a DAT file being referenced. You know, it's doing a ton of stuff, a ton of bad.
None of this looks particularly good to me. You see it's creating something in the temp directory. We're not going to do a full analysis of this payload, but I just wanted to show you how these things are actually delivered inside of malicious link files.
Now for real casework, we typically don't want to parse LNK files one at a time. And so just like with other Eric Zimmerman tools, the Link Explorer command line tool also handles directory level processing. And it's very easy, right? We can just point it at any folder we want using the D or the directory argument and ask for, say, a CSV output with the CSV flag.
All right, so I'll just point it over to my recent folder here and just output that as a CSV.
And it's going to walk through the entire directory and parse every LNK file it finds and produce a flat CSV for us with every field broken into its own individual columns. And we'll get things like the source and target timestamps, the local paths, volume data, network data, arguments, everything we might want into a nice CSV. And if we drop that into something like Timeline Explorer, well, we very quickly created ourselves a sortable and filterable view of file access across the user's entire profile.
So a few examples of what this could get us in practice. We could create a kind of most recent activity view by sorting by the target modified or source created. We could filter the local path on a specific extension or folder that we're interested in. And suddenly we get targeted answers, right? We want every {dot} x file interacted with or every file accessed out of the temp directory.
And the hunting opportunities here are limitless. We could filter on the network share fields, right? And so just a ton Anything we could think of here in these columns, we could start to chop up and filter by. Very powerful.
And so that's a good spot to wrap things up. Unfortunately, forensic artifacts on Windows can be complex, and we only have so much time to discuss them in these videos. And so I encourage you to continue your research, right? LNK files are easy to overlook because they're small and unassuming, but they give us file access evidence with rich metadata. They can survive the deletion of their targets, and they can tell us about the devices and shares involved in that activity.
Now there's plenty of more to dig into, you know, jump lists, the automatic and custom destination files that they're built on. Again, we could go deeper into malicious link triage. All good candidates for follow-up videos. But as always, if this was useful, be sure to hit like and subscribe, and I will catch you in the next one.
Vidéos Similaires
Agentforce NOW AMA: Build with React and Salesforce Multi-Framework
SalesforceDevs
490 views•2026-05-28
How agent o11y differs from traditional o11y — Phil Hetzel, Braintrust
aiDotEngineer
450 views•2026-05-28
WEB TECHNOLOGIES UNIT-2 | Degree 4th sem BCOM Computers web technologies unit-2 full explanation💯✅
LearnwithSahera
1K views•2026-05-29
More tests are always better? How to use AI to identify tests that bring little value
Alliance4Qualification
335 views•2026-05-29
Search Algorithms Explained in 60 Seconds! 🤖💨
samarthtuliofficial
218 views•2026-06-01
People of Game of Thrones using JavaScript DOM
AltCampus
296 views•2026-05-30
Introduction to Problem Solving Part - 1 | Lecture 1 | Intermediate DSA
ascensionix
107 views•2026-05-29
So What's Odin Lang Even Good For
TechOverTea
131 views•2026-06-01











