5 Best antivirus Solutions for Linux Malware in 2019

By estimate, it can be easily said that more than 50% of web servers around the world are running on Linux. In most of the organizations for daily office works the Linux is the only choice, even if not, then also to process the sensitive and secure data Linux OS is implemented around the world in most of the organizations.

While Linux is known to be more secure than Windows and OSX, it also has another goodwill of being an invulnerable OS for any kind of virus or malware attacks. Now think where more than 50% of the web servers are running with Linux, where the hackers will definitely try to breach many of those servers for their greedy needs and to do that, they must have tried with many methods including the development of computer viruses and malware to breach Linux securities. Yes, it is true that even Linux has a good amount of potential threat from Computer Viruses and Malware.

If you still think that Linux is immune to any malware attacks, check your fact over the internet. Though even in 2019 it is quite hard to breach into a Linux system due to the lack of root access of the system for any malware, there are many other potential problems which can be created by the malware.

Especially if you are also running a PC or a server with Linux then you are a serious computer user as newbie users are prone to use MS Windows most of the time. While being a serious user it is your duty to keep an eye on the security of your data and the system. Most of the malware available for Linux are not able to breach and take out raw data out of your Linux system, but still, they are capable of executing such commands which will make your system fail down, even your HDD can become corrupted.

So, go through this article in full as we are about to discuss this matter in brief but in clear points to protect various Linux OSes such as Ubuntu, Fedora, Linux Mint, Centos and more. Most importantly we are about to discuss the solution of this problem, like which tools to use, which measures to take to ensure safety.

Can Windows malware harm a Linux computer when it’s executed with Wine?

I am an (Ubuntu) Linux user. Sometimes, I have to use Wine for running Windows executables.

I would like to know if Windows malware (virus, trojan, worm. ), i.e. malware that was not intended to do harm when being executed with Wine on Linux, can do harm to my Linux system. I use a standard Wine installation. Wine is never executed as a superuser.

I guess it could read/write/delete files from my folder, and connect with the Internet.

I think, but I’m not quite sure, that it can’t install software. Could it install harmful (Firefox) plugins?

3 Answers 3

You are right about accessing the file system and internet, especially because the home folder is mapped with write permission by default. This implies that it can mess with your documents as well, for example adding macros to Open Office documents, deleting your mp3 files or sending interesting files to someone on the internet.

And yes, it can write to your Firefox profile and install an Addon.

Connecting to the internet means, that it can fetch commands from a C&C server to turn your computer into a drone.

I guess some maleware will fail to find those locations outside the standard windows folders. But other will just scan all drives for interesting places.

Firstly, a bit of background on Wine. Wine provides an executable loader for running Windows executables. Also installed or made use of optionally is a binfmt handler described here, which is how the linux kernel deduces what loader to execute — for example, somewhere built into the kernel is a binfmt handler for ELF files for Linux. Function calls from these executables are then translated by the Wine runtime into their equivalent Linux system calls. The Wine FAQ deals with the question of wine being an emulator.

So, back to your question — could Windows malware infect a Linux box? I said theoretically yes — here are the various threats you face:

• Bugs in the format handlers. If a specially crafted executable causes Wine to incorrectly load the PE file, you might well be able to exploit it.
• Bugs in Wine’s function translation. This is the same as saying «bugs in the Windows API», if you like — if certain functions translated in Wine are susceptible to buffer overflows etc, then they can be exploited.
• The fact that function calls are translated. This very fact in itself means malicious activity can happen.
• The setup and limitations of the Wine install. What file systems have you mapped? Can the executable escape this «chroot»?

There is one key proviso here — being aware or planning for infecting Wine. If malware is written with the expectation that it may be run on Wine, then it can begin to use Wine specific exploits, possibly detecting that Z: is mapped to / and performing appropriate actions. The earlier points in my list above are the least likely, but also the most damaging if they occur.

However, most malware is not written for Wine. You can think of Wine as a separate build target, almost, since how it implements the Windows API is different to how Windows implements the API. Most malware is aimed squarely at Windows, so I’d expect the damage to occur only to the «Windows» install. Indeed some malware may not run, where the Wine developers have assumed strict usage of an API function and where Windows allows something different.

So, to cut a long story short, Wine increases your attack surface by a sizeable amount by allowing you to execute arbitrary Windows programs. The same general rules apply to Wine as apply to any piece of software:

• Do you need it? If not, don’t install it.
• Is it up to date? If not, update it.
• Be careful what you run with it. It is not a substitute for being careful with what you download, access and run.

Executing Windows malware in Windows Subsystem for Linux (Bashware)

A blogpost that shows a practical approach to setting up malware to run on Windows using the Linux subsystem and wine to avoid detection.

Origin Story

I did a talk recently at the Bangalore null/OWASP meetup where I spoke about and demoed the concept of the research done by Check Point Security folks, called Bashware.

Bashware (bash+(mal)ware) is the idea of running Windows binaries (malware) in the Windows Subsystem for Linux (WSL) using wine support. This allows for some programs (not all Windows PE executables though) to be run inside WSL while being shielded from system inspection tools like Antivirus solutions, process monitor etc.

While setting up the demo for this talk, I realised that the speed of execution that is shown in the video released by Check Point Security was very likely not possible as it took me couple of hours of setup and downloading/installing of components required to make this run from scratch. In the video, a binary called malware.exe is run and within a minute the binary does the following

1. Enables WSL
2. Enables Developer Mode
3. Installs WSL
4. Installs wine
5. Executes nc.exe -lvp 1337 via wine

In my opinion, the malware.exe simply runs the last command while everything else is already setup on the system. Let’s go ahead and build a PoC and see what we happens.

Let’s build a PoC!

In any case, if you want to try setting this up, here are the commands that worked for me. This is 5 step process at the very least. You will need to be on a Windows 10 64 bit Edition machine with Windows 10 version higher than the Anniversary Update (version 1607).

Step 1: Enable WSL

The Windows Subsystem for Linux can be enabled either by using the dism binary using an elevated command prompt or using Powershell’s Enable-WindowsOptionalFeature module as shown below. A reboot is required after this step

Step 2: Enable Developer mode (Optional)

Developer Mode in Windows 10 allows developers to install and test unsigned applications and was required to install WSL, but post 16215, you no longer have to enable Developer Mode to install WSL. I ran into some installation issues though which did not recur once I had enabled Developer Mode, so including this step here.

To enable Developer Mode, go to Settings -> Update & Security -> For Developers and click on the Developer mode radio button and click Yes on the message box that is shown

To script this or to do this via a command prompt, we can use the reg command to add registry values directly. The following command sets the required values in the Windows registry (requires elevation).

Step 3: Install WSL and Linux components

This can be done via the Turn Windows features on or off applet as shown below

or using the command prompt with the lxrun command

Step 4: Install wine inside WSL

Wine (originally an acronym for “Wine Is Not an Emulator”) is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.

Basically, Wine allows you to run Windows programs on Linux by translating Windows API calls to Linux (POSIX) equivalent API calls. Not all Windows programs can be run using Wine though, however there are a large number of programs that do work.

Anyways, Wine is required to run the Windows binary (malware) to complete this PoC for bashware. You can do this using a bash terminal in WSL. Open cmd and type bash and press enter to launch the WSL environment. In bash, type the following commands to enable 32 bit architecture support, add the Wine PPA, download and update the package lists from the repositories and finally install wine.

Step 5: Download and run netcat 64 bit using wine

This was the trickiest of all the steps. The original research article on the Check Point Security website does not mention the binary type that will be eventually executed, although there are hints throughout the article.

Looking at the video and pausing at 0:12 seconds I realized that the netcat binary used in the video was the original Hobbit version compiled by someone into its 64 bit equivalent on 26th December 2010. Using a little bit of Google search I found the exact binary that was used in the video, which I subsequently used in the demo as well.

So go ahead and grab a copy of netcat 1.11 from https://eternallybored.org/misc/netcat/

(You can compare the Date Modified of the files in the video and this download and chuckle along :D)

Finally, to run the netcat and complete the PoC, cd to the directory where you unzipped the download and run the following command (all in bash, obviously). You may very likely see multiple preloader: Warning: failed to reserve range 00007ffffe000000-00007fffffff0000 . You can ignore these warnings and proceed.

This will run the netcat binary inside WSL using wine. The netcat parameters in this command cause it to verbosely listen on port 1337 and execute and send STDIN, STDOUT and STDERR of cmd.exe back to the connecting client.

You can verify if the port is open using netstat or TCPView

From a different machine or another command prompt window on the same computer connect to the open port using another copy of netcat (I used the nmap version) as such:

Is this really stealthy?

Once the connection was established, I wanted to see if this can be detected by some common Windows system inspection tools. I used TCPView, Process Explorer and Process Monitor. The results were interesting as expected.

Using TcpView

TCPView provides a graphical UI to view all network connections, the teardowns and new connections being made along with the process information of the PID that created the connection.

In this case, TCPView was able to list the open port, attributing it to wineserver, but was unable to get more information.

Using Process Explorer

Process Explorer was able to detect the wine64-preloader and the wineserver, but beyond that very little information was available.

The process memory and network listening status was all that was available in Process Explorer. The error message shown in place of the path is shown when (amongst other things) the handle of a privileged process, opened with PROCESS_QUERY_LIMITED_INFORMATION, is used to call QueryFullProcessImageName

Using Process Monitor

I had better luck with Process Monitor in looking at the process and the execution path. I would highly recommend trying this out on your own setup as the number of entries is just too many to go into details.

The wine64 binary path (on the Windows Filesystem) was detected as well as several CreateFile , ReadFile and CloseFile references to nc64.exe by a process that had no name or path (!?). The LXCORE.SYS driver was also visible in the stack of the process with various API calls to execute and manage the wine64 invocation of nc64.exe .

Final Thoughts

In my opinion, the video and research published by the folks at Check Point Security had some glaring and obvious holes in it. But given the overall simplicity of execution and the absence of proper tools to inspect and analyze Windows binaries running through Wine through WSL (whew!), this can become very tricky very fast.

To be fair, it really is a lengthy process, requiring privileged execution, multiple reboots and Internet access. No wonder Microsoft downplayed the whole thing as is. However, it cannot be denied that this is a cool technique at camouflaging execution.

As is always with any untrusted sources, practice caution when opening email attachments or executing downloaded content.