CyberWire Daily - New developments in the WSL attack. [Research Saturday]

Episode Date: June 11, 2022

Danny Adamitis from Lumen's Black Lotus Labs, joins Dave to discuss new developments in the WSL attack surface. Since September 2021, Black Lotus Labs have been monitoring malware repositories as a part of their proactive threat hunting process. Danny shares how researchers discovered a series of suspicious ELF files compiled for Debian Linux . The research states how the team identified a series of samples that target the WSL environment, were uploaded every two to three weeks and that they started as early as May 3, 2021 and go until August 22, 20221. The research can be found here: Windows Subsystem For Linux (WSL): Threats Still Lurk Below The (Sub)Surface No Longer Just Theory: Black Lotus Labs Uncovers Linux Executables Deployed As Stealth Windows Loaders Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities,

solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. The Windows environment came out with the Windows subsystem for Linux originally in April 2016. That's what they were calling version 1. The original version was all right. It was kind of working. But then back in April of 2021,

they released what they were calling version 2, which was greatly improved, in my opinion. That's Danny Adamaitis. He's a principal information security engineer with Lumen Technologies' Black Lotus Labs. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs,

yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network.

Continuously verifying every request based on identity and context. Simplifying security management with AI-powered automation. And detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. And then this is this really interesting thing because it allows you to use some of these core Linux terminal commands

from your Windows compute environment. So some of the things that they were kind of highlighting are what I'm calling power users. So they were able to create some features to do things like version control for GET. They were able to kind of allow you to more easily set up and remotely deploy Docker containers for all of your Kubernetes instincts. You can connect and stand up a containers for all of your Kubernetes instincts.

You can connect and stand up a database with all of your favorite things, whether it be Mongo, Postgres, what have you. And it just kind of allowed a lot of those more power user functions to be able to be accessible to them from the Windows environment. So that way people weren't kind of bouncing back and forth between Windows and Linux computers anymore.

I see. So all this happens, as you say, within Windows itself, so you're not spinning up a virtual machine. No. The point of this was to have what they were calling a near-native Linux terminal directly from your actual host machine, so that way you can completely avoid

that dual booting machine or that virtual machine environment, which tends to have a little bit more lag. Interesting. Kind of the best of both worlds then. That's what Microsoft's trying to do. That's what Microsoft says, right? Well, you know, I can imagine for someone like yourself

who has a security mindset that when something like this is introduced, there's probably two sides of your brain. One side that says, hey, cool. And the other side that says, wait a minute, hold on, right? Yes. So that was kind of the other thing that immediately came to mind

is that when I was reading through some of the Microsoft documentation and the types of users that this technology was targeted towards, it appeared to try to make life easier, but kind of putting on my red teaming hat for a minute, these seemed like the types of users that I would really want to gain access to. If you can potentially gain access to someone who's remotely deploying your Kubernetes instincts, that could allow you a greater level of access. Or if you were to compromise the person

who manages and stands up your databases, that could potentially allow an attacker to have access to that. Or if you were an attacker to have access to that. Or if you were even able to get access to a developer who was doing Git versioning, that could allow for something like a supply chain attack. So that's one of those things where when I saw this, it just kind of made me realize that while this is a great opportunity and a great feature,

the types of people who are using this are typically going to have more privileged access than your normal everyday user in an environment. Ah, I see. Well, let's go through it together. I mean, things sort of began, was it back in 2021 that you all first saw something that caught your eye? So back in, I believe it was the summer of 2021, as I kind of mentioned, we were doing some of our proactive hunting,

and we came across a sample. And when we first observed this, we saw it was a Python compiled executable specifically for Debian. So we were able to kind of reverse engineer that example. And when we actually reverse engineered it, we were kind of shocked to see that it looked like PowerShell. So for those of you who are familiar, typically whenever you see PowerShell, that only really works on Windows systems. It's not natively installed into your Linux environment. You can obviously install it, but it's not typically what you would see. So when we kind of saw that, we were a little bit perplexed. And then that's kind of when it started to click that we were seeing some of another sample that was using the C-type libraries, which would allow

your Python to actually interact with your Microsoft native libraries and kind of interact with the Microsoft operating system. That's when we kind of realized that this wasn't just your normal Linux malware. Something about this seemed very odd. So we were kind of following that particular development for, I want to say about two months, because we were just kind of seeing what looked like one

or maybe like one group of people kind of uploading a sample like once a week, once every two weeks, for a number of weeks. And we were able to kind of follow their development. And then towards the end of the fall, we actually observed that they stopped uploading samples. And that's when we kind of surmised that maybe they were actually starting

to actually perform something operationally, which is when we released our first report. I see. Well, I mean, let's pull that thread together there. I mean, what was this capable of doing? So it looked more like, I guess, like a stage herd than a fully functional Trojan. It looked more like, I guess, like a stager than a fully functional Trojan. So when I say a stager, what that means is it would kind of get on the host machine, so it would actually modify the current version run key. So if the system were to be rebooted, you would still have access to it post-reboot.

It would try to look for things like any viruses that were running on that particular operating system. So if it saw any of those things, it would attempt to kill it. And then after it did both of those things, it would try to create a reverse shell. And then once you have that reverse shell, that would afford them the functionality to remotely upload files, remotely download files,

run arbitrary commands, kind of do all that stuff that everyone would have to expect. And again, we just kind of thought that this was really kind of interesting because we don't really see, you know, this was the first time at least that I've ever saw a L file that was, you know, running PowerShell. And because it was using that kind of Linux gateway into Windows, that made it particularly stealthy? So because it was kind of living in what we're calling this nebulous world of being an L file on a Windows system, it kind of lived in that weird in-between world.

I will say EDR has gotten very good these last couple years of detecting malicious PE files. However, they don't really do a whole lot to look for or detect malicious L files. Instinctively, they think, okay, an L file isn't really a threat to a Microsoft computer. L files only run on Linux, therefore we don't really need to worry about them. Which just kind of led to this interesting phenomenon that I was

calling the Bruno effect, where a lot of the firms, they talk about L files the same way that Disney characters talk about a family member named Bruno. They don't really want to talk about Bruno until the entire house is crumbling down around them and they realize maybe we should have talked about Bruno a couple hours ago. I love it. I love it. Well, your research into this continued past 2021. In fact, you all published an update here recently. What is the latest? So after we kind of did that initial report, we kind of created some what I was calling fuzzy ER rules to just kind of see what else is going on out there.

The idea being that, you know, maybe this was just a one-off incident, or maybe this is going to be the start of a more sustained pattern. And based off some of our current research, we believe that this is something that's being actively explored by a number of different groups. So in our latest research, we were able to find a number of different samples that we kind of generally broke down into two categories. There is one that we are calling the open source tools or open source frameworks. And then there is a second subcategory that we're calling custom developed tools. So if I can, I think I'll start off with the custom developed tools because I felt that that was a little bit more interesting. But what we were seeing here was that people were actually developing their own tools

and things like Python, compiling them as an L file, and then trying to potentially use them on a Windows system based off of things like the file pass. So we were able to see things like a keylogger that would communicate with a hard-coded Gmail address, which again, we kind of thought was interesting because, again, it's one of those things where if you were on a system

and you have a low host-based detection rate and you're communicating with Gmail, potentially from a US-based entity, I don't really think that's going to be flagged very often. We also saw some interesting ones. One that caught my eye was called this shellcode injector. So this would basically try to reshell to a remote IP address. It would try to download a resource. It would compute the

size of that shellcode. It would then spin up a new thread, and then would try to inject into that. So for the one, for the, I think, two samples we found, there was actually what we're calling private IP space in there, which kind of shows that might still be in development. But this is kind of what we're calling a viable technique to download something like potentially a Cobalt Strike or a Metasploit. Some of these tools that we tend to see used again and again and again. But this would allow them to gain that initial foothold onto that system and then run that more advanced tool in memory.

The last one we kind of saw that was really interesting was this tool called stub.py. And then this one was interesting because it actually had the ability to download a resource and then it would actually take a hard-coded key and then actually decrypt it before running the XRF payload. So again, this would then provide that added layer of network security where even if something was being analyzed by a network firewall

and they didn't have that key, they might not be able to actually identify it as a payload. Interesting. Now, the other category that you're tracking here, you refer to as more open source tools and modules. Is that right? So these are the tools

that are just publicly available on GitHub that we think are just being repurposed by either people for red teaming purposes, for kind of experimental purposes, or potentially even for cybercrime. The issue is that it's kind of hard for us to delineate the threat actor's intent because we're only able to see some of the samples. And as we kind of alluded to before, they tend to use a lot of third-party infrastructure. So especially for these open source tools, they were almost always using things like Discord or Telegram, which makes it really hard to pull out that network signature.

But we saw things like a Telegram key grabber. So what that would do is, it's not actually going after keys per se, but it's going after authentication tokens. So it would try to steal the authentications for something like Google Chrome. It would steal it for Firefox. It would steal it for Brave. And then once it had those authentication tokens, it would be able to then kind of use that to gain access to other remote resources. We saw one fully functional RAT

that was called Discord RAT. And it's pretty much what the name implies. It was a remote access trojan that would allow for uploading files, downloading files, taking screenshots, doing key locking, stealing clipboard functions, and then it would just communicate with a Discord channel.

Then the third one we kind of saw was a very similar agent, but it was using Telegram. So again, this is something that would allow some of that functionality, but the interesting aspect of that was that because it was using Telegram, to me it kind of hints that maybe this was going after something that was more of an Eastern European flavor. So if you were a US-based entity and you were to see something like Discord,

you might think, okay, maybe it's just someone on the team who is communicating with a friend on Discord, and that would seem completely normal in a US setting. If you saw Telegram, it would kind of maybe raise a couple eyebrows. If you're going after someone from maybe Ukraine, for example, and you saw something like Telegram, that would seem completely normal, whereas Discord might kind of be the odd man out there. So it just kind of allows them that functionality to kind of say, you know, what is my target environment going to potentially look like, and then how do I find something that better blanks into that noise? Now, these elf executables, how would they find themselves on a system? Is it the usual ways through phishing and those sorts of things? This is the area where it's a bit of a blind spot for us, admittedly.

But the one thing that we are kind of surmising is that we suspect that WSL was already pre-installed on the operating system. Some of your more avid readers might be familiar. There was a report from Checkpoint, I believe in 2017, that talked about trying to download WSL. The issue with that kind of research was that in order to download WSL, you need to already have system-level access. And if you already have system-level access, it seemed a big superfluous. So what we're kind of assuming is that a threat actor has found a legitimate workstation on a target environment that already has WSL installed, and that they are just kind of moving laterally onto that system. But then once they're on that system,

that could potentially allow for them to run this kind of other module that we identified to grab credentials from things like your Google Chrome database. And once they were able to do that, they could potentially get your clear text username and password, or they could potentially install one of these other remote access trojans or key lockers that we talked about to allow them to kind of maintain that foothold in a network and a more stealthy mechanism than might otherwise be on just a pure Microsoft Windows box that doesn't have WSL installed.

I see. So if I were to, I don't know, if I had an ELF binary on a system that didn't have WSL on it and I try to execute that, will it ask me if I want to download and install WSL? I do not believe so at this time. So if you are just your average everyday guy who's maybe working in accounting,

and you just want to try to run an L file, it's just going to kind of say, you know, can't run this particular file, and it won't really do anything. And I guess the presumption is, it's a little presumptuous, but it's probably fair to say that if someone has WSL installed on their machine, they're probably a higher level user. Correct.

Most of the people who have WSL, again, tend to kind of be in this class that we call power users. So these are people who tend to be a little bit more savvy, tend to be a little bit more involved in things like database administration or Kubernetes. So again, it's one of those things where it's kind of targeted towards those, I want to say, higher-end users. Yeah. So based on the information you've gathered here, what are your recommendations? What should people be doing to better protect themselves?

So the first thing is going to kind of seem obvious, but only install WSL on systems that actually really need it. So again, if you are someone who is potentially managing a couple databases for your organization, and you really use this and it helps make your life easier, well then absolutely, we think it might be a good idea for you to keep that installed. However, I would not put this on anything like a golden image. If you are a traveling salesperson, you probably don't need this functionality because I don't think a lot of them use that.

The other thing is, of course, just trying to kind of do the basics that we talked about before, like monitoring your system processes. Because this kind of lives in that nebulous space we talked about where you're an L file on a Windows system, EDR is doing better, I will say, in the more recent time, especially for some of the open source frameworks, but it's still not perfect yet. So you really need to have good system monitoring for things like creating remote threads, creating remote processes, editing register keys. So a lot of the samples we actually saw, they tended to rely on pretty unsophisticated ways of persisting, things like run keys or startup paths.

And that stuff might actually be detected by your Sysmon tools, and that can kind of help you that way. And then the last thing is just kind of good practices of if you're only connecting to internal databases, maybe stepping a firewall rule that says, hey, let's not allow this to come to the actual internet. It can only connect to internal IP addresses that would then kind of cut off that C2 mechanism. Any idea who might be behind this? Right now, we don't really know if there's

any one group behind this. Based off some of the samples we've seen, we suspect it might be a couple different groups of people, which is kind of why we almost categorize this as a class of attack than a particular campaign. So, for example, when we talked about some of the stuff like stub.py, there was some, I want to say a little bit of code commenting that was in Portuguese. When we looked at some of the samples that were back in the fall,

they were actually in Russian. And then there was some that were just kind of in English. So it doesn't seem like there's just one guy who's on the internet developing all the WSL malware. It kind of seems like it's something that's kind of being poked at and explored by a couple different groups of people. But because of this kind of low detection rate, we kind of wanted to try to do

what we can to raise this as an area of concern because, you know, we feel that it is being explored by a number of different groups of people and we don't really know what the future holds. Our thanks to Danny Adamitis for joining us. We'll have links to his ongoing research discussing Windows Subsystem for Linux, WSL, in the show notes. And now, a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected

lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365, with Black Cloak. Learn more at blackcloak.io. The Cyber Wire podcast is proudly produced in Maryland out of the startup studios of Data Tribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing Cyber Wire team is Rachel Gelfand,

Liz Ervin, Elliot Peltzman, Trey Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabey, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Vilecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilby, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.