Introduction to macOS Red Teaming in 2026

Okay. So, um, hello everyone and welcome. Um, it's probably been a long day of talks for everyone, so we appreciate you making it to the one of the final slots. So, introductions. Uh, my name is Victor Vanderhelm. Um, I've got about eight years in offensive security and lately I've been working in red teaming. Um, I enjoy malware development and automation. Um, and in my free time, I'll be snowboarding or making pizza. Cool. >> Yep. Uh, hi, I'm Matthew. So, I've been in the industry for about six years now. Um, my kind of technical niche is just stupid things that work. It's not really a proper niche, but it's what I enjoy. And then in my spare time, I try and

keep this guy alive despite his best efforts. >> Great. So, a few uh disclaimers. Um, this is an introductory guide. Um, so we're not going to be dropping any like zero days or anything like that. Uh, we're not Mac OS experts by any means. We're just sharing our knowledge uh and experience and there's nothing here related to our employers and obviously please don't use this for illegal purposes. So why are we doing this talk? Um, so really the whole point of this talk is to kind of share knowledge to the general um security crowd about Mac OS specifically. Um generally Mac OS has been becoming more popular lately. A lot of uh modern companies are just using

Mac OS today um from the start. Um Mac OS is also quite unusual as a system. It's not you know there's not a whole bunch of information out there about the security considerations around it. Um and yeah, so generally we're just trying to bring Mac OS security knowledge to the people whether you're uh an experienced uh security professional working with Windows and Linux or perhaps a student trying to get into u the industry. Um so we're hoping that this talk will give you like a solid um foundational kind of knowledge on Mac OS. So the struct the talk will be kind of structured um like so. So it'll be a bit of a foundational basics piece and then

a more practical bit with net and then finally some sort of defense and obsc considerations. So for anyone that doesn't know a really a really quick uh intro to what red teaming is. Um it's basically a realistic kind of attack simulation um where we're trying to go from point A to point B. Um so really uh to the crown jewels and the whole scope is uh an organization in its entirety and the whole goal is to do it undetected. So a bit of context before we start um if you consider a Mac OS organization typically you'll be something like a zero trust uh architecture um especially with these modern companies. So what does that mean? It means typically

you'll have um a set of endpoints for example MAC devices something like an IDP to to to handle your authorization and authentication and then a whole bunch of cloud services um that you will be authenticating to which will hold your data and your uh operational technology etc. Um so yeah everyone probably is familiar with IDPs but that will be things like your uh entra ID Google octa those kind of things and they kind of govern the uh security um policies for your organization. So, Mac OS. Um, so if you were to approach a Mac OS system for the first time and you've never got your hands on one or you never seen one, it would kind

of look like a Linuxy kind of thing. Um, it's actually got a lot of the same binaries um as a a typical Linux distribution and the CLI kind of uh use of it will feel very familiar. Um, a lot of the switches might be different though for your for example for set etc. Um the kernel is XNU. Um and this is quite an interesting kernel as it has uh two micro kernels as part of it. One of which is BSD and the other is U match Apple's proprietary kernel. In the past uh MacBooks have ran on Intel and then more recently they've shifted to only ARM. So you will have um yeah all your modern MacBooks today will

be ARM based. Um, an interesting thing to note is that the applications are kind of siloed uh in Mac OS uh systems. And furthermore, there's like a sort of granular permission layer applied to the applications in binaries. And by that I don't mean the user execution context as in as whether it's a root user or a standard user executing the binary, but rather um the application itself will have a set of uh permissions that dictate what it can do on the system. I'll get into that more later. So, if we were to kind of think about the uh the main security pillars of a Mac OS system, you would have SIP, Gatekeeper, and TCC. And these all

together kind of u or basically the core security features on Mac OS. So, SIP stands for system integrity protection and what it is essentially is a uh a security layer which protects core operating system functionality and libraries and uh the kernel from kind of uh tampering. Um generally the idea behind it is not allowing the users um or the admins of these systems to kind of intentionally or unintentionally tamper with the system in such a way that it's disrupted and that you lose access to the functionality. What uh this means as well is that the root user on a Mac OS system is no longer the more the most powerful user on the system. So if you're coming from

the Linux world, you will be you would think that the root user could do whatever uh they want such as loading in kernel extensions etc and and just taking down the system and deleting all the files. That's kind of been nerfed in this case uh on Mac OS. Another kind of uh really important security feature um on Mac OS is gatekeeper. So this will be your kind of built-in application control layer. So it does quite a few things um and generally um it will kind of there will be a number of checks that are enforced when an application or a binary is run on a Mac OS system. And um one of the ones to note will be the quarantine

attribute. So if you're u if you it's kind of like a flag that's appended to an application or a binary when it's downloaded from the internet similar to your Windows mark of the web. Um so that will kind of be used uh to determine whether it's malicious or not or it should be allowed to execute in your environment. Another really kind of crucial check that Gatekeeper does is a signature check. Um so applications um will have a signature often in Mac OS um and andor might be notorized and and generally um the existence of a signature will kind of indicate whether it's been vetted in some way by Apple um and Apple kind of uh strongly encourage if not require a

signature especially when you consider things like distribution on like their app stores etc. Part of the signature is um entitlements which if you remember from um a few couple slides ago um this sort of granular application uh permission layer. Um so embedded within a signature for your application and binaries uh you will have something that dictates what your application can do on the system. Um, so this could be something that indicates that your application can access the microphone or the webcam on your MacBook or perhaps uh something else that will be an exception for how it could work with the operating system. For example, uh loading in unsigned libraries uh unsigned libraries into your application.

So if you wanted to visualize the signature um you could use the code sign utility in Mac OS. Um so in the top uh left you can uh see um the signature for the Java binary which is basically indicating that it's been signed by Apple. Um so this is a trusted binary. Um and then on the bottom right you can see the entitlements associated with the Java binary kind of indicating what it can do on the system. So if you wanted to, we thought it'd be quite useful to visualize a flow diagram as to how a gatekeeper works when you execute an application or a binary. Um, and uh really one of the first things

that happens when you execute the application on a on a system is there will be like an AV check. There's a built-in AV in Mac OS called XProtect and I'll just scan the binary. If it's malicious, typically it'd be uh denied from executing. Um now, in my opinion, I don't think highly of X protect. Um in the four years that I've used the Mac OS uh system, I've never seen an expert protect prompt of any kind. The second kind of check that occurs uh will be a quarantine flag check. Again, this is more of something that aids gatekeeper into understanding whether something is potentially malicious or not. Um, it won't completely prevent uh the execution, but often it might.

And lastly, um, as I mentioned on the previous slide, there'll be a check for signing and notoriization. Um, so, uh, if if it has a signature, um, and it's being compiled and created elsewhere, it'll typically be allowed to run on your system. Um there are cases where you could still execute a binary u without a a sort of vetted Apple signature. The last kind of core security mechanism to talk about on Mac OS uh will be the TCC layer which is essentially a user consent layer. Um and uh you can they kind of take the shape as uh similar to these kind of pop-ups that you've uh that you see on the slide and u they

kind of give the user the ability to u accept or deny particular actions performed by your application on your on your system. Um so uh typically this would be when an application tries to access uh a directory such as your documents or your uh downloads um you would see something like this or if it tries to access your microphone. So really the idea behind it is to give full control to the user so they can dictate what an application does and they're aware at all times as to what this application does. Um it's important to note as well that this affects the root user too. the root user cannot circumvent these pop-ups in any way.

So, we've seen that um Mac OS is kind of secure by design. Um the the security pillars are kind of run deep and being weaved into the functionality and the design of the operating system. Uh generally it's kind of the Apple way or the highway. And by that I mean Apple wants to tightly control um the execution layer and kind of make sure they're involved in the distribution of software within their ecosystem. Um and lastly um uh they've Apple have kind of designed uh the user as the main entity uh and the most powerful entity on their MacBooks. So it's all kind of they want to hand the power to the user to kind of protect their data and their

privacy. So um what does this mean for us as uh offensive security professionals or redteamers? What do we really have to think about when we uh when we try and run an engagement um on a sort of Mac Mac OS environment? Um so really one of the first things we have to consider and and work around will be gatekeeper which handles the execution control. Um so we'll have to find a creative way of kind of uh executing something that kind of satisfies the gatekeeper checks. Um we also want to consider uh whether or not we uh need to um trigger TCC prompts. So there'll be there'll be cases where you can depending on your execution you can circumvent TCC prompts

altogether. But perhaps as a red teamer you'll want to spin up some very targeted ones that could blend in to the the overall amount of prompts presented to the user. they might just click accept as seen with like MFA fatigue text. Um, and lastly, you want to consider whether or not you want to privilege uh do a privilege escalation to the root user. Um, now knowing that the user is the most important entity on the Mac Mac OS system. >> Cool. All right. So, I'm now going to take us through the part of the talk where we run through um a sort of red team scenario. Kind of the hands-on how do we actually address the security um

the security controls that we've just run through if we're running a red team of or a similar sort of offensive security engagement or if we're hackers. Um, first things first, we need to think about the types of things that we need to prepare on our side before we even think about touching our targets MacBooks. So, first part of that is going to be command control C2. I'm going to assume a certain level of familiarity with kind of red team and offensive security concepts like C2. Um, we can chat afterwards if any of those kind of passed you by. Um, so if you've ever done any sort of offensive security against Windows, you'll be familiar with

C2 framework. So things like cobalt strike and covenant and so on and so forth. Uh, and there's similarly for Mac lots of these out there. So you don't have to do all the work of creating command and control yourself. You can use someone else's work. Custom stuff is an option. Uh, it can be quite a good option, especially if you get AI to write it all for you. Um, but whichever of these you choose or whatever you decide to write yourself, there's kind of three main things that I would recommend you bear in mind. So, the first one uh I'll give you for free. Avoid shelling out. Click. Avoid shelling out. So, by this I mean, um, a

lot of if you're familiar with Linux, there's tons of terminal commands on Mac OS that are going to be super familiar to you. However, actually using these is going to be one of the blue team's main signals that they can rely on to try and detect bad guys. So, wherever possible, you want to try and do stuff in code. So, that could be compiled code, scripting languages, even if it's not super elite, you're immediately going to be head and shoulders above the competition that are using shell commands. Related to this, the second one, can anyone tell from the picture what I think your C2 framework should be? What is that table? It is extendable. Um, you're not going

to be able to predict every single line of code that you want to run on an engagement before you start. So, you need some sort of way of delivering new scripts, you know, dial scripts, compile, whatever it is, uh, after you've already got the implant because otherwise you're going to end up having to go back to shelling out doing the commands already there. And then the final one, >> socks. >> Socks. Yeah. So, uh, you, so you want some sort of socks proxy or just some sort of way of tunneling traffic from your attacker machine through the victim machine out to whatever web services you're trying to hit from their context. Just one of the most common things that

you end up needing in any sort of red teaming. Once you've picked or made a C2 framework with these sorts of things in mind, you then need to start thinking about how you're going to get that C2 framework running on your your target Mac OS devices. Uh, and there's tons of ways you can run code on a Mac OS device, whether you're a legit software author or malware author. Um so a lot of these have kind of uh parallels with Windows um methods of running code. Some of them more direct than others. Um importantly anything from kind of install/container and up you're going to need to get kind of signed and notorized. Hence the steady growth of scripting languages

both native and custom as uh as a point of interest for malware. But before we pick our favorite of these and start writing malware, we need to actually think about what we can realistically get running on a device, uh it's all well and good writing some malware that works as an installer package. Uh but if you don't have a way of getting an installer package to a Mac OS device and running it that bypasses all those security controls that we've run through, you'll have wasted your time. So before you start writing a payload, you need to find some sort of bypass to some of these controls. Um so the first one we're going to go kind of

go in a little bit more depth into is quarantine. So I'm just going to go a little video thing. Um so I'm going to show you at really high level how quarantine works. This isn't going to be like Mac OS internals. This is just going to be for like a slightly slightly technical level. What does it actually do? So on the right hand side of the screen we've got uh just a trivial web server hosting a file. On the left hand side of the screen we've got a terminal in the users downloads directory. So if we click to download it and we list our downloads directory where hey downloads work as you would expect on a

Mac OS device. Um but the interesting thing is going to come here when we list the extended attributes of the file. So this is essentially metadata stored in it's like the alternate data streams on a Windows device if you're familiar with that. Uh and what we're going to see most importantly is this com apple quarantine attribute. This is Chrome essentially ratting on us and saying you didn't make this machine. You didn't make this file Mac OS machine. I downloaded it for you. And then just for a simple comparison, if I just make a file with echo uh and then list its extended attributes with this xra command, we'll see there's none. So this quarantine thing is it's like marker web

is something that gets applied when you download a file. And that's the screenshots in case. So why do we care about quarantine? Well, as we mentioned earlier, it's what gets gatekeeper interested in our file. So if we got a user to download that file and doubleclick it uh and hadn't bothered to get it signed and notorized and had that quarantine attribute applied then the user is not going to be able to double click open the file. Gatekeep's going to look at it say you've got quarantine but you haven't got a signature so Apple's not looked at it uh and say no you can't run that. So what can we do about this? How can we

avoid getting this quarantine attribute if it's so important for gatekeeping? Uh I'm going to show you kind of a trivial example that hopefully will get your mind worring for like the general class of like how you can approach find bypasses. So on screen when it loads uh is the uh me downloading the exact same file from the exact same web server but instead of using a web browser I'm using curl. And even though this is like a really obvious other way to download a file, the quarantine attribute's not been applied. Why is this? Well, essentially it's the quarantine attribute is not like a magical thing that Mac OS itself applies. Apple expects the people writing like software for Mac OS um to

like apply that attribute themselves, right? Um, but as you'll see, they're not actually all that strict about it when it's not a typical pointy click through your browser, download something type flow. Um, and even something as obvious as curl just completely breezes through it. So, if you want to try and get past quarantine, try and think of things that from the perspective of the hacker is a download, right? It gets the file on the disc. um but might have snuck past Apple's enforcement of please make your things apply quarantine on downloads. So if you if you've not managed to find um if you've not managed to find a quarantine bypass and you're in a bit of

a rut and you're just trying to get stuff to work, you might start googling blog posts and find ones from even two years ago that say we'll just tell your user to rightclick run anyway. Um, >> click. >> So, >> right click. Sorry, >> you can set it to have a right click. Yeah. Um, maybe command control click. Whatever it is. Um, this is um, so this was really useful if you're super elite at social engineering or maybe slightly more likely you're a red teamer doing an assumed breach scenario. Um, but Apple have gotten rid of this in maybe about a year ago and I think the way they did it is actually quite an interesting indication of how

they approach some of these security questions. So, what I'm going to show you if Oh dear. Ah, there we go. Um, uh, what I'm going to show you is kind of what the equivalent flow looks like, what they've replaced right click run anyway with, um, and just how hard it's going to be for you to get your your target users to do this. So, if you've got an So, you've got a user to download the file, they double click it, they see they can't run it, what you then need to somehow convince them to do is go to the settings um application, go to privacy and security, find the bit that says we block this file to protect your Mac,

click open anyway once, click open anyway twice, realize that they cut the video off too soon, and click to the screenshot, uh, and see that they now need to input an administrator username and password. I want to pause here for a second just to point out how kind of interesting this is. So um that file from like a traditional I guess Unix file permissions perspective is just the user's file. They're perfectly capable from like that technical level of just removing the quarantine attribute themselves. That's not an administrator action. But what Apple have kind of done here to try and put roadblocks in front of attackers uh is require administrator credentials to do it in the kind of pointy clicky

gooey way. Um and this is kind of uh so this is kind of indicates um like an interesting kind of dichotomy of um that Apple was trying to balance it which is to not lock technical users from doing stuff themselves. Um, but you could do this from tunnel easily. Uh, but try and put roadblocks in front of non-technical users getting fish into doing the same thing. Um, so just another gatekeeper bypass method and one that is actually potent going to work for you potentially uh is using scripts. So gatekeeper really at the moment is focused on auditing binaries. Scripts are text files. So, gatekeeper does not care. You don't need to get your script signed and notorized in

order to run it. Um, and so these are becoming like more and more interesting for for Mac OS malware. Um, so you've got things like native script interpreters like Oscript. This one is possibly a bit overplayed by now. Um, but you've also got things like Brew. So, if you're not familiar, Brew is like the unofficial Mac OS version of like Linux package managers like um apt or yum. Uh it's unofficial, but if you're on a developer's MacBook, you're almost definitely going to find it. And then of course uh IDE uh extensions uh essentially in that IDE extensions are basically JavaScript files run by uh an interpreter which is your IDE. So again uh it doesn't matter so much if they uh

if they're being if they're not u signed notorized free of quarantine. So, one of the things I I was kind of getting at with the um gatekeeper bypass with the admin password is that uh in a lot of ways these security um controls are just that little bit more lapse when it comes to stuff that targets stuff that's going to be used by technical users, right? Um on the one hand, a MacBook is an expensive Chromebook, right? It's for business users to go on the web and use their important business things where their job lives. Uh, and on the other hand, they're really powerful developer machines and like lots of developers really love them. So, App has

to kind of balance um not getting in the way of developers too much. Obviously, they do a bit, but not getting in the way too much while protecting the sort of pointy-clicky business users. Uh, and this kind of dichotomy is one of the reasons why ClickFix has become such a prevalent attack vector, especially for Mac. Um, so essentially, I'm sure you've heard of ClickFix by now, but essentially it funnels users who should never touch a terminal, uh, who don't know what they're doing with a terminal into suddenly using a terminal into copy and pasting commands from your malicious website. Maybe you've hijacked search, you know, poison search results with dodgy adverts, so on so forth. um you've

gotten them into this zone where suddenly all of uh Apple's carefully crafted security controls are just that little bit more lax. Uh so interestingly there there is this is getting more attention and there are kind of up and cominging security controls uh against this. I'm not going to go into sort of depth in them and how they work but Patrick W's got a good blog post on it um since he got there first and then Apple stole it and of course has other ones as well. Um but there's various ways in which um people are trying to like stop users from uh being so susceptible this by just by throwing up um warning messages and

things like that. How well these things work really time will tell. Um so just to kind of wrap up that sort of payloads initial access section. Um, if you if you want to deliver something that's essentially a binary, something that should be getting signed, um, but isn't, you want to try and bypass quarantine. And to do that, you want to try and find something that's a download but not a download. Um, if you can't find anything decent there or you just really want to use script interface anyway, go for it. You'll um, you don't need to sort of care about gatekeeper at that point. you don't need to care about your files having quarantine or not. Uh,

and in both of these scenarios, you're going to have a much easier time if you're able to funnel your users into terminal commands rather than gooey. But hey, go nuts. Try and find stuff for gooey applications as well. It's kind of more fun. Okay, so post exploitation, what do we actually do when we land when we we do all this stuff and we land finally on a Mac OS device? So, for the types of companies that we're really um talking about in this talk, um a Mac OS device is actually is almost worthless in and of itself. It's interesting to us in terms of what it can give us and typically that's whatever access our target user has to

their company's cloud resources. So, we're not even going to sort of think about getting root and bypassing SIP and stuff. going straight for the users's access to company resources. So, for example, if you've ever done uh red team or offensive security targeting like Windows or devices or just any sort of device in a company that is sort of cloud heavy, uses lots of SAS, um you want to go straight for the cookies and from the perspective having an implant on a device, you're in a super good position to start going after these cookies. I am not going to go into lots of technical detail about the different methods. I recommend looking up a tool called Chainbreaker. That's my personal

favorite. Um but in g as a general gist of the concept, if you if your targets using a crossplatform browser um like Chrome, well then your cookie theft methods are also going to be crossplatform more or less. You'll have to tweak them a bit. There'll be some nuances, but the the sort of core concepts are the same. So you things like um remote debugging, stealing from disk and then figuring out how the OS does the crypto. A lot of that stuff is going to be kind of analogous. If you are lucky enough to land on the MacBook of a developer, then you can start trying to find things like CLI credentials. Um so if they've used AW

CLI or maybe if they have code on their disc that you can try and like back door, so get hop onto um hop into CI/CD that way. um things that you might find when trying to sort of route around in the user's home directory. As a word of warning though, be careful of TCC. So, as we sort of brought earlier, TCC demands that you get user consent if you try and access desktop documents, downloads, and some other >> email as well. Yeah. Um this is really so if you're this is really going to hit you if you accidentally do like a recursive file listing. So you think you're just hitting home directory, but your C2 is actually going into all of

the subdirectories. You're suddenly spamming loads of prompts without meaning to. Um, if you So obviously if if you manage to land in a process that has TCC permissions, great. Do what you want. Access files you want. Uh, go for it. But if you don't have the TCC permissions you want, then really there's two approaches you can take. One is to spam prompts. Um, this really will depend on what process you're in and how gullible you think your user is. So, if you're if you're Google Chrome trying to access downloads, you're probably going to get away with it. They'll probably click okay. But if you're something really dodgy, then maybe you won't. Um, but if you're if you don't have that and

you you don't have that kind of confidence, um, then really I'd suggest just stick to the home directory. Um, if you're on a technical user's laptop, there's going to be dot files uh and these sort of like dot directories with like interesting cloud stuff in there that you can have a lot of fun with without ever trying to sort of mess with TCC. So once you've done that, once you've e like figured out a way to access the users's cloud um resources and things that are important to them for their job, uh really we've now stepped out of the realm of Mac OS red teaming and we're really just in the realm of standard red teaming. This is the point

where you now just need to think about what's important to the company that you're targeting uh and like how you can kind of impact that. So, if they're, I don't know, a company that sells I'm looking at projector. They're a company that sells projectors, how can you disrupt their projector supply chain or maliciously send a thousand projectors to the wrong union or whatever it is. Um, at that point, Mac OS is kind of irrelevant. And that is that for my little section. >> Thanks, Matt. Um, so a few defense and obset considerations.

Nice. Um, so, um, we've looked at a few of the core security mechanisms on Mac OS, but if you know what what would you do if you wanted to take things further and better protect yourself? Um, so, um, there is the Objective C Foundation um, kind of ran by Patrick Ward and his team that have released a bunch of open source tools such as Lulu, Knockk Knockock, and Block Block and other tools with similar weird names. Um and generally the idea is to give the user more control of their system either by uh providing more consent boxes um u for I don't know downloads performed by random applications and scripts or perhaps uh tools that allow you to uh

identify um library hijacking vulnerabilities on your system etc. Um, and if you're uh an enterprise or or corporate environment, you might consider something like Santa, which is almost like a more granular uh way of controlling your application control or doing the application control side of things. This was uh started by Google and I believe is now maintained by Northstack security. Um, but it yeah, not bad uh as an option for application control. Um, next we have ESF, the endpoint security framework. Um, so ESF is basically uh like a bridge between the userland side of Mac OS and the kernel. Um, and it kind of provides telemetry from the kernel into the userland um, uh, more specifically to applications

and binaries that have a specific entitlement. Um so this kind of system might be leveraged by security vendors such as AVs and EDRs to kind of ingest this telemetry. Um so a bit of history in the past Mac OS actually allowed you to load in kernel drivers or texts. Um but this was kind of prevented when I think with SIP and generally to kind of prevent tampering with core OS functionality um sort of opted for this uh ESF bridge. So the kind of telemetry that this will give you will be things like process execution, fork and executions and write events um and other things such as process memory mapping etc. So if we take um a sample malicious

Python script um something that kind of downloads a binary and writes it to a disk makes it executable and then runs it at a as a child process. What kind of u telemetry would that give us with ESF? So we in this case we've opted for red canary Mac monitor which is one of these open-source um ESF telemetry ingesters. There's a whole variety of them that you can find on GitHub. Um, and we've kind of traced the activity to kind of show it to you. So, uh, you'll notice when we execute the Python script, we'll have a notify execute event. Um, and this will kind of indicate the, uh, Python command line, uh, that we used. Um, and you also

notice the code signing details. In this case, you'll notice that u there's the Apple signature there because uh Python is a vetted and approved um application for Mac OS systems. We'll see that for the file creation, write and ch modding events, we have uh again equal granular kind of telemetry for each one of these things. Um, and something to note here is that the uh quarantine flag is marked as not having been applied on the downloaded file. Um, so this kind of ties into what Matt was saying earlier. Um, how uh kind of applications have the responsibility of applying this flag and in this case things like script interpreters such as Python do not apply this flag. So this

could be useful for your future engagements. Um, last we execute our uh binary that we downloaded with Python. And this case it was uh I think something like a C2 agent, but you'll you'll see that it's flagged in orange as in the exact event is kind of suspicious. And this is most likely due to the fact that the code signing um is like the signing element is a bit odd. You'll notice an ad hoc signature, which is almost something like a debug signature um or a temporary signature that allows for a file to run under certain circumstances. If you're curious, this is a Lulu alert if you had Lulu running on your system, uh which kind of detected the binary the

the binary download in Python and provided an extra layer of consent to the to the user. So, if you're kind of interested in the whole ESF telemetry side of things, um whether you're um an offensive security professional trying to make yourself more stealthy or perhaps a defender trying to identify gaps, you could use something like the EDR telemetry uh web resource. This will document uh what a lot of the top vendors kind of use and and what's not being used. And you can work with this information. So what have we learned uh from this talk? Um generally Apple um invests heavily in kind of preventing the execution um or rather unintended execution and and they they apply a lot

of control there. Um if you're kind of new to Mac OS once you understand some of the core uh functionality and and like understand the system you can kind of get creative as to how you're going to target it and work with the kind of environments they're associated with. Um, you can use ESF to your advantage as uh as an offender um to kind of understand your footprint and the IOC's you you kind of create. Um, and you should definitely be be testing your uh your attacks and such uh in labs and seeing if they trigger TCC events as mentioned by Matt when you're crawling systems etc. Um, and other than that uh we kind of wish you uh happy hacking.