Live data from Hacker News

Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

blog.lumen.com

31–40 of 44 posts

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#31

"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 m…

> 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 abus…

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)?

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#32

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…

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.

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#33

"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 m…

> 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 abus…

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

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#34
post #32

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…

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.

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#35

"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 m…

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

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

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#36
post #24
post #15

Earlier quoted context omitted.

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 o…

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.

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#37
post #7
post #2

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).

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

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

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#38
post #16

Earlier quoted context omitted.

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.

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#39
post #9

Earlier quoted context omitted.

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

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.

Re: Black Lotus Labs uncovers Linux executables deployed as stealth Windows loaders

#40
post #36
post #24

Earlier quoted context omitted.

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 o…

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.
Post reply on HN