BLOG

The OpenSourceMalware Show #4

RubyGems bot attack, ShinyHunters ransom Canvas, and the latest on Mini Shai-Hulud.

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

The OpenSourceMalware Show #4

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

In this episode we covered:

RubyGems bot attack: Hundreds of bots pushed 500-plus packages to RubyGems, some carrying exploits, forcing the registry to shut down new account signups. Jenn and Paul break down why the DDoS label may be misleading and what this exposes about the friction-vs-safety tradeoff every open source registry faces.

Canvas ransomware by ShinyHunters: ShinyHunters breached Instructure, the company behind the Canvas LMS used by over 30 million students globally, stealing 3.65TB of data including private messages between students and teachers. Instructure said almost nothing publicly for days. Jenn and Paul discuss the data sensitivity risks for minors and close with breaking news: Instructure paid the ransom.

Mini Shai-Hulud and TanStack: Team PCP is not connected to the original 2025 Shai-Hulud campaign. Paul explains how they used Adnan Khan’s GitHub Actions cache poisoning technique to compromise TanStack and 90-plus packages without long-lived credentials, why attestation and trusted publishing didn’t stop it, what the CIS country geofencing in the payload actually signals, how malware is now targeting .claude directories on developer machines, why novel malware still dominates the OpenSourceMalware database by volume, and why open sourcing their worm and doing press interviews is likely to hasten Team PCP’s capture.

Episode Resources

[00:00:00] Jenn Gile: Hello, Paul. It is May 13th on my part of the planet, May 14th for you. We’re recording a day earlier than normal because we’ve got stuff going on this week. We have a busy schedule, so we’ll air this at our normal time, but to anybody listening or watching, we’re talking to you from the past.

[00:00:10] Paul McCarty: Or the future, depending on where you’re listening to this.

[00:00:14] Jenn Gile: True. Big week behind us. We’ve got three distinct things we want to talk about, and they give us heartburn across the board. A mutual friend of ours posted recently online about how there’s a lot of bad going on in tech right now and what people are doing to manage it. My response was similar to what I saw from a lot of other people: yeah, there’s a lot of not-fun things happening in the cybersecurity world right now. We all gotta do what we can in our little corners. The thing that keeps me motivated and positive is I talk to people every day who are committed to making it better. Find your tribe. Take a step back from the computer. Paul, what do you do when you’re starting to feel a little overwhelmed?

[00:01:45] Paul McCarty: Last night I was stressed. This has been a tough week. My six-year-old came to me and said, “Hey Dad, do you wanna play some chest?” I said, “Do you mean chess?” They said, “Yes.” And I said, “Yes, let’s play.” We had an hour-and-a-half game because they are still learning. I was at my most stressed with these Melbourne BSides presentations to get done, and it was just the perfect thing to take me out of the zone.

RubyGems Bot Attack

[00:02:30] Jenn Gile: Let’s get back in the zone and start with RubyGems. Yesterday, RubyGems had to disable the ability to sign up for a new account after hundreds of bots tried to push packages. We’ll share the links in the show notes. RubyGems initially called it a DDoS attack. I’m not sure that framing is useful. It may or may not have actually been a DDoS attack, but the net outcome was they were overwhelmed with around 500 packages, some of which contained malicious code. Paul, what do you think?

[00:03:00] Paul McCarty: RubyGems is not a large registry, but it’s not a small one either. 500 packages to me doesn’t sound like a lot. npm sees 500 malicious packages a day minimum. It’s still a bit cloudy what’s going on here. The DDoS label might come from some of these packages doing things that DDoSed other services. I’ve seen some data that supports this, but I haven’t verified it. Then you have this problem about trust, safety, and onboarding. All of the platforms face this. GitHub, GitLab, npm, PyPI, RubyGems all want to make joining as easy as possible, but if you don’t have CAPTCHAs and similar controls, bots can join. Last time I made a RubyGems account, it was pretty easy.

[00:03:45] Jenn Gile: Most of the ecosystem was created to reduce friction. Developers don’t like friction. Marketing and sales people don’t like friction. Security people would like some friction. Tough balance.

Ransomware Attack on Canvas (Instructure)

[00:04:05] Jenn Gile: Moving on from RubyGems. Something happened literally right after we closed out last week’s live stream: we found out about a ransomware attack on Canvas. Anybody with a kid or who has been in school has probably heard of it. It’s used as an online learning platform for schools, and this is an incredibly broad impact attack. Fortunately my son’s school district doesn’t seem to use Canvas, so as far as we know we’re not personally affected. But Paul, what I heard from you immediately was: you guys are.

[00:04:55] Paul McCarty: Yeah, we are. This hits very close to home, literally. My kids’ school uses this platform. Canvas is an LMS, a learning management system, owned by a company in Salt Lake City called Instructure. Instructure has around 2,014 employees and about eight security people. That’s a pretty poor security-to-employee ratio, and I’m pointing that out. One of the other frustrations I’ve had is that there’s just no data about what happened. That frustration is aimed at the school, at the Department of Education locally, at government officials, and at Instructure itself. None of them are talking about what’s happening. Meanwhile, data is sitting in the bad guys’ hands. This is Shiny Hunters, by the way. They keep threatening to release it and have pushed back the dates a couple of times because I think they believe somebody’s going to pay them.

[00:06:00] Jenn Gile: The impact here can be really terrible. This is access to potentially messages between students and other people. You can start to paint a picture of who the trusted adults are in a kid’s life. My background before working in tech was with the US government in passports, and this type of data could potentially make it easier to steal a child’s identity. If you know enough about that child, you could start trying to obtain legal documentation in that kid’s name. There’s a lot this data can be used to do that’s harmful to children and harmful to schools.

[00:07:10] Paul McCarty: I guarantee there’s going to be a class action lawsuit in the US if not other places. Part of this has to do with the fact that there’s a lot of data around people in protective services, with significant legal protections around that. This is going to get really gnarly really quickly.

Mini Shai-Hulud and TeamPCP

[00:07:40] Jenn Gile: Let’s move on to our third and biggest topic: Mini Shai-Hulud. There’s been some statements and speculation about the connection between Mini Shai-Hulud and the original Shai-Hulud campaign in 2025. Nobody we’re connected with has a firm grip on who was behind the 2025 campaign. But we have some evidence around why we don’t think it was Team PCP. They love the spotlight. They love to take credit. They love to brag. And we saw none of that last year with Shai-Hulud. Those two things combined make it unlikely they’re connected. Why did they choose to name their campaign Mini Shai-Hulud? We don’t know. My theory is it gets more clicks with a familiar name. People will remember: Shai-Hulud was awful, that was a bad experience for me and for the industry.

[00:09:00] Paul McCarty: Team PCP has admitted that Mini Shai-Hulud is theirs. They’ve been very upfront about that. They’ve also never claimed to be the original threat actors. There was an interview that Jenn and I were looking at before this where one of the Team PCP leaders was talking about some of their TTPs. They pivoted really dramatically in early 2026, and I think people have forgotten that. This was not in their wheelhouse beforehand. It’s something new, and they’re progressing really quickly. In this interview, the person being interviewed admits that they’re being mentored by somebody else with more specific knowledge around GitHub Actions and cache poisoning. The cache-poisoning-to-package-ecosystem workflow they’ve developed is very successful. Attribution by certain researchers to the original Shai-Hulud? There’s no evidence to support it. This latest campaign is Team PCP copying other methodologies and TTPs.

TanStack Compromise and the Wave of GitHub Actions Exploits

[00:11:30] Jenn Gile: To rewind the clock a little bit: Mini Shai-Hulud launched around April 30th. We saw them compromise four SAP packages, something we talked about a couple of weeks ago on the show. It was successful but not enormously so. Then it was quiet for a week or ten days. We took a breath and talked about other things. Then they compromised TanStack. The TanStack compromise is different from what they did with those SAP packages and different from what they did back in March with Trivy, Aqua, and LiteLLM. The TanStack compromise has been very successful for them. It’s an npm worm and it has compromised around 90-plus packages, either directly through TanStack or through other account takeovers.

[00:12:45] Jenn Gile: Some people are calling this wave six. I don’t know that that label is helpful. Let’s call it the mid-May attack. The way they got into TanStack was through a GitHub Actions vulnerability, and this is maybe the third time we’ve seen this technique in a major account takeover attack this spring. They’re evolving and learning how to be more effective at getting into a maintainer’s account. We saw a lot of social engineering last year. This year is trending more toward exploiting an existing vulnerability to get a token.

[00:13:20] Paul McCarty: It’s evolved quickly and it’s pretty technical. This is all based on Adnan Khan’s 2024 cache poisoning technique. He and Ronnie Carter drop new research on this every year. I saw them at DEF CON last year, and they’ll do it again this year. Without getting too deep into the details, the technique lets you create a commit and a PR that automatically kicks off certain Actions. The PR doesn’t have to be accepted. You create the PR, and then these Actions take place using a unique cache poisoning trick.

[00:14:15] Paul McCarty: What’s special about this one is that it didn’t use long-lived credentials. It didn’t take advantage of PATs. It uses OIDC, the way you’re supposed to do it. That guarantees a pipeline from the GitHub repository to the artifact it generates. But if a bad guy gets into the process, which is what happened here, that attestation doesn’t save you. I hear a lot of people focusing on attestation as a singular solution that fixes everything, and that’s just not the case.

[00:15:20] Jenn Gile: There’s been a bit of conflation between account takeovers and the rest of the body of malicious open source out there. A lot of the tips people are talking about, version pinning and cool-down periods, yes, you should do them. And they’re not going to protect you against 100% of the malicious open source out there. If you think about these protections as a Venn diagram with 20 circles and all the malware in the middle, each protection is only touching an edge of that body of malware. I’ve been looking at data from OpenSourceMalware on the packages added to the database in the last three months. It continues to be overwhelmingly novel malware, not account takeovers. Account takeovers are absolutely escalating, and most of what we’re seeing is Team PCP. Lazarus Group continues to stay more focused on Contagious Interview-style attacks targeting individual developers, whereas Team PCP is going the account takeover route and getting a lot of attention for it.

Novel Malware vs. Account Takeovers

[00:17:45] Paul McCarty: Meanwhile you have thousands of individual attackers coming at your walls 24/7, 365. If they find a hole, they are just as dangerous for your organization as the big attacks. This morning I saw nine packages from one npm account that are still up. In the package.json, they pull a Python payload very similar to the Team PCP infostealer. The names are things like “ethers-address,” simplistic packages around the Ethers crypto ecosystem, and you know those are going to match the names of some people’s internal packages. The bad guy has already unpublished some of these packages, which means npm isn’t taking them off and you can’t get download stats on them. This is what’s happening constantly. They only have to be successful for two or three crypto organizations to steal the money. DPRK stole $2 billion last year without doing big high-profile account takeovers. Team PCP is not going to come close to that with all their splashy attacks. We have to put that into context.

Attack Evolution: Transitive Dependencies, VS Code Tasks, and .Claude Files

[00:19:45] Jenn Gile: Before we come back to Team PCP, I want to talk briefly about the evolutions we’re seeing. Defenders get better and threat actors shift. With an account takeover, the main package they take over may not actually have the malware in it. That’s what we saw with Axios. The malware is in a transitive dependency. We’re going to be seeing that more, and it’s going to be harder to catch because you’re less likely to be scanning the transitive dependencies called by your primary dependencies.

[00:20:20] Paul McCarty: The VS Code tasks file is still being used by everyone now. Microsoft made a big deal of fixing the auto-execute behavior and turning it off by default, but a lot of people download the new version and then immediately turn it back on. Or they upgrade from an existing config that already has it enabled, and it stays on as soon as they open VS Code. It’s so successful that every threat actor group is using it now. And the .claude files thing: packages are now dropping files into the hidden .claude directory on developer machines. Nobody was doing this two months ago.

[00:21:30] Jenn Gile: This is moving incredibly fast. This is why data sharing within trust groups is so important. There’s no way to keep up if you’re not collecting intelligence together.

Geofencing and CIS Countries: A Tell or a Vibe-Coded Artifact?

[00:21:50] Jenn Gile: Let’s go back to Team PCP. Geofencing has come up as something people think is significant with the latest attack. Paul disagrees. Lay it on us.

[00:22:00] Paul McCarty: In the interview I mentioned earlier, the Team PCP member was asked whether they had put in geofencing for CIS countries, the Russian-aligned group of nations: Russia, Belarus, Azerbaijan, and others. This is common tradecraft in Russian malware: it checks to see if the locale, location, and environment are set for those regions. We saw this with the Glassworm campaign back in February, which we loosely attribute to Russian actors based partly on this geofencing. A lot of people saw the geofencing in Mini Shai-Hulud, and the Team PCP member said, “We’re a big crew and some of our people live in those places.” They’re not a big crew. I immediately smelled it. That claim isn’t true.

[00:23:10] Paul McCarty: My theory, and one of my friends posted something similar, is that they’re going to Claude or whatever agent they’re using and saying “build me malware, don’t make any mistakes,” and the CIS exclusion is being pulled in as a best practice. The model is assuming: if you operate anywhere close to Russia, just put this in by definition. It may just be the AI making a regional assumption. That said, in the interview they explicitly claimed they put it in themselves, so the truth is unclear.

[00:23:45] Jenn Gile: There’s also evidence of two things happening with Team PCP at once. One, they’re clearly using AI. They say so themselves. And two, they’re being mentored. Those two things coming together help them move faster, and sometimes you end up with tells through AI that don’t actually mean what you think they mean.

[00:24:10] Paul McCarty: All vibe coding, whether it’s legitimate vibe coding or malicious vibe hacking, means you’re building on your laptop and pushing directly to production. You miss the staging checks that a typical CI process would catch. That’s why we’re seeing payloads that don’t execute correctly because someone made a typo somewhere. They should be doing PR review for their own malware. They’re probably using Claude for that too, which: please do not put Claude in your CI pipeline. There are active attacks targeting Claude in CI.

Team PCP Open Sources Their Worm

[00:25:40] Jenn Gile: The place we want to wrap up on Team PCP is around them open sourcing their worm and the observations we have from the interview. These people like attention. Open sourcing the worm is an attention-grabbing mechanism, but it will also make attribution more difficult in the future.

[00:26:00] Paul McCarty: This chasing clout has got them done. They were asked in the interview, “Are you worried about getting caught?” and they said something like “This could be a life-changing event or a life-ending event.” I don’t think it’s really computed for them. They’re pretty young and probably very bad things have never happened to them. The reality is that by open sourcing the worm, every OSINT forensic detective in the world is going to be looking at that source code and finding tells. Things like the .gitignore file, macOS-specific artifacts, all kinds of little details. The two GitHub repos they use to push these compromised repos: GitHub and everybody else has telemetry they’re looking at. Every time you put one of these things out there, every time you do one of these interviews and then say “yeah, I put out false intel all the time” after presenting on that same interview, that is its own tell. Team PCP: what you’re doing is wrong and illegal, and you are hastening your capture. Prison sucks regardless of what country you’re in, and that’s in your future.

What the Industry Needs to Do

[00:28:45] Jenn Gile: Looking at the data: something like 75 to 78% of the packages added to the database in the last quarter have no attribution. It’s a small percentage that we know definitively where the malware is coming from. The SCMs, the infrastructure providers, the AI model providers: what needs to happen?

[00:29:30] Paul McCarty: In this era of vibe coding, we need to double down on earlier principles. It’s kind of ironic that part of the solution is falling back to 1990s and early 2000s concepts: isolation, DMZs, separation, networking controls. These foundational things actually provide meaningful protection now. Make sure you’re checking packages, GitHub repos, and other components against a threat feed at every stage of CI. And make sure you’re actually using CI. Vibe coding naturally doesn’t work well with CI. Platforms like Lovable aren’t built to work with genuine CI pipelines. Creating a secondary database for test and staging is difficult on these platforms, so people just don’t do it. We have to fall back to these foundational controls, because they have real power now.

[00:31:40] Jenn Gile: Hope everyone has a good week. Oh, one last thing.

[00:31:45] Paul McCarty: I just got the notice that Instructure paid the ransom. ShinyHunters has removed the data and it’s not going to get out there. Government, Australian government, Instructure: you can continue to pretend like you can keep this undercover. The class action lawsuit is coming.

[00:32:05] Jenn Gile: And on that note, mic drop. We’re out.

[00:32:10] Paul McCarty: Bam.

[00:32:12] Jenn Gile: Boom. All right. Later.

[00:32:14] Paul McCarty: See ya. Take care.