In April 2016, I published a research report that analyzed a very nasty piece of adware that targets Mac OS X. Called OSX.Pirrit, I discovered that it wasn’t your typical adware program that just floods a person’s browser with ads. With components such as persistence and the ability to obtain root access, OSX.Pirrit has characteristics usually seen in malware. While OSX.Pirrit’s main goal was to display ads, the way it did this contains many practices borrowed from traditional malware. Ultimately, OSX.Pirrit’s code had the potential to carry out much more malicious activities. As a result of the report, some of Pirrit’s servers and a few distribution websites were taken down. But the story doesn’t end there.
Check out some more of Amit's cutting edge research on Operation Soft Cell.
A few months later, I learned that a new variant of OSX.Pirrit was in the wild. After investigating it, I discovered that a company called TargetingEdge created OSX.Pirrit and, in July, wrote a report discussing how I figured this out. And once again, some Pirrit’s servers and distribution websites were taken offline.
Now it’s time for chapter three (download a PDF of this report here). Curious to see if OSX.Pirrit was still alive and spreading, I recently started to research it again. And, to my surprise, it’s very active. Not only is it still infecting people’s Macs, OSX.Pirrit’s authors learned from one of their mistakes (They obviously read at least one of our earlier reports).
Unlike old versions of OSX.Pirrit that used rogue browser plug-ins or even installed a proxy server on the victim’s machine to hijack the browser, this incarnation uses (or shall I say abuses) AppleScript, Apple's scripting/automation language. And, like its predecessors, this variant is nasty. In addition to bombarding people with ads, it spys on them and runs under root privileges.
My research hasn’t gone unnoticed by TargetingEdge. For the past two weeks they've tried to prevent me from publishing this research. Cybereason has received a few cease and desist letters from a firm claiming to be TargetingEdge’s legal counsel. The letters demand that we stop referring to TargetingEdge's software as malware and refrain from publishing this report. Included below is the official response TargetingEdge requested that we include in our report:
Cybereason isn’t the only security company that identifies OSX.Pirrit as a threat. Twenty-eight other antivirus engines on Virus Total also classify it as such. The authors of this software went through great lengths to mask themselves and distance themselves from it.
I'm still researching this program and, in general, constantly track threats, whether it’s sophisticated nation state APTs or “benign adware." Research is how the security community learns about the latest threats and how to stop them.
As the letter shows, TargetingEdge is trying its best to deny any link to OSX.Pirrit. However, in January 2017, a former TargetingEdge employee, whose name was one of the two found in the dropped files that led us to the company, sent Cybereason his resumé, which clearly establishes a connection between TargetingEdge and OSX.Pirrit.
Every time I stumble across an interesting malware sample I write YARA rules for it. These rules allow me to find new variants once they’re released.
Just before I wrote this report, one of my OSX.Pirrit-related YARA rules started returning thousands of results, indicating a wave of new infections. After downloading and analyzing some of the samples, I identified OSX.Pirrit straight away and noticed that many of its methods changed. This report analyzes this latest variant.
An important note before I discuss my research: In this report, the term installer refers to TargetingEdge’s main product - an installer that installs software like a video player or a PDF reader that’s downloaded from a site. These installers will install the downloaded software and the additional malware.
All the installers that are downloading and executing these scripts are running as root since the first thing that do after execution is to ask for the user’s password. This is a key point since it explains how everything in the process described in this report is running with root permission.
Since users are, by default, in the sudoers list, getting the user’s password equals getting the user’s root password. For more details, read this report or watch my talk from LayerOne 2016.
I started my research by looking at some telemetry data from the infected Macs and other threat intel providers. After acquiring enough samples of Mac software installers (for more information on the installers, read this report on OSX.Pirrit), I wrote some code that executes the installers and looks at all of the outgoing connections that the installer creates. After doing that, I learned that the installers are are generating HTTP requests to a specific URL, but that URL is actually a one-time link that contains the ID of that specific install as an HTTP parameter, so every link only works once.
I then decided to mess with the URL to see if I can get one URL that will always work. To my surprise, it was simpler than I thought. By using a quote (“) as the id parameter and sending that request to the server, the server will return a URL with a link that always work:
And now when I request that URL, the server will return the installation script back to me:
Another interesting thing to note is the “us” field in the request. Setting it to True delivers a different installation script that points to a different server. My guess is the “us” parameter stands for “United States” and it points to a different ad server. You can clearly see this in a screenshot comparing the two files:
A bash script with 329 lines is downloaded. This is very similar to the scripts I saw last year when I analyzed OSX.Pirrit and it is very safe to say that both this script and last year’s script were written by the same group or even person. This script has several functions, some with names that are very descriptive, others with names that don’t say much. The script also contains many domains and URLs, which help us understand how vast TargetingEdge’s infrastructure is.
The 329 line long script starts by defining a function called rnd(). The purpose of this function is to generate and return one random word by accessing the dictionary wordlist file (provided by the operating system in /usr/share/dict/words) and picking one random word:
The names that are generated are used to create a random directory in ~/Library/<random name>, which will contain the dropped application. In this case, it’s the browser hijacker.
The script then extracts the UUID of the machine, saves it to a variable called $mid and sends it back to one of TargetingEdge’s many command-and-control (C&C) servers by issuing a simple curl command:
The script also sends other data back to the C&C server, such as the generated app name, its path and its version.
The script will then download a component of the malware called “updater” from yet another server.
The variable in the address points to
http://t[.]46sdzf3zdg1dxg2[.]us/download/hjfgkdvuewree?uu=1
The downloaded file is a tar.gz archive. Next, it’s extracted.
The script will also create a launchagent in ~/Library/LaunchAgents/com.<RANDOM NAME>.plist.
That launchagent will run “updater” as root once the script finishes running.
The next step is downloading the “updater” binary.
When analyzing the “updater” binary, it is very easy to understand its purpose by looking at it with a disassembler (in this case I’m using Jonathan Levin’s jtool):
As the names of the functions show, they are all infrastructure related: keeping the infrastructure updated, downloading files, installing new versions of the malware on the machine. But there is one function that stands out: [UpdaterCommunication runExternalApplication].
Disassembling it in IDA Pro clearly reveals this function’s purpose:
The function executes /bin/sh with NSTASK with a parameter in the format of a string.
The updater file is the only file that’s codesigned. However, unlike the original OSX.Pirrit, it was codesigned with an ad hoc signature instead of a normal certificate. Ad hoc signatures are used to provision iOS applications in test environments. An ad hoc signed Mach-O executable has no meaning on macOS since the component that checks and validates ad hoc signatures, the AMFI trust cache, does not exist in macOS. My guess is that if this binary wasn’t ad hoc signed by mistake, it was an attempt to fool antivirus programs.
As a part of updater’s work, it enumerates running processes using the NSWorkspace class, calls the runningApplications function and then iterates over the output to see if either Firefox, Chrome or Safari are running. It then downloads “ad packages” for the browsers that are installed on the system. Updater always runs in the background (it’s also installed as a LaunchAgent) and ensures that the ad packages are always up to date.
The dropped updater binary will now be moved to ~/Library/<random name>/<random name>. After updater has been renamed and moved to a proper directory, the script will finally create the the LaunchAgent plist file in ~/Library/LaunchAgents/com.<random name>.plist.
As the following screenshot shows, the random word that was chosen when installed in my analysis setup was “roadless”. This means that the file was created in ~/Library/roadless/roadless and the LaunchAgent name was com.roadless.plist.
After the updater LaunchDaemon was created, the script will now download a file called sr_v2.tgz to /var/tmp/sr.tgz. It will then be extracted to /var/tmp/dvs. This file contains the malware that will hijack the browser.
Once extracted to its temporary directory, we can see a bunch of files and directories extracted.
Among these files are two executables (Protector and updater) and various installation and setup scripts (setup.sh and install_updater.sh):
The program will now execute yet another setup script, called setup.sh. This script installs the program’s next components. The authors left the program’s internal name in the setup script: DaVinci.
In the next step, the script again generates a list of names but doesn’t use the wordlist file on the system. Instead, it selects a word from the names.db file:
Immora Nalen Quoroden Enthinge Kimathen Cheechran Ightquemos Dandan Morkim Ertur Etiao Schiwarkin Vayt Crybur Ashsul Tiavorurn Dannalmos Saml Rek Sideb Therkkin Usktas Cereng Builing Nysgar Beldanash Roinnris Yenga Ightem Pertino Athechyer Sysir Nomaro Rilchin Yerrack Elmeld Riarat Tasard Miom Panur Milobe Rothl
After a random name is chosen from names.db, another LaunchAgent for DaVinci is created in /Library/LaunchDaemons/com.apple.<randomname>.plist - As clearly shown, DaVinci is trying to mask itself as a legitimate Apple LaunchDaemon.
In previous versions of OSX.Pirrit and BrowserEnhancer, in some cases, the malware dropped malicious browser extensions to track the users and display ads. Since browser extensions are fairly easy to identify and remove, the authors chose a different path (which I will talk about later) and tracked the user’s browser. However, this installation script tries to remove old versions of the user’s Safari browser extension and removes a Safari extension called “omnikey”. I don’t know what TargetingEdge has against Omnikey but if I had to guess, I’d say it interfered with either their browser hooking (more on that later) or the data they received from machines with Omnikey installed.
The script will look inside the /Safari/Extensions in every user’s home directory to see if there are any old installations and/or “unwanted” extensions. Any that are found are deleted.
This script will also try to do what TargetingEdge calls a “pure install”. It’s basically executing the app bundle that was in the archive - BrowserEnhancer.app.
Since BrowserEnhancher.app is an actual binary executable (inside an app bundle, of course), it requires some proper reverse engineering work:
Right off the bat, when looking at the dylibs that the binary is loading, we can see that just like last year’s OSX.Pirrit, this is yet another QT project:
This is also evident when looking at some of the internal functions and data types in the binary:
BrowserEnhancer.app’s has several responsibilities but its major one is reconfiguring properties inside the internals of all the installed browsers. BrowserEnhancer will search the system for installations of these browsers:
This function is trying to read a Windows registry value related to Internet Explorer so that it could change some settings. Obviously, this function is in for some serious disappointment since this is a Mach-O executable running on macOS.
Once the browsers are found, BrowserEnhancer will modify their search provider settings from the browser’s default to http://tika-search[.]com. A quick visit to Tika-search’s about page shows us that this is actually another venture of Download Valley’s Goliath: Babylon Software.
In other cases, depending on the browser’s setting or geolocation, the search provider will be switched to http://delta-search[.]com.
Visiting delta-search reveals a site that’s nearly identical to tika-search. Only the logo is different.
Once BrowserEnhancer was executed and installed, a script called post_install.sh stops all running instances of Firefox and Chrome and restarts them so the changes can take effect. Note the use of osascript, which we will get back to later.
Once updater and BrowserEnhacner are installed, the main installation script downloads another archive file called uj_v_5.3_rf.tgz:
The content of the file is then extracted to /var/tmp/mako.
That directory contains yet another binary executable called macver and yet another installation script called install.sh and a plist file named macver.plist.
The installation script starts with the TargetingEdge’s favorite modus-operandi: Generating a random name from the wordlist in /usr/share/dict/words:
Once a random name is chosen, the script uses defaults to write a new plist file to ~/Library/Preferences/com.application.plist. It will add a new dictionary entry to that file. The dictionary will contain the random name that was chosen for the new executable by the installation and the name for the plist that holds its preferences:
As we can see, it points to com.sailcloth.plist. Let’s look at that file:
As we can see, the file contains the machine-uuid, and a URL that should be loaded each time the browser is directed to visit google.com.
Once those plists are written, the script will then continue to create and run individual LaunchAgents that will run macver for every user on the machine but the guest user:
Dry facts first:
macver is a Mach-O 64-bit executable file. It is not importing any third-party frameworks such as Qt (for a change). However, closely examining this executable reveals some interesting details.
The strings section of the file contain a lot of base64 obfuscated content:
De-obfuscating the base64 strings reveals the following code:
Here is another example:
That code is AppleScript (Jonathan Levin’s book *OS Internals volume I thoroughly covers Applescript’s inner workings) and injects JavaScript code directly into the browser.
Like I said earlier, this variant uses AppleScript. Instead of running a proxy server to intercept traffic or installing a browser plug-in that can be easily removed, the authors use Applescript (which was originally meant for automation purposes) to inject javascript directly to the browser.
Using AppleScript, the authors can exfiltrate and inject both information and code from/to other apps. In this case, AppleScript is used to poll the running browser for the currently viewed URL. Then, a block of JS code is injected into a hidden <div> in every page that the browser is visiting. That code is used to extract information, to track the user and to plant code in the page if needed.
Macver is running and executing (via NSTASK) osascript (the AppleScript interpreter), which will execute the aforementioned (and some other) scripts that are going to interact and in fact “hook” (to borrow terminology from BeEF) the browser. Once a browser is hooked, macver can read and write (or inject) content to and from it. Once the browser loads a website, macver knows exactly what website is being visited and will then inject ads into the browser.
In this example, once macver was running, I went to Google and searched for “error.” After I submitted the result, the browser immediately opened a new tab that displayed an ad for MacKeeper, the well-known, fake antivirus program for Macs.
In the following image we can see macver running in its own terminal window. By default, macver prints to stdout a lot of debug information so there is actually very little need for debugging:
TargetingEdge has taken extraordinary efforts to distance itself from from the code that’s running on an amazing number of machines worldwide. After analyzing different samples, I had several C&C domains (the ones that are used to “phone home” to the authors and tell them which machines are infected). Every domain was registered with a privacy guard so there was no way to find out who registered it using public information.
Eventually, I started cross-referencing domains with each other using ThreatCrowd and found that some domains were not registered with a privacy guard. This was probably a mistake. A mistake was how I figured out who was behind OSX.Pirrit last year. I found the names of TargetingEdge employees inside the permission tables of the dropped files. But they learned from that mistake. They are no longer using their first and last names as usernames - they have switched to use more amusing names:
The non-private domains also had a DGA pattern and were connected to the same IP address, which is connected to other TargetingEdge domains. These included a privacy guard. As ThreatCrowd clearly shows, the non-private domains were registered by a person associated with TargetingEdge:
And that’s not the only domain that’s connected to TargetingEdge. Here’s some whois data on 3fzf1fseg1xzgd1e5[.]us:
According to LinkedIn, this individual was a senior executive at TargetingEdge and he is currently the CEO of a “Blockchain-based digital advertising company.”
As I said before, Pirrit/BrowserEnhancer/DaVinci (or whatever you want to call it) is not a ground breaking threat. However, it is a great example of how an adtech company is borrowing nefarious tactics found in malware to make it hard for antivirus software and other security products to detect them. There is no difference between traditional malware that steals data from its victims and adware that spies on people’s Web browsing and target them with ads, especially when those ads are for either fake antivirus programs or Apple support scams. Adware is just another type of malware.
As for OSX.Pirrit malware, it runs under root privileges, creates autoruns and generates random names for itself on each install. Plus, there are no removal instructions and some of its components mask themselves to appear like they’re legitimate and from Apple. And don’t forget that TargetingEdge used domains that appeared to be generated by some sort of DGA and made many attempts to hide any link between the domains and TargetingEdge.
OSX.Pirrit/BrowserEnhancer/DaVinci checks every box on the malware checklist and should be treated that way, even if its authors don’t like it. The security industry created the term “potentially unwanted program”, or “PUPs”, to handle adware companies that try to intimidate security companies that identify their products as malware by sending them cease and desist letters. It’s time for a paradigm shift. If there’s code that’s mining data and hiding itself on a computer without any way of removing it, that’s malware, plain and simple.
Want to threat hunt like our researchers? 
Amit Serper is Principal Security Researcher at Cybereason. Amit leads the security research at Cybereason’s Boston HQ. He specializes in low-level, vulnerability and kernel research, malware analysis and reverse engineering on Windows, Linux and macOS. He also has extensive experience researching, reverse engineering, and exploiting IoT devices of various kinds. Prior to joining Cybereason, Amit spent nine years leading security research projects and teams for an Israeli government intelligence agency, specifically in embedded systems security (or lack of).
Copyright © 2017 Cybereason Inc. All rights reserved.
Amit Serper is Principal Security Researcher at Cybereason. He specializes in low-level, vulnerability and kernel research, malware analysis and reverse engineering on Windows, Linux and macOS.
The surge of Emotet attacks targeting Japanese organizations in the first quarter of 2022 is a continuation of the earlier Emotet activity, with some changes in the malware deployment process. The Cybereason XDR Platform detects and blocks Emotet malware...
Cybereason is excited to announce the creation of a U.S. Government subsidiary, Cybereason Government Inc., dedicated to prevention, detection and response of malicious operations targeting U.S. Government agencies...
