Encore: Hunting Threats in Developer Environments

Speaker A: You're listening to the Cyberwire Network, powered by N2K. Cyber attacks can really come from anywhere. Now. Even applications that we think are totally legitimate may be abused by an attacker to get what they want. And that is why it is so important that we keep learning about, uh, new advances in cybersecurity and new techniques that threat actors use in attempts to gain a hold of our networks.

Speaker B: Welcome to Threat Vector, the Palo Alto Network's podcast where we discuss pressing cybersecurity threats and resilience and uncover insights into the latest industry trends. I'm your host, David Moulton, senior director of thought leadership for unit 42. And today I'm joined by Tom Vechterman, senior threat researcher, and Daniel Frank, threat research team lead at Palo Alto Networks. Tom has a strong background in cyber threat intelligence, malware analysis and network forensics, with experience spanning both private sector and Israeli military service. His work at Cyber Reason and now at Palo Alto Networks has uncovered some of the most advanced cyber espionage campaigns in recent years, ranging from attacks on telecommunication infrastructure to abusive cloud platforms in the Middle East. Daniel brings over a decade of experience in malware research and threat detection with a career that includes senior research roles AT Cyber Reason, F5UM Networks, RSA Security, and now Palo Alto Networks. He also holds a patent for detecting fraudulent activity from compromised devices, just one of the many ways he's contributed to building a stronger defense against sophisticated threat actors. Today we're going to talk about a pressing and emerging risk. The abuse of software development platforms by both cybercriminals and nation state adversaries. As development tools like IDs, low code platforms and public code repositories become more powerful and interconnected, attackers are finding creative ways to exploit them, often bypassing traditional detection mechanisms. This includes a recent case involving a Chinese APT group that use Visual Code Studio to deploy malware within a development environment. A campaign uncovered by our guest today. For organizations with CICD pipelines, development teams, or third party coder integrations, this episode shines a light on a growing blind spot. If attackers can exploit the very tools your developers trust every day, it's time to rethink how we secure our development infrastructure. So Tom set us up. Why are low code, no code environments becoming so popular for developers?

Speaker A: That's a good question. So I would say that, uh, uh, now with the rise of AI and everything, uh, you see that a lot more and more people don't need or want to know how to actually code to do all the stuff that they want to do in their day to Day work. And that's exactly what low code platforms gives the user the ability to create sophisticated automations without needing to know how to program.

Speaker B: Yeah, so it sounds like it speeds you along and it allows somebody with less skills to make something incredible quickly. Um, but you don't have that foundational understanding which can be a risk if you don't know what you're doing.

Speaker A: Exactly.

Speaker B: So Daniel, let me take it over to you. What's behind this rise in the abuse of software development platforms like VS Code, low code environments and even code repositories?

Speaker C: Well um, for a start we know that threat actors are always looking for new ways to infect users. Right. They keep adapting to the current landscape. So um, what we've noticed uh, over the last year or so that um, the abuse of IDEs has increased. Significantly increased. Right. So um, as part of our day to day job, uh, like Tom I and the rest of the team, so we you know we hunt for these instances, you know we try to find uh, things that are kind of flying under the radar, like new techniques for example. So and about a year ago um, we started noticing more and more incidents where threat actors um, abuse legitimate software development platforms like Visual Studio and others as well, you know to uh, carry out all of these hacking uh, operations. Now that got us intrigued. I mean um, and one of the first questions that came to our mind was like abusing legitimate software is not a new thing eventually. But why focus specifically on software development? Well there could be a number of reasons. Um, A you want to target developers in an organization. Right. And B software development platforms usually um, enjoy these really high privileges uh, um, within systems and they have access to ah, source code and other sensitive information. And above all they're legitimate. Right. Um, and we are seeing more and more of these attacks against technology companies and uh, R and D of tech and also uh, uh, cryptocurrency firms by nation state threat actors and it's mostly for intellectual property and espionage. Um, but also um, some threat actors are conducting these modern money heists and the case of North Korean cyber warfare program is a perfect example for that. So as we all know North Korea, they're under these crushing international um, embargoes and sanctions and they have to work really hard to bypass these limitations. Now what we are seeing is more and more of these North Korean uh, threat actors uh, targeting software developers in uh, leading western technology on crypto organizations and with the intention of infiltrating um, these institutions.

Speaker B: So Tom, let me take it uh over to you. What makes IDEs like VS code such a valuable entry point for adversaries.

Speaker A: Well, it might not come as a shock to you, but the first thing that makes it so attractive is of course, the human factor. One of the things we've noticed is that works pretty well for those North Korean hackers is using social engineering. Um, for example, they would convince people to open projects and run them in their ides under different rules, like, uh, a fake job interview. And this could be really effective. Also, some IDEs have built in capabilities to control the machine, so the attackers sometimes don't even need to deploy malware. Now, because IDEs are of course legitimate applications, a lot of people use them and that makes, uh, the attack a lot harder to detect if an IDE is being abused. Another good reason is that if the attacker's goal is to get a hold of source code, what's a better target than the main tool developers use every day to write that source code? So like we see developers have access to sensitive source code in their organizations and that, uh, makes them like a prime target for attackers. Right.

Speaker B: Let me talk to you about malicious extensions. What makes those such a risk for developers?

Speaker A: Well, think of it like this. It's kind of like installing a sketchy browser extension. There's always a risk involved. Now, VS code is a little different from your typical ide. It's basically a lightweight code editor. And what makes it so cool is that you can download, uh, thousands of different extensions that are available in the marketplace. But with that also comes a risk. Uh, anyone can upload an extension to the VS code marketplace, and that includes people who want to cause us harm. So threat actors can hide malicious code inside these VS code extensions, and that could be the start of a full fledged attack.

Speaker B: Tom, walk us through the Chinese Apt case that you presented at rsac where VS code was used as an attack vector.

Speaker A: Oh yeah, I love that story. Uh, so, uh, like any good story, it started with a really suspicious alert popping up, uh, in our telemetry. And that alert was particularly interesting to us because it came from an environment that belonged to a government entity located in Southeast Asia. So we started investigating and when we dug into the details, we saw a lot of that weird looking activities that just screamed to us espionage. We saw reconnaissance activities that were after sensitive, uh, information. We saw exfiltration activity trying to steal data. We saw them trying to gain access to valuable servers. What was amazing to us is that when we looked at the origin of all of that, uh, malicious activity, we saw that all of those commands were Executed by a process of visual studio code. It was a super legit signed verified process. Nothing uh, unusual stuck us to us. So we were wondering what is going on here? And that's how we found out about this really rare technique that was leveraged by the attackers.

Speaker B: That's wild. That had to shock you when you saw that in the alert and you started to uh, chase it down because it's legitimate and, and it's malicious altogether.

Speaker A: Oh yeah. At first I was like uh, what's going on here? It took me a couple of days to realize what it is. At first I thought okay, maybe it is injection or DLL sideloading. But I couldn't find indications for either of those and I was stunned at first.

Speaker B: Is this the first time you've run across something like that?

Speaker A: Oh yeah, it was like. Well actually uh, a cool story about that is that it all the technique. And when I tried to search about the technique I only found some poc that were published about it like a half year prior. But there were zero reports about the technique being used in an actual meshes operation. So as an analyst it was pretty cool to see it like, I guess like a first time abuse of the technique in the wild.

Speaker B: Daniel, you mentioned abusive low code environments. What kind of threats are you seeing in these platforms specifically?

Speaker C: Okay, so local platforms, what uh they do is that they offer a lot of these powerful features. I mean they can access things like users files, they can access their clipboard and even their Internet connection. And this is just like to name a few. Right. And the best part, it's all the hun through and easy to use interface. So you don't need to be a coding expert or anything close to that. But um, here's the problem. So if an attacker gets hold on one of these platforms, they can create these automated workflows for all kinds of malicious activities and without needing to deploy any extra malware. I mean it's like they got this built in toolkit to do a lot of damage without even trying too hard.

Speaker B: How are the tactics different from like a traditional supply chain attack or backdoors planted in build processes?

Speaker C: Well, I'd say that um, the main difference is that in supply chain attacks the attackers uh, need to find a way to insert malware uh, into an installation process of this uh, legitimate software, uh, or the other. But um, in this type of attacks that we're talking about, um, all the attackers really need is good social engineering skills to gain access to a developer's IDE and some bad intentions. I mean it's that simple.

Speaker B: So would you categorize this as like a new class of insider risk or is this actually something that's a little closer to like a stealthy external compromise?

Speaker C: Um, well, I would consider this more of a stealthy external compromise. Um, so the threat comes um, essentially from external threat actors who um, mislead employees rather than, let's say, from an insider, uh, with this malicious intent. Um, because these employees, I mean they do not run malicious code on purpose. Right? Um, they're tricked to doing that. And I would also like to emphasize another point. I mean since many developers in an organization use the same IDs and usually such activity looks legitimate, so spotting it can also be really tough. I mean unless you're actively hunting for it.

Speaker B: Tom, um, what telemetry or visibility gaps are allowing attackers to operate inside development tools without detection?

Speaker A: Yeah, so this is where things get kind of tricky. So uh, one of the biggest challenges with dealing with IDE abuse is that uh, at the end of the day these are legitimate applications and usually they are trusted in the environment. So it is not out of the ordinary for them to perform a lot of activity. So when they are doing stuff like accessing the file system, reaching out to external servers, spawning uh, processes, that's not necessarily malicious. And that's exactly what uh, attackers are banking on. They're hiding in plain sight. So this can make it hard for defenders to differentiate between day to day use of an ID and, and malicious abuse by a threat actor.

Speaker B: What's going to need to change the most environments to close these gaps?

Speaker A: I would say the first step, uh, like with a lot of these problems is awareness. You've got to actually recognize that IDEs, while of course are essential, can also be attack surfaces. The next step will be to work on tailored detections and hunting queries. We need to understand what normal behavior looks like for tools like VS Code and what sticks out. And that takes some uh, environment specific

Speaker B: tuning for defenders out there. What are some of the high fidelity indicators of compromise or maybe even the behavioral patterns that uh, are tied to the developer platform abuse?

Speaker A: So obviously uh, the exact indicators can shift depending on the technique and the attacker's playbook. But there are definitely some patterns that uh, we see that are popping up over and over again. One of the biggest red flags we see is when an IDE spawns a shell process like a, uh, cmd or a PowerShell. And when those shells start running things like recon, uh, commands, trying to map the network, pull credentials or even move laterally well, at this point you should have the alarm ringing.

Speaker B: Oh, for sure. Can you share any success stories where those techniques were detected really early?

Speaker A: Oh yeah, definitely. Uh, I love that question. So I have uh, one story that happened pretty recently and it is related to a campaign we call Contagious Interview. And we actually explored that one in our RSI conference session. So in this campaign, North Korean threat actors were posing as recruiters and they were trying to trick developers into running malicious code under the guise of a fake job interview, hence the name, a, uh, Contagious Interview. And we spent a lot of time dissecting that campaign and mapping out the different ttps. And we've created a lot of different detections around our techniques. And not long after our investigation, we actually started seeing this threat actor attempting to target our customers using very similar ttps. But because of all of the work that we did on them, Cortex XDR was ready and it blocked all their malicious attempts. And this is an idea that we really focus on in our team. That research isn't just a theory. It directly powers our defenses.

Speaker B: Absolutely. Daniel, what are some of the proactive ways organizations can secure their development environments without slowing down their developers?

Speaker C: Uh, this is a really important question, David, and I'm glad you asked it. Well, there are a few ways organizations can uh, secure their development environments, but I will highlight two main ones. Well, first off, before running any code from outside sources, like third party code, and this is something that we talked about a lot during our rsa, uh, conference presentation. So it's really important to scan that code either manually or automatically. And this goes for code you're importing into existing projects or when you're starting a new project. And the same also applies for uh, now the second and probably even more important point is that regular security awareness training is key. Everyone in the company should be trained, but it's especially crucial for developers in this case, uh, to be aware of these kinds of threats and know how to recognize them.

Speaker B: Are there best practices for extension vetting that you recommend?

Speaker C: One way to manage things, and this is relevant especially for uh, managing Python packages. And we talked about malicious Python packages during our SEG conference presentation. Um, is by using a, um, local cached repository within organizations. So this way developers can install packages and specific versions of these packages from these local, uh, company servers where the code has already been pre audited. And when it comes to vetting extensions like the VS code extensions that we mentioned, um, it's best to um, for the very least to stick with uh, signed extensions, uh, from trusted developers. Now of course, nothing's ever 100% foolproof, right? But taking these precautions can really at least lower the risk of picking up malicious third party code or extensions.

Speaker B: Guys, your team analyzes nation state tactics. How would you differentiate between cybercriminal versus APT use of these dev tools? Maybe. Daniel, uh, you go first.

Speaker C: Yeah, um, it really depends on the approach, I would say. So for something like malicious extensions, it's actually pretty simple I guess, uh, a cybercriminal doesn't need much. Just um, take a malicious extension, upload it to a store, maybe trick users, uh, in a way or two into installing it, and voila, they're in. Right? Um, anyone with basic technical skills can manage that. But for more targeted attacks like setting up these fake job interviews, that's where apts really come into play. And they've got the resources and motivation and time, I guess, to pull off these more complex social engineering tricks like that.

Speaker B: Tom, is it a technique we expect to see more broadly adopted across, uh, different threat actor categories?

Speaker A: Oh, absolutely, and we've already seen it happen. I'll use VS Code CLI abuse as an example again. So as I said when I first started digging in how Chinese APTS were abusing VS Code CLI to mask the activity, I couldn't find any report about the technique actually being abused in the wild. But today is a very different story. If you search for the abuse of VS code right now, we'll find many reports from several different threat actors who abuse that very same technique. So we are seeing it live how this technique is being adopted by more and more threat actors in more and more attacks.

Speaker B: Daniel, where do you see the threat landscape heading over the next year? Are we like moving into a new phase of developer focused cyber attacks?

Speaker C: I think we'll definitely see more of these attacks than we already seeing that in recent months. And um, especially as different threat actors continue using AI to make their interactions with targets even more convincing than they are now. And trust me, they can get pretty convincing. And also as long as um, malicious code can still slip into these, um, marketplaces and different uh, development projects, we're going to see this attack vector probably grow and become bigger threat in the near future.

Speaker B: So guys, one of the questions I like to ask at the end is what's the number one thing that a listener should take away from our conversation today? Tom, we'll start with you.

Speaker A: Well, uh, one thing that I really want people uh, to take from that is that uh, cyber attacks can really come from anywhere now. Even applications that we think are totally legitimate may be abused by an attacker to get what they want. Uh, and that is why it is so important that we keep learning about new advances in cybersecurity and new techniques that threat actors use in attempts to gain a hold of our networks.

Speaker B: Daniel, over to you. What's the most important thing that a listener should take away from today's conversation?

Speaker C: Um, well, first of all, um, there are so many ways that threat actors can get in. And I mean both cybercriminals and nation state apts, they can get super creative, um, where they need to infiltrate, um, organizations. And it's also crucial to remember that legitimate applications are prime targets for attackers because they can sneak in unnoticed, they can run malicious code on commands, uh, within this app or another, and it makes it so much harder to spot and differentiate from legitimate activity. And let's face it, we're all human, right? And we all make mistakes. So as Tom said, this is why it's so important to stay proactive and look for these kinds of threats and keep up with the latest trends in cybersecurity.

Speaker B: So, Tom, Daniel, thank you so much for an awesome conversation today. Uh, I really appreciate you bringing your insights and kind of a snapshot of the talk that you gave at RSAC this year.

Speaker C: Uh, thanks, David. Great to be here.

Speaker A: Thank you so much. David. Had a great time.

Speaker B: That's it for today. If you like what you heard, please subscribe wherever you listen and leave us that review on Apple Podcasts or Spotify. Uh, your feedback and your reviews really do help me understand what you want to hear about. If you want to reach out to me directly about the show, email me at threatvectoraltonnetworks.com I want to thank our executive producer, Michael Heller, our content and production teams, which include Kenny Miller, Joe Betacourt, and Virginia Tran. Elliot Heltzman edits the show and mixes our audio. We'll be back next week. Until then, stay secure and stay vigilant. Goodbye for now.