Exploiting MacOS

by Vince
in Blog
Hits: 160

I have a friend that is a huge Mac nerd and about a year ago, he was talking about Mac OS being secure.  Full disclosure, I have a MacBook Pro and a Mac Mini -- I like the platform.  But I took his comments as a challenge, jumped on Ebay, and I bought a Mac Mini for exploitation. 

Under the hood, a Mac is a Linux operating system and like most Linux flavors, there are variations between them.  Let's be honest, at some point, a Mac Remote Code Execution (RCE) vulnerability will materialize and having Tactics, Techniques, and Procedures, for the Mac platform will not hurt me.  And that's basically what this is all about.

Here's the situation, we end up on a Mac system, what do we want to know?  The same thing we always want to know.  We start off with the basics:


Something that didn't occur to me until I had my Mac go to sleep -- THE MAC GOING TO SLEEP!  The caffeinate command aids us with this issue and we can prevent the system from sleeping for however many seconds.  

What are my name servers:

What hosts are on the network:

Querying DNS, I want to locate my high value targets:

Let's say I shell a Windows system and there's a user on the machine.  I will interact with the user in order to either direct them to a malicious page or I will attempt to steal credentials.  Wouldn't I want to do the same thing?  Of course.  

In this script, I'm opening Safari and I'm directing the user to my malicious page:

When the script is executed:

Upon clicking OK, the user is directed to our page:

Continuing on with my evil ways, I want to steal credentials.  We have several options, the first will pop a credential box and the second will pop a credential box with a red stop sign:

When the script is executed:


We can start with the first and if the user hits cancel, we can come back in with the second.  

With both attempts, the user enters their password and we see those in clear text.

There's also a yellow exclamation icon that we could also use in our escalation process.  

Now that we have credentials, we can move into the root account:

Again, this post is as much about showing the possibilities as it is about the specific syntax for achieving specific tasks in MacOS.  

Enumerating the network setup:

Enumerating the Wi-Fi connection:

Viewing all of the Wi-Fi networks in the area:

Our Wi-Fi network specifics:

We already covered how to enumerate the name servers but what if we wanted to Man in the Middle (MITM) the DNS:

Let's talk about execution -- along the lines of a reverse shell.  If we write a .sh script and drop it on the desktop, the Mac will try to open it with an editor.  However, in the Mac environment, the .command extension will give us the type of execution we'd expect from a .exe in a Windows environment.  

Below is a basic reverse shell:

If we move this to the Desktop:

And we execute it:

We get execution (see below) but we have this remnant in the form of an open terminal window (see above).  That's undesirable and it can draw some unwanted attention.

In my script, I added the pkill command but for some reason it didn't close the window.  I can execute pkill manually and that would work so it must have something to do with the script.  Taking a slightly longer approach, I'm searching for the process, getting the ID, and I'm killing the process by ID:

Our command on the Desktop, we execute it:

We catch our shell and we've accomplished the task of removing the open terminal window.  

In the event we should lose our connection, we want some sort of persistence to get back on the system.  Working with a simple reverse shell, we can package that up in a .plist file: 

The next few lines will copy our .plist file into the appropriate location, change to the correct ownership, and set the .plist file to launch on startup.  

We logout and login:

With our handler setup, we catch the inbound shell.  

In my efforts to pierce the perimeter of the Mac, I was unsuccessful.  I tried Macros in Office Documents and various other techniques including the .command file trick.  The .command file works amazingly unless you bring it in from an external source.  Either via SMB share or Email, the result is still the same.  The Mac recognizes that it came from an external source and we get the following when we attempt to execute it.  Take note though, we ARE able to email it.  

By default, the Mac firewall is disabled but that doesn't mean you can find open ports on a port scan.  However, if the Mac firewall is enabled, we may want a technique for defeating it. 


Quick side note -- while working through this process, I found a number of older commands which no longer work.  In fact, another task I performed worked while writing this up and then it stopped working with the most recent update.  

Back to the firewall -- when you look through the output, it appears as if the process of disabling the firewall didn't work.  This is some of the quirkiness I discovered will sifting through old posts about Mac command line syntax.  Like some of the other failed attempts, I thought this was also headed in the wrong direction.

However, if we reboot the system from the command line, when we look at the firewall after a restart, it's disabled:

So -- regardless of the output, it still works.  

Wrapping this up -- I have a few other tricks up my sleeve but I'm keeping those close to the vest for now.  But the main takeaway here is that it's a Mac but it's just an operating system and we want to compile the same techniques we would use on any other system.