Moderator's introduction
One p.m., as I said, we're opening the second part of today's event.
[A break is cut from the recording (22.5 minutes). By this point the program had shifted: Vladislav Azersky's talk was scheduled for 12:15, and the moderator opens the second part of the day with the words “It is one o’clock…”.]
And Vladislav Azersky will open it. For a long time, Windows and Linux existed for the specialist as two worlds. But with the arrival of WSL, the boundary between them has become much more blurred. What all this changes for the DFIR specialist and how it works is exactly what our colleague will tell us. Let's give him a round of applause.
Vladislav, the floor is yours.
Talk
— Right, I hope you can hear me. Yes. Today we'll mainly talk about a component that appeared at a certain point in time, called Windows Subsystem for Linux. And I honestly wanted to talk about some kind of forensics here. Right, next. Ah, there, all good.
So let's talk about it. But I'll say right away that there won't be any bone-crushing digital forensics here, because, as it turned out, there are no forensic artifacts specifically related to this component. Very surprisingly, there are no ETW providers that would push events into the Windows Event Logs. And that's surprising. You start googling, not even googling, you download the extracted manifests, you search them for occurrences of Subsystem, Linux, and it's all empty. That's the first problem. Second: okay, are there any text logs, or anything else that might be generated.
Maybe it'll be sitting in some SQLite database, or somewhere else. No, empty. Of course, there are still certain traces left we can use to determine it. There are some mentions, again, in those same event logs, but they are more indirect. And in the registry.
As for the history of WSL's development, one thing to note right away is that there are two versions. The first appeared in 2016, the second in 2019. On the next slide I'll say more specifically how they differ. But for the end user the underlying principle doesn't really matter much. So, what do we actually need WSL for? If you still prefer working in a Linux environment, but at work you've got a Windows host, or you're a developer who mostly works on the Windows operating system, then this might be a solution for you, because you can easily set up a certain component in Windows, flip a few switches, so to speak, and then download a distribution, open it and work from the console without any problems, a proper Linux console.
As for the next turns, so to speak, not of development but of history, EasyWSL is already helping us, a kind of tool that's open, open source, free. It lets us take images that we can pull from Docker Hub, and convert them into a full-fledged WSL distribution. So now we at least get the ability to import something, and also export it. And in 2025 this happened: Microsoft decided to finally release the code of the kernel and everything else publicly. But there are a few points: some drivers and libraries there, again, are still proprietary, but the bulk of the code is present.
Now let's... Let's look at what WSL looks like and the fundamental difference. Maybe for a forensic examiner this won't be terribly important, and the same goes for some developer and everyone else, but it's good to know these subtleties so you understand later how, for example, an attacker or a user can interact with it.
WSL1 and WSL2: how they work and what changes for DFIR
In the first version there was simply a layer, a translation layer, which essentially implemented Linux system calls passing through the Windows kernel. And the second version, that's the one we'll discuss. We can see a big picture here on the right. And basically, in principle, this is what it all looks like. A Linux virtual machine is spun up, and inside it we have each distribution, because we can create several of them. For example, we want Kali Linux and Ubuntu on our Windows system. Consequently, we'll have two of these dotted boxes inside that virtual machine. And so we can already interact with them somehow.
In the end we get this: there's a host box running Windows. At startup, the WSL Service starts inside it, the Linux VM. And inside that, when we want to open some distribution and work in it, naturally, a WSL distribution gets created. And as for the specifics of working with WSL, there's a lot of important stuff, because in some attacks and cases, of which, honestly, there were quite few, but mostly, if you look at what's in the news field, you could find something. About the specifics. Let's start. First. We can run Windows executables from inside WSL. For example, we simply go into some distribution, get a bash shell and can run things, either by specifying the full path, or by just typing, say, notepad.exe, and it will launch.
Great. And here it's worth noting, for example for a SOC specialist, that in this case the parent process will be wsl.exe, which in turn launches notepad.exe. Next, there's the fact that every distribution has the Windows file system mounted, that is, the host's. And we can easily, as a two-way thing, both copy and save certain files. We'll take a quick look at that a bit later too. Again, for analysts there's an important point, if, again, they have telemetry, that all the file operations we perform from WSL, for example, we downloaded some file and want to drop it into the Windows file system, will be handled by the system process dllhost.
Why do I emphasize this? Sometimes it happens that in some EDR solutions there are simply no detection rules for this behavior. And for the most part this second paragraph applies more to WSL 2. The first one has a similar mechanism too, but it works a bit differently. And the last one is network isolation. Essentially, WSL 2 is fully isolated, that is, its network stack. And in this case what can that lead to? If our Windows host system has something like Sysmon installed, which collects telemetry on network connections, or an EDR, then later we won't see anything, because all of it will be happening inside the virtual machine that hosts our Linux distribution.
That's why attackers in some cases took advantage of exactly this. Next, let's walk through what all this actually looks like. For example, we can run commands in a distribution, specifying it from Windows OS. Here we just use the native tool wsl.exe. For example, we do a listing to see how many distributions we have. And then we specify a particular one of them. Next, the root user and exec. As you've noticed, there's no situation here where a password is prompted, or we even pass one here. This means that in the course of working with the WSL tool, it turns out that into every Linux distribution installed on the system we can easily log in as root.
That's a particular quirk of how it works. Consequently, even if we've locked down root somewhere, so nobody could do anything, from Windows we can easily pull it off anyway. And the second point I mentioned, the peculiarity, is that once we're inside a distribution, in WSL, we can launch, say, calc.exe by specifying its absolute path, and it pops up right here. All of this works by default. This exact mechanism, where some Windows executable gets launched from a Linux distribution. Here we can see how to disable it. We simply write into each distribution, it has a config file, /etc/wsl.conf.
For example, these two lines. Then nothing like that will happen anymore. Second point. As you noticed, in the second column we had the fact that we can copy files back and forth. And what does that look like here? If we want to copy from Windows into some WSL distribution, we go to the UNC path \wsl$ and then specify the name of the distribution itself. And then we get the files and directories that are valid for the Linux OS. And the second point. We're inside the Linux distro and we want to copy some files to the host box. Here everything is already mounted. It lives in the /mnt directory.
We go into, say, a folder and can copy right away. Here at least a simple listing has been done. Okay, so why did I talk about these peculiarities? Because these peculiarities are already being used in some cases that you can see publicly. But before that I want to say that even when you're gathering some information to understand which groups did what, when they did it, and whether they even did it at all, you still need to double-check the info, because several sources mentioned that a number of groups, such as Turla, FIN7, Ryuk, used WSL. This was in two or three sources, and it was very strange, because there were no other mentions anywhere.
It turned out to be just some kind of neural slop, where the person didn't actually check what was written, so this here is more up-to-date info.
Cases: Qilin and npm typosquatting
The first mention was actually around 2017, but more or less one of the companies wrote up that we found an ELF file that interacted with WSL. There are no specifics, none at all. They just found some particular sample, analyzed it, said we found it, and everything else, goodbye. The second one, essentially, is some affiliates of the Qilin group. Early February 2026, the attackers gain access to the infrastructure in the standard way through some RDP, or there's already some RAT there. Next. I don't know why, but they decided to pull this off. They either activate or deploy WSL. But for this we actually need to already have full control over the machine.
If we're talking about the situation where WSL isn't there. What do they do next? They load the ransomware in ELF format and run it in the WSL environment. And what happens? Since the Windows file system is mounted for us, all the user files will be affected, because this ELF file will go through the files already located on NTFS. And what do we end up with? Encrypted files on the host Windows OS. And the last recent story. There was a certain campaign that the attackers pulled off. It was in August. What's the specifics? It's npm typosquatting. They created around 40, or even 50, npm packages with similar names. That is, the difference could be that they swapped two adjacent characters, or, for example, replaced an l with a one.
And after such a package was delivered to the system, a script was run there. What did this script do? It first checked whether the system, that is, whether the user is running under Linux. If they're running under Linux, then it checked the next thing. Whether in this case they are running specifically within a WSL distribution. For this it checked two environment variables, because they're always there by default. And what happened next? The ransomware was downloaded, copied from WSL to the Windows file system, and launched. Oops, not even ransomware, but a stealer. And it stole credential data. These are basically the cases that you can at least find.
Attack vector. Let's move on, we narrow it a bit, that is, we even generalize. What do we end up with? We have two options for the attack vector. The first is when the attackers gained access to the WSL distribution via a malicious script or package, like the third of the news items presented that were published. And the Windows side, when the attacker gained access to the host machine. This can be in a corporate infrastructure. A person decided to connect, raised their privileges and started working. And here two scenarios matter. First, WSL isn't installed for us, therefore you'll need to get full control over the system. That means we need admin rights.
If they're not there, we won't install WSL, because you need to enable exactly these two components, one related to WSL and one to the Hyper-V system, that is, to virtualization. If it's installed, we can then download some distribution and work with it further.
Persistence, delivering a distro, and detection
Let's look at persistence. We have, again, in each distribution a file /etc/wsl.conf, there's a boot section, there's a variable, say, the word command, a key. Here we can specify a command that will be run at the launch of the distribution itself. Here we actually just have a reverse shell, which gives the attacker the victim's shell. And here we'll go with the scenario that will most likely be more applicable. That WSL is installed on the system, they connected to the host and then carried out this whole thing. So they did a listing, then specified a certain distribution and then did the next thing. They wrote a command in the /etc/wsl.conf file.
The second point, very specific, which mostly won't work, is persistence via a WSL plugin. There is such a possibility, but here we need a digital signature. And most likely issued by some trusted authority, because otherwise for a test one we'll have to disable a certain mechanism where Windows doesn't trust self-signed digital signatures. Great. Let's say attackers can sometimes steal them from some company, and they signed it. Next, what do they need to do? To sign the DLL itself that has some payload, for example, download some beacon and run it, and then register it at a certain registry path.
And here we just specify the path where all this will be. And here there are two ways it works. We can restart WSL, or shut down the computer. Essentially, at system startup, or when the service restarts, the payload located in the DLL will be launched. And one more very important point. Let's talk about the fact that these distros have to be sourced from somewhere. We can, for example, deliver them.
There's a project on GitHub that, essentially, lets you create a custom WSL distribution and add a payload to it. In this case a calculator was used. The person, the developer of this script, wrote the code, and basically here's how it looks. We specify there the name our distribution will have, and -p calc.exe is which executable file will be launched at startup, exactly, when you enter the distribution itself.
Next, this calc.wsl file is created for us. We deliver it to the host, specify this command. It calmly shows up here in the listing. And we launch it. On launch, wsl -d calc, the calculator launches in WSL for us. It's built, most likely, on a fairly lightweight Alpine Linux image. And there it will be somewhere around 10 megabytes. How does this look if we need to check for their presence? First, in the registry, at a certain path, it may be hard to see here, we have information, how many distributions we have installed. Here there's a path, here there's a name, here there's, and also additionally, if needed, what the name of the virtual disk of this Linux distro that appears for us is.
And then we go by certain indirect logs that we can somehow dig out. There are two journals, I won't talk about them in detail, because what matters to us here is exactly the entries we see here. First, where our virtual disk is located. Most often, by default, when creating a new distribution it'll be called ext4.vhdx. Consequently, we can somehow think it through and in one case set up rules with a SOC, in the other search.
Even simpler. We can, say, skip those odd things the attacker does, or some user who wanted to deliver it this way in the previous case. We, for example, put together some small 10-megabyte distro and made an archive out of it. And what can we do? We can simply deliver that archive, import it and specify the path where our ext4.vhdx virtual disk will live, and then it starts up just fine. Another example. Okay, we don't want to deliver anything from our own server. We can use the winget utility, which will grab something from the Microsoft Store, for example, a Kali Linux image again, or from the public open winget repository.
Here, for example, the attacker runs winget search kali, finds the distros, and then depending on the choice it will be downloaded either from the winget repository or from the Microsoft Store. And here we have to keep in mind that if the attacker uses the winget utility, then in this directory, under this file pattern, we'll find a lot of useful stuff. The command that was run will be recorded. So in those cases we'll see that winget search kali is present, whether it succeeded or failed. And the last one, that an installation was performed.
I'd also like to mention, though I won't go into it in much depth, that the SpecterOps folks did some pretty good research where they showed they can launch processes directly in the Linux container without using the WSL utility, as we saw earlier. A specific COM interface is used for that. If you're interested, you can read it, it's all laid out in a lot of detail there. They got to this after the WSL source code was published.
OK, so we've gone through what WSL is and what its specifics are, but what about digital forensics, really? Well, as we can see, not much gets generated, there are really only some indirect links, so we come back to the standard. Since our host system is Windows, this is Windows forensics. And then, if we're working with distros, we look at what we can find, what forensic artifacts, or logs there are in the Linux distro itself. And here we can build a sort of pipeline of actions. First, we go through the base artifacts and logs of Windows, which let us establish whether WSL is installed, whether it's in use, that is, whether the components are on and there are already some distros.
That's without context, just to find that out. Then we move on to the digital forensics of the Linux OS. If we noticed we have some distros, that they appeared at some odd moment, that they aren't used by a developer or some user, then what do we do? We either do a triage, or copy that ext4.vhdx image and then analyze it. Within DFIR, I would proceed specifically as an incident responder, from the position of forming a hypothesis based on current attacker TTPs, because most often we're dealing with some external threat, which often operates by its own particular standard. And then I would switch to analyzing the forensic artifacts and logs of the Linux OS.
If you're interested in reading some other research, and generally getting this presentation, head to this Telegram channel, everything will be there, most likely either today or tomorrow. Thank you. I'll take your questions now.
Q&A
— Raise your hand, colleagues. Any questions?
Yes, I see you, I see you, coming, coming, coming. That's great, because I thought there'd be no questions again.
— Vladislav, good afternoon. Very good talk. And my colleague and I are actually thinking about a question right now: what if, for example, you set up auditing on this Linux subsystem and output the logs through a path mounted on the Windows system? Is that an option for monitoring activity in there? Yes, it's possible, and most likely that's one of the options, because I didn't mention it here, but during my research I found there are these plugin systems, we can somehow use them, and I noticed: oh, there's a Windows Defender plugin, I can install it and something happens. I'm looking at it thinking, OK, I hope it's not purely tied to their MDE, and it'll at least save some logs to files.
Turned out it doesn't. But potentially you could indeed look at WSL plugins, but there's a big problem here. You'll most likely have to disable Secure Boot and grant Windows trust so that a self-signed certificate works. In part, this functionality they introduced could work very well, because it would run inside that Linux VM, and you could simply collect right away from the various distros that get spun up in there, some kind of logs.
Otherwise, yes, most likely in this story you either just restrict users from using WSL, monitor the enabling of the components, because, again, only a limited number of people will use it, hardly some accountant or lawyer. But if you collect from there, you'll have to, inside the distro itself, set up some tool for monitoring and data collection, so that later, as a good option, you copy it to the host machine and pull it from there. Well, it seems that's really the only viable option so far. Thank you.
— Colleagues.
— Thanks for the talk. Here's my question. Don't modern EDRs look inside Hyper-V containers? WSL mostly runs on Hyper-V, right? Yes. Honestly, I don't have that kind of analytics or statistics. But I've seen somewhere that at least various international vendors are introducing that functionality. As for the Russian market now, I don't know, but maybe some have already at least done something basic to look inside, or are on their way. Because after all, if you pay attention, it's 2026, and the main cases appeared right here. Apparently there is some need after all to dig deeper into this Linux VM.
And essentially those same plugins, again, if they could be installed properly, could at least be some kind of solution.
— Well, the mere fact of Hyper-V starting up is effectively a signal too, because... It will be a signal, 100%, but again, you have to take into account the context, and, again, I'm not in favor of using WSL there, it will be used by a small number of people, so most likely you just target those users who genuinely need this tool. Can you encrypt that virtual disk using WSL itself? I mean, roughly speaking, Kali runs on an already encrypted disk, and when the forensic examiner comes, accordingly, he can't do anything without some key, and the key, accordingly, is fetched over DNS or something like that.
Potentially you can do that, but attackers are unlikely to, because most often they need, without any potential errors, to do something further, because what comes next? You come into the chat to talk with them, and they go: OK, great, send us some files to check. And then it turns out that if they can't be recovered, or something else, that's it, that's already a big problem. They won't get their potential money.
— All right, okay, thanks. Colleagues, any more questions? I don't see a single hand. Vladislav, thank you very much. As always, thorough.