BSides Buffalo 2026: Bad Apples: Orchestrating Movement and Execution via Native macOS Protocols

Um this is William Gibson and Briani uh doing a lightning talk on bad apples orchestrating movement and execution via native max. Take it away guys.

Yes. there. All righty. Hi everyone. Uh, thanks for having us here. Excited to be here at Bside Buffalo. Uh, I'm Julian Gibson and this here is my co-orker Ryan Conry. Uh, we both work for a company called Cisco Talis. And today we're going to be talking about our research that we got published recently called Bad Apples, weaponizing uh, native Mac OS primitives for lateral movement and execution. So, the core idea of this research is simple. As Mac OS becomes more common in enterprise and developer environments, attackers do not always need custom malware or novel exploits, uh, a lot of interesting capability already exists inside the operating system. Uh, though through Apple script, remote application scripting finder spotlight metadata

launchd, and built-in transfer utilities. So my portion of the research focuses more on Mac OS execution behaviors whereas my co-orker Ryan's here focus more is on lateral movement. So today we'll connect those together in one post access story and uh my friend Ryan here is going to start by framing why all this matters now and especially for Mac Enterprise. So historically the enterprise has been made up of mostly Windows devices. Uh and up until recently we've seen a bit of an uptick in that share going more towards Mac OS devices. Um because of the historical context of the market share we feel that there is less of a focus on Mac OS security compared to

something like Windows security. Um some of this uptick that we have seen for Apple uh has primarily been with that are software developers or IT professionals or people in the seuite executive level because we are seeing an uptick in roles such as these that are using Mac OS devices. We can expect that these machines are going to have things like source code or SSH keys, cloud credentials or sensitive business documents on them which would make them a prime target for their attackers.

And when we approached this uh research topic originally, we came in with the assumption that most of the lateral movement would be performed with more SSH centric uh approach. Um and as such most of the things that would be monitored would be more SSH uh artifacts on the device. And this was kind of backed up by some of what we saw on the loopins project which is the Mac OS uh version of the wall bass project. Um I think there was only maybe two binaries that were marked as viral movement and they were both leveraging SSH as well. Uh so we wanted to take more of a focus on tools that were uh Mac native or easily obtained uh

through a package manager such as Brew and preferably would not have reliance on

technical difficulties.

All right. So the this slide here you can see uh is important because we do not want people to walk away thinking that this is one required sequence. Uh these are distinct technique fins. We looked at application scripting and atenski uh for remote control. We looked at osa script and terminal as execution paths. We looked at finder for discovery and spotlight metadata for staging. We looked at launch agents as a persistence trigger. And we looked at multiple transfer channels such as SCP, SMB, Netcat and SNP traps and SOCAT. In real instance, these may appear independently but um and an attacker may use only one or two. So correlation should come from telemetry not from assuming every behavior in this.

So to understand the first set of behaviors, we need to understand what uh RA is or remote application scripting. So uh remote application scripting formerly known as uh remote apple events where extends Apple script interprocess communication across a network. Uh under the hood this uses the APC protocol and Apple event. The important point of this is that uh remote application scripting is not a malware feature. It is a legitimate administrative and automation feature. a controller can send Apple events to a scriptable application and on the target Mac. >> The target application then performs some sort of action. This changes the way we need to think about remote activity. Instead of a traditional model where a remote login

spawns a shell and runs uh commands, uh remote application scripting allows one Mac to remotely influence applications on another Mac through application level IPC. That change is doing uh or for defenders that the pivot identity uh identifying cross IPC and application level not just shell commands. So once we have an understanding of uh remote application scripting as a remote control primitive the next question was whether we could turn that into a form of execution.

This was one of the more interesting parts of our research from my side. Uh a straightforward idea uh would be to be uh have remotely tell system events to run a shell command but Mac OS blocks that path with a familiar negative handler uh behavior shown in our published research. So in other words, there's an international security boundary that prevents that direct remote shell execution. The useful finding was that terminal.app behaves differently. Terminal is designed to accept uh script driven terminal actions. So instead of treating remote application scripting as this thing that executes code directly, we treat a remote application scripting as a control layer and a terminal as the execution proxy. Conceptually the flow looks like this.

Remote application scripting sends Apple events to terminal.app. Terminal starts the shell site behavior. The payload materials transported in a safer encoded form, decoded onto the target, permissioned and then invoked by the shell. The key defense point is that the suspicious behavior is not just basic exists or bash exists. It is the lineage and context management. Apple events the influence of terminal um terminal producing shell activity and remote execute uh automation context behind it. Up next, we're going to show some related movement case uh using remote application scripting not just to execute but to discover useful information on a remote map without a normal shell.

So from a lateral movement side, remote application scripting is also useful when you are not trying to execute payload because finder is scriptable. A controller can use remote application scripting to ask binder on the target system for information. For example, from the research we were doing, we uh query mounted volumes. Uh that can uh when you query mounted volumes, you can reveal network shares, external storage and other useful context without creating the same kind of interactive shell telemetry defenders may expect to find. This matters because a lot of detections are focused on process execution trees. But with Apple events, some of the interesting action is happening through application behavior and IPC for interprocess communications. Want to try

this real quick? >> Yeah, sure.

Can be detected by the monitor by your system.

You want to try that.

Hey. >> Yay. Okay. Hopefully we're back up and running again. Um >> so uh I'm start off the top of the slide here real quick but from uh from the lateral movement side remote application scripting is uh also useful even when you're not trying to execute because finder scriptable controller can use remote application to um application scripting to ask finder on the targeted system for information. One example from research is that we recorded mounting volumes which can reveal external network shares storage other useful context to see. So this man does a lot of detections are focused on process execution issues but battle events some of the interesting actions happening through application behavior or process communications. So if the detection

strategies don't like show me suspicious shell commands this type of discovery will occur quiet. So of course SSH still matters. The nuance is that even when SSH is a transport uh Mac OS automation can change what the activity looks like. So uh SSH still the obvious common but one of the things we wanted to highlight is that SSH into a map does not only mean classic shell commands. When an attacker can invoke OSAS script over SSH, they can interact with Apple scripts capabilities that can include system information, finding manipulation, gooey automation or shell execution through Apple script handlers. So defenders may see an SSH login and think they understand the session because they have the SS SHD and

shell logs. But in most descriptives use some of the impact may occur through Apple or finder um finder side effects rather than a single command tree. So the important detection point is to treat as you can connect remote session to Mac OS automation services. Um so yeah so one of the next uh uh things we want to talk about is one of the stranger areas of our research uh where we use finder comments and spying metadata as a staging space. Yeah. So as Billy mentioned remote application scripting uh typically interfaces with a Mac application. So we wanted to see if we could use this relationship to kick off our viral tool transfer uh research. Um we also kind of

came in with the understanding that a lot of endpoint security products will either be fingerprinting or scanning the file content to determ if it's malicious or not. So we wanted to try and think outside the box and see if there's another way we could stage payload. Um and that's where we became aware of spotlight metadata. So if we use remote application scripting plus finder, we can create an arbitrary file and then rather than write to its file contents, we can write to the spotlight metadata to store a payload. Um the payload can later be uh uh obtained, decoded if necessary, and then executed. Um and this is kind of a little more of an interesting way we found to transfer a

payload to a a target device. And while the talk is mainly on lateral movement and execution, we couldn't ignore the the opportunity of persistence here. Uh so we were thinking that we could have a P list in the user's launch agent directory that would then use finder to read the comment on the file, decode it if necessary, and then pipe it to some script interpreter for execution. And that takes us to a few more lateral transfer uh methods that we researched. Uh as we kind of mentioned from the beginning, uh we wanted to look at things that weren't just SSH. Um at the top of the list, we see secure copy and SFTP, which we use SSH under it. Um that

was kind of just our baseline, but we wanted to look at some other things that were not just SSH. Um, we also wanted to look at things that might blend in with that uh typical enterprise network traffic that we might see. We mentioned that more software developers and IT professionals have been adopting Mac. So, we wanted to see if things like netcat and git could also uh as tool transfer. Um, and last we wanted to kind of look at things that technologies and tools that may not be typically associated with uh tool transfer but we could repurpose for uh remove and we just wanted to uh shine a spotlight on a couple of the methods

that we used. Uh the first one was SNMP trap. So, SNMP is typically used for uh monitoring network devices and by using traps and customer IDs, we can successfully transfer a payload from one device to the other. Uh TFTP, which is typically used for bootstrapping devices and more workflows, kind of falls under that IT uh typical workflow traffic that might blend into an enterprise. Um and finally, SoCAD, another tool that is not as popular as Netcap, but still used by network professionals. Uh might not typically be viewed as something that could be uh tool transfer utility, but we uh we thought that might be a convenient blind spot that we could take advantage of. So we kind of wanted to showcase here

that rather than just hunting file names, we should be looking for the behaviors of uh some of the techniques we executed. Uh we want to be looking at things like unusual process uh lineage like RS execution. Uh anomalous behavior such as uh frequent reads and writes to file comments. And lastly, unusual or abnormal peer-to-peer traffic uh as it pertains to SMP, TMTP, and uh tools like that.

So the controls should map to do not treat this as one model for remote application scripting exposure. uh the vendor should disable remote uh applications by default and only allow on devices. Uh the same goes for remote login should be explicitly managed not casually enable clean. Uh for transfer services disable or restrict TFTP and SNP services monitor for watching changes to enable network facing changes unexpectedly for network exposure using Mac OS application firewall and stealth mode where appropriate to reduce unsolicited reachability and for the execution side TCC is very common also transparency consent control. Uh the automation category governs whether one application can control another expected script or process terminal or finder that should be restricted through ant

mobile management where possible and treated as signal window. The larger point is that Mac OS already gives the vendors some control. Point is the challenges and making sure that they're deliberately configured properly. So we'll close this main section of our research here with the takeaways uh we want the vendors to remember here after this talk. Um yeah so the main takeaway here from bad apples is that Mac OS movement and execution permits are native, persistent and huntable. They are native because they use things like Apple built uh These things have the bill for administration, automation, metadata and file transfer. They are persistent because some of these mechanisms like launch agents and metadata backstaging can survive beyond the single command or

session and they are huntable because they create patterns. sample events, D lineage, EPPPC references, binder metadata, uh, finder metadata rights, B64 decode change, launch state triggers, and unusual peer-to-peer transfer protocols. So, our recommendation is to model remote application scripting, monitor metadata, extreme services. If you do these three things, you make the cost activity much more visible in your environment. So to close this off here, the question we want everyone to think about is where do you see these behaviors sitting? Do you have visibility into run application scripting and VPC and environments? Do you modify your metadata rights? Can you identify peer-to-peer transfer protocols between Macs? And can you distinguish approved admin automation from unexpected automation? The answer is no.

That is the gap this research is trying to highlight. These are the native Mac OS primaries. So the solution is not just malware detection. It is behavior modeling, surface control and telemetry coverage. The point of this research is not that every Mac environment is being useless for today. The point is that the primitives are already there. Remote application scripting app events find the metadata launchd and data transfer utilities can all support movement and execution when misuse. The defense opportunity is to model those behaviors, restrict unnecessary services, govern information through TCC and NDM monitor metadata operations and quarterly process lineage with inter internal network activities. These bad apples are native but they are also huntable. We'll keep the uh keep

these uh next few slides here since we had some technical difficulties and stuff. Um but uh yeah start us off here. uh go ahead and get a QA and then we got some appended slides every questions all good I'll take a shot um when you were using um it was a script to use terminal as the proxy and then do all this assorted stuff is part of the reason that that's able to work better because terminal app has more privileges built into it. >> Yeah, it has more accessibility and to which that's where we were then able to encode the Oscript itself within B64 to which normally within the normal terminal shell uh as we mentioned if you

look into publish research we go more in depth but get some nasty uh handling errors and stuff like that. you don't like that you do that. But the moment you encode it uh and uh deliver it to the terminal as a proxy and tell the command to decode it, all of a sudden you got some pretty moving uh scripts getting written onto your computer which as we mentioned within the logs itself don't come out clean. There's a uh there are correlations to be made. There's patterns. We recognize understand that oh this is a malicious action. Like I said, you're not going to just see a shell command be executed and all of a sudden all these different uh

behaviors happen is a seamless certain behaviors that need to be recognized and properly locked within especially for those where you know majority of your employees are working with some background. I appreciate your question. Thank you. both. >> So yeah, question go ahead and we'll show off some of these slides here. There's interest this uh yeah right here got our technique family mapping that's demonstrating the uh different typing remote application scripting remote uh execution maps software deployment style execution tunnels proxy remote application scripting level discovery mastery of services control lateral tool transfer maps to t Technique T1570 is a tooling launch agent provide the persistence trigger information. >> Thank you very much. >> Yeah. Screenshot this one. This is all the hypotheses

that we kind of had while we were doing research trying to try and uh the environment a little bit. Yeah, that's it.