Ransomware. Ransomewhere? Inside malicious installers on MacOS, that’s where.
With the new wave of ransomware attacks we have seen at the beginning of this week, especially targeted toward Spain, we can see that mostly Windows attack vectors are mostly being utilized, in what appears to be a variant of the Bitpaymer family, related to the Dridex group of malware.
But what does the future hold for attacks such as these? When will we see the attack vector change drastically to target something that your company is most-likely unprepared for? We are seeing bad actors targeting low-hanging fruit on Windows, while the world of end-users are going mobile. If iOS development is part of your enterprise, then whether you like it or not, MacOS literally has to be an integral part of your infrastructure…because XCode. Is it possible that this is something that has gone unnoticed in the threat detection landscape, or is the perception of the threat level just perceived to be so low that we haven’t yet come up with a good way to protect against it?
In recent years, Apple has completely given up their focus on enterprises, and started focusing directly on consumers. They want to create hardware and software that is as simple as possible and can be used as easily as possible by the end user. Understood. That’s where the money is — at least when you decide to take their particular approach of casting a wide net only on one side of the boat.
Apple has taken a foothold in this direct-to-consumer market and made their presence known, while deciding to get out of the enterprise support business altogether. This initially started with killing the X-Serve line of enterprise-level hardware back in early 2011, and opting for a software-based server solution. That being said, as you can see from its history, support for that software is dropping fast. In a nutshell, there is no longer any such thing as an OS X network, and if there is, you can bet your ass that it’s way past EOS and EOL. As enterprise administrators of Windows networks, what are you to do when your company requires Macs to do their job, and those Macs require access to internal resources?
Apple has let the responsibility of MacOS security fall into the hands of Windows administrators
I remember back in 2013 when I started working for an enterprise that, at the time, only supported Windows 7 for end users. I brought my personal Macbook Pro to work one day, and out of curiosity, started hacking around, as a hacker do. As it turned out, I was able to join my laptop to the top level AD forest using only NETBIOS creds. So yeah, Macs have native Active Directory support via Open Directory, but you can’t push Windows GPOs to Apple computers. Enterprise admins (who are obviously mostly-skilled in managing Windows networks for end users) are now having to support 2 separate policy frameworks that don’t really mesh together, and third parties have had to step in to basically bootstrap security features that are altogether lacking in MacOS. Enter JAMF…
JAMF is supposed to offer secure Mobile Device Management (MDM) for Apple products, including Mac computers. I cannot say for certain how well this works. All I know is that when this concept is thrown at enterprise-level Windows admins, they are going to have a steep learning curve to setting it up correctly, if in fact there is a secure way of setting it up correctly at all. I received a MacBook Pro that was supposedly locked down with JAMF installed and configured, as well as Symantec Endpoint Protection. When I got to my desk, I sat down and opened up my laptop and told Siri to start a stopwatch. In 15 minutes and some change, I had completely uninstalled JAMF and SEP, deleted the managed service account, deleted my AD account, created a new local admin account, and reset the root password, all before enabling the initial encryption of the device via FileVault, which was now set to only be unlocked via my personal iCloud or passphrase of my choosing. The main shortcoming and takeaway here is that you have to be a local admin to do just about anything on MacOS. In order to be a local admin, you have to have
sudo access. When you have
sudo access, for all intents and purposes, you are
root, and you own the system.
MacOS and the risk of APT
I could have actually maintained access to internal networks by leaving JAMF thinking it was enabled by moving the binaries around, which allows the ability to toggle actual access on or off, and I would have had to access via my AD account probably in order to get around NAC policies. However, I decided to just take this bad boy completely off-grid. So now you have a rogue Macbook Pro in the building that is able to only connect to limited-access internal WiFi networks. What’s the attack vector?
Well, I can make an educated guess and say that there are probably a whole lot of sites that are hosted externally (maybe AWS?) whose security groups are locked down to only the external IP ranges of the enterprise. Check. I can also make an educated guess to say that a wider range of internal resources can be accessed by this computer when accessed over VPN. Check. From this point, it only becomes a matter of how skilled an attacker is at information gathering and network traversal, because now they are completely undetectable — if the attacker is the owner of the computer…or if this computer becomes compromised, and now it has no form of specifically-authorized applications or even any form of Endpoint Threat Detection, or much less Endpoint Threat Detection Response. You can throw as many “what if” security questions at me as you want — the truth of the matter is that in a redteam exercise, I successfully carried out this operation in the wild. Granted, it was on a network that I was already familiar with, but with an Advanced Persistent Threat, all it takes is time and persistence to become familiar with a network and the habits of the users.
So what would it take to turn this into a real enterprise-level threat? Well, let’s think about the numerous Mac Minis that are constantly connected to internal networks in order to access SCM to build Xcode applications for iOS development. How would an end user interface with those machines. What kind of code could be pushed into the CI/CD pipeline? These are all open-ended questions, posed to make you think about risk. In the end, however, all it would take is an Advanced Persistent Threat from one developer’s laptop in order to figure out how to go about wreaking so much havoc. Of the top of my head, I would keep a close eye on their local git repos and
.bash_history to see what type of SSH connections they made. From there, I would create a local Bash function, sourced in their
~/.bash_profile that would override the default
ssh command and would run code on the remote system, which could do any number of things. Does their primary SSH target function as the main build server in a smaller development shop? A single Jenkins server that is responsible for all of the pipelines? These types of servers are often developer-owned, and since they are not customer-facing, they often don’t follow the same Disaster Recovery procedures, like regular, off-site backups. These would be excellent targets to introduce ransomware, when thinking like an attacker.
So how would one go about setting up an APT against MacOS? Well, that’s where I come in, to show just how easy it is on current versions of MacOS X using tools like [REDACTED], and how it was even easier on previous versions of OS X using tools like [REDACTED].
Edit: I was recently approached by HakDefNet International to sell the rights to these two programs, and graciously obliged. My whole intention was to release these tools to bring awareness to the insecurity of MacOS, which is something that HakDefNet will be able to do much better than me alone. I’m actually glad to get these malicious programs off the streets and into the capable hands of security research professionals, and all my thanks go out to them.
That is your gateway to establishing an Advanced Persistent Threat. Was that my goal when releasing these tools? Absolutely not. My goal was to help spread security awareness by providing a real world incentive — basically lighting a fire under the asses of those responsible for enforcing security on MacOS X.
Blue and Purple Teams: A Call to Arms…
Does your ETD detect attacks such as this? Do your scanners detect a root reverse shell that is not some sort of Windows-based meterpreter payload? Will your SIEM ever be be alerted on native MacOS functionality that writes directly to a raw TCP socket? Gmail virus scans don’t detect it. You can send the weaponized
.dmg directly through Gmail in a phishing campaign. JAMF doesn’t detect it. You can open app and run it just fine. Symantec Endpoint Protection doesn’t detect it. It’s normal MacOS functionality. Nothing to see here, right? We often get caught up in putting out fires as they light up and preparing for the ones we see most often, but when is it time to start preparing for the sparks that will ignite a blaze we haven’t yet seen? I think that time is now, and I think that SOCs, blueteams, and enterprise EDT providers should start getting ready to detect and mitigate against these “unorthodox” attack vectors, which could otherwise easily slip past the radar and wreak havoc upon systems before anyone ever has the chance to figure out what happened or how exactly it happened.
Security preparedness is a proactive measure, not reactive. These are measures taken to protect against what could happen in the future. I’m ready to see somebody standout against the the crowd by keeping their current focus on containment, but give just as much effort to prevention, and the time for that to happen is before it’s too late. And while you’re at it, take a good hard look at MacOS X.