Jenn Gile 0:01

Hello. Uh it is Wednesday, July 15th. Paul and I are recording a day early. So hello from the past. Paul, what you got going on?

Paul McCarty 0:13

I'm in the future right now for you. So like how does it be a good idea? I don't know where the timeline is, right? I don't know where in the multiverse I sit right now. But um yeah, things are good. It's very windy here. We got a week's worth of rain coming at us, but luckily the Southern Hemisphere headquarters is about to open for open source mailware. So I'm very excited about that.

Jenn Gile 0:35

Yeah, that's gonna be great. Um, we have a full list of things uh to talk about today. Let's do a quick hit. It's at the end of the list, but I'm gonna pop it up to the beginning. Besides Adelaide is coming up. Tell everyone what's going on there.

Paul McCarty 0:51

Yeah, so that's not uh next week, it's the week after that. So it's Monday and Tuesday. It's a weird day, but it is what it is.

Jenn Gile 0:58

Um July 27th.

Paul McCarty 1:01

Yes, ma'am. Yeah, it's two days. It's 27th, 28th, but I'm talking, I'm speaking on the 27th. I'll be there both days. I really like this event. I didn't go last year, but I went the year before that. Um, and the cool thing about this Adelaide is that this is this is where a lot of the defense sector in Australia is for whatever reason, for historical reasons. There's like this large kind of defense ASD.

Jenn Gile 1:22

Not in Canberra.

Paul McCarty 1:24

Oh, I mean, it's absolutely there, but from a private sector perspective, a lot of it is in Adelaide, maybe because it's a port. I don't know. Who knows? I don't know what the history is, but it's there, and so it has a very different flair from other B sides. It's definitely very government. I mean, it's got the community aspect for sure, but it's got a different flair, which is one of the reasons I like it. Varied.

Jenn Gile 1:46

Yeah, that's a reason in general I love the B-Sides conference, is you get like a flavor of the local community. It's different every B sides that you go to. Okay, let's hit the news. So yesterday I was winding on my day and I saw GitHub made an announcement about Dependabot. And for anyone who's not familiar with Dependabot, it is GitHub's open source SCA tool. They even actually don't call it an SCA tool, but essentially that's what it is is it does code scanning um for your dependencies that are in GitHub and um can do like auto upgrades for you. And that is relevant because the announcement that they made is about cooldown periods, which we've talked about quite a lot uh in the last year in the community. And so what GitHub has done with Dependabot is they have flipped the switch so that cooldown periods are automatically on for all packages for uh a period of three days. Now, there's some caveats there. If you have a security upgrade, it'll override that. But um they have changed a default. And I think this is an interesting choice on their part. And I'm a little like on two sides of the fence about it. And I'll tell you why I'm a little like torn. And I want to hear what you have to say, Paul. Um, so the good is cooldown periods in general are good. You know, consuming something immediately after it's published dramatically increases your chance of uh consuming an account takeover piece of malware. Not that all malware is ATOs, but almost all ATOs are taken down pretty quickly these days. Um, and so a three-day cooldown is certainly going to make a big difference there. Um, on the con side, the people who will encounter this in production probably won't understand why this has been turned on. And so you're gonna have a lot of developers perhaps wondering why they are being blocked by dependabot from upgrading to latest. And so I think on the con side, that may push some conversations for security teams or whoever owns Dependabot in a company to kind of explain why this policy has gone into effect. And um, I don't know, it it I think will net be good, but it could create some chaos or strife for people in security, and I never like to see that.

Paul McCarty 4:24

Yeah, um, I agree. I mean, I think that there's you know, there's arguments on either side of this whole cool down thing, and we've talked about this before, so I won't belabor that, but uh, I think the other thing about Dependabot is that nobody serious uses Dependabot, right?

Jenn Gile 4:38

Uh I'm let me just I wasn't gonna say it.

Paul McCarty 4:42

That's my job here. I know the alt the alternate name for this podcast is the the spicy sp podcast, but um spicy cyber podcast. Um I do have that uh URL. Um listen, the the reality is that you know uh the only people that have Dependent Pot turned on are small teams and you know people at the beginning of their journeys because it's just a noise generator. It creates if you know a lot of people turn it on to create PRs and it creates PRs and then people just you know cancel them, right? And then they just have and so it's just it's a noise generator. And so I think that the conversation around the complexity around conversation with cooldowns is a more nuanced conversation, and the people that are using Dependabot probably by and large aren't gonna understand the nuance for why there's this balance between you know ingesting something as quickly as possible to address vulnerability risk while trying not to ingest it within the first day to keep yourself away from account takeover risk. So malicious package account takeover risk. Yeah, that's well put.

Jenn Gile 5:48

I mean, if you troll the Reddit archives, you're going to see 99% of them are people just absolutely trashing on Dependabot. And sometimes it's for fair reasons. Um, most of the time it's for fair reasons. So yeah, I don't know. I know a lot of people use it. Uh, it's not only small shops. I've talked to lots of people at bigger shops. It's usually about budget because it's free. Um, but you know, there's that old saying, like a puppy.

Paul McCarty 6:17

You're not, you're not, yeah. I mean, you're not really disagreeing. Maybe the small shop thing you're disagreeing, but aside from that, you're not really disagreeing with no, I'm not disagreeing with you at all. Nobody that has maturity in this space uses this as an SCA product, right? It's a it's a it's a box ticking thing at best if you're a large organization.

Jenn Gile 6:33

Yeah, it's usually something people choose to rip out when they get more mature, but uh a lot of people are using it. So yeah, it should be interesting. Okay, let's talk about two compromises that happened in the last four days or so. They're totally unrelated. Uh, the shape of them is totally unrelated, so we're going to talk about them separately. The first of those compromises is JScrambler. Uh, it came through on July 11th. And uh this came through in kind of like three steps. Uh, they published a whole bunch of malicious versions of the main Jscrambler project. We don't quite know how the threat actor got access. Um, it was made possible through an NPM publishing credential, but we don't know if that was a stolen credential. We don't know if it came through a GitHub Actions exploit. We just know the threat actors had access to a cred. Um, they started off by publishing three malicious versions that shipped a pre-install hook. So kind of that classic NPM lifecycle script auto install your malware feature. And then they published two additional versions where they moved the trigger. So um versions 8.18.0 and 8.20.0. And then they published four related J Scrambler packages that pinned to that 8.18.0 version. So some very like interesting series of things that the threat actors did here. Uh, Paul, you did a deep dive on the malware because um I was looking at our threat reports and I said, hey, it looks like uh 8.18 is malicious. It had been reported by another uh researcher and it hasn't been taken down. Let's double check, you know, is this a false positive on their part or did J Scrambler miss something? So, Paul, you dove in. What did you find?

Paul McCarty 8:33

Yeah, I mean, I think the when you pinged me about that, I was going systematically through each version and verifying, you know, which versions had it and which versions didn't. And I really quickly saw that 8.18 and 8.20 still had the payload, but didn't have the um pre-install and the setup.js files that the earlier versions of it were using to trigger it on install, right? Um, so yeah, I mean the the um you know I looked at so many different malware strains since then. It all kind of it's in the blog, it's in the blog posts. Um it's in the blog post. Uh, but I think the thing that's really interesting about this one is that uh, you know, the original post from um a researcher, and I I don't actually know this researcher that well, but specifically called out 8.18. And I think what happened is I think somebody at the J Scrambler team, you know, grepped for the existence of the pre-install stuff, didn't see it, and then just skipped 8.18 and 8.20, and then went back and got 8.20 out. Anyhow, three and a half three and a half days later, I ping on my GitHub issue. I'm like, hey, 8.18 is still an NPM. What's going on here? And we got a really terse, classically Euro response back to us saying um basically it's been deprecated. Didn't say, oh, you know, thank you. You know, I've now deprecated it because of what you said. You know, it was just like so, and also too, reading, I'm looking at the the incident the incident response blog post that they posted, which they did a really good job of from a timestamp and a kind of incident response perspective. This is a really good, and I wish I saw more of this. And because they have a background in in code integrity, I think that's where this is coming from. But what I don't see is I don't see ownership and explanation of how this got into the J Scrambler um organization. Um, and that's concerning for somebody that you know is is building a code integrity platform, a paid commercial code integrity platform.

Jenn Gile 10:39

Yeah, and uh something that was observed by one of the researchers in the GitHub issue was uh Jscrambler had initially started deprecating before the threat actor was done publishing all the versions. And uh, you know, the hypothesis here is Jscrambler didn't rotate credentials well enough, missed something in this series because they came out and they published uh what they said was a safe version that was lower than what the final safe version was. I think it was like 8.15 or something was a safe version.

Paul McCarty 11:18

It was, yeah.

Jenn Gile 11:19

And um, yeah, the other researcher came back and said, Hey, you you did not rotate this correctly. There's still publishing. And so there's clearly some things missed there. Um again, I know uh we don't love seeing these ever, um, but the IR part is only part of it. Understanding kind of the post-incident, how did this happen is important to the community. Would have been great to see that.

Paul McCarty 11:48

Yeah, and just you know, like it's just take take a little bit more responsibility for it, right? Like the and listen, having been in this situation, I just want to double-click on something you said there. Having been in this situation before where you have a credential has been stolen and you're trying to do incident response at the same time, it's very common for this kind of these things to overlap where you're getting rid of stuff and they're pushing new stuff. So that's not surprising, yeah. Um, and the fact that they didn't rotate creds correctly right away, because they did have a very, very quick response to this to their credit.

Jenn Gile 12:22

From reading between the lines of their incident response, I think they actually had detected it before the community reported it. There was something that was anomalous behavior that they were able to identify. So they were on it very quickly.

Paul McCarty 12:36

Somebody saw a notification. I can't remember if it was in a slack channel or if it was an email, but somebody saw a Slack notification. They're like, oh, that doesn't look right. And so they they saw it almost immediately via that. Which is one of the reasons that you want to have those, you know, those notifications, those async notifications turned on. And a lot of people don't because they think that you know whatever ASPM tool they've got inside the CI is enough. No, turn those notifications on, have them sent to because at the very least, when you're doing instant response, you can go back and you can look at the timestamp for each one of those things. That's important.

Jenn Gile 13:05

Yeah, well, that's the same situation that happened with NX a couple months ago. That's how they figured out that a threat actor had gotten access is those notifications. So uh embrace a little bit of noise. Okay, let's talk about it.

Paul McCarty 13:18

Let's talk about the other one.

Jenn Gile 13:20

Async API. Um again, not related. Uh what we do know about this one is attackers gained access through a disclosed GitHub Actions vulnerability. Uh, not only was this a known vulnerability, but async API was aware of this vulnerability. It was, you know, there was a PR open for something like 58 days to resolve it. Oops. Um, so a threat actor came in and was able to take advantage of that vulnerability to gain access. Uh again, this is not a situation of a stolen uh credential. They were able to gain access through a vulnerability. So, you know, we've talked a lot about tokens uh expiring and email and things like that. None of that would have helped in this situation because of the existence of this bull. So they pushed some malware that um has some markers from miasma, and we'll talk a little bit about how it is and is not the same as the other miasma that's been out there. And um something that's I think worth noting because people are always curious about who's behind these. We have a potential indicator, and that is that it monitors for Russian language, and if it finds it, it exits. As we know, that's not a guarantee that it's you know there for a Russian actor. It could just be somebody vibe coded something and that got pulled over. Um, but yeah, Paul, um, you've taken a look at the payload. You know, it's not a worm, but it is miasma. So let's talk maybe a bit about how we've seen miasma evolving since it was released, what, in late May, I think is when that uh uh worm got open sourced, or maybe it was June, but yeah, not that long.

Paul McCarty 15:16

No, it hasn't been it hasn't been that long. Yeah, I mean this is a classic pwn request. Um it uses you know pull request um target, pull underscore target, but sorry, pull underscore request underscore target. You and I both know somebody that's been behind the scenes sending out disclosures to people and might or might not have sent one to this team team. I it's just you know, and uh and and by the way, something you you forgot to mention, or didn't sorry, you didn't forget, but they got done the same team got done in Shy Halud 2.0.

Jenn Gile 15:49

Yes, and indicators is that it's not a related attack.

Paul McCarty 15:56

Correct.

Jenn Gile 15:57

You never know for sure, but yeah, they could have just been incredibly unlucky this year.

Paul McCarty 16:02

Yeah, but I mean that there's a thread, pwn requests, you know, there's a thread of pwn requests through all of these, right? And so if you get done in 2025 via GitHub Actions, um, you know, you would think that you would replace these or or refactor all these GitHub, these workflows, but you know, obviously that's not you know the case. Uh but getting to your other observation about is this miasma or not, I think this is mostly like a um like it's a it's a moot point. It's like you know, because the as you and I were talking before we started rolling, the miasma now that word has evolved because as soon as they open sourced it, it changed it from being like what is the TTP specific to the first miasma attack, which was worm, to now they've open sourced it and it's become this other thing, right? And that's not that's not me making some decision, that's just culture and language and the freeform nature of it. So I saw somebody being persnickety about this isn't there, this isn't a variant or whatever. And I like there's I I just don't think that's an argument worth having, right? Is this derived from the Miasma open source code? Yes, absolutely. I don't think anybody disagrees with that. Do they make significant changes to it? Yes, and happy to talk about those.

Jenn Gile 17:17

I'm curious, and I know this is not a definitive thing you would know, but why do you think they might have decided to remove the worm component? Because, you know, in the malware game, the more people you can hit, the more stuff you can potentially get. Now, certainly, as I'm asking you this question, I'm gonna partially answer it, and then I want to hear your thought. But uh, you know, it being worm-like certainly will make more people find it potentially, and so you might get caught sooner. But what do you think? Why do you think they removed the worm?

Paul McCarty 17:51

You know, obviously I don't have any specific thinking. Um uh, but you know, it just in general, I think that we we I think we attribute way too much brilliance to these authors and these threat actors, and I think they just took something that was open sourced and they modified it and got it working. And maybe they ripped out the NPM, the worm stuff because that just complicated it. Who knows, right? And the CIS stuff might have been added by Claude because it's done in the past. Team PCP added, you know, a CIS check to theirs, and then somebody asked them, you know, do you have anybody in in the CIS? And they made up some bullpucky answer about you see I didn't cuss there, bullpucky answer about um oh well, you know, we have team members all over the world. Not true. Um, uh, you know, so anyhow, the CIS part could just be there because you know the agent suggested because yeah, oh somewhere else, all malware looks for CIS countries. You're writing malware here, let me help you. Here's the section does a CIS check. Yeah, it also confuses people too, because then you start looking at you know Russian or Russian aligned actors. Um, so you know, there's a million, not maybe not a million, there's a lot of reasons that the because this could be like this. Um uh so yeah.

Jenn Gile 19:04

Who knows? Okay, speaking of state sponsored, let's talk about something that we do know who's behind it, and we do know it's state sponsored. Is uh we just released earlier today, and I'll share the link in the show notes, some new Pollenwriter research. Uh, for anyone who has uh not been following that research, or um, you know, you kind of get lost in the campaign names. Just in brief, Pollenwriter is a North Korean state-sponsored campaign that we found earlier this year. Um, it originally was weaponizing credentials stolen through a different campaign that Paul, you uh named Tasks Jacker, which I enjoy. Um, and we think it's probably uh we would consider it like a parallel or sub-campaign to Contagious Interview, which has been running for several years. And we're seeing a lot of activity in Paul and Writer over the last, let's see here, March is when you discovered it. So what is that, four months? Um, but what they basically do is they uh fork popular open source projects, submit malicious pull requests, they inject payloads into JavaScript config files, and um they're very good at putting those payloads in files that people just don't look at in code review. Um, the the font files was one of the locations. Um but the you know, bringing us back to present tense, present time, uh you've been working on detections and found another more than 2,400 poisoned repos that you can attribute to this campaign.

Paul McCarty 20:53

Yeah, um, so that brings it over like 4400, I think. Um something like that, yeah. Something like that, yeah. I think the thing that's really unique about Pawn Rider and the reason it's kind of a separate we talk about as a separate campaign or a separate thing is that every single one of these poison packages is sitting on top of existing you know compromise. So basically, the only reason that DPRK can do this is typically because they have compromised a developer's laptop, either through a contagious interview, interview process where they, you know, the the victim downloaded something, or a malicious npm or pipy package or what have you. Um, or there's you know a couple other ways that this happens too as well, or just the spread of it naturally inside of the open source ecosystem, which is which is I think what we're seeing now. We're seeing like a lot of people just getting pwned that way. But anyhow, it's it's really unique because it r does require existing compromise, not of GitHub, but on the developer's laptop. And this is where you and I are going to be coming out with some more stuff about the human botnet that and and you know what DPRK is able to do with this. But that's a very concerning thing. If they've got persistence and they can do Pollen Rider, they can do other stuff too as well. So um it's not cool. Uh yeah.

Jenn Gile 22:06

What I think people may be familiar with with Contagious Interview is kind of the playbook previously was reach out to a software developer, you know, tell them that you want to interview them, have them do a take-home. That's where the poisoning happens, uh, and then use that access to steal their crypto. That was kind of the playbook with contagious interview. Um, what Pollenwriter is doing is it's continuing that uh exploitation of the developer who got popped again, one of several ways. Uh, once you've taken their crypto and you've gotten into their repos, you know, what we've seen is this is predominantly individuals. Uh, you know, they haven't had whether not targeting or just not successful, they haven't exploited as many organizational repos. It's predominantly individual repos. That doesn't mean that organizations are not getting compromised by this. It just means that it's not the repo that's been compromised.

Paul McCarty 23:12

100%. And you can see that in our data set. So if you go to github.com slash open source malware slash pollenwriter, you'll see our data set there. And you can just look right in the CSV files and you can see we've labeled organizations, which are, you know, typically companies or or you know, some abstraction other than a human single human being. Um, you know, there's a fair few of those in there. And this is something that DPRK kind of cottoned on to. And I think we're still playing catch up inside of the enterprise. Well, not just the enterprise, which is you target the individual to steal their crypto. You also target the developer to get access to what they have access to. And if they're a freelancer, that's even better, right? If they're just some guy working for themselves in Armenia, right? And they work with 10 different companies, some of them might be crypto and some of them might not, then that one person has access to the source code, the core intellectual property of all 10 of those clients, and they can then push those payloads into them once they compromise that one developer on their their machine. So it's just a very um and you know, like in the whole contagious interview, LinkedIn recruiting, it's still going on, but now they're using they're using the same payloads, the same Pollen Rider payloads now. So I saw one yesterday on Twitter. I interacted with it. So if you follow me on Twitter, you'll see me interacting with this person. But they got done just two days ago, stole all the crypto. The victim said, I don't know how many wallets they drained. And I'm thinking to myself, how many freaking wallets do you have, yo? If you don't you don't know how many wallets got you.

Jenn Gile 24:43

You don't know how much money you lost.

Paul McCarty 24:45

But here's the thing is I went and looked that GitHub repo was already in open source malware. It was already, it was a compromised, it was somebody else that had already been compromised via Pollen Rider. Pollen Rider then used it on a net new person via you know, classic contagious interview fake recruiter. This is just like the levels of inception here, Jen, is just crazy off the charts.

Jenn Gile 25:10

I want to pull out some stats from the research that we published today. Um, as I was kind of going through it and preparing it to publish, these are still kind of in my head. So the first stat, uh, in case you sort of missed it, listener, in the numbers, is we have seen basically a six and a half time increase in confirmed poisoned repositories since we pulled the numbers, the repos in April. So that's pretty substantial. Um, the second thing that is a clear trend here is how they are uh smuggling the malware in. And there's two ways, but there's a very clear uh leaning toward one way. And so in 94% of the cases, Paul, you found that they were through a config file injection and just uh you know, five percent or so was through one of these uh font files. And then there's like a very small percentage where both were um present. So talk to me, talk to the listeners about why these config file injections or the fake font vector might be a smart place to hide your malware.

Paul McCarty 26:33

Yeah, great.

Jenn Gile 26:34

Don't give anyone advice here.

Paul McCarty 26:37

Um yeah. Well, that's I was just thinking while you're talking, I was just thinking about something else I want to talk about. I was like, oh, actually, I don't want to talk about that because I don't want to get in the way. But um you know, sometimes describing the problem in too much detail, you know, lets the threat actor know how you're finding it. And I don't want to do that. But um, yeah, so listen, a lot of the um so basically the whole pollen writer payloads kind of fall into two categories. One is that they're appending malicious JavaScript to an existing, or or actually it's not always existing. If it exists, they just append it to it. Otherwise, if it doesn't exist, they just create a file. It's just hilarious. They create a file and then append their payload to the, you know, because they got this all they got this orchestration clearly in Pyong Pang or wherever they are, and it's working and they don't want to change it, right? They're iterating on all the other places, but they're not changing that. So there's that way. And so basically, then what happens is you have to run the app to to get the nasty thing to have it run in your machine and get compromised that way. Now, the other way, and they are really doubling down on this, is VS Code. And I know I'm the guy that's out here bitching about VS Code, but the reality is that listen, don't take my word for it, go and look, right? Either look in open source malware or go hunt yourself. DPRK uses VS Code because it is very, very successful. It's successful if you're using VS Code, it's successful if you're using any of the IDEs or or AI agents that sit on top of it. But basically what's happening now is that the they'll use VS Code to automatically instanti and to run to execute the payloads, and they use several different versions. Like Jen said, they use fake font files, which are really not font files, it's just JavaScript, and they append a font TLD, you know, name suffix to it. But um uh or they just run uh just as a command inside of of task.json, or in a small number of cases, they use a fake dictionary file, which is basically the same thing as the font file. It's just like it's not a dictionary, it's just you know, basically JavaScript with a dictionary.dict um appended to it. Um but what we're seeing increasingly now, and this is something that we need to flesh out more in our data too as well, is that DPRK is shipping these with at least two of these triggers in every single repo. So they're gonna have a task.json trigger so that if you open up in in in VS Code, it automatically or cursor it's gonna automatically run, or windsurf is automatically gonna run. But also if you just spin it up, you're also gonna get count compromised via the um you know the vite config files or the the um the other um uh JavaScript files that they're they're appending to. It's really smart. Multiple multiple triggers per repo means that they increase their chances of of that trigger happening.

Jenn Gile 29:23

One of the yeah, and I don't think we've talked about this out loud, but one of the advantages of hiding your malware in VS Code files is they don't get the same scrutiny as dependencies.

Paul McCarty 29:38

Correct.

Jenn Gile 29:39

And I think in some ways that's changing. Um, you know, I'm talking to more and more people who understand the risk there, but it's somewhat complicated from a management perspective to control what people are consuming. And again, these are individuals who are being hit by uh this campaign. And so the probability that these are getting scanned by any kind of an enterprise tool is like zero. They're you know left to just look at the the thing that they're pulling in and say, Oh, that looks okay. And then they miss uh the malware hidden deeply in these these sneaky little places.

Paul McCarty 30:23

Yeah. Um something else they're using a lot right now is git. So they're using git branches. So they use a uh a git web hook, sorry, git hook, excuse me.

Jenn Gile 30:34

Use your poisoned poison git hooks.

Paul McCarty 30:37

Yeah, yeah. They use the post checkout, which is a very no hardly anybody uses it, but basically then what happens is inside the task.json, they just run uh a git command that changes the branch, and as soon as they do that, that triggers it as well. So and they're using other kind of crafty ways, they're using pre-commit hooks too, as well. Um, so just this, and you'll sometimes we'll see those in addition to some of those other triggers too as well. So we are not to your point, we are not prepared for this. The existing security tools that you're using probably are not able to catch this stuff, and even if you go and mm yourself manually like change VS Code to not run some of these things, these payloads will drop a settings.json file over the top of it, which overwrites your settings, so then they can basically get rid of some of the hardening that you've already done to VS Code. I mean, it's it's just well you have to give them credit, man. It's well done, and it's super effective. Um, as I said yesterday, I'm you know, continue to see people on LinkedIn and and Twitter getting popped. That's super effective.

Jenn Gile 31:39

So, to kind of wrap this up in terms of advice, uh, if you know, listeners out there, if you're running take-home coding tests, if you're installing any unfamiliar front-end templates, if you're cloning project starters from strangers, uh treate, you know, treat all of that as untrusted, especially the config and the font files. Make sure you check those. And then um, if unfortunately you did consume something dangerous, we do have a detection script that can help you um identify that. It's in the blog that we'll share the link of. I think maybe it's also in that repo that you referenced, Paul. Is that right?

Paul McCarty 32:19

Yeah, and in that original blog post, the original pawnwriter blog post at the bottom of it, I also tell people how to harden VS Code. So I'm sorry, I don't have that link in front of me right this second, but um, we'll try to append that to the to the podcast.

Jenn Gile 32:33

Yeah, I can pop that in there. Um, unlike with NPM lifecycle scripts, where you really do have a legitimate reason to have them turned on, um, there are some things that you can disable in VS Code that everybody will be happier. Well, not North Korea, but everyone else.

Paul McCarty 32:50

Unfortunately, a bunch of extensions that people run, which are awesome. We didn't even talk about that. That's the other way that DPRK is getting people, but a lot of extensions unfortunately require those tasks.json to do stuff for the extension. So it's kind of similar to the you know, like the fact that ES Lint requires a post-install script to do stuff to set it up. So it's unfortunate. We you know, we require a lot of these automated script things.

Jenn Gile 33:16

Yep. Okay, we are at time. Uh, I think we're at a good place to stop. I'm gonna tease a little bit next week. We're planning on talking about some macOS malware. Uh, our friends over at JAMP published some really cool stuff, and we found some other cool stuff. So, more uh on that next week.

Paul McCarty 33:36

Yeah, I'm stoked. Thank you, everybody. Thanks for listening. Appreciate it.

Jenn Gile 33:39

Bye.