BLOG

The OpenSourceMalware Show #6

OSV false positives, Crowdstrike takedown of Glassworm infra, and MSFT nukes a researcher

By cb482791-4ef1-4762-96ad-b0ca4bdd538e ·

The OpenSourceMalware Show #6

The OpenSourceMalware Show is available on YouTube, LinkedIn, and as a podcast.

In this episode we covered:
OSV false positives from AWS Inspector: AWS’s automated malware detection pipeline submitted 157 false positive entries to osv.dev. The entries were merged before anyone caught the errors. When the community began pointing out that some of those “false positives” were actually real malware, AWS started adding some back, making this a mess on both ends. AppSec vendors piled on publicly despite relying on OSV as their primary detection source without contributing to it. Paul publicly thanks Chi Tran’s team at AWS Inspector for their contributions overall.

CrowdStrike, Google, and Shadowserver take down Glassworm C2 (including the botnet vs. worm distinction): The operation targeted four infrastructure components: Solana blockchain dead drops, BitTorrent DHT, Google Calendar abuse, and commercial VPS servers. The legal and technical basis for the takedown is unclear and CrowdStrike declined to comment on specifics. Paul explains how blockchain memo fields work as dead drops and how multi-stage attack chains evolve. As part of the discussion, Paul clarifies the technical difference between a botnet (centrally orchestrated persistent access across many machines) and a worm (self-replicating), and ties it to how both Glassworm and DPRK/PolinRider operate.

MSRC, Nightmare Eclipse, and the state of coordinated disclosure: Researcher Nightmare Eclipse published six unpatched Windows zero-days (RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, MiniPlasma) after a breakdown in MSRC’s handling of their disclosures. Microsoft’s claim that no prior notice was given is contested. Nightmare Eclipse says MSRC knew BlueHammer was coming. Microsoft’s MSRC blog post named all six vulnerabilities, invoked its Digital Crimes Unit, and never acknowledged Nightmare Eclipse’s claim that Microsoft deleted the account they used to report bugs and paid them nothing. The MSRC post instead triggered a flood of other researchers sharing similar experiences: Gabriel Landau reported MSRC agreed to issue a CVE in exchange for an extended embargo, then patched silently and broke that agreement. Rootsecdev reported a five-month wait followed by a “doesn’t meet the bar for servicing” response, while Microsoft silently fixed it anyway. GitHub then banned Nightmare Eclipse’s account; GitLab followed suit days later. Paul and Jenn note this reflects a broader, documented pattern of MSRC underinvesting in researcher relationships, not an isolated incident.

Using GitHub as a forward-hunting collection source: Paul and Jenn co-authored a guide with Feedly based on the hunting technique Paul has used to discover campaigns like PolinRider. Workshop may be submitted to DEF CON Adversary Village.

Episode Resources

[00:00:00] Jenn Gile: Hello, we are live. It is May 28th. Paul, I can’t believe May is almost over. What happened? I realize this is something that you get over a certain age, and this is just something everybody says all the time, but seriously, what happened? It’s almost June.

[00:00:06] Paul McCarty: As you’ve said in the past, time is a flat circle, but as you get older, the circle just spins faster.

[00:00:12] Jenn Gile: It gets smaller. Well, I just got back this morning from San Francisco. I was at an AI agent security summit put on by Zenity, and I have to say they did a really nice job. The content was outstanding. It ranged from people talking about the opportunity that security practitioners have in front of them to be using agents. Really great networking. I gave a talk on malicious skills that went down pretty well.

[00:01:00] Jenn Gile: Funny story, I haven’t told you this. So I walked in the door home about an hour ago, and my husband’s working away, and he’s like, “Hey, fill-in-the-blank vendor has invited his team to be part of beta testing an AI chat agent.” I see your face. For people who can’t see the face -- that’s the face I made. And he was like, “What questions should I be asking?” And initially my brain went for, “Okay, here’s how I would test it, this is how I’d figure out…” And then I was like, “Wait, wait, wait. Did you do a security review first? Okay. We have to have a totally different conversation.”

[00:02:00] Jenn Gile: This vendor turned on this feature for them, gave them no security documentation. We don’t know anything about how they’re segmenting data, how they’re training things -- no answers. And he works for a legacy kind of company where software development is definitely not something that they do. It’s not the tech industry. I guarantee the IT team knows next to nothing about what to ask. So I am departing on an adventure to help him figure out if this thing is safe to use, and then get it approved for use internally so he doesn’t get fired. It’s a wild world out there. We’ve been at this for what, a year and a half or so, and there’s still a lot to learn.

[00:02:45] Paul McCarty: People weren’t pen testing stuff like this to begin with, especially small businesses. But now with how quickly people are turning on AI features and AI chat features, they’re not pen testing these things. There was this assumption by those of us in the AppSec community that with all this new code and all these new features, there’d be an equal number of security checks along the way, and the opposite is happening. We’re seeing less.

[00:03:15] Jenn Gile: This particular vendor is a big company, but they serve an industry that absolutely does not have cybersecurity professionals on the same tier. Certainly not people who know more than me, and let’s be clear, that’s a low bar. While I was at the event yesterday, I was part of a tabletop exercise that was on almost the exact same topic. We had a debate about whether it was realistic, and then I walk in the door to this kind of thing. So yes, it’s realistic. But anyway, let’s cover the news.

OSV False Positives and the AWS Inspector Team

[00:04:00] Jenn Gile: You sent me a link, maybe it was yesterday, maybe it was the day before, about OSV deleting 157 malware entries because they had been found to be false positives. These were malware reports that had been reported by a team at AWS through some automation. Before we talk about the reaction, what I understand -- correct me if I’m wrong -- is there was some kind of LLM generating reports where the reports were not vetted by a human on the outgoing side, and then on the incoming side into OSV, maybe nobody at OSV validated them either. Am I understanding that correctly?

[00:04:45] Paul McCarty: We don’t know exactly what was validated on either side, either from the AWS side or on the OSV side. That’s correct.

[00:05:00] Jenn Gile: And that’s something that happened, and candidly, I’m not super surprised. It’s not ideal. There is real harm when false positives make it into the ecosystem, whether it’s vulnerabilities or malware. But the reaction from application security vendors was immediate and kind of brutal, and honestly kinda not cool.

[00:05:30] Paul McCarty: 100%. I said this to a group of my friends on Signal -- I really think this is crappy. But I think it was really crappy that a bunch of ASPM and AppSec vendors jumped on this. First, because most of those vendors have never supported OSV in any way. They’ve never submitted a single thing to it. And yet many of those vendors -- and I’m not gonna use any names -- have used OSV as their primary malicious package detection source since 2023 when they turned it on.

[00:06:00] Paul McCarty: Here’s the backstory. AWS is the largest contributor to the Open Source Security Foundation, which is part of the Linux Foundation, which is who collaborates with Google for osv.dev. AWS has been submitting for a while now, and they submit so many that they recently moved to an automated submission process. They’re not doing it the way that I used to do it, just making PRs -- they now push mass submissions. And by their own admission, Chi at AWS in the PR says, “Hey, we turned on some new detection rules and they’re a little bit too trigger-happy, and we pushed some stuff that we shouldn’t.” So 157 of those.

[00:06:45] Paul McCarty: Now here’s the problem: they’ve already started rolling back some of those. So some of those are actually legit -- I’ve found between eight and 15 that were real malware.

[00:07:00] Jenn Gile: I saw one comment about, “Hey, you guys, no, this one’s real.”

[00:07:05] Paul McCarty: Well, I found a fun number of them too. Here’s the problem: when LLMs decorate these things -- and everybody inside their malware detection engines is using LLMs -- you basically have static findings and your sandbox findings, those all come together, and the LLM goes through those things. It’s a very gray area, especially with some of the crypto ones, where you’re seeing wallet addresses and other things. It’s really easy for something to get ticked over from 49% malicious to 51% malicious, and then it’s decorated as malicious and it gets shipped. This idea that it’s really obvious at face value if something is malicious or not is not the case. Bad guys hide stuff.

[00:08:00] Paul McCarty: I think it’s crappy that people are piling on who are not part of the process, who are not part of the solution. The vast majority of submissions over the last couple years have been from AWS and from Chi’s team at Inspector. So I just wanna say publicly: Chi, I appreciate your work. AWS, I appreciate your work. There’s this little bit of mess-up, but shit happens. I would rather get a couple of false positives than lots of false negatives. That’s my take.

[00:08:30] Jenn Gile: Yeah, absolutely. And I think we should be clear: we do believe that there needs to be a solution for malicious threat intel that’s not OSV. OSV is amazing for vulnerabilities. It’s not really purpose-built for malware. But that said, this is a community. Let’s be cool. Speaking of community, we got a hello in the comments from our friend Francois at Boost. Hope you’re doing good, my friend.

CrowdStrike Takedown of Glassworm Infrastructure

[00:09:00] Jenn Gile: Let’s move on to our second topic. You shared a link from CrowdStrike -- I know, flat circle, like I said. CrowdStrike announced that they did a big takedown of Glassworm C2 infrastructure. So they didn’t take down the threat actor. Nobody went and made arrests. They took down infrastructure. It was a collaboration between CrowdStrike, Google, and the Shadowserver Foundation, which does have some ties to law enforcement. But we were kinda wondering how they managed to pull this off since we didn’t see any government involvement.

[00:09:45] Jenn Gile: I found an excerpt from TechCrunch where they said, “It’s not clear on what legal or technical authority CrowdStrike and others operated to take down the operation. When asked by TechCrunch, the CrowdStrike spokesperson declined to comment.” Very mysterious. So we can set that to the side and talk about what the takedown actually included, because it was four pieces of infrastructure. To educate listeners a little bit -- if you’re not familiar with how malware delivery works, it’s rarely just the package that you ingest. There’s going to be a dead drop where stuff is getting exfiltrated to, perhaps a typosquatted URL. In this case, the four things were a Solana wallet, BitTorrent DHT, the Google Calendar stuff -- which I think is fascinating -- and commercial VPS providers. Wide variety of things.

[00:11:00] Paul McCarty: This release, first and foremost, this is great. Glassworm was a very real problem and I’m super happy to see this, so nothing I’m saying is critical of this operation. I just wanna say, having been in this space for a long time, this release presents more questions than it does answers. There are so many things I wanna know.

[00:11:30] Paul McCarty: The first is this paragraph from the blog: “CrowdStrike also said there were multiple wallets on the Solana blockchain that were subject to a takeover.” However, they did respond to a question from IT News and said, “As a result, infected machines can no longer receive new instructions or payloads.” So basically Glassworm used the same technique that DPRK innovated on first.

[00:12:00] Jenn Gile: I did drop our article from a month ago -- the four arms of one monster. Multiple vendors detected different parts of the monster, and we realized it’s all one thing. So that’s available, I’ll drop it over on LinkedIn later.

[00:12:30] Paul McCarty: Yeah. Basically the way bad guys do this, whether it’s Glassworm or DPRK, is there are multiple stages inside the attack chain. In the middle stages, they want to use things like dead drops so they can change those. Because at the end, the final stage is typically served from an actual C2 service -- whether that’s an IP address or a domain -- and that doesn’t change a lot. So when you look at the whole attack chain, there’s a lot of innovation and change at the beginning -- at the shift left of the attack chain -- but not much at the end. For DPRK, there are typically five or six stages. There are two or three bash stages alone before you get to the final stages.

[00:13:00] Paul McCarty: Same thing was going on here with Glassworm, and so they used, in the second or third stage, these memo fields inside of blockchain addresses, specifically on Aptos, Ton, and then there’s a Binance component that I don’t really understand. The things that you put inside those addresses are immutable, but these little memos -- you can make transactions, basically spend a little bit of crypto to change these things, and so those things are mutable. The bad guys have used those as dead drops very successfully. They specifically say in the blog that they took those down, and they go into no detail. So I’m like, “How did you do this? This is magic.”

[00:13:45] Jenn Gile: They collaborated with someone.

[00:14:00] Paul McCarty: Obviously Google was involved, so the Google Calendar thing -- they can be managing that. But there are multiple questions here that I have, and I don’t know if we’re ever gonna get answers because they appear to be pretty quiet on this. And my friends at Google, I’m calling you out. You haven’t helped me out here, so what’s going on?

[00:14:30] Jenn Gile: Come on, dish. One thing that is almost a throwaway in the CrowdStrike blog -- and you kinda see it echoed in the PR that got picked up by other outlets -- is they talk about taking down a botnet, and they don’t actually explain what they mean by that. We have talked about a human botnet through a different campaign and a different threat actor. What do you think makes this a botnet? Or do you think it is?

[00:15:00] Paul McCarty: I don’t know. I’m gonna go into total speculation mode here. If I remember correctly, Glassworm was using the same kind of technique for force push code once they compromised a developer. They were using that technique for a while. I don’t know if that’s ongoing. Maybe they’re talking about that. So in that scenario, they’re basically talking about the botnet in the same way we are -- only we’re talking about DPRK and PolinRider, and they’re talking about Glassworm, which we’re assuming is Russian.

[00:15:30] Jenn Gile: Why don’t you give the botnet for dummies explanation? What does it mean?

[00:16:00] Paul McCarty: Okay. Over the years, with Contagious Interview and specifically with DPRK -- basically the idea is that developers are compromised via fake recruiter Contagious Interview campaigns, or the equivalent from Glassworm or somebody else. A developer now has malware running on their machine and/or ongoing access to their GitHub credentials or NPM credentials -- some kind of persistence is in place. Then, once they have persistence on hundreds or thousands of developers’ machines, they can go and do other stuff onwards from there.

[00:16:30] Paul McCarty: We’re seeing that with PolinRider. And actually, TeamPCP even did some of that in this second-to-last wave -- I got some juicy data out of that as well. But the idea is they have persistence, and they can do onwards bad stuff. For PolinRider, which is DPRK, what they’re doing is going and compromising additional repositories or forking things as that compromised user to get their code into popular open source projects. That’s the typical way they’re doing this.

[00:17:00] Jenn Gile: Kind of worm-like behavior, and I know there’s a big debate about whether Glassworm is really a worm. We’re not gonna get into that, but it’s worm-like.

[00:17:00] Paul McCarty: We need to make a distinction between worm and botnet. The reason that you and I call what PolinRider is doing a botnet is because they have control and persistence of the machines, and then they are manually going out and orchestrating things on all these different machines. Versus a worm, which is self-replicating and goes and finds things.

[00:17:45] Jenn Gile: Worth clearing up. Okay. I think we’ve exhausted what we know about the CrowdStrike thing, and everything else is speculation.

[00:18:00] Paul McCarty: I have so many questions.

MSRC Threatens a Security Researcher

[00:18:00] Jenn Gile: I know. The next thing on my list -- you popped this on me in the five minutes while we were prepping. There’s an X post about a nasty bit of finger-pointing going on that could be pretty damaging. Why don’t you explain it? I haven’t even read the post. I got the 30-second version from you.

[00:18:15] Paul McCarty: The internet is abuzz about this right now. Casey Ellis and Gossi the Dog and everybody else is talking about it. Here’s the backstory, a simplified version. A researcher known as Nightmare Eclipse had been working with MSRC -- the Microsoft security team -- on zero-days that Nightmare Eclipse had found, and there was some breakdown in communications. Honestly I don’t really know what happened there. But old mate Nightmare Eclipse decided to just drop them. And the problem is this happened at a contextual time when other researchers are just not working with bug bounty or security teams at all and just dropping stuff.

[00:19:00] Jenn Gile: Yeah, let me read what it says. Gabriel Landau, the researcher, reported a Device Guard bypass with a 90-day window. MSRC told him it met their bar and they’d fix it, and they asked him to hold off disclosure for extra months. He agreed on the condition they issue a CVE. They then patched it silently, decided after the fact it didn’t meet the bar -- air quotes -- and never issued the CVE. So in his words, they strung him along for a few months to keep him quiet and then broke their word. And then another researcher, rootsecdev, says he responsibly disclosed a legacy auth flaw that allowed password spraying while avoiding smart lockout. Five months later, same thing.

[00:20:00] Jenn Gile: Microsoft posted about it meaning to defend their coordinated disclosure policy, and instead it’s become a thread of researchers explaining why they stopped trusting Microsoft’s process. And honestly, that’s fair.

[00:20:30] Paul McCarty: Yeah. I think it’s less important what specifically happened with this case and more about what’s been brought on since then. A pattern. Which is that Microsoft has not acted in good faith with many researchers. Simultaneously, Microsoft has under-budgeted for its security teams -- I have a bunch of friends that just recently got laid off, had dinner with one of them last week. And from a GitHub and NPM perspective, it’s just a crap show. I deal with this all the time when I report malicious NPM packages and GitHub repos. They just take a long time to get back to us, and MSRC is doing the same thing over here.

[00:21:30] Paul McCarty: And the important thing here is that Microsoft’s response is just crappy. It basically equates the security researcher to having performed criminal activity. It says something along the lines of, “Our legal team is going to aggressively prosecute, blah blah blah.” And that’s just crappy because security researchers that disclose these things are under no legal obligation to do so. There are no rules about this, just to be clear. There are no laws about this. We’re doing you a favor.

[00:22:00] Paul McCarty: When I turn in a malicious NPM package or a malicious GitHub repo, I’m doing Microsoft a favor. I’m giving them free security help. To have them respond back in that way when they have systematically been underinvesting in this space and not dealing with researchers well -- it’s just a really bad look. And Kevin Beaumont, Gossi the Dog, brilliantly put this together saying, “Microsoft, this is gonna hurt you more than it’s gonna help you. You might wanna rethink this policy of coming out hard swinging. This is on you. We’re giving you free help, so don’t turn your back on that.”

[00:22:45] Jenn Gile: There’s a lot of narrative in the security industry right now about AI slop and bad bug bounty reports, and this is a clear example of that not being what’s happening. It’s one thing if you’re getting junk and you can’t wade through it, but these are, from all information available, legitimate reports that were received and acknowledged, and then the handling of them is poor.

[00:23:00] Paul McCarty: And then GitHub closed, shut down Nightmare Eclipse’s GitHub account.

[00:23:10] Jenn Gile: No.

[00:23:15] Paul McCarty: Yeah. Burned it all down. When they have a long, 20-year history of specifically allowing security researchers to post PoCs -- internally there was a lot of support for that. And here, because it specifically affects Microsoft, they shut it down. This whole free speech thing is kind of Elon Musky, right? Free speech until it affects me negatively and then, nah, no. Say what you want until I don’t like what you say.

[00:23:45] Paul McCarty: And then GitLab -- yo, I gotta call you out -- because Nightmare Eclipse went over to GitLab, took all their repos over to GitLab, and GitLab shut that down. I have heaps of friends at GitLab, and I’m very disappointed in the fact that you guys shut that down. That’s pretty crap.

GitHub as an Intelligence Collection Source

[00:24:00] Jenn Gile: Well, let’s end on, I don’t know about a high note, but a useful note. You and I did a collaboration with Feedly recently, and I’m pretty happy with how it turned out. I think it’s really useful. We wrote up a guide on how to use GitHub as a collection source. Where this idea came from was a workshop that you delivered -- several times -- at BSides and various places. It’s based on a technique that you use. Correct me if I’m wrong, this is the technique that you used to discover a lot of the PolinRider malware, right? So give us where this came from, and why should people be using this?

[00:25:00] Paul McCarty: Basically this is just my simple techniques to forward-hunt inside of GitHub looking for bad guys, and looking for the scale of DPRK and Glassworm and other stuff inside of GitHub. Ultimately it’s just a set of search patterns, strings, as well as a process around that. I did an all-day training on it -- GitHub, VS Code, NPM, and PyPI in one day, which was too much. I knew it was gonna be too much, but I got really caffeinated and I talked really fast.

[00:25:30] Jenn Gile: You were really excited, yeah.

[00:25:30] Paul McCarty: Yep. And at least one person has come to me and said that they’ve taken what I taught them in that class and now have built actual production forward hunting in their ecosystem, and they’re actually using that to find stuff. And I just think that’s amazing. So this Feedly one is kind of a condensed version of that. You did a lot of great work on this, Jenn -- taking my big expansive thing and making it much more easy to access and more to the point. I appreciate that.

[00:26:00] Jenn Gile: Anybody who listens to this podcast understands the difference between you and I, I think. I’m the cliff notes, and you’re the detailed version.

[00:26:00] Paul McCarty: You can wax prolific too. I’ve heard you do it lots of times.

[00:26:10] Jenn Gile: I can ramble. But yeah, I’ll make the offer -- if anybody wants the workshop, I think we’re open to delivering it elsewhere. Did you put it in for DEF CON or anything?

[00:26:30] Paul McCarty: No. I might do it for some of the villages though. Adversary Village, I might do it for that. I just gotta wrap it up in a specific way for each one of those.

[00:27:00] Jenn Gile: For anybody who’s putting in CFPs for the week of fun in the summer -- Adversary Village and AppSec Village are closing, I believe, May 31st. BSides Las Vegas is closed already, DEF CON’s closed already. So we should start hearing pretty soon what those schedules look like.

[00:27:30] Paul McCarty: The light bulb went off while you were talking -- I definitely put in this GitHub search thing, hunting in GitHub, for a four-hour workshop. I did one last year that was similar: red teaming the software supply chain, which was very successful at DEF CON. They’re four-hour workshops. I put in for the same thing. I haven’t heard back yet, so let’s cross our fingers that comes through.

[00:27:45] Jenn Gile: People keep asking me if we’re speaking and I’m like, “I don’t know.” But we’ll be there regardless.

[00:28:00] Paul McCarty: Oh, I got double rejection from Black Hat.

[00:28:05] Jenn Gile: Oh, bummer. Well, I guess I’m not surprised. It’s hard to get into Black Hat. And it feels like it’s getting harder. It’ll be interesting to see what is getting accepted. I don’t think it’s personal, Paul, but at the same time it sure feels like it, doesn’t it?

[00:28:25] Paul McCarty: Right? It really does.

[00:28:30] Jenn Gile: No, we’re not salty. Okay. We’re not salty at all. We’re at about 28 minutes or so, so I think this is a good time to wrap it up before we just start bagging on Black Hat. We’ll see you all in a week. Take care.

[00:28:45] Paul McCarty: See you guys. Thanks for listening. Appreciate it. Cheers.