Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders | Hacker News Reader

Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

blog.lumen.com

128 pointsfraqed43 comments

"WSL is a supplemental feature that runs a Linux image in a near-native environment on Windows, allowing for functionality like command line tools from Linux without the over-head of a virtual machine."

But since WSL 2 it does use a VM. According to wikipedia:

"a real Linux kernel,[4] through a subset of Hyper-V features." "with a Linux kernel running in a lightweight virtual machine environment."

edit: unless they mean user overhead of getting it to work. I kind of read it as performance overhead.

When installing WSL you can still choose if you want to use WLS 1 or WSL 2, and you can switch between them. If you keep your files not in the WSL filesystem, WSL 1 is still the recommended choice because of the lower overhead for file access.

Plus WLS 1 is marginally easier to install because you don't have to enable Hyper-V

I recently updated my visual studio code development environment and it depends on WSL 2 now. It seems to be that this is the direction MS is heading.

You also don't get "vmmem" process that eats memory and doesn't give it back

> But since WSL 2 it does use a VM.

As a related sidenote: Try doing an apt install metasploit inside a "VM" while an antivirus is running on the host.

You'll soon realize that the "VM" will be bricked by quarantine actions on the NTFS based filesystem, which kind of defeats the reason of the V in VM.

I fear once more people realize this, there'll be NTFS stream based "hidden" malware and other filesystem rights abusing tools everywhere all over again.

That’s because the VM has hooks into the host filesystem though, isn’t it? Does it still happen if the VM is fully isolated from host resources (files, ports, devices)?

Wouldn't simply activating file-level encryption in the Linux subsystem be enough to throw off Windows-based AV scanners?

I didn't test whether or not LUKS or similar filesystem level encryptions are transparently mapped to the Windows kernel.

Might be a good way to avoid this behavior. The default (from the Windows Store) Ubuntu based VM however doesn't use filesystem level encryption, and every folder or file inside the "VM" is available somewhere buried in the Roaming folders.

Yeah, you'd have to install LUKS or eCryptfs or something, but I think it would be worth a try. I expect Windows would only see the encrypted files then.

Is WSL still opt-in? Something to be aware of for power users, but most Windows users are never going to know about or figure out how to turn on WSL (at least as of the last time I tried it).

Yes, and I believe enabling it requires administrative rights so the risk to a lot of organizations with locked down Windows installs is minimal unless they’ve enabled WSL intentionally

Pretty much all government contractors use windows for bureaucratic and spying purposes. Good luck convincing your security-minded boss to let you have a linux playground when it increases attack surface area.

I got WSL setup in my computer without the admin rights.

That's interesting. The mainline builds seem to require running dism.exe with admin rights, and the preview builds require running "wsl.exe --install" with admin rights. Curious how you got around that.

Sure you didn't just get it without UAC?

If you actually don't have admin rights, was this WSL1?

I honestly don't remember how I did it. But I have WSL2 with ubuntu. I know ubuntu I downloaded from the windows app store.

The install process for WSL is still fairly complex for mainline Windows builds. However, in the preview channel, it's mostly just "wsl.exe --install". And that wsl.exe ships with the preview builds. I can see this being a bigger target once that feature is pushed down to the mainline windows builds. It does still require admin rights.

See: https://docs.microsoft.com/en-us/windows/wsl/install-win10

It's not something a consumer will do by accident, and IIRC the last time I set up Enterprise on my work machines I also had to activate itanually.

Most Windows users are also never going to know how to get Microsoft Office on their Computer when it doesn't come preinstalled. Usually people have other people who do things like this for them

This comment made me sad, a little. 15 years ago practically everyone would know how to do this: download the installer from Microsoft and run it.

It was possible to download an installer from Microsoft 15 years ago (except MSDN)? For most people getting Office meant trip to the store and getting a box with physical CD.

It was:

https://web.archive.org/web/20060430185620/http://g.msn.com/...

A link to download an Office Trial, which at the time was just the full version of office which worked without a key for a trial period.

I seem to recall there was an online store for Office to purchase a key.

Though, I suspect you're right, most people probably bought a box back then. These days, I'd expect the average consumer to use the preloaded Office stubs on new PCs.

This seems like a symptom of forgetting 2006 was 15 years ago. I did the math this time but if someone off hand mentions 20 years ago I still think of the 90s.

Ha, you're right, I might have overshot my time period a little. I was thinking Windows 7 era, plus some late Vista/XP. Wikipedia tells me Windows 7 was released in 2009, so my statement would probably hold better if I'd said "around 10 years ago". But on the whole I think it's close enough :)

In all fairness, things were a lot easier back then. Installers all had the same UI and you knew where to find them afterwards. Now the UI is different for all of them and you have no idea where the program went when it finished installing.

What a condescending comment

True. Very condescending.

The fact remains, no matter the tone.

Most, not all Windows users CBA with "computers" and call _us_ to install software.

There's a reason shops charge a fortune for basic maintenance. People don't have the time/inclination to learn it.

This is my own opinion, based on my own experience. YMMV.

It’s also terrible, thankless work, if you don’t charge an arm and a leg people think it’s worthless work.

> Most...users are also never going to know how to get...on their Computer when it doesn't come preinstalled.

What?

Isn't that the biggest selling point of MacOS on HN/Reddit?

I don't know anyone who has locally installed office software anymore. It's all GSuite or Office 365.

Really? I think they will just Google "buy Microsoft office" and follow the instructions on the first link that pops up. Or buy it from the Windows store app.

Interesting, though it doesn't explain how it's invoking WSL. As far as I know, you would need a second part of the payload that invokes WSL and runs the ELF binaries.

I think the idea is that the user would run these malicious binaries in WSL themselves, thinking it's a safe environment for testing. But actually, anything run in WSL will have the same privileges as the user who started the session, due to the interop features (even if it's not running as root in WSL).

from what i read, it just sounds like the issue is that windows virus scanners haven't been updated to check hashes for elf binaries. wsl added a new executable type to windows and the virus scanners haven't caught up, so now you can have these malicious elf binaries laying around that a user could run and the virus scanner will ignore them.

the nature of the ones they found sound simplistic. just python scripts in one of those self extract and run bundled python interpreter and included script single file executable archive things.

This github issue in interesting: https://github.com/microsoft/WSL/issues/2886

It sort of hints that you could coax LxssManager.dll into running an elf binary without WSL itself really running. Though you would need to do some things to make lxss happy, so it's not trivial.

But there's no advantage to starting with a Windows binary and executing a Linux binary just to have it execute a Windows binary again. You may as well just start with the final payload if you are already able to run code in Windows, there's no point invoking WSL in that scenario at all. I am pretty sure the attack scenario imagined here is regarding Linux binaries executed in WSL by the user or other software inside WSL, not code which was already running under Windows.

No, but assuming a windows binary executing a Linux binary is somehow bypassing (some) heuristics, etc...

That might be an advantage. You have full access to windows files, etc, from WSL.

How about this. May be this is a bad idea too. Can we have like WSL3, where highly optimised Linux kernel runs on hypervisor. And Ubuntu/arch share the kernel using containerised approach. And individual apps too can run using the same workflow? That way we have benefits wrt overhead. Something like electron but they all use the same ringtone instead of a new instance. Again it may be a bad idea, just curious of the benefits.

https://docs.docker.com/desktop/windows/wsl/

Oh, I thought each instance of the os has its own VM upto now. Still, I wish it would be more native experience rather than depending on docket desktop, if it makes sense.

If you install separate WSL2 images for each app it does. If you go the container route with Docker (or your container orchestrator of choice) naturally they'll be shared.

I'm having issues parsing your comment, but WSL2 is already a single Linux VM with containers for each "distribution". That's how the /mnt/wsl/ thing works — it's just a mount mapped into your container. Also, all distributions share a network namespace.

Oh, cool, I didn’t know that.

Reply on news.ycombinator.com