Detection Dispatch (Alex's Version)

DE on Mac Finally Has a Champion. Her name is Olivia Gallucci.

Season 1 Episode 4

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 37:13

macOS detection engineering has had a documentation problem for years. Everyone told Olivia Gallucci she was locking herself into a platform nobody cared about. Then infostealers showed up, enterprise Mac fleets exploded, and suddenly her work was the most in-demand research nobody knew existed.

Olivia is a security engineer at Datadog living inside macOS internals...from Apple Silicon boot chain to ESF event families to IOKit abuse....and she is single-handedly dragging macOS DE into the light.

In this episode we get into:

  • Why you can't just flag osascript anymore and what to look at instead
  • The process tree trap that trips up every Windows-native DE who crosses over
  • Background Task Management: the persistence metadata everyone's sleeping on
  • Living off the Orchard binaries
  • Why your EDR is abstracting macOS telemetry from you and what to do about it
  • Jonathan Levin's books, Jaron Bradley's Sprite Tree, and the resources that actually matter

Follow Olivia's work on: 

  • oliviagallucci.com | [ret]2read — An OS Internals Newsletter (Substack)
  • LinkedIn: linkedin.com/in/olivia-gallucci
  • 2026 main stage at BlackHat 

Detection Dispatch (Alex's Version) is an independent detection engineering & threat hunting podcast. Rebuilt. Community-first. Featuring a lineup of the real and active projects pushing the limits of detection engineering, threat hunting, and everything in between.

SPEAKER_00

This episode is brought to you by Detections AI, the DE community's favorite share detection repo that just shipped a new Intel exchange. Create, share, and discover threat intel tied directly to community detections, adding more context and better intelligence to the same mission. Welcome back to Detection Dispatch. If you have been in detection engineering for more than five minutes, you've probably had the moment of trying to wrangle the Mac DE life. And maybe you're comfortable with Windows, uh, but in the Mac Unix, uh Linux world, it looks obviously very different. It's its own thing, its own beast with its own uh boot chain, telemetry, and obviously attack surface of its own. Uh, and also one that's not very well documented, well, at least as much as a Windows side. But my guest today has been really helping to offset that exactly when it comes to uh fantastic Mac DE research. So I am so honored to host Olivia Gallucci today. She's been quite literally living inside the Mac OS uh internals and just has been taking stage after stage after stage talking about uh OSA and the ESAPI and uh utility abuse. And well, I first came across her at actually the ThoughtCon conference, which is one of the most amazing conferences here in Chicago. Olivia, thank you so much for coming on the pod. I have been looking forward for this one. How have you been? What have you been up to? And what are you working on these days?

SPEAKER_01

Thank you so much for having me. I'm super excited. The things I've been working on these days are pretty much surrounding uh virtual table abuse and low-level API abuse, especially within IOKit. And the reason why I'm focusing in that area, as you said, is that I'm trying to document as much as what I can. And I found that they're IOKit is documented in terms of how to use it, but not in terms of its history and its security. So I really want to kind of shine a light on that because I have free time.

SPEAKER_00

Well, you are truly doing God's work because Mac OS CE truly is something that's not really well written about. People say uh, well, there's not a lot of malware that really happens on Mac OS, but that was before info sealers really took nice.

SPEAKER_01

100%. That was actually how my career took off. A lot of people were like, oh, like, are you sure you want to do this? You're like really locking yourself into this platform that people don't use or people don't care about or whatever. And it turns out once the info sealers came around, there was a lot of companies who were using Macs and all of that, and they just didn't understand them. And that was when my work kind of blew up. Like before InfoSealers, my work was kind of seen as useless, which is sad to admit, but like I really was treated as like a second-class security engineer until this came around. And now people are like, thumbs up. And I'm like, yes.

SPEAKER_00

I'm I'm so glad you stuck through that because now you this work is in an insane high demand. If you think about the kind of people that work on the intensive dev work, they prefer macOS. They prefer to develop in macOS, they're shipping product on macOS. Uh, and and to think that uh a little bit of history, to think that macOS didn't really have a well-documented telemetry, like a logging model up until recently is crazy. It's crazy to even think about.

SPEAKER_01

100%. I I agree. I think it was just their products were were so good and uh so few people used them except for personal computers. I guess they were just able to get away with it.

SPEAKER_00

For real. Seriously. Well, I we gotta know a little bit about how you even decided to get into this niche. You really hit the jackpot of choosing it. So, how did you end up in macOS internal work out of all places in detection engineering? Did you even start in detection engineering? I think you did more the offensive side first.

SPEAKER_01

Yeah. So I came into the security field through falling in love with the open source community who taught me like, I guess, the the basis or foundation of my knowledge. Then I worked on one of Apple's red teams. Okay. The macOS obsession happened because I disliked the idea of security through obscurity, especially in consumer products. And I found that I'm good at you know breaking systems down and documenting them because you know, I personally forget a lot of things and I found that if I write them down and put them on the internet, it helps me because I know where to find that information if I want to get uh back into it. Apple Stack sits at a really interesting intersection. So we have Darwin and XNU under the hood, a lot of service-oriented behavior in the user space, and then a very opinionated trust pipeline layered through secure boot, code signing, notarization, gatekeeper, and expertect. When I got into vulnerability research, that gave me enough complexity to find Apple systems interesting and enough structure to obtain good detections. The detection engineering angle followed because I wanted to intern my internals knowledge into triageable signals. And the whole info stealer thing came about around at that same time. So it worked out well.

SPEAKER_00

Truly, you've got this foundation from quite literally the inside of it. So, and which is I can't think of a better way to be doing now detection engineering if you fundamentally understand how the system works. So I want to get into the how of that, because I think that the thing most Windows Native DE hit first when they approach Mac OS is just like, where do I even start? What do I even look at? Uh, which of course, the artifacts and the telemetry look very look very different in both worlds. So, in terms of like the mental model of the data, what's available? Here's where I think it gets really tricky for people that are coming from the Windows world, all of these event IDs with all of these processes that map to event IDs. And that's been you that's been pretty open and they're exposed. And it's really where kind of the telemetry gravity really gravitates towards, I guess. But in Mac, it's not so much, right? Can you tell us a little bit about how you're thinking about it this way? What's kind of the most underrated piece of macOS telemetry that you typically go for and look at?

SPEAKER_01

So, yeah, a couple things. So, first of all, that confusion or that need to uh be able to even get into the Mac space is by design, all of Apple's stuff is like custom built and very specific to uh Apple's ecosystem. And because it wasn't documented and all that, that really turned a lot of people away because the amount of time they were gonna have to spend to even understand it meant they were gonna have to sit down and like reverse engineer the operating system themselves because they weren't gonna be able to get the logs and other things like that. And the other thing is to this day, there still is um a barrier because if you go to like the MITRE attack matrix, which is so super cool, I like the framework and all that. If you look at Windows, you can see all those event IDs, you can see all of that. And then you go to the macOS one and it's like, oh, they have like a sentence on like how this works. So like that's great. Um, and that's just kind of how it is. And so when it comes to the mental model, the endpoint security API is Apple's user space observation model for Mac OS. So Apple wants tooling in the user space through system extensions like endpoint security, driver kit, and network extensions rather than third-party KX. Extensions run in the user space because they are like preferred over kernel extensions since they only get the privileges they need to function. So I personally start with the event families that preserve causality and like security intent. So think things like execution, process lifecycles, high-value file mutations tied to persistence, and trust boundary events around gatekeeper or exprotect. That said, some people end up with a lot of noise because they're treating every file touch or GUI adjacent event as inherently meaningful without adding service management context, code identity, or uh user intent. My prioritization is to anchor on exec, fork, and exit, like persistent relevant files and metadata mutations, even things like service registration or launch services, then enrich with signing, notarization, bundle ID, team ID, and whatever trust verdicts the platform emits. And this just allows you to get a much higher fidelity signal than you know, flagging on uh one malicious signal, like at the beginning point of installation of malware.

SPEAKER_00

Any noisy traps that uh we should be aware about.

SPEAKER_01

100%. Um AstaScript. I a couple of years ago, you know, just flagging on AwesoScript was like, ah, you know, we shouldn't be using it. But now uh I really think people need to stop pretending that this is a new technology and look at everything after the Awescript part. One example of this is that, you know, AI companies that, you know, they they pretty much vibe code themselves and install and access Mac OS through Awesuscript, which is really suboptimal for detection engineers. This is why just flagging uh AstaScript is absolutely terrible and why intense data analysis needs to be done on ASAScript commands because both attackers and legit companies are installing and using software and files through it. Essentially, if you only look at AwesoScript, like it's just constant alert fatigue, which we used to be able to do like a year ago. But if you look for AwesoScript plus what it caused, you can usually get somewhere.

SPEAKER_00

I want to say that if you're looking at it within the concept of your CrowdStrike or your EDR, it does throw off the process traits. Yeah. And so, in terms of what's available, what's worth mining, how are we thinking about the parent-child relationships? Gets really messy on the window side, but it's consistently messy. In the Mac world, you've got XPC, the something, something suddenly launched, and the work is not the thing that shows up as the parent. And you have to look at the behavioral correlation and it falls apart if you're not thinking about it the right way. And that's something I really had to kind of teach myself and unlearn and relearn. Uh, how do you think about the process tree in when X XPC is in the mix?

SPEAKER_01

Yeah, so the trap, in my opinion, is assuming that Unix parentage equals user intent. Mac OS service lookup is here around here, bootstrap namespace driven, and LaunchD manages like daemons, agents, and service registration. XPC services exist specifically to split up applications into smaller, more reliable, and more isolated pieces. So if you only look at like PPID, you'll miss the actual initiating app, the session namespace, and the service label that explained why that action happened. So I treat parent-child relationships as 100% necessary, but not sufficient. I want the parent, the responsible app identity, if available, the service or helper label, the session, and the temporal chain that said there are graphical programs that help with this. They're local, so you use them locally on the Mac. One of them is Jaron Bradley's Sprite Tree. And I just mentioned this because if you're viewing processes through the terminal, a lot of this information is there. It's just difficult to view because of how much information they throw at you at once.

SPEAKER_00

The the GUI that that Sprite Tree duh has is definitely a good visual. I I first came across that in have you uh read this book by what's what's who's it from? Uh yeah, Jeremy. Yeah. Oh my god, he made that.

SPEAKER_01

Yes, he made that tool too. And that the book is absolutely amazing. I've done the activities and all that, the the pictures and all of that really.

SPEAKER_00

The Sprite Tree and also the book. I was like, oh wow, no wonder. No wonder he used it in inside of his book. Living off the land attacks in the in the mac OS world, it's also referred to as LOO BINs. You brought up OSA script, which is clearly probably the prime example. The living off the land attacks. By the way, what is what is the L-O-O bins? Is that lol bins? You know, lol bins in in Windows, but why is it LOO bins in Mac? I've seen it.

SPEAKER_01

I think it's living living off the living off orchard, living living off the orchard? Because it's Apple? Well, it's something orchard. I forget the exact like abbreviation, but it's something or living off orchard. Because it's Mac, because an Apple Orchard. Yes.

SPEAKER_00

Is that is that really why, or is that just a coincidence?

SPEAKER_01

Um, it's I'm not sure if like Apple came up with that terminology or whatever. Um it's probably someone else probably did, um, to be honest. And then I think it just stuck with it.

SPEAKER_00

So okay. So then what are the top macOS or Orchard binaries that you're seeing get really abused right now? And what and how does that reflect in in the in in the telemetry?

SPEAKER_01

Okay. Um, so first off, you're 100% right. The big one is still ASAScript. Uh, Apple Script is a bridge into Apple events and into shell execution.

SPEAKER_00

Yeah.

SPEAKER_01

Um, I'd also say things like script editor. So um there's an app on macOS called it's like script editor.app or script.app, which people often forget about because people don't really use it. But what that does is it allows you to write and execute code. The third bucket is service management tooling and interfaces such as launch CTL and bundled uh helper registration paths, because those are how execution turns into persistence. In telemetry, the interesting pattern is never really like the binary name itself. It's really the chain. So, like uh user action or app, AwesoScript or helper invocation, downstream shell or file mutation, and then service registration or background task state change. Overall, I would watch for the binaries that bridge loser user land automation into execution and persistence. And I think overall, like one of the things I've noticed is that AwesoScript and service service management paths matter more than like a utility name, which I think sometimes people look for.

SPEAKER_00

I see. And that's and that's what you've been going like stage after stage about.

SPEAKER_01

There's that's one of the things. And then the other thing is something known as background task management and its state and its surrounding metadata. So a lot of people, I'm not sure why people haven't focused on this as much. Like it is a little bit more historical because it's been around. But Apple gives us a structured view of login items and background items through system settings, uh, a command called SFL tool dump BTM and the unified log subsystem and the attribution data that maps helper executables back to the parent application. Mac OS also exposes gatekeeper events and expert uh detection details through endpoint security, which means you can correlate like an untrusted thing ran with a persistent helper that was just registered. And I think a lot of teams are still overfocused on like scanning launch agent directories and underfocused on the state that Apple is now explicitly maintaining for them. So to get good detections on Mac, I wouldn't use like a single log line or anything. I try to use, you know, background task management and its surface around login items, bundled helpers, and service metadata.

SPEAKER_00

Have you run into, I guess, because now you're more on the vendor side of things, but have you run into because I've run into getting the leadership buy-in to try to get more of this kind of telemetry onto the detection engineering side. And whenever I would constantly try to, you know, ring uh ring the bell on it, it was always, it was always like this would take an insane amount of re-architected work around this. Like how, how much, how, how much, you know, do you really need this? Like the lights are still on. And it was this whole thing where it was never really that uh taken seriously. Have you run into anything like this before? And how and and how can DES help make a case for getting this level of visibility from Mac?

SPEAKER_01

Okay, so that it's a super hard problem because the amount of so like if you just run like unified logging for around a second on Mac, you'll have like a hundred unique distinct logs.

SPEAKER_00

Yeah.

SPEAKER_01

And like shipping that off somewhere is gonna be crazy expensive. The thing is, EDR companies, what they'll do is they will look at these events and they won't explicitly tell you they're looking at these events, but they'll ship part of that information and they'll keep part of those logs on the Mac and they and they'll ship part of that information out. And that's why you're still able to see things like the file path, uh, who it executed as, and all those types of things, right? So the EDRs are abstracting this from the detection engineers and they do it in a way that will sometimes even make like macOS logs and Windows logs and Linux logs almost look very similar because they'll try to like make it uniform. And I understand that that can be helpful, but if you're a company that's using Mac or whatever, you you kind of need to focus on Mac telemetry a little bit more.

SPEAKER_00

Yeah.

SPEAKER_01

There is one EDR company, I haven't used them, but it's called uh Forion. It's written by two people who are two Mac enthusiasts and they focus exclusively on Mac. So they will actually collect that telemetry and you can go in and check which telemetry you want shipped. You can go in and say, hey, I want this telemetry shipped for these three Mac books because they might be a little bit more uh privileged or have access to sensitive data. So they're really the only company I know that's doing this and shipping it for enterprises. Otherwise, you're kind of stuck looking at it on your machine, or else you just have to build your own tools, which is gonna take probably years. Like, yeah.

SPEAKER_00

No, that's true. And because Macs take up such a small portion of the whole stack, they are not gonna dedicate the TLC that that it needs. Have you come across any open source, maybe not maybe agents, but sort of like the shippers, the the collection of it that maybe that maybe they do some kind of normalization or translation or adding of enrichment to it? Because I've that's what I've been on the hunt for. I haven't I haven't come across anything.

SPEAKER_01

You could probably do something funky with like OS query, because OS query is open source and you can modify it in the way you want. The tricky part is that there's so many different versions of OS query and all of that. But I think the way that you could maybe do something is you could use like a GUI tool like Mac Monitor or something, and um be like, okay, here's what's going on, here's the type of events that I want, here's what's useful, and you it will show you like the statistical breakdown of how many events are firing and how many events you would actually need to ship. So you'd be able to do like that cost analysis there, and then maybe use uh OS query to get your findings from that and then ship it to wherever you want.

SPEAKER_00

Definitely. I've I have noticed that in the DE world and the way that teams make up their DE uh sort of like role team dynamics, they're not assigning just one DE in the Mac OS land. Like they're the same DE has to run detections for Mac OS Windows and of course, like the cloud and I and I just so much to it's so much to wrangle. I'm like, this this requires a whole dedicated just domain practice alone. So this is just always just some something else to add on to the backlog. It's it's very underserviced, I will say.

SPEAKER_01

Yes, yeah, and it's it's super difficult to the amount of time because Apple will also update their systems without notice. So you have to then go like read the new sear publications and all that to be like, oh, well, endpoint security was just rewritten. So now I need to know what what's going on with that.

SPEAKER_00

Oh my gosh. Do you have an alarm or do you have a notification for when they do? How do you subscribe to that?

SPEAKER_01

I don't, but there's a way to get this information a little bit earlier in advance. And so you'll notice that it's super hard to set up like automations on Mac if they're on, if they're not on like enterprise systems and it's because of the way privacy stuff happens on Mac. It's called Apple Business Manager. This program allows EDR companies and companies who have like a need to know how that telemetry is accessed, and it sets up a little bit more of a working relationship so that when that update's released, the EDR companies can have a little bit more time to update their platform so that once you update your Mac, your EDR and all that stuff won't break. Do EDRs still break after updates? Yes, they do quite a bit, but it does lessen that burden a little bit.

SPEAKER_00

I love that. I thank you for sharing. Last segment, persistence, of course. We can't not talk about persistence in the Mac OS world. We've talked about telemetry, we've talked about process trees, we've talked about uh native binary abuse. Uh, the other place that Mac tends to go with persistence is, and what I've been reading a lot about is launch agents and launch daemons. They're getting a lot of airtime right now. The persistence catalog obviously has gotten a lot more interesting in the recent months and a lot more creative in the last couple of years. So is there anything that's uh it's get is getting slept on right now in terms of in terms of these?

SPEAKER_01

With the launch agents and launch daemons, I won't say anything's really being slept on. There's a reason why like they're still making headlines. However, there's other means that are possible again to bring it back to like the uh the app bundled helper and login items ecosystem around SM app service and background task management. For reference, SM app service controls uh these are like helper executables inside an app's main bundle and can register login items, launch agents, and launch daemons as helper executables for the app. Uh app also provides BTI inspection points and approval rules based on the bottle ID, team ID, and service labels. And that means that persistence increasingly comes with metadata that we can consume, and the missed opportunity is failing to query and baseline that metadata data. And what I Personally, I found is that file system only hunting will miss some of that higher fidelity context. It's just does your EDR or your company allow you to uh access that information in a way that you can actually scan it? So I think the better or the best model, at least right now, is asking what background capability did this app register? How is it attributed? And how does Apple expose that state?

SPEAKER_00

I like that. A lot of our a lot of the core detection engineering work is to constantly test our detections. Have you played in the world of atomic cell tests for your macOS detection rules? What has that looked like in terms of in terms of keeping kind of the latest and greatest and the health of your rules overall in good shape?

SPEAKER_01

Yeah, so I think the automated testing, I think helps some people. Like you can treat it as a matrix. And then you'll care about is like scope, registration mechanism, trust state, and operator experience, which would be things like user versus system context, launch agent versus launch daemon versus app uh bundled helper, managed versus unmanaged signed and notarized versus not, and then whether the registration produces BTM state, unified log events, and launch details with the labels or all three. And the way I personally do it though is that because EDRs will send you what has actually executed on the Mac, I use a test Mac. I I'll I'll just say, here's my detections. Can you write a program that will trigger all of these detections? And a lot of times, like when you have past attack data available, you can just change out where they would be connecting to a C2 or whatever, and I'll just put like oliviagalucci.com so it won't like nothing will happen. And it will just run this full attack, but with just like benign stuff, and you'll be able to see whether or not everything's properly working. And of course, Apple's docs tell you where like the launch D property list lives, how login and background items are exposed, and how to dump that state and which matching keys exist and manage profiles. The the biggest gap really isn't like, oh, we forgot launch agents. It's like we didn't correlate that BTM state, the service label, code identity, and trust events into one analytic. And as a result, the incident response team can be really fed up, but the detection engineering team is like everything's working.

SPEAKER_00

So yeah, I I will say I haven't have yet to hear, you might not like to hear this, but I have yet to hear anyone on the forensic side and the IR team say that they love doing forensics on Mac or on Mac or Unix. Uh it it's it's it's pretty brutal to do any kind of forensic work on there uh with with what we have. Um and I will say it's probably easier to build detections. I mean, they're both hard, but it's easier to build detections rather than being on the alert dissection side and figuring out you know what exactly happened. And it is such a different world in terms of if if they're not the same person, they're usually not.

SPEAKER_01

Yes. And it's it's super difficult too because Apple, in many ways, even they're like their enterprise laptops, they were built with with privacy in mind, which adds to that. Yeah. And a lot of the forensic tools companies don't have money for. There's a lot of really, really good Apple forensic tools, but people don't want to spend like a ton of a ton of money on them. So it's usually just like government agencies that will will buy the the fancy tools, and the rest of us are not that open source tools are bad by any means. It's just like, you know, a lot of them are outdated and or their maintainers will stop, you know, maintaining them.

SPEAKER_00

So yeah, that's that's true. Is there anyone in the community in the Apple community that you tend to follow for any any other research? Because I feel like you're the only one that I know of.

SPEAKER_01

Nah, so I I'd I would say where I fit is really good with like bridging non-Apple people into the Apple world because I like to do really in-depth documentation. But the way that I do my research is I use other people in the Apple community. So, first of all, Apple's materials, they they will publish like these huge, like 96-page documents. I will print them out at work and go through with a highlighter. Oh, wow. So I'll do that. And then there's another guy, his name's Jonathan Levin. His books are like a foot and a half long, like they're super tall. It's a book that I would honestly be caught embarrassed to read. I wish he would change the setup. So if you ever listen to this, Jonathan Levin, your books are embarrassing to carry around. But anyway, a little bit. Huge. And they're they're quite expensive, but they're well worth the money because this guy like sat down and like just like reverse-engineered the OS before Apple published any of this information. So you can really see how the computer is working, how iOS is working, how they overlap and where they don't. And even though like these books at this point are 10 years old, they're still the foundation of how these systems work. And a lot of companies, even companies who, you know, build and make Macs will use his materials to train employees because of how good it is books are like they're so incredibly in-depth. Um, and so yeah, that's why I'm recommending also reading Jonathan Levin's work because otherwise you're just gonna have like a couple blog posts and all of his books aren't really on the internet. He did a really good job of locking those down. So Publisher Village.

SPEAKER_00

Can you only can you only find them at like the the DEF CON book book village or where there's where they sell books? No.

SPEAKER_01

I have no idea. I will say Levin is incredibly hard to get in contact with for some people. I like he'll be like, oh, you can either he doesn't like it when people order from Amazon because he doesn't get as much of a pay cut, but you can order from Amazon. One of my friends, unfortunately, never got her books, and so I'm not sure to recommend Amazon at this point. But if you like message him on PayPal and you're like, hey, can I get XYZ books? Um, he'll send them to you. I will say I ordered all mine on Amazon. I got them just fine. Uh, he also can like see who's ordering them, and like sometimes he'll put a little note, like he put a little note and he's like, Thank you so much for covering my work, which I thought was really sweet. Um this is really uh if you know, you know kind of a thing. I mean, I don't, I think it's just because all this stuff was considered to be irrelevant. Like Levin was someone who like documented this stuff before it was cool.

SPEAKER_00

Oh my gosh. So between him and John and Jaron Bradley and Olivia Millennich, I think you've got a pretty solid uh uh you know, adding to your RSS feed. Thanks, thanks. Well, I I do have to ask, um, were you a part of the uh encounter of the Mac Mini shortage when where everybody tried to run open claw on their Mac Mini? Did you ever try to do that?

SPEAKER_01

No, the I was not gonna jump on that open claw bandwagon because um, as as I'm sure you probably know, you know, girls like you know, we we need to be careful. And when you install something on your machine that could essentially just like dox everything about you and your family and your home, um, I was like, yeah, I'm not signing up for that. But uh there's that. And then the other thing is is that while uh I did work on Macs before, we always were using the hardware, and as a result, I now collect Mac books. So although I don't have a Mac mini and it would be awesome to have that processing speed, I have enough Macs for a lifetime.

SPEAKER_00

I see. Yeah, I see. I I will say I I truly believe that was a really coordinated influencer campaign movement to orchestrate that Mac shortage. Because everyone started to say, I'm doing this on Mac Mini. And and truly there it became a nationwide shortage. But if you look back and seeing how often or how really they're going back into these agentic workflows, it's really not I mean, can are they really that necessary? I think the true craft is to really figure out if you can really incorporate it into your real student day, other than just the fun of building one to begin with, because it's so much lower entry to do stuff. That's fun and that's cool and that's entertaining, but how can it actually plug into your daily life? That's I don't think anyone's really perfected that truly.

SPEAKER_01

I agree. I 100% agree. And it really frustrates me with like the amount of executives and stuff. They're like, we're replacing people with AI. And I agree there's certain tasks that might not need to be done in the same way, but it's like the thing is, is there was a reason why that person was hired, and you know, the AI pipelines they're they're failing for a reason, they're not in there for a reason. And as a result, like they're not only is that one person you laid off, like, yeah, they're big frown and all that, their team is up big frown because all the things that person was doing, they now have to do because AI isn't replacing them.

SPEAKER_00

It's not, it's not, and then it's not all this content where it's like, oh, my Mac mini, I have now an agent that does all of my all of the business units. They each have an agent, like a worker be agent, doing doing twice as much output as as a human could. And the output is absolutely atrocious.

SPEAKER_01

Yeah. One of the presentations I did was on my AI workflow on vulnerability research. Yeah. And the there was a company there that had published their analysis, and they were like, hey, you know, we found all these really dangerous bugs. And then a couple, and I felt really dumb. I was like, Am I going to be honest and state that even when I use deep research and all of that, even when I've spent like three grand training my AI models on Apple's open source code, like I still haven't been able to just find a vulnerability with just AI. And it was super weird because everybody else was like, oh, we've been able to do this, we've been able to do this. And then like a hit piece on this company came out a week later about how they had self-sided themselves, done all these things. And I'm sure this company has been able to find some amazing vulnerabilities and stuff, but just the idea that they were finding like tens of thousands and then had to update their statistics to be like, oh, we trained it on vulnerability data that was already public. And I was like, oh. So you never really know.

SPEAKER_00

And you know what? I have yet to see macOS be a part of the uh the whole mythos marketing program, I project class wing thing.

SPEAKER_01

I will say I don't know. I will say I think people are doing their best at fixing these bugs, like internally at Apple. That's not information like I know for sure, but like Apple's a big company, so they they're probably running mythos on their own computers, you know.

SPEAKER_00

Obviously. But they've got their own version. Well, Olivia, this has been everything that I have hoped for and more, obviously. I've been looking forward for just the insane amount of things that the entire community can learn from you. And I truly thank you for all the work that you do because I know that you do it fullheartedly and uh with the best intentions ever. And we need we need to see more of it. So please don't ever stop doing that ever. And also just the thing I keep coming back to in terms of this conversation is, and I keep trying to evangelize, is that Mac OS should not be a niche problem anymore. I think the fleet is there and malware does not not happen on Mac. Uh, so I think we should move beyond that mentality. And uh the detection community has been very much playing catch up on this tool, but we have you to think to really offset that in terms of how we're thinking about it. So thank you so much. Before I let you go, where can the community follow your work, your newsletter, your blog, any upcoming talks? Will you be talking at DEF CON Black Hat in Vegas this year?

SPEAKER_01

Yeah, so the best places to uh see my research are OliviaGluechieve.com and the Red to Reve newsletter, um, my social medias, of course, and then of course conference talks. Yes, I will be Black Hat mainstage. Could not believe it. I was like, dang, that's crazy. But the other place to really follow the stuff I'm doing and the stuff the public Apple research community is doing is a foundation called Objective C. There's a ton of talks online. Uh, folks from Google Project Zero, Patrick Wardle is the guy who runs it. He also published a ton of Mac Mauer books and all of that. And all of them are extremely open because of all the things that Apple has kept secret. And as a result, you can look at all the tools and all the papers and stuff that they've published. And I think those are generally a pretty underutilized thing because reach out to any one of the people giving those talks or those authors, they will do everything to help you because they have been through the struggle.

SPEAKER_00

I bet, I bet. And that oh, that objective uh by the sea conference, that's in Hawaii. What a oh what a great place for a conference.

SPEAKER_01

Yes, Maui. It's I've been to the hotel they posted it at but before when I went to my first one. It is amazing. Like it's right on the beach, the pools are great, the weather is incredible, and the hotel like never gets rain. And as a result, like most of the hotel is outdoors and they have this crazy architecture.

SPEAKER_00

It's really oh my god. I'm so excited for you. I I I feel so uncultured when I tell people that my favorite place in the world is Hawaii. I've been to a lot of places. Like I've I've really I really have had the blessing of going to a lot of international places, but it's like not everything hits all the check marks. Like you're not gonna get a blue beach with white sand with non-rocky beach, like bright blue water, like it's and also like hiking and mountain, like you just it doesn't hit all the check marks marks, and Hawaii does. And I feel so uncultered for saying I love Hawaii so much.

SPEAKER_01

No, I think that's awesome. I like Hawaii too. I think it's a very, very thumbs-up place. And I I considered moving there, but the thing is is that I need like Uber Eats at 3 a.m. And that's hard to do. And Hawaii.

SPEAKER_00

It is it is very I the island life is is hard, yeah, to get to get food from for sure. And it's just always very expensive too.

SPEAKER_01

Yes. Oh, I remember I woke up. This might be a little too much for the podcast, but I remember waking up and I was like, oh, I know there's ho there's food downstairs. I'm gonna go get some bacon and eggs. It was fifty dollars.

SPEAKER_00

Jeez, I know they really gotta figure that out. Maybe with the drone situation, you would think that'd be much more advanced. I don't know. There's there's a girl that's rowing from California to Hawaii right now. Well, that's crazy. I think I've been keeping up with it. She's she's halfway there.

SPEAKER_01

That's awesome. I didn't know that. Is it like in a little boat? Uh in a yeah, a rowboat in her rowboat. That's crazy by herself.

SPEAKER_00

Yeah. Yeah. Wow. She's almost there. I'll I'll let you know when she's there. Sound good. Well, if you are building Mac OS detection, then you don't have Rut2 Read in your RSS feed, your inbox, or wherever you consume your content, you should go fix that today. All of Olivia's links will be in the show notes. This has been Alex's version of Detection Dispatch. I'm Alex Rotato, your host. We'll all see each other very soon.