[shawnz]

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

[a-dub]

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.

[tyingq]

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.

[shawnz]

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.

[tyingq]

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.