If you have a good reason to believe, and are able to demonstrate, that a file was mistakenly classified, please complete the following form and provide the file details.
If you believe an application, file or URL you encountered is malicious, tell us about it.
Author: Uriel Kosayev, Researcher @AiroAV (Airo Security)
As Mac malware become more wide-spread, and as detection mechanisms get more sophisticated, malware actors need to adapt. If not long ago almost any variant could easily run on any machine without any scrutiny, today it needs to hop over many obstacles. From Google’s SafeBrowsing, thru Apple’s Xprotect and GateKeeper down to third-party AntiVirus solutions and network appliances. We constantly investigate these techniques in order to better design and develop mechanisms for better detection and removal of these threats from users’ Macs.
In this analysis of the Adware ‘Shlayer’ we review its infection flow, with an emphasis on its evasion techniques. In our next analysis report, we’ll investigate Shlayer’s extension deployment, and its mouse and search hijacking mechanisms.
We’ll provide a review of how Shlayer uses:
– Bash scripts to evade static detection mechanisms;
– Dynamic content loading to evade Code-Signing and Safe-Browsing;
– Encryption to evade network security solutions;
We’ll also present the pre-encrypted data which Shlayer harvested from our Airo Lab’s victim machine. With this data, Shlayer’s C&C determines whether, and how to further attack the machine, e.g.: which ‘offers’ to advertise; which apps and extensions to install, etc.
Similar to most cases, the adware is spread via free movies, free games website sites and similar sources. The malicious file comes as a mountable DMG that includes a proper code-signed App-Bundle:
The App-Bundle includes three (3) important files:
● File 1 – The main binary executable: This is a clear-text bash script, which is located under the MacOS folder. In this example, the filename is: 9Vb2HR0. With other samples we checked, the filename was different.
● Files 2 & 3 – encrypted files: The files enc and enc2 are encrypted, and located under the Resources folder.
Below is the code of the main bash executable:
As we can see, the bash script decrypts and executes the file enc.
Below is the decrypted content of enc, which runs in the memory:
This code again decrypts the file enc2 (which is a compressed file), and then unzip it to the path: /tmp/<random_name>/Player_<variant_id>.app
The decryption mechanism is pretty simple: base64 and AES with a password. In this scenario, the password is: 6570001937.
While the encryption mechanism is somewhat simple, it is yet effective as Shlayer successfully utilizes it to evade static analysis and static-based Antivirus products: the malicious code which executes by the eval command runs in the memory level. Consequently, no decrypted files which contain the maliciously executed code are stored in the file system.
The main App-Bundle of the second stage (previously decrypted enc2 file) is very similar to the App-Bundle and main bash executable of the first stage: it uses the same password used in stage1, to decrypt the additional enc file.
Below is a dump of the code of the 2nd stage enc from runtime memory. To simplify readability, we manually reconstructed the code:
The code from the eval command above gives us the last bash code that runs also in the memory level, as shown below:
The above code collects basic information from the victim’s machine, including Hardware-UUID, session_guid, OS_version, and volume_name. Then, the collected data is sent to a Shlayer’s C&C IP address, using an HTTP-GET request with cURL:
The HTTP-GET request parameters explained:
Below is a list of the HTTP-GET parameters, and the data sent with each
● c = probably a Campaign ID
● u = Hardware UUID
● s = Session GUID
● o = OS version
● b = The password which was used in previous bash stages
If the server is satisfied with the received information, it responds with a download redirection (which is further described in the 3rd stage below).
As we can understand from the previous bash script:
● The “3rd stage” ZIP file is downloaded to: /tmp/
● It is then unzipped with a password
● The files under Contents/MacOS get execution permission
● The app is executed with arguments “s”, “session_guid” and “volume_name”. This checks if the DMG that contains the first stage App-Bundle is currently mounted to the system. If so, the app loads the installer. Otherwise, the app exits and terminates the process.
● The full path of the main Mach-O installer (discussed in Stage 3 below) is:
/tmp/Player.app/Contents/Resources/Player.app/Contents/MacOS/ (in this case: 18EA04C0917E)
This is what the 3rd stage Mach-O installer (18EA04C0917E) looks like:
Before the installation GUI is presented to the victim, we noticed network traffic with an encrypted payload that was transmitted, to-and-from several remote servers.
Here is an overview of the HTTP request packets:
We can notice that all servers are hosted in the same network (188.8.131.52/24 CIDR).
To reveal where the threat-actor’s servers reside (C&C), we used a Whois query. As shown below, the result indicates that the IPs come from an Israeli based ISP:
Below is an example of one of the encrypted payloads, sent from our Victim machine to the C&C:
Fingerprinting – The Harvested Data
Before the encryption occurs, Shlayer’s “3rd stage” Mach-O installer harvests information such as browser’s versions, Hardware-UUID, Serial Number, MAC-address and more, to fingerprint the victim’s machine. With this information, Shlayer determines which applications and extensions to provide the victim with.
Below we can see part of data sent before the encryption takes place, (debugged in our lab, using IDA Disassembler):
Furthermore, the image below shows part of the symbol table of the 18EA04C0917E Mach-O binary (using the nm -m command), which displays few encrypt/decrypt functions. This gives us a stronger indication of the encryption mechanism which is implemented in this stage.
Based on the information presented above, we can conclude that Shlayer uses OS built-in encryption mechanisms, rather than its own.
Here is a summary of the evasion techniques implemented by Shlayer:
1. Static Detection: In each one of the stages described above, Shlayer decrypts files and executes their code in runtime memory. This technique allows Shlayer to evade static detection mechanisms, such as old-school static anti-virus solutions.
2. Code-Signing & Safe-Browsing: Shalyer evades Apple’s Code-Signing and Safe-Browsing security mechanisms (such as by Chrome and Safari), by utilizing dynamic content download (as further described in stage 2 above).
3. Network Security: Shlayer transmits encrypted payloads over the network, thus it evades network security solutions.
The Shlayer Adware disguises as a legitimate Flash-Player installer. It uses a few simple and evasive Bash scripts, which act as droppers. After two stages where Bash scripts are executed, the Mach-O binary installer is executed.
Then victims are fingerprinted as their system information such as MAC address and Hardware UUID is harvested. Finally, Shlayer encrypts the data and sends it to a remote C&C to determine the specific applications and extension to provide the victim.
The approach of either dropping stages, mixed with the 3rd Mach-O installer, is interesting as it manages to successfully evade all of the following security measures:
– Apple’s built-in security mechanisms
– Antiviruses, either static or dynamic in some cases.
– Network security and Browser security solutions
Uriel Kosayev is an ex-military (IDF) security researcher with over six years of experience in the Cyber Security field, as a hands-on practitioner. Uriel is also a lecturer, who has developed cybersecurity courses and training. His experience includes Malware Research, Reverse Engineering, Penetration Testing, Digital Forensics and Incident Response. In his military service, Uriel strengthened an elite incident response team, acting on both the practical and methodological fronts. Prior to his military service, Uriel led an independent Red-Team, that provided offensive security research services.
Try Airo AV and Airo Web Protection