 I appreciate it. Yeah. Good morning Aloha and welcome to my talk on Apple's background task management. My name is Patrick Wardle. I am the founder of the Objective C Foundation. There I work on free open source Mac security tools. I write the art of Mac malware book series and also co-found and organize the Objective By The Sea Mac security conference. Basically all things Apple, all things Mac. So today what will you learn? What will we dive into? What am I going to be talking about? Well the cool thing is there's kind of many facets to this talk. I mean really the goal is to focus and understand on Apple's Mac OS's background task management, BTM, which of course will explain exactly what that is. But we're also going to cover topics of reversing malware detection, Mac OS internals and more. So hopefully there's something in this talk for everyone. We're going to start by diving into the internals of Apple's new background task management. I will caveat this part. We're going to get into the weeds pretty deep. Some reverse engineering, disassembly. But this is really important for the remainder of the talk. And with an understanding then of the internals of this background task management, we'll then show how we can build some neat tools to leverage this. Then because you know Defconn's a hacker conference we'll talk about of course how to fully bypass this new system. And then we'll end by talking about how to detect our zero-day bypasses. So first let's start with an overview. Starting with defining and talking about what is background task management. So this is something that was largely introduced in Mac OS 13. So the most recent version of Mac OS. And what it is, it's a system designed by Apple on Mac OS to govern and consolidate persistent items or in Apple's parlance background tasks. So what are persistent items? Persistent items in the context of this talk are simply processes that have installed themselves in a manner that every time the system is rebooted or the user re-logs in are automatically re-executed by the operating system. So things like an auto updater that needs to run every day is going to persistently install itself. Of course malware is going to do the same thing because if malware does not persist and you reboot your system you've just disinfected yourself. Now what happens when an item is installed that persistently installs itself is three things, three visual things related to BTM. First, and again this happens on the most recent version of Mac OS, there's going to be a system alert informing the user that whatever they just installed is persisting. So an alert to the user saying hey, something just added itself to the operating system is going to be automatically restarted. Second, there is a security message that is broadcast that security tools can register for, which is a notification, a programmatic notification saying hey, something just persisted. You can see from a security point of view, from a security tool this is something that's very useful. And then finally that item is going to be registered in a database, the BTM database. So why do we even care about this? Who cares about this? Well we do. First and foremost as defenders we now have a nicely organized subsystem that manages most persistent items. If we can understand and tap into that we can build and I'll show you exactly how. Very powerful security tools that can now allow us to generically detect persistent malware. This is awesome. As hackers though, BTM definitely poses some problems to reasons. There's going to be an alert telling the user hey, something just persisted. So if you get on a system and try to persist your back door, the user will now be alerted. And also as I just mentioned there's a security message that's broadcasted so any security tools that installed on the system will get a notification. These are both brand new events on the latest version of macOS. So you can see as hackers this is a problem for us. So we need to figure out exactly how to get around this. Now BTM is largely undocumented. Apple really doesn't describe a lot. So the first part of this talk is really going to be diving into the internals of this subsystem. Now when I want to understand something on macOS I always turn to the logs. And this is because a lot of components in the operating system, even undocumented ones, give us a lot of very informative log messages. Unfortunately on macOS a lot of log messages are redacted. So what we first have to do is install a logging profile which basically tells the operating system hey, please unredact and log everything. And there's a link on the slide how to do that. It's pretty straightforward but just know if you're going to be spelunking around in the logs make sure you've kind of turned on this full logging capability. So now that we have logging off and running, we just install a launch statement which is a persistent component. And then look in the logs and see what is shown. So we can see on the slide there's a few very interesting log messages that are directly related to the BTM subsystem. And what we're going to do is we're going to take these log messages and find the binaries that are responsible for generating them and look in their disassembly at the functions that are broadcasting or logging these messages to figure out exactly what's going on. So there are great signposts. So we can see two things are happening. First there are two binaries, two processes that appear to be responsible for BTM. One is called SMD and the other one is called background task management D. We'll dive into both of these. And based on the method names, we first see one that's called launchD will scan your path. And then the second one, register launch item. So it appears that the operating system has noticed that a new item was persisted is going to scan that directory and then register that item. This makes sense. So let's first talk about SMD. This is the system management demon. And the first thing it does is we see that it generates a log message saying got a FS event. FS stands for file system. And if we debug this, we can see that when this log message is called, if we poke around and look at some of the registers, we can see that one of the registers contains an XPC dictionary with an event that is related to watch paths. Now if we look at SMD's property list, which contains information about how it should be launched and some other activities, we can see it contains key value pairs that tell the operating system, please invoke me any time something is written, for example, to the launch daemon directory. And if you're not familiar with Mac OS, writing something to the launch daemon directory is how you persist an item as a daemon. So what this is telling the operating system is, hey, I am interested any time something is added to this directory. If we dig in a little more looking at some of the method names that we saw in the log messages, we see that SMD will generate a XPC connection to a service called com.apple.background task management. Now XPC is a Mac specific IPC inter process communication mechanism that allows one process to talk to another, to both send messages but also to invoke methods and code in the remote process. And we'll see BTM utilizes this heavily. Again, if we poke around in the debugger, we can see that the scan path that SMD is looking at and is going to talk to the other component is the launch daemon directory, which is where our persistent item was just placed. Let's look a little bit more at these XPC messages to confirm who SMD is sending them to. We can use Mac OS's LSMP command. This is LS list MP mock ports. This will show you who is sending mock messages and to whom. So we get the PID of background task management run LSMP and we can see, yes, there's a bunch of mock messages, XPC messages coming from SMD. And if we set a break point on the BTM daemon, we can see that the way its methods are invoked are via this XPC message. So really SMD is just talking to the BTM daemon. So now let's look at this BTM daemon. This is like the second piece of the puzzle, kind of the core component of the background task management subsystem. If we look at its property list, we can see it has various mock interfaces. These are the XPC interfaces that processes such as SMD can connect and talk to. And then also the path to its binary. Let's take a closer look at its binary. We can see first that it's going to be running with root privileges. This makes sense because it needs to monitor system activity, manage these persistent items. If we look at its entitlements, which are capabilities, additional features that the operating system will give it, we can see it has some related to managing BTM. Also, there's an interesting one, and we'll dive into this more, showing it has a entitlement allowing it to submit endpoint security events. We'll see this is how that security message is generated. If we look at its launch item registration function, we can see that what it's going to do is once it gets a message from SMD, it's going to look at, for example, the launch daemon directory and find the new item that was added. So, for example, when I install zoom on my system, zoom legitimately installs a launch daemon, a persistent component, we can see in a debugger that the BTM daemon has now the property list of that new item that was registered. We now have another player that enters the scene, and this is the BTM agent. So, if we go back to the logs, we can see that there's a log message from the BTM daemon that says, should post advisory, and in this case, it is set equal to true. Next, we see a log message from a new process called the background task management agent, and we can say, we can see a log message saying, posting new advisory notification. So, at the bottom of the slide, we have kind of now a full diagram attic overview where SMD is going to get the initial notification, send an XPC message to the BTM daemon. The BTM daemon is then going to talk to this new process, the BTM agent, which is then going to show the alert to the user. So, let's briefly look at this agent, it's the last piece of the BTM puzzle. If we look at its property list, we can see it has some mock and XPC interfaces. Again, these are exposed so that processes, such as the BTM daemon, can send a message to it. And then also the path to its binary. If we look at its binary, we notice it's running as not root, but as the user. This makes sense because the agent is responsible for displaying the notification on the user's desktop, which you have to be running in the user session in order to do that. In terms of entitlement, we can see that it has various BTM specific entitlements, and also then a private Apple entitlement that allows it to generate system notifications. On macOS, you need these entitlements, for example, to show a system prompt. Okay, we're kind of wrapping up the internals of this, kind of one of the last pieces, we need to look a little closer at how this message is actually displayed. So we know that the BTM daemon is going to send a message to the BTM agent, and if we look at the agent's disassembly, we can see it has a method, aptly named post advisory for content. And in the bottom, I've debugged this instead of breakpoint on this method, and we can see that the argument that it's passed is the message that should be displayed in the notification. So this is just the internals of how the agent then will display the message to the user, alerting them as to the fact that something was just persistently installed. Once that has been displayed, we see one other log message which shows that the background task management daemon, it's kind of the core piece, is actually updating some undocumented proprietary database with what appears to be the item that was registered. And we'll dig into this more when we dive into writing a tool, but basically what the BTM daemon is doing is now storing information about the item that was just persisted into a new database. So that was kind of an overview, we kind of got into the weeds, but it's important again to understand these different components, because as we now talk about writing tools to interact with them, we have to understand those, and also when we want to bypass these, we're going to have to have this understanding as well. So that's out of the way, let's kind of pull it back a little bit and talk first about how we can write some neat tools to leverage BTM to detect persistent malware. Now why this is such a great idea in my opinion is because the vast majority of malware is going to persist. Again, persistence is a way to ensure that you are automatically re-executed by the operating system each time the system is rebooted. So this is something that the vast, vast majority of malware strives to achieve. I study the new Mac malware of each year, it's kind of one of my end of the year highlights, sadly, and I've noticed some interesting trends, and this is not surprising to me, but again, this just reiterates that most malware is going to persist. So in 2015, which is now almost 10 years ago, I was like, hey, since all Mac malware is persisting, I should write a tool that monitors for these persistent events, and then when malware persists, regardless of how it got onto your system via a zero day, a trojanized installer, a supply chain attack, I might not be able to detect all that, but as soon as it persists, I can alert the user. So I release this free open source tool called BlockBlock, and BlockBlock does exactly kind of as the name implies, it will monitor for persistent activity and then alert the user. So this is what Apple is doing now. It took them 10 years or so to realize this is a good idea. I like to think that they were inspired by my tool, but you know, from a security point of view, this is great that now this is built into the operating system. And to me again, this just iterates the fact that Apple now has also realized that because most Mac malware is going to persist, this is a great way to now alert the user that perhaps something has slipped onto their system. Let's look at a brief example, Dazzle Spy, one of my great examples for this because it was deployed via zero day safari bugs. So a very powerful deployment mechanism, right? Users in this case were almost SOL if they inadvertently browsed to the site, clicked on the link, the zero days would infect their operating systems, their Mac OS systems, even if they were fully patched. If we look at the embedded strings for Dazzle Spy, we can see something related to a launch agent, which is another way you can persist. And if we run a file monitor and execute the malware, for example, in a virtual machine, we can passively observe it persisting itself as a launch agent. So again, even if we can't detect the zero day exploitation or prevent that, as soon as the malware goes to persist, if we are able to detect that, we can then alert the user that something is amiss and maybe stop the infection before it's gone too far. So the first idea I had to leverage this new BTM is I want to dump the database because the BTM database has a nice comprehensive list of all the persistent items. So the idea is like let's write a tool that you can run on a Mac system that says show me everything that's persisted. Now this will include legitimate software, for example Zoom, we saw, but if there is any persistent malware on your system, it will likely also be in this database. The problem is this database is proprietary and undocumented. Luckily though, Apple ships a tool called the SFL tool that allows you to interact with this database. And one of the commands it has is dump BTM. And if you execute this, it will nicely dump the database. So here, for example, we can see the information about Zoom's persistent component in the BTM database. Now it's great that there is a command line tool, but I want to be able to programmatically do this so I can add this to my own security tools. So I said, okay, well, SFL tool obviously knows how to grab this database, parse it. Let me reverse engineer and figure out how it does this. So if we reverse engineer it, we can see in a nutshell that it sends an XPC message to the background task management daemon. And the daemon will then send the database, its contents back to the SFL tool. We can see that also in the log messages with the BTM daemon saying, yes, I received an XPC message to get the contents of this database. So it said awesome, let me implement this same code, let me talk to the BTM daemon, kindly ask and say, hey, I also want the database. So I mimic the code of SFL tool, compiled and executed this, and it completely failed. Basically, we can see a log message saying, Patrick, you don't have Apple's private entitlement. Rude, you can't talk to me, please go away. And we can confirm this if we reverse engineer the background task management daemon, we can see it has code to check who is talking to it. And it will only talk to processes that are privately entitled, meaning things like SFL tool. I can't get that private Apple entitlement, I can't spoof it. So BTM daemon is basically going to tell me to take a hike, whereas FSL tool is going to be allowed to make that request and get the contents of the database. So fail. But can we just access the database directly? Yeah, as long as we have full disk access, we can. So the first thing is that let me dig into this database to figure out what exactly it is. I ran the file tool on it, it told me it was an Apple binary property list. We can use the PLUT command to convert it to a normal property list. But unfortunately, that doesn't really help because it shows us it's just a NS key archived, which is a jealousy object that has a bunch of other serialized objects. So really the database has a bunch of undocumented serialized objects, so not the best format. But SFL tool can somehow deserialize those objects and display them to the user. So if we reverse engineer SFL tool some more and figure out how those objects are deserialized, in theory we should be able to write our own deserializer and then read the database directly ourselves and display this information to the user. So if we look at SFL's tool, we find it's deserialization code, which describes the objects that are in this database. So what we can do is we can essentially re-implement that deserialization ourselves. I'm not going to go through all of this, but we can see there's things in these serialized objects such as an executable path, bundle identifier, et cetera, et cetera. We can then with this deserialization logic complete, write some code that opens the database, loads it into our own keyed archiver, and then invoke the decode object of class method, which will invoke our custom deserializer and deserialize all the objects for us. So I pushed this logic into an open source library called dumpbtm, and with this library now you can write a five or ten line program that simply can interact with the database. The library exposes two main methods. The first one is dumpbtm. You can either specify the path or it will look it up for you. This will print it out to standard out, or it will load the contents of this database into a dictionary that then you can programmatically dig into more. So here's an example, the output of our dumpbtm tool. This should look exactly like SFL, SFL tool, which was the goal. Another cool thing about it is this doesn't need root access to run where Apple's SFL tool does. So if we execute this we can see we're opening the background task management database which contains all the persistent items on the system that we're interested in and starts printing them out. Again we can see for example the zoom daemon that has installed itself. So what I then did was I took this library and I implemented it into one of my well-known security tools called knockknock. Knockknock's goal is to simply tell you who's there, pretty much saying these are all the persistent items and with the addition of this new library code it can now also query the undocumented btm database, get all the persistent items from that and display that. So on a system where Dazzle Spy has infected via the Safari Zero Days we can now enumerate its persistence and alert the user that their system is infected. Now there's one kind of downside to that approach and that is it's somewhat reactive, right? You're going to get on a system if you're doing some forensic analysis or seeing if it's infected and you're going to now query and yes you can get a list of everything that's persisted but it would be nice to get a notification in real time when something is persisted. That's a little more proactive. So let's talk about how to do that now. Now you might remember that I mentioned that the background task management daemon has an entitlement related to end point security. What is end point security? It's another subsystem in Mac OS that's designed to be designed to interact with third party security tools. The idea is the end point security system and we'll dive into this more. Basically monitors all sorts of activity on the system and then third party security clients can tell it what they are interested in and when that event occurs the end point security subsystem will programmatically deliver it to them. So for example we will see we can tell the end point security subsystem hey we are interested whenever something persists and then it will programmatically call us. So this is really great for a security tool to monitor for example whenever a persistent item is installed. Whether that is zoom or dazzle spy via zero days. So what we can do is we can look at the header files for the end point security system and we note that in Mac OS 13 the most recent version when BTM was introduced there are some new end point security events that we can now listen for and the one we're going to focus on is the BTM launch item ad. As the name implies this is a message that will be delivered anytime a new item is persisted. So the idea is an installer or piece of malware comes along and persists itself if our ES client has registered for these notifications Apple will deliver that to us. So you can see if you're writing a security tool this is great. You can then perhaps examine that item alert the user generate a log message etc etc. So let's look how to do this programmatically. This is some standard end point security code. This is how you write a client basically three steps. You tell it what events are of interest to you. Here we want to detect when a new persistent item is added so we tell it we're interested in the BTM launch item ad event. We create a callback that will be invoked when this event is delivered to us and then we subscribe which kicks off basically our listener. Now whenever something is persist the operating system will call us because we said hey please let us know and here are some additional information about the contents of that message. So we can see things like the item, the executable, the path to its property list. Again these are the components of the message that are going to be delivered to us. So now if we add this code and compile and execute we are now listening essentially for persistence events. If Dazzle Spy comes along and infects this system we can now see that we get a notification from the operating system from the end point security subsystem telling us hey just to let you know a new persistent item was added here is the path to its executable and also the path to its property list. This is great because if we look at that first we can see it's an executable software updater that's running from a hidden directory huge red flag. Its property list is also called calm.apple.software but if we look at the binary software update it's not signed by Apple so another huge red flag. So this is an example of now how we can generically detect even brand new malware that's being deployed via zero days simply by monitoring for persistence activities. Now one problematic issue the other end point security event related to persistence events the remove events is broken. Like you can register for it but when a persistent item is removed it's just never delivered. So Apple please fix. And speaking of broken the btm launch add event was actually horribly broken to begin with in two ways. First whenever an item was persisted the operating system would just call you with all the items that were persisted which is totally unhelpful. I'm only interested in the new items not the 25 other items that are already on the system. And then also if you persisted as a login item which is another persistence mechanism you wouldn't get a notification at all. So I sent a bug report to Apple and I said hey yo this is like all broken they took their happy time but eventually in macOS 10, 13.3 they fixed this. Okay so now we've talked about the internals of the btsm subsystem. We've showed how we can write some pretty powerful detection tools that allow us to detect malware when it persists. So this is great for defenders. But as I mentioned Defconn like it's a hacker conference so we need to like put on our black hats and talk about now how to break this subsystem. And the reason we want to break this subsystem as hackers are twofold. First let's put ourselves in the shoes of a hacker. We come along we infect a mac system with our 0 days. All well and good. We go to persist. Two things now happen because of btm. First a big system alert is generated and displayed to the user saying hey something just persisted. And like if you're browsing safari and all of sudden this pops up like yeah you're probably owned. And then also as we showed this will generate a endpoint security message which means that if any security system is on your on your mac any security tool it will pick up this event and also be like yo strange you've essentially been hacked. So as hackers we want to bypass both the security alert and the endpoint security event. Two things to point out these are both separate so we have to find attacks and bypasses for both of them. But the good news is both of them are independent on the functionality of the persistent item. Meaning regardless of what happens to the alert and the security event they're both notification so either way the item will be successfully persisted. It's not like the operating system is waiting for the user to click on the event and say allow. So this is good. This means if we can suppress these messages or somehow prevent them from being delivered we're great our malware will be able to persist invisibly and still function. So one thing you can do and this is not really a bypass per se it's more just a limitation of BTM is simply persist in a way that is outside launch daemons, launch agents or login items which are the three persistent mechanism that BTM currently monitors. These are the most popular ones but there are myriad of other ways for example you can persist as a cron job and currently BTM does not monitor cron jobs. There's also a great blog post by Chaba who basically shows that there's 20 or so more esoteric and stealthy ways to persist. So if you persist your malware in any of those ways again as long as you're not a launch daemon, a launch agent or a login item, BTM doesn't even come into play. But I wanted to directly bypass that system alert. So method one is hilariously simple. If we go back to that SFL tool and look at what it supports, one of its commands is the reset BTM database. And the idea is if your database gets into a funky state you can reset it. The operating system will then just rescan all the launch daemon agent and login items directory and rebuild the database. So that's great. The problem is when you execute that it puts the background task management daemon in like a funky confused state. So if we look at the log messages what we can first do is reset the database and then persist an item. And if you look at the log messages you can see that should post advisory is now set to false. I don't know exactly why but I know that if you reset the database this will always be the case. So what a hacker can now do granted with root privileges is just reset the database, persist their item. Their item will be successfully persisted and restart every time the system is rebooted but the alert will never be delivered. And again they're simply using Apple's own tool. So this isn't some crazy like heap overflow. You're basically just saying hey please reset the database and the system is like cool and then you can persist silently. So that's awesome but the problem with that is you need root access. So I said okay let's do one better. Remember the BTM daemon will send an XPC notification to the BTM agent and say please display a notification to the user. What privilege level is the agent running at? User. And this is because it needs to display a message on the user's desktop session. So I said can we just send the BTM agent a stop signal like yo go to sleep for a minute. What happens? Well it turns out you can do this. The BTM daemon will still deliver the message to the BTM agent and believe that was successfully delivered but since the agent is sleeping it's not really going to get that message and so it will never be displayed. So what a hacker can do is get the process ID of the BTM agent which again is running as user so lowest privilege level. Send it a stop signal to put it to sleep. Go to persist. BTM daemon will try to deliver the message and think it succeeded but the agent is sleeping. And then once they have persisted kill the agent which again you can do because it's running with your same privilege level. You need to kill the agent because otherwise when you wake it up the alert will have been queued and will be displayed. But if you do this you will now be able to persist and the alert to the user will never be displayed. Now this is well and good. I'm like cool. Like these techniques work on the latest version of Mac OS so hackers take note. I guess Apple take note too. But you know I'm like cool users might ignore that alert anyways. What I'm really more interested in is preventing the end point security message because security tools including my own listen for this method. This is how Apple says register for persistence notification. And you can imagine security tools are not going to necessarily ignore this. A user might ignore an alert. A security tool if it gets a persistence event is going to examine that very closely. So again as adversaries, hackers we want to figure out how to prevent that message from being delivered. And it's a little harder because this is all being delivered in the root session. So I went back to the BTM daemon and started looking around at how it submits events to the end point security system when it detects something has persisted. And unfortunately if we follow the call chain, we can see it calls into the kernel. Which means we're going to have to pop into kernel. However right below that kernel call, we can see a log message that says fail to submit event. So I'm like okay well it looks like there's a failure scenario I have no idea what that is. But we can figure out what that failure scenario is and trigger that. We might be able to prevent the end point security message from being delivered to any security tool on the system. Which is the goal. So we pop into the kernel and there's kind of a lot going in on the slide kind of follow the black arrows. We can basically see that in the end point security kernel extension, so this is running in kernel mode, we find a bunch of methods. One is called PDB read audit token. This reads a process ID from a user mode buffer and then calls another method create from PID version. And this invokes the proc find API. Given a PID. This is going to be important. Then it calls another method to get the executable Vnode. This is kind of like the file system Vnode of the process it's just looked up. So basically it's trying to get a path to a process. What process? Well if we set a break point in kernel mode and install something for example oversight which is one of my utilities that installs a launch login item. We can see that the process that it's looking up is the responsible process that has persisted the item. And we can confirm that if we look at the end point security message in user mode we can see that the PID and the process match. So again what the end point security kernel extension is trying to do is look up the process that is responsible for generating the persistent event. The installer, the malware, etc. etc. This makes sense because they want to deliver that to the security tool in user mode. So I looked at that a little more and I thought okay what happens if the responsible process is like gone? What if it executes really quickly right? This is kind of happening separately so maybe it'll get confused. And so what happens we can see in this case they call proc find with null. They don't have a PID because the process that persisted at least I thought it was gone. Now if you call proc find with null which is also zero you get back a process object but it's the one belonging to the kernel task. Because the kernel task is assigned PID zero. It's not really a process per se but this is just how it works on macOS. And that's okay. I mean they kind of have the wrong process at this point but it's problematic then when they call proc get executable vnode because the kernel doesn't have an executable vnode. It's not a running process backed by a binary per se. So that is going to return null which causes them to return error number three. And if we go back to the log messages in user mode we can see a log message that says fail to submit ES syscall error three no such process. So I was like okay I think I can trigger this but how? Like how do I develop a proof of concept? And I thought about it and I said oh wait a minute my own tool block block uses the CP command to install a property list. It copies that and that's a very quick command that exits. So I was like is this going to trigger this kernel bug and bypass that? So let's do a demo. I haven't prayed to the demo god so fingers crossed this all worked but go bigger go home. The first thing we're going to do I'm going to make this a little bigger is we're going to execute Apple's ES logger command and this is going to this is a utility and end point security client that allows you to listen for end point security events and we're saying please listen for the BTM launch add item. So in theory if an item is persisted we should get notification. We're then going to have some log messages running this is just going to show us the error message and then we're going to install block block. Fingers crossed put in my password this is definitely going to work. Now we do get an alert we'll address that in a second. These alerts are again separate from the end point security subsystem. If we go over here though we see there's no message. There's supposed to be a message. Why isn't there a message? Well if we go back to here and look for Lib end point we can see that we have successfully triggered this kernel bug failed to submit event sys call failed error no such process and this is because block block again is a script that executes shell commands which start and stop very quickly. So the kernel doesn't have time to look that up or isn't tracking those separately. When it goes to look that up that process is already gone and so it doesn't have a pad and so it errors out. So basically all you have to do to bypass the security events is to do that. Okay let's I guess we have some time let's show how we can block these messages as well. Yeah awesome. Thank you. So I'm going to uninstall block block click through this just to kind of reset everything uninstall and we're going to run it again and we're going to this time try to hide those alerts. So I remember I told you the launch agent the background the BTM agent is responsible for displaying those alerts and so what we can do is just tell it to go to sleep. So let's do that exactly. So what we can do first over here I'll make this a little bigger is we're just going to get the process ID of the background task management agent. We can see it has a pit of 86276 it's also running as me as the normal user. So what we can do is we can do this programmatically or we can just do it via the kill. We're going to send it the kill stop command which is going to say hey go to sleep and we can confirm that if we do the process listing again it now has a T here T means that item is now suspended. If we and I'm going to reset this because the uninstaller for block block installs something persistently but does it programmatically so this generates an event this just proves that normally we should get an event. So I'm going to reset this to show that the installer doesn't we're now going to run block block again and the hope is we don't get a security event and be no no alert is shown. So fingers crossed live demo number two block block is going to install hooray happy we're going to get an alert from block block saying I'm up and running but no alerts from the endpoint security system and no alerts from the subsystem. So now what we would do is we would kill the agent to make sure that those messages are not delivered. What I'm going to do instead resume it to show you that if we didn't do those those would actually be there. So again normally a hacker wouldn't like continue the agent they would kill it at this point which is again because it's running with the same privileges but if we continue it we will see those are the messages. So they were delivered but because the agent was sleeping they weren't actually shown and if we kill it they will never be displayed. So what we have done is fully bypassed background task management which is I think kind of problematic. And why is this problematic let me just clear these annoying alerts. It's really problematic because this is a security mechanism that Apple has basically told us will protect our Macs but in reality it's implemented incredibly poorly and is trivial to bypass. And this is problematic because users might now be overconfident in the security of their system because Apple has promised them this security feature and security tool vendors might also be leveraging this to detect persistence believing it works when in reality it's broken and trivial to bypass. So that in my opinion is problematic. So let's end kind of on a more positive note and show how we can detect these bypasses until Apple gets their act together and actually start shipping secure implementations. So the first thing we want to do is how do we detect if someone resets the SFL or the BTM database. This is not something that should ever normally happen right. It's kind of an undocumented database no one really knows about the SFL tool. So if you see someone resetting the database it's like probably a hacker trying to leverage one of these bypasses. So what we can do is we can write a process monitor that can detect when this process is spawned and also look at the arguments. We can write a process monitor that's either passive that can say hey this happened or using other endpoint security events you can actually receive a notification when a process is about to be spawned and if it's the SFL tool with the dump BTM command you can actually prevent sorry with the reset database command you can actually block that all together. So this is a way to essentially prevent that command from being run so that database cannot be reset. What about telling the BTM agent to go to sleep? Well it turns out we can also use the endpoint security system to register for signals. Specifically we can use the event type auth signal which will be delivered to us anytime a process is trying to send a signal to another process. What we can then do is we can examine both the signal and the source and destination process and if the destination process is the background task management agent and the signal that is about to be sent to it is a stop event to put it to sleep we can tell the operating system do not allow that to happen. So if we implement this code and are running this in our security tool you can now see that when the attacker tries to send that sig stop message to tell the BTM agent to go to sleep our security tool will deny that and that will actually fail. So now we've prevented the agent from going to sleep. Again these are things like Apple should be doing it's like lame that we have to do this but is what it is right. In terms of getting the end point security notification for persistence this one's a little tougher because it's a kernel flaw so kind of hard for us to detect. Well good news is there are other end point security alerts or messages that will also be delivered that are not susceptible to this bug. For example when a piece of malware writes a property list to the launch daemon directory to persist yes in theory this is supposed to generate a BTM launch item ad and will in some cases but we showed how to trivially bypass this. This will always also generate file notifications for example notify create notify write that will be delivered to us and are not susceptible to the kernel flaw which allows us then to say hey something was written to those directories. So what we can do and this is how block block detects persistence is it doesn't use the BTM launch item ad because it's broken currently I wish it worked to be really nice but instead it uses the file events to monitor the locations where items can persist as I mentioned those events will always be delivered accurately and correctly. So it listens for those events if it turns out it's in one of those directories it then alerts the user. The other thing is unlike apple's approach it has the ability to block that so you can actually take some action against that versus just clicking on an alert that's like yeah cool. Okay so let's wrap this all up with some takeaways. So we talked about understanding macOS's BTM subsystem. I think it was important to understand that because we want to write tools and also understand limitations. So once we had an understanding of the internals of the background task management we showed how to write some very powerful malware detection tools that are built on the fact that mac malware persists and BTM now manages and governments governs persistence. Unfortunately we showed that it's trivial to bypass the BTM subsystem entirely. Again all these approaches worked on all the latest versions of macOS so go out and cause chaos I guess. No don't. But you know again one of the other takeaways is like if we're not doing this research who is? Like what is apple doing? Like counting their trillions in Cupertino? I don't know but it's really problematic when they say hey there's this great new security system that's built into macOS. You now are protected against a persistent malware. Well in the reality like that's really not true. And again as I mentioned that's problematic because users are going to have a false sense of security which is bad. Makes them easier to victimize. And then also security tools might be thinking they're doing their jobs when in reality they're not at no fault of their own. So again maybe anything apple says take with a huge grain of salt and continue to keep poking on macOS because even new code that apple releases is well I would say subpar. Now if you're interested in learning more about Mac malware, reverse engineering, writing security tools, I've written some free books on the topic. Volume one is out. Go to taomm.org 100% free online. I'm also going to be doing a book signing today right after this talk at the No Starch Press. So if you want to pick up volume one get my signature check it out. I'm also writing volume two which covers basically the topics we talked about today which are the programmatic approaches to detecting malware. So again the nonprofit I'm part of because I think we're doing a lot of really cool things that I think many of you will be interested in. We organize the OBTSEcurity conference. I see a lot of friends here from that conference so thank you all. We also raise money for college scholarships for students who are going into technology fields and we have various diversity programs as well. Our current effort though is raising money for the wildfires in Maui. Many of you know I live there. A lot of my friends had everything lost working to raise money for that. So something very personal. If you feel like you want to support that it's awesome or even just share this. It's something that would be very meaningful to those who lost their houses and their loved ones. So speaking of thank you also want to briefly just end by thanking the companies who support the nonprofit. We're able to organize this great conference. I'm able to release these tools these free books give these talks thanks to them really couldn't do that without them so I briefly want to thank them all and also thank you all for spending this rather early Saturday morning with me talking nerdy about Mac OS stuff. So thank you again to you all.