Security researchers have discovered malicious Linux binaries created for the Windows Subsystem for Linux (WSL), indicating that hackers are trying out new methods to compromise Windows machines.
The finding underlines that threat actors are exploring new methods of attack and are focusing their attention on WSL to evade detection.
Using WSL to avoid detection
The first samples targeting the WSL environment were discovered in early May and continued to appear every two to three weeks until August 22. They act as loaders for the WSL environment and enjoy very low detection on public file scanning services.
In a report today, security researchers at Lumen’s Black Lotus Labs say that the malicious files either have the payload embedded or fetch it from a remote server.
The next step is to inject the malware into a running process using Windows API calls, a technique that is neither new nor sophisticated.
From the small number of samples identified, only one came with a publicly routable IP address, hinting that threat actors are testing the use of WSL to install malware on Windows.
The malicious files rely mainly on Python 3 for carrying out their tasks and are packaged as an ELF executable for Debian using PyInstaller.
“As the negligible detection rate on VirusTotal suggests, most endpoint agents designed for Windows systems don’t have signatures built to analyze ELF files, though they frequently detect non-WSL agents with similar functionality” – Black Lotus Labs
Less than a month ago, one of the malicious Linux files was detected by just one antivirus engine on VirusTotal. Refreshing the scan on another sample showed that it went completely undetected by the engines on the scanning service
Python and PowerShell
One of the variants, written completely in Python 3, does not use any Windows API and seems to be the first attempt at a loader for WSL. It uses standard Python libraries, which makes it compatible with both Windows and Linux.
The researcher found in a test sample code that prints “Hello Sanya” in Russian. All but one file associated with this sample contained local IP addresses, while the public IP pointed to 185.63.90[.]137, already offline when the researchers tried to grab the payload.