When macOS gets frostbite.

Dave Bittner: Hello, everyone, and welcome to the CyberWire's "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. [ Music ]

Jaron Bradley: So we have some different live hunt rules set up, and this one, actually, stumbled about because of the way in which it was performing shellouts to collect process information. 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.

Dave Bittner: That's Jaron Bradley, Director of Jamf Threat Labs. The research we're discussing today is titled "ChillyHell: A Deep Dive into a Modular MacOS Backdoor." [ Music ]

Jaron Bradley: 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 Mandiant as 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 released the blog post.

Dave Bittner: Well, I mean, let's dig into the details here together. What is ChillyHell? What is it setting out to do here?

Jaron Bradley: Yeah, so ChillyHell is, really, even if you look at the strings of it, it's a pretty obvious backdoor as soon as you start glancing. 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 executable that just say "Welcome to ChillyHell" and like caps and exclamations. You know, like, it's just kind of interesting right off the bat, but it is a backdoor 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 Jamf where we're geared, kind of, you know, 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 giving -- it's connecting back to an attacker kind of in a stealthful manner.

Dave Bittner: And how would someone find themselves contending with this? How does it find its way onto somebody's Mac?

Jaron Bradley: 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 VirusTotal. 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, you know, 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.

Dave Bittner: 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?

Jaron Bradley: Yeah, definitely, so if you're not familiar with the process of, kind of, how Apple carries out 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 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, you know, pass all the checks and rouse the least amount of suspicion is to sign it as though you were a real developer. So sometimes, developers -- or 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 just 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 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 in the process, but it's just a bit surprising to still find this kind of completely unmarked in VirusTotal, completely signed and notarized, even to today, I'd say.

Dave Bittner: Yeah, it's an interesting observation. I mean, given, as you said earlier, that -- how overt this was as 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 the being developer signed and Apple notarized.

Jaron Bradley: 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 creator has made will, essentially, be broken, like, 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 it -- 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. [ Music ]

Dave Bittner: We'll be right back. [ Music ] Well, let's dig into some of the details of how ChillyHell works. My understanding is it profiles the host and tries to blend into a system?

Jaron Bradley: Yeah, it uses a lot of file names that would not attract a lot of suspicion, which is something we see pretty regularly in, 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.apple, dot this or that, or you have 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 files. 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 attacker, where that's then kind of saved and they're able to identify the computer, 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 platforms, because we don't see a whole lot of that kind of anti-forensics 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 your malware, or 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.

Dave Bittner: For folks who aren't familiar, can you describe to us what time stomping is?

Jaron Bradley: 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 daemons, 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 time stamps of another service. So I've seen that quite a bit from malware, again tiny -- or sorry, ChillyHell, does that in 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 time stamps of files to try and make it -- to jump out less for -- to forensic analysis and incident response.

Dave Bittner: 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?

Jaron Bradley: Yeah, the big technique is usually to take another installed service and take the exact time stamps of that service and apply it to your newly installed malicious service.

Dave Bittner: I see. Well, let's talk about command and control here. How does ChillyHell communicate with its operators?

Jaron Bradley: Yeah, so, essentially, it does this by entering a loop. You know, a lot of malware does this from the daemon 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 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 of 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 beaconing through frequency analysis, and so, it picks a random sleep and it -- 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, you know, kind of making the malware expandable should the developer want to is certainly something that we take interest in, and it means, you know, 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, you know, is this sort of -- it's very Unix feeling, that BSD side of the operating system, right? So it's -- 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.

Dave Bittner: Well, I mean, how does ChillyHell compare to the typical MacOS malware that you all study?

Jaron Bradley: Yeah, great question. I think from a stealth 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, like, 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 a fairly well-developed piece of malware.

Dave Bittner: Yeah, well, what are your recommendations then? I mean, how should folks best protect themselves here?

Jaron Bradley: Yeah, it's funny because a lot of the recommendations that we used to see coming along from the Windows side, right, as the malware market just kind of exploded on the Windows side a long time ago, is Macs 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 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'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 you could just second guess, do you actually need to install it, right, or take the time to discover what you're installing. So it's 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 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 the solution, is making sure you have the right visibility.

Dave Bittner: 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?

Jaron Bradley: 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, they're on Macs, so we're probably fine, like, that is -- as that market share continues to shift a little more, it's getting -- we have to ask ourselves that a little more and more, as Macs become more prevalent in our environments. [ Music ]

Dave Bittner: Our thanks to Jaron Bradley, Director of Jamf's Threat Labs, for joining us. The research is titled, "ChillyHell: 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@n2k.com. This episode was produced by Liz Stokes. We're mixed by Elliott Peltzman and Tré Hester. Our Executive Producer is Jennifer Eiben. Peter Kilpe is our Publisher, and I'm Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]