CyberWire Daily - When macOS gets frostbite. [Research Saturday]

Episode Date: December 6, 2025

Jaron Bradley, Director of Jamf Threat Labs, is sharing their work on "ChillyHell: A Deep Dive into a Modular macOS Backdoor." Jamf Threat Labs uncovers a newly notarized macOS backdoor called ChillyHell, tied to past UNC4487 activity and disguised as a legitimate applet. The malware showcases robust host profiling, multiple persistence mechanisms, timestomping, and flexible C2 communications over both DNS and HTTP. Its modular design includes reverse shells, payload delivery, self-updates, and a brute-force component targeting user credentials. The research can be found here: ⁠ChillyHell: A Deep Dive into a Modular macOS Backdoor Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. Most environments trust far more than they should, and attackers know it. Threat Locker solves that by enforcing default deny at the point of execution. With Threat Locker Allow listing, you stop unknown executables cold. With ring fencing, you control how trusted applications behave, and with Threat Locker, DAC, defense against configurations, you get real assurance that your environment is free of misconfigurations and clear visibility into whether you meet compliance standards. Threat Locker is the simplest way to enforce zero-trust principles without the operational pain.

It's powerful protection that gives CISO's real visibility, real control, and real peace of mind. Threat Locker makes zero-trust attainable, even for small security teams. See why thousands of organizations choose Threat Locker to minimize alert fatigue, stop ransomware at the source, and regain control over their environments. Schedule your demo at Threatlocker.com slash N2K today. Hello everyone and welcome to the CyberWire's Reader's Reindeer. Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. So we have some different live hunt rule set up, and this one actually stumbled about because of a way in which it was performing shellouts to collect process information. And we sort of said, hey, like, there's a lot going on with this executable than just collecting processes, right? It's doing some really interesting stuff. That's Jaron Bradley, director of Jamp Threat Labs. The research we're discussing today is titled Chili Hell, a deep dive into a modular MacOS

backdoor. So that's kind of what initially caught our attention. And then the more we looked at it and kind of observed it, we saw it aligned with a report that had been previously done by Mandy. And there was a private report that they shared at one point that they gave us permission to kind of, you know, share a little bit of additional detail on when we release the blog post. Well, I mean, let's dig into the details here together. What is Chilly Hell?

What is it setting out to do here? Yeah. So, Chili Hell is really, even if you look at the strings of it, it's a pretty obvious backdoor as soon as you start glancing it. If you're familiar with, you know, reverse engineering or anything like that. It jumps out immediately as kind of, I don't know, it looks a bit cybercrimey right off the get-go. There's strings inside of the executor that just say, welcome to chilly hell and like caps and exclamations. You know, like, it's just kind of interesting right off the bat, but it is a back door that's definitely set up to give attackers access in the background on a Mac computer. And I believe there was different variants of it as well.

At JAMP, we're geared kind of heavily focused on the Apple side. So that's the sample that we went and took a look at. But I believe it comes in multi-platform written in C++. But that's ultimately what it's doing is it's getting back to an attacker kind of in a stealthful manner. And how would someone find themselves contending with this? How does it find its way onto somebody's Mac? We think it's relatively targeted in terms of the attacker and the creator. You know, given, like I said, we kind of found this in Virus Total.

We don't, we haven't known, we don't know exactly who's been hit by it or been affected by it. We know that it came out in 2021. is when it was kind of quote-unquote notarized, which I can speak to in a second. But that to say, it's been around for a long time, and it's very difficult to tell how many people have maybe been hit by it because it's being used by, again,

an actor that kind of seems like they're perhaps cybercrime-focused, but maybe also still a bit targeted in terms of who they'd actually go after. well you noted that this is apple notarized it was also a developer signed you all pointed out in the research here what's the significance of that yeah definitely so if you're not familiar with the process of kind of how apple carries out their their app distribution process essentially you kind of you pay for a Apple Developer Certificate. You pay that through the Apple Developer Program generally, and you get this signing certificate where you're able to

basically build an app and then you sign it, cryptographically saying, hey, like, I developer XYZ built this app. I'm assigning it to my account. And in order for like an app nowadays to open without any hiccups, without any pop-ups, without anything that says Apple was unable to scan this app, Are you sure you know what you're opening?

You know, stuff like that. Without, in order to not cause any of those pop-ups, you have to be signed and notarized by Apple. Your app does. So a lot of what we've been seeing on the malware side from Apple, Apple or Mac-focused malware, has been unsigned malware that attackers often include some type of instructions in terms of how to execute, right?

Maybe they pop something up that says, in order to install this, you must run it in the terminal. And some users fall for this. But the appropriate way to actually pass all the checks and rouse the least amount of suspicion is to sign it, as though you were a real developer. So sometimes attackers get their hands on these signatures. Sometimes they apply for them for these certificates.

and then they're able to cryptographically sign that malware. So that's what we saw in this case, which I would say is a bit of an anomaly these days, because we don't often see it getting signed. But even more rare, this one was submitted to Apple, and it passed that notarization check. So the second portion that I kind of referred to was notarization, where the before distribution, again, for no hiccups to go off, you have to upload your app to the Apple Notarization Service where they perform some type of scan.

It's a black box. We don't know what it is. It's just something on their side where they run your app through a number of checks. And they tell you whether or not you get a result on whether or not it's notarized. And if it failed that test, that you generally get a message-why. So this being notarized in 2021 would have been around the time Apple was setting up this process.

I can't remember the exact year that Apple kind of added this notarization step. But it would have been pretty early. It would have been pretty early in the process. But it's just a bit surprising to still find this kind of completely unmarked in virus total, completely signed and notarized even to today, I'd say. Yeah, it's an interesting. observation. I mean, given as you said earlier

that how overt this was and kind of calling itself out as being perhaps up to no good and yet still managed to make its way through multiple layers of both being developer signed and Apple notarized.

Yeah, and that's kind of one of the plus sides of this whole process that Apple has set up is like, yeah, as soon as the executable is found, it can be unnotarized, right? And that'll essentially cause all those pop-ups to occur on your system once they've revoked that notarization or the team ID in general, they can revoke that as well, the signing certificate. And now anything that that creator has made will essentially

be broken across all Apple devices and it won't work. So the response can be very speedy, but when something does slip through like this, like even analysts might be more likely to kind of dismiss it, saying, ah, well, that's signed and notarized, right? That doesn't look like malware. And maybe that's something that occurred in this case. Who knows? But yeah, I'd agree that it was pretty surprising

that this just kind of hid for so long. We'll be right back. AI is transforming every industry, but it's also creating new risks that traditional frameworks can't keep up with. Assessments today are fragmented, overlapping, and often specific to industries, geographies, or regulations. That's why Black Kite created the BKGA3 AI Assessment Framework to give cybersecurity and risk teams a unified, evolving standard for measuring AI risk across their own organizations and their vendors' AI use. It's global, research-driven, built to evolve with the threat landscape and free to use. Because Black Kite is committed to strengthening the entire cybersecurity community. Learn more at blackkite.com.

Well, let's dig into some of the details of how chilly hell works. My understanding is it profiles the host and tries to blend into a system? Yeah, it uses a lot of file names that would not attract a lot of suspicion, which is something we see pretty regularly. Well, malware in general, but especially on the Apple side, you've got so many files on the operating system that are just called, you know, com.com.com.com.com, this or that, or you've got so many services running at the same time.

And this malware, it definitely took, the creator took a look at, you know, what exists on the operating system and tried to create different file. If it had to create files, it would do it to try and blend in, definitely, with file names that wouldn't rouse too much suspicion. But, yeah, it did a lot of that. It did some profiling of the user that was on the system, you know, pretty typical like stuff that malware does as soon as it runs and sends that sort of sends those details back up to the to the attacker where that's then kind of saved and they're

able to identify the computer should they should they need to you know determine whose computer that is or try to pinpoint a certain computer but those are the first steps that it does I'd say some of the really interesting stuff is some time stomping that it does this is particularly interesting to me, you know, kind of as a security analyst on the Apple, on the Apple platforms, because we don't see a whole lot of that kind of anti-phorinsics approach on the Apple side. It gets done, and we're seeing a little more of it here and there. But that's a technique that this particular malware was doing that I don't feel like we've seen in a lot of malware that we've reversed as of late. And then it would even do that

at a programmatic level where it would try to do it without shelling out to a bunch of commands, which can be kind of a giveaway that you might be a malicious process if you're doing really weird shell commands, right? And we see it doing that kind of in a more stealthful manner. So that was something pretty interesting to see, I think, from this specific sample. For folks who aren't familiar, can you describe to us what time stomping is? Yeah. So in the Mac world, when it comes to malware, this is, I think, for sure, most common with when you're dropping persistence on the system, at least in the context that I've seen it. Attackers like to try and ensure that those persistence items, because they're such good kind of indicators of usually where malware is pointed and what it's trying to run at startup.

a lot of times they will try to adjust the time stamps on those daimons so that it looks like they're tied to or they were installed at the same time as another service and that they match the timestamps of another service. So I've seen that quite a bit from malware. Again, tiny or sorry, chilly hell does that in a kind of a more stealthful manner than I've seen it done by other malware. But yeah, that's essentially it. You're adjusting the metadata timestamps of files to try and make it to jump out less to forensic analysis and incident response. Right. So these files that it installs just looks like any of another handful of other system files that got installed with the OS, that sort of thing. Yeah, the big technique is usually to take another installed service and take the exact timestamps of that service.

and apply it to your newly installed malicious service. I see. Well, let's talk about command and control here. How does Chile hell communicate with its operators? Yeah, so essentially, it does this by entering a loop. You know, a lot of malware does this from the Damon perspective. But the loop that we identified in this case is it's retrieving task. It's making sure that there's not an existing instance already.

running of those of that task check and then so long as there's not it's going to execute and then it's going to sleep for a random number between 60 and 120 seconds and that's just so to kind make it once again another kind of anti-detection technique right a lot of times analysts and threat hunters may be able to identify malware if it's doing an exact sort of check every x number of seconds. That's sometimes a good way to detect beckoning through frequency analysis. And so it picks a random sleep and that way, you know, a number between 60 and 120, it's not always going to be consistent and it won't look as obvious from a beaconing perspective. So, yeah.

You mentioned in the research that there's modular design here. Why is that significant? What are some of the modules that you all were able to find? Yeah, so a lot of them are ones that you would expect to find built into malware, but the modular design and basically kind of making the malware expandable should the developer want to is certainly something that we take interest in, and it means there might be new iterations of this malware in the future with more modules, right? So connecting back to a shell, obviously a very popular feature to have in your malware where you can run direct shell commands, and that includes doing it in a pretty well-designed

way from the Unix side, obviously part of MacOS is this sort of, it's a very Unix feeling that BSD side of the operating system, right? So the way that it was developed was pretty knowledgeable in terms of how to create that shell. A lot of attackers will do something very hacky and just kind of just do this thing where you pass a single command over the network. The malware sees that command and then it just sort of spews it out and sends all the output back. This was done by actually creating a pseudo terminal, which again generally you're taking the time to do it correct. if you do it that way. So that, to me, is always an interesting feature in malware

because it kind of dictates how familiar the creator was with the operating system they were going after. Well, how does Chili Hell compare to the typical MacOS malware that you all study? Yeah, great question. I think from a stealth perspective of the X-Ect perspective of the executable itself. The second we looked at it, it was pretty obvious.

So maybe not super obfuscated or stealthy in that perspective. But I think in terms of the design of it, and again, this design in C++, it's not Go or NIM or some of these other languages that we're seeing lately that kind of have this inherent sort of obscurity. when you compile the executable. So maybe that was one of the reasons that it felt so simple to reverse compared to other samples we're seeing as of late. But from the setup and from the attacker knowledge of kind of the Unix side,

I'd say it's a little more advanced from the design perspective on that side. We did also see some noisy stuff like a password cracker being included as one of the modules. that you're referring to. And that's kind of a noisy approach to a solution is to actually crack passwords on the system because you're obviously going to be using a lot of CPU and resource-intensive operations to do that. So, again, not the stealthiest of malware

that we've encountered as of late, but it's still fairly well-developed piece of malware. Yeah. Well, what are your recommendations then? I mean, how should folks best protect themselves here? Yeah, it's funny because a lot of the, a lot of the, you know, recommendations that we used to see coming along from the, from the Windows side, right, as the malware market, like, just kind of exploded on the Windows side a long time ago.

As Max are becoming more popular, like a lot of those recommendations are still the same. They're just coming later than they originally came on the Windows side. So in this case, just with this part, particular malware and what the actors were seen historically doing, it comes down to knowing what you're installing, right? So even in this campaign where the actor, in the original campaign, the actor was responsible for installing, basically taking over websites as more of a watering hole attack type of approach, right? And which makes it very complicated. like you're on a website you think you trust and what you're installing you think you think you're

doing legitimately right so it can be very difficult but ultimately what the attacker was having you install was something very pointless that if you took the second to ask like all right i'm on this website i trust a website it wants me to install this what is it you have no idea like maybe maybe you could just second guess you actually need to install it right or or take the time to discover what you're installing so it's a very a very basic solution one that just taking the extra second to knowing whether or not you're installing something, figuring that out. Now, from a perspective of, from the perspective of what can we as security folks do, right, it comes down more towards the telemetry side, knowing what's being installed, knowing what's your employees are installing out there and making sure you have visibility into those types of questions so that you can identify attacks like this. that becomes more of the solution is making sure you have the right visibility.

And I say this as a Mac user with my tongue in my cheek, that perhaps when it comes to malware, our sense of smug superiority needs to be a thing of the past, right? Yeah, absolutely. And that's something that I've been speaking to a lot lately. Again, we've just been seeing the market shift a little more, even in terms of, yeah, we kind of, we went on this journey since, you know, the year 2000 where we've gone from like the single, maybe the executive team at a company using an Apple device or a couple Apple devices to all of a sudden, like, the entire engineering team is using Apple devices, right? Like, your engineering team holds access to so many important computers and so many different important processes at your company, most likely.

So this thing where we're like, well, they're on Macs, so we're probably fine. Like, that is, as that market share continues to shift a little more, we have to ask ourselves that a little more and more as Max become more prevalent in our, in our, environments. Our thanks to Jaron Bradley, Director of Jamps Threat Labs for joining us. The research is titled, Chili Hell, a deep dive into a modular MacOS backdoor. We'll have a link in the show notes.

And that's Research Saturday, brought to you by N2K Cyberwire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app.

Please also fill out the survey in the show notes or send an email to Cyberwire at n2K.com. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ivan. Peter Kilpe is our publisher, and I'm Dave Bittner. Thanks for listening. We'll see you back here.

here next time.