MacOS Red Teaming 207: Remote Apple Events (RAE)
Last MacOS Red Teaming post we briefly covered several common remote administration options available on macOS by default, such as SSH, VNC, ARD, and Remote Apple Events. While we deep dived on VNC and ARD (Apple Remote Desktop) last post, this post we are going to focus on Remote Apple Events (on port TCP:3031). Before understanding Remote Apple Events (RAE), it's important to just understand what Apple Events are. This post requires a good deal of background info, but if you already understand Apple Events and Apple Scripting in general, you can skip to the next two paragraphs respectively and move straight on to Remote Apple Events.
Apple Events are a type of IPC call on macOS, that is to say they allow applications to speak to each other programmatically. From a high level, this blog post really helped me understand the inner workings of Apple Events in abstract and human terms. That said, here are some of the official Apple Events docs, including object structures and programming guides, which will be invaluable if you start working with this stuff on a technical level. One way these Apple Events can be thought of, is very similar to the COM model when compared to Windows, with Remote Apple Events being like DCOM. That is to say, applications can choose to publish a set of functions through the Apple Events API using the info.plist of the app and specifying a target ".sdef" file. Parsing this ".sdef" file specifies which functions and structures the application publishes though the Apple Events API. You can browse these files in the AppleScript Editor by dragging the applications into the Library, which will let you fully explore all of the functions and objects you can reference in a given application through the Apple Events API.
That said, AppleScript will be a huge driver here for interacting with the Apple Events API (and later RAE). This is a pretty esoteric scripting language from far back in Apple days. The Open Scripting Engine (OSA) is what AppleScript rides, and includes some newer features such as being able to write Mac Automation in JavaScript (aka JXA), as well as the ScriptingBridge for extending other languages. OSA also comes with some command line tools, such as osascript and osacompile, for running and compiling scripts respectively. That said, we will be focusing on AppleScript for this post, which I found this set of docs invaluable for writing. I also found this site, which provides a ton of the older Apple Script docs and examples.
Finally, back to Remote Apple Events (RAE). You can enable this service in "System Preferences" -> "Sharing", then enabling "Remote Apple Events" which will spawn the eppc service on TCP port 3031 on all interfaces. The traffic is encrypted with TLSv1 and requires authentication with a valid user on the system. This allows remote machines to connect over this port using the "eppc" protocol in AppleScript, and thus call Apple Events on remote machines. By default, tons of native applications offer features over the Remote Apple Events API. There are some hangups when using Remote Apple Events but I couldn't tell if these were supposed to be security controls as I was able to get around basically all of them. For example, some of the Apple Event favorites are disabled remotely, such as "do shell script", however we can get similar functionality by calling the Finder and Terminal applications. I put together a proof of concept repo to show some of the useful pentest tasks you can run if you have creds and find RAE listening:
I also spent a good deal of time writing a backdoored application in swift that exposed some malicious functions over Apple Events. I followed this guide to understand the structure of the application an how to expose it to Apple Events. I then backdoored the previous application with the swift application called ShellOut, which gave me a starting place for some of my initial malicious functions. This was a neat persistence technique I was exploring to offer malicious Remote Apple Events, however when I discovered the native lateral movement capabilities I figured that was probably more useful than backdooring a single apps events. Enjoy all!
Apple Events are a type of IPC call on macOS, that is to say they allow applications to speak to each other programmatically. From a high level, this blog post really helped me understand the inner workings of Apple Events in abstract and human terms. That said, here are some of the official Apple Events docs, including object structures and programming guides, which will be invaluable if you start working with this stuff on a technical level. One way these Apple Events can be thought of, is very similar to the COM model when compared to Windows, with Remote Apple Events being like DCOM. That is to say, applications can choose to publish a set of functions through the Apple Events API using the info.plist of the app and specifying a target ".sdef" file. Parsing this ".sdef" file specifies which functions and structures the application publishes though the Apple Events API. You can browse these files in the AppleScript Editor by dragging the applications into the Library, which will let you fully explore all of the functions and objects you can reference in a given application through the Apple Events API.
That said, AppleScript will be a huge driver here for interacting with the Apple Events API (and later RAE). This is a pretty esoteric scripting language from far back in Apple days. The Open Scripting Engine (OSA) is what AppleScript rides, and includes some newer features such as being able to write Mac Automation in JavaScript (aka JXA), as well as the ScriptingBridge for extending other languages. OSA also comes with some command line tools, such as osascript and osacompile, for running and compiling scripts respectively. That said, we will be focusing on AppleScript for this post, which I found this set of docs invaluable for writing. I also found this site, which provides a ton of the older Apple Script docs and examples.
Finally, back to Remote Apple Events (RAE). You can enable this service in "System Preferences" -> "Sharing", then enabling "Remote Apple Events" which will spawn the eppc service on TCP port 3031 on all interfaces. The traffic is encrypted with TLSv1 and requires authentication with a valid user on the system. This allows remote machines to connect over this port using the "eppc" protocol in AppleScript, and thus call Apple Events on remote machines. By default, tons of native applications offer features over the Remote Apple Events API. There are some hangups when using Remote Apple Events but I couldn't tell if these were supposed to be security controls as I was able to get around basically all of them. For example, some of the Apple Event favorites are disabled remotely, such as "do shell script", however we can get similar functionality by calling the Finder and Terminal applications. I put together a proof of concept repo to show some of the useful pentest tasks you can run if you have creds and find RAE listening:
- AppleScript to list remote directory
- AppleScript to remotely read the contents of a file
- AppleScript to write a file to a remote machine
- AppleScript to get execution permissions on a new file remotely
- AppleScript to run remote script
- AppleScript to remotely open a new app
- AppleScript to change desktop background
- AppleScript to open a web page
I also spent a good deal of time writing a backdoored application in swift that exposed some malicious functions over Apple Events. I followed this guide to understand the structure of the application an how to expose it to Apple Events. I then backdoored the previous application with the swift application called ShellOut, which gave me a starting place for some of my initial malicious functions. This was a neat persistence technique I was exploring to offer malicious Remote Apple Events, however when I discovered the native lateral movement capabilities I figured that was probably more useful than backdooring a single apps events. Enjoy all!
