Jenn Gile 0:01

Okay. It is Thursday, July 2nd. And uh I don't want to jinx us, but we're having another quiet week, and I'm I'm happy about.

Paul McCarty 0:13

Yeah, I mean, quiet week, it's all kind of relative. Like, has there been any kind of crazy team PCP slash you know DPRK Shy Hulud style attack? No. But I mean, NPM malware is at an all-time high.

Jenn Gile 0:29

So yeah, well, fair. Uh, I was talking to somebody back on Monday this week who wanted to know uh if I thought we'd seen the last of Team PCP, if they've retired. Uh I don't think so. Um, it's interesting that we haven't seen anything notable from them in a few weeks, but uh like let's not poke that there.

Paul McCarty 0:54

Well, I have a mini update. Well, let's hear it. I can't go into a ton of detail, but I think one of the main and I I've I'm on record as saying I did the Sans podcast last week. I'm on record saying team PCP is really just one person. Like exploiters and some of the other people, those are additional people, but team PCP is really just one person. Um and they might be in flight. We'll just leave it, we'll just leave it like that. Yeah, and by flight I mean fleeing. I think I think we're gonna have something important to talk about soon. Oh, um, actually, speaking of which, um gosh, I didn't put this on the agenda. I'm sorry, everybody, this is off script, but uh go for it. Uh the FBI posted a uh, you know, the cyber equivalent of their wanted poster 14 PCP today. So uh oh, I missed that. Yeah, sorry.

Jenn Gile 1:55

Uh share it.

Paul McCarty 1:57

Yeah, I'll find it right now and send it to you. I'm sorry.

Jenn Gile 2:01

Okay, well, while you're uh searching the internet, though I think I can probably find it pretty quickly as well.

Paul McCarty 2:07

I got it here.

Jenn Gile 2:08

Yeah. Uh let's come back to that. And uh the first topic on our agenda is something that both of us, I think, is good news. Um, GitHub released two changes last week. And I will say, like kind of quietly released. The only reason I knew that these had happened is because of other accounts that I follow. I haven't seen GitHub be very loud about it. Um, I will talk about them one at a time, kind of in the order that I found out about them. Uh, it's a slightly different order when they came out. But the first thing I learned about um is that NPM has added what they're calling preventative account protection for high impact accounts. And what that means is if uh one of these high-impact accounts changes the email address associated with the account, there is an automatic or uh sorry, changes the email address or uses a 2FA recovery code, the account is placed on an automatic 72-hour read-only hold and an alert gets sent to the previous email address. And um, what this does is this creates a mechanism when the maintainer gets locked out by a threat actor. Um, they the threat actor can't actually do anything with the account. So the things that they said in the announcement that they freeze are not an exhaustive list. They're saying that it's uh security-related things. Let me see if I can find the list. Uh publishing, managing tokens, changing package visibility, modifying org or team membership. Um, so all of that is frozen. So uh this only applies to what they call high-impact accounts, uh, which they don't define in this blog, but from what I've heard kind of through other channels, might be packages with uh more than a million downloads. So, you know, very popular accounts. And, you know, the the goal here again is to shut down one of the more common but not exclusive account takeover mechanisms. So this is going back to uh, I guess, the human path being exploited if somebody gets locked out. Uh, you know, for example, we saw a lot of those social engineering related attacks earlier and last year, where um the attacker would get a hold of um you know something related to the maintainer's account. For example, they might send them a phishing email or something like that. They would use that to gain access, change the email, get them locked out, etc. Um, there's also circumstances where the attackers have gained access through other means and choose to change the email as a delaying tactic so that the you know genuine maintainer doesn't know or can't do anything about an attack. Uh what it's not going to protect against is these other um, you know, more machine path type attacks. You know, if they can get into the pipeline, if they don't need to change the email address or you know, use a 2FA code in order to break into the account, then it's not gonna work. Uh yeah, Paul, what do you think?

Paul McCarty 5:28

I have I have a lot to say about this, but I'll try to I'll try to simplify. I think this is on the whole, I think this is slightly on the better side. Because I see, you know, I'm not that I'm negative or anything, but I tend to see, I look at a change like this and I think, okay, what is the benefit? Now let me think about what's what's the negative, how can this go bad? And you kind of touched on it there a second ago. What we've seen in many of these cases where a high-profile NPM maintainer has been compromised is they get locked out of their account, and then you have this kind of weird situation where they can't go make productive changes to the bad thing that has now been published by the threat actor. And I'm worried that a blunt instrument like this change will have more negative effect than it will positive, and that's not me just trying to be, you know, armchair quarterback, you know, throwing stuff at NPM. I think that this makes sense at face value, but when you really look at what happens after one of these big ATO style account takeover style compromises, one of the most damaging things that we've seen is when the account maintainer, the legitimate account maintainer, is locked out. Is this problem, is this change gonna make that worse? I hope not.

Jenn Gile 6:58

But maybe Yeah, I mean, I think it maybe depends on the order that the threat actors do things in. If they, for example, uh compromise the package before trying to change an email address, then I could certainly see um, like what you're talking about, it makes it more difficult for maintainers to potentially uh, you know, recover. So I think we'll see, right?

Paul McCarty 7:27

Yeah, and sorry, and one thing I missed there, which I meant to go into detail. So it says that this is going to be a 72-hour read-only state, and you can kind of, you know, forgive the pun, you can kind of read between the lines here and and see that they are effectively saying that this the maintainer will not be able to make any write changes. And this is where my concern comes from. If everything gets turned, does that mean they can't publish or remove? Can they not make write style changes?

Jenn Gile 7:56

Presumably, yeah. I would assume anything that's not read-only is therefore not uh achievable. So yeah, right.

Paul McCarty 8:05

I think I think then that really kind of opens this up to be, you know, more potentially, you know, cause more harm itself is an automated blood instrument. And we see that with NPM, whenever they do one of these kind of automated things, because you know, NPM doesn't have security staff anymore, because GitHub's security staff is is threadbare, um, you know, when one of these automated changes happens, a lot of times the technical people inside of the GitHub organization, you know, don't have time or they just can't fix it really quickly. And so then we have a problem where something that's malicious is still out there long at the time. The other thing I wanted to point out is that there is a secret flag. There is a secret flag in NPM. You cannot get it from the fire hose, you have to know how to go and look for it. But there is a secret flag that is applied to um these important maintainers. Um, and it's on a per, it's not a maintainer flag, it's a package flag. And so if you know where to look for it, you can find that, and then you know, and you can just basically just walk, you know, the whole fire hose and find all those flags for the specific packages, and that's your list right there.

Jenn Gile 9:13

Yeah. Well, time will tell. Uh okay, moving on to the second uh change that happened at GitHub. This one actually went through the day before the um high impact account 72-hour hold thing. And this one is self-service credential revocation for incident response circumstances. And uh I think there's a couple things to understand about what this is. First, it's only for GitHub enterprise owners, so uh not for anybody using GitHub, you have to be uh subscribing, and it gives you the ability to either um revoke a single individual's credentials, all of their creds, or uh across the entire organization. So it says you can revoke authorizations, delete tokens and SSH keys, uh, list and revoke SSO authorizations, and then individuals will have the ability under the GitHub Enterprise uh contract as well to review their own uh credential counts and self-service revoke or delete. And so I think we have a few things to say about this. One, uh, this is a great feature. This is absolutely necessary. We have seen so many examples in um the last year where organizations had a lingering credential somewhere that they didn't know about and didn't have a way to find out about. We're seeing vendors create products to address this problem. So uh no, no hold bar. This is a good thing. Uh asterisk, it's a little bit of a bummer that it's only for GitHub Enterprise. And uh, Paul, as we were preparing, you made a little bit of a comment of like, gosh, it's 2026. This is it's actually a little surprising that it's taken this long.

Paul McCarty 11:09

Uh it just it just proves that you can take the word enterprise and you can apply it to something, but that does not mean that it was built with the enterprise in mind. And GitHub Enterprise is the perfect example of that. This is a product that evolved out of standard GitHub, which was not, you know, it's not really built for an enterprise. So the fact that in 2026, July 2026, we are now finally getting the ability to do this. I mean, hey, this is a great, this is like one of the best things they've done like ever. This is one of the best kind of you know mitigation tools they've ever given us. So I'm happy for it. Not complaining about it, just wondering why did it take you this long to add something, you know, to something that's called enterprise. Now, here's the other thing I I want people to understand there's a very specific account boundary here that this only applies to credentials that are generated by somebody that's inside the envelope of your enterprise, working on an enterprise uh resource. So this does not bleed over into these people that you've given access to your enterprise that say, yeah, and here's here's the problem, Jen. You've given I've given you access to my GitHub enterprise, and you've got a bunch of personal stuff, and then you've got access to enterprise assets, right? You create a pat for some of your personal stuff, but it it applies to lots of stuff. I can't go and kill that pat for you, as far as I can tell, you know, and and we need more details here, and I'm sure people like you know, Francois and other people that spend more time looking at this will understand better. But as far as I can tell, just on the on what they've given us so far, you have a problem here where you know somebody's been compromised, uh, but you can only revoke assets that are specific to the enterprise itself. And so what does that mean in terms of them creating their own PATS, for example? I don't know.

Jenn Gile 13:06

Yeah, might need a little poking at that to really understand the edges.

unknown 13:10

Okay.

Paul McCarty 13:11

I don't know if I want to test I'd have to create and pay for an enterprise just to test this. I don't think I yeah.

Jenn Gile 13:16

Yeah, well, maybe uh if somebody else out there in the community plays around with it, let us know. Um next on our list, uh we have kind of a I don't want to say a weird situation that we ran across this week because it's not unusual, but it bears talking about because it is some uh not great behavior on behalf of an organization that can cause some harm. So that's the only setup I'm gonna give it. You've really been looking at this uh throughout the week. So why don't you talk us through what you found, what your concerns are about it, what the community should know about it.

Paul McCarty 14:02

Yeah, so just a little bit of background here. Um, last year I found um some sneak researchers um creating some malicious packages in the ecosystem. And Jen, I just dropped you the.

Jenn Gile 14:13

Yeah, I remember that. I will uh drop that link in the chat.

Paul McCarty 14:16

Yeah, and and listen, so basically what happened you know last year was that some researchers that work at Sneak created some malicious packages targeting Cursor, specifically three packages targeting cursor. Cursor was not a customer of Sneak. Um, and um, you know, I found them and called them out publicly, and their CTO and a bunch of people came on my LinkedIn page to you know tell me how it wasn't really a problem. But like everybody that looks at this, like my group of friends and you know, the the the signal researcher group, like it's a really bad look, right?

Jenn Gile 14:47

So yeah, I was at another vendor when that happened, and there was a lot said in the the vendor community as well as the customer community about their behavior.

Paul McCarty 14:57

And I I get where this comes from because having done bug bounty and and offensive research, sometimes you get this ability to do things where you're allowed to cross this kind of ethical and and legal line, right? But that's very rare, and so what you see now happening is you see certain researchers, you know, acting like they um get a little lull out of the uh the screen share, starting to distract you, but it got me.

SPEAKER_01 15:24

One of our LinkedIn users this is crazy shocking.

Paul McCarty 15:28

The only the only downside to live stuff coming up in the podcast is that I stop and look at it, but um, yes, very shocking, which was the comment. Um, yeah, so I mean, I you know, I the what we see is we see a new kind of generation of security researchers not understanding where that moral line, that moral and ethical line is. And so there's the moral and ethical line, right? Which is as researchers, we're not supposed to do any harm, right? So, for example, the the best example of this, and something I've been railing about for years, is when bug bounty researchers create their payloads inside of their you know, their POC NPM or Python packages or whatever the case may be. The kind of you know, the understood what they can ex-fill is typically like host name, public IP, you know, maybe system host name, something like that, um, maybe username at most. But that's it, right? Because what you're trying to do is you're trying to show to the the program team that, hey, you know, we ran this inside your organization, we got this data, we prove improv impact. So you have to be able to collect a little bit of information, right? But that's where it stops. But you still all the time see bug bounty researchers ex-filling all kinds of stuff. Like the most common thing they do is they just they gank every single environment variable that's running via ENV.

Jenn Gile 16:47

Well, we talked about this maybe a month ago with the Mwica campaign, which may fall further on the naughty side of that trend. But why don't you explain what you found this week?

Paul McCarty 16:59

Yeah, I think Jen's bringing me back on center. I just wanted to give that background there because I think it's important. Yeah, yeah, I know. Um, so what I found this week is six packages um published, um, and then they're not hiding their identity, published by a security researcher that's working for a new um cybersecurity startup that's in stealth. And basically, what those packages do is that they target OpenAI, Anthropic, Vercell, Olama, and a few others. Um, and they're info stealers. Um, now they're careful in those info stealers to not ex-fill credentials, which is good, but they exfil a bunch of information that that uh it's it goes beyond, it crosses a line. Basically, what they're they're ganking a lot of information, pulling stuff out of.git, dot ssh. So this is like this is sensitive stuff, even if it's not credentials. Um, and you know, it's pretty obvious that they're doing this, you know, to kind of build some research capability that they can then launch their startup on. But I just want to call it out, and we got a we got a blog post coming. I wanted to call it out because it's our job as security researchers to to find the bad things. And it's not our job as security researchers to become the bad guy. And I like I'm you know, come at me, bro. You can, you know, I'll be at DEF CON, come at me, and I'm happy to have a very lively conversation with you about this. But this is not good behavior, and we want to call it out, and we're gonna do that in our blog post.

Jenn Gile 18:25

All right, we will get that blog post up uh by the end of the week, I think, and we'll share the link out. Um, circling back to what we talked about at the top of the episode. I've got the uh FLAF is what it's called from the FBI about team PCP. Uh, what's been noted is it's a flash, and I'm sure that stands for something because it's all flash.

Paul McCarty 18:50

Um acronym.

Jenn Gile 18:53

Yeah, it's an acronym for something. Um it uh is in lieu of doing a traditional wanted poster, and I don't know the ins and outs of why they decide to do one versus the other. Uh so the warning here is this is a PDF. You know, do what you will with the PDF that comes through. Um, but it goes over uh you know who Team PCP is, the behavior that they've been doing, the IOCs that you can look for. So worth taking a look at. Um anything else you want to say on that?

Paul McCarty 19:25

Yeah, I mean, uh there's you know, there's some good uh indicators in there, but there's like we have a whole lot more in OSM. So if you want, you know, if you're somebody working in government or you know law enforcement and you want better data, indicator data, come and talk to us.

unknown 19:40

Yeah.

Paul McCarty 19:42

Weird plug, but nonetheless.

Jenn Gile 19:46

Um, okay, for next week, uh, we're excited. We're gonna have our first guest on the show. His name is Mikhail Barbaro. He's the head of security at the Eclipse Foundation, which uh maybe you haven't heard of them, but you probably have heard of OpenVSX, which is one of the projects that the Eclipse Foundation manages. I got to sit down with him this morning to talk about uh what we'll be discussing on the show. Uh he's very passionate about the foundation and making Open VSX uh secure. So I think it's going to be super interesting. Um, something that I learned today, and I wouldn't uh blame our audience for not knowing this either, but the reason for Open VSX really having a moment right now is actually because all of these AI IDE platforms, you know, they run on VS Code, but they don't use official VS Code extensions for various reasons. And so they have turned to OpenVSX. And so that's platforms like Cursor and Windsurf. And so Open VSX is really having a moment in a way that is uh potentially great for the ecosystem, but uh as all of these things go, it also is making it an attractive new target for um threat actors who want to exploit users of VS Code.

Paul McCarty 21:13

Yeah, I've got a little spiel here. Um I'm really excited to I'm really excited to have him on the podcast. I've been vaguely critical of of their organization in the past in terms of security practices. So I'm I'm you know, I'm oh I'm coming to this with open ears and open heart. And if I'm if I've been wrong about something, I'll definitely cop to it live on air. Um, but uh, you know, I'm excited to be to help them and be part of the solution. Um but um something I want to segue here is you know, these these uh registries are great because these registries do have the ability to kind of create some security choke points, which is awesome, which is why you should be using them. Because the reality is that anybody can go and download these VS Code extensions from a GitHub repo or anywhere else, right? They're just uh they're just they're basically just JavaScript, you know, proprietary zip format, that's all. Um, and uh what we're gonna start to see is we're gonna start to see the same thing happening in the VS Code ecosystem, VS Code extensions ecosystem that we're seeing now with NPM. Bad guys, let me be very clear. We're gonna talk about this more on next week's show or maybe the week after that, but in anticipation of V12, the the NPM package manager changes that are coming, which by the way, are this is gonna roll in not like thunder, but like a whimper because nobody's gonna upgrade. But anyhow, um that aside, I'm already seeing a shift in the deployment of malware in npm packages to these other kind of non-install script. And I'm seeing all kinds of unique ways. And I haven't even shared this yet with Jen this morning. I got up super early and went through a bunch of them. But we're gonna start to see the same thing kind of things happen in the VS Code ecosystems too. And that's why it's that much more important to use these platforms like OpenVSX, where they really are concerned about security and they want to do something about that. So that's important, and they can add that kind of that um that security layer for us.

Jenn Gile 23:07

Yeah, you know, some color I would love to add on top of that is uh something you and I have talked about before. You know, people ask us about how scanning happens for various different types of assets, and you know, you have NPM, you have PyPy, those are kind of like known locations for specific types of things. But then you have um, I guess things that don't meet the regular mold. Uh, you have AI skills and you have extensions where they can just live in any GitHub repository, and that makes it much more difficult uh for both defenders as well as you know organizations like us that are doing proactive scanning to find all of the skills and the extensions that are out there. These two things behave in very similar ways, you know, setting aside the fact that one's natural language and the other's code, um, you know, where they live, how they're used, they behave similarly. So um, plus one to what you just said about consuming them through a credible ecosystem. Um, what I learned about OpenVSX and what we'll talk about next week gives me hope that it's a good place uh to start, you know, feeling a bit more trustworthy about what you're consuming. But uh I guess even if you don't think it's perfect, it's better than just pulling it down off some random GitHub.

Paul McCarty 24:37

Yeah, and frankly, you know, based on some of the things you said that you guys talked about, I I feel more confident about about OpenVSX than I do about the official VS Code marketplace. So there's that.

Jenn Gile 24:49

Yeah, it should be interesting. I'm really looking forward to the conversation next week.

Paul McCarty 24:53

I wish I could be there live for that part of the conversation, but I'm not getting up at 1 a.m. So I'm sorry I won't be.

Jenn Gile 24:58

But yeah. Uh you know, this whole thing where uh we're more connected because of technology also doesn't change the fact that the earth is round and um you and I are on very different parts of it.

Paul McCarty 25:13

Right. And and humans need as much as my body tries to pretend like that's another case, humans need sleep.

SPEAKER_01 25:19

Humans need sleep, yes.

Jenn Gile 25:21

Okay, we're at about uh 25 minutes so far. I think we've exhausted this week's agenda. Did you have anything you wanted to talk about before we wrap?

Paul McCarty 25:30

No, I I I could go like no, we'll we'll save it for next week when it's a little bit more structured. I do want to get into these kind of these new ways that bad guys because I've I've got a bunch of screenshots to share with you and stuff like that too as well. So I think it's just watching people be creative, in this case, bad guys, but watching bad guys be creative is really fascinating. It's one of the things I love about my job.

Jenn Gile 25:50

Yeah, always saying new things. We may not like the things we see, but it is if if nothing else, it is interesting.

Paul McCarty 25:59

Right.

Jenn Gile 26:00

All right, everyone, have a great week. We'll see you next week.

Paul McCarty 26:04

Thanks for listening, people. I appreciate it.