Understanding and Mitigating Bashware and Similar Threats

Every component of an operating system adds new functionality, and at the same time, creates potential openings for new forms of malware. Recently, a potential risk was identified with the Microsoft Windows subsystem for Linux (WSL), which is now part of Microsoft Windows 10.

It should be noted that at the time of writing, this is just a potential exploit, and not one that we have seen used by malware, as of yet.

The potential security implications of this feature and how most security software cannot cope with it were discussed in detail by Alex Ionescu last year at Black Hat (Here is the video https://www.youtube.com/watch?v=_p3RtkwstNk).

The issue is that WSL runs an instance of Ubuntu Linux on a Windows PC seamlessly, such that a piece of malware can hide itself inside this Linux instance while running on the PC.
This creates a situation that would be very difficult for a traditional detection-based solution to handle.

The process would be as follows:

1. The user downloads and executes a file that has not previously been identified by the antivirus products installed and is, therefore, undetected by the antivirus software system.
2. The executing file enables the Windows Subsystem for Linux (WSL) and sets it up in a similar way to a Docker container, by running the bash.exe command. The bash.exe command has a number of parameters that can be added, so it also has the potential to execute file-less malware.
3. The malware executing file then installs a malicious payload inside the Linux instance and executes this payload.
4. Because the malware is running inside a Linux container inside Windows, antivirus products on the Windows environment do not see it.

At this point, it’s important to note that Comodo Internet Security and Comodo Advanced Endpoint Protection (AEP) would have stopped this form of attack.

At Step 1, because dropper.exe is not going to be detected, it will be treated as an unknown file and will be executed in a Comodo Container.

Step 2 will, therefore, not work because when dropper.exe tries to execute bash.exe, bash.exe will also run inside the Comodo container, which will block all of its COM-based communication with LxssManager. Bash.exe is, therefore, going to produce an error:

Comodo uses containment technology, which virtualizes the HDD, Registry and COM, which prevents files and file-less malware from performing malicious activity, even when the file has not been previously identified as malware. When a file that has an unknown security status tries to execute, it is contained in a virtual container, and when the bash.exe command tries to run, its access to the COM will be blocked. This will generate an error in the bash execution, and the terminal window will be encased in a green border, indicating its contained status.

Both file-based and file-less malware are stopped by Comodo’s solution. Comodo’s containers have a proprietary virtual COM/LPC subsystem to provide COM/LPC support for applications running. LxssManager’s COM interfaces are intentionally not enabled inside the container right now and will be enabled once the technology matures. See https://github.com/ionescu007/lxss/blob/master/WSL-BlueHat-Final.pdf for the current problems.

As a vendor, we have been using virtualization-based security for malware defense for over a decade, since 2009. And as the cost of using virtualization has dropped, the practicality of this model has increased.

The method described above is one of the many ways malware writers can bypass security software in a post-virtualization era.

Related Resources:

Best Antivirus Software