The new iBotnet


Mario Ballano Barcena

Symantec, Ireland

Alfredo Pesoli

Editor: Helen Martin


Mario Ballano Barcena and Alfredo Pesoli take a detailed look at what appears to be the first real attempt to create a Mac botnet.

Recent weeks have seen the discovery of a new piece of malware affecting the Apple operating system. This article will take a detailed look at what appears to be the first real attempt to create a Mac botnet.

The malware variants are OSX.Iservice and OSX.Iservice.B; they are both Mach-O format universal executables designed to run on Apple operating systems.

The main binaries are almost identical, but what differs between them are the ways in which they are distributed and installed on the victim system.

The variants have been found inside bogus copies of iWork ’09 and Adobe Photoshop CS4 which were shared on the popular p2p torrent network. The author of the malware downloaded the original/trial versions of each program and introduced a copy of the malicious binary into the packages. Users who then downloaded and installed the applications from the torrent download would have been infected (see Figure 1). It is estimated that thousands of people have downloaded the infected torrent files.

Users who downloaded and installed iWork ’09 and Adobe Photoshop CS4 from the torrent download were probably infected by the OSX.Iservice malware family.

Figure 1. Users who downloaded and installed iWork ’09 and Adobe Photoshop CS4 from the torrent download were probably infected by the OSX.Iservice malware family.

Installation and distribution

The two variants use different techniques to obtain the user’s password, which is needed in order to execute the malware with full system privileges. Note that the malware will not run if it does not have root access.

The first variant, OSX.Iservice, was bundled within the rogue iWork ’09 installer. The malware author modified the mkpg package to include the ‘iWorkServices’ package (the malicious executable). In this case the malware gets an authenticated session through the installer itself.

In the second variant, distributed through the Adobe Photoshop CS4 torrent file, the trick is a little different. In this case the application package has not been altered. Instead, it is the crack for the application that contains the malicious binary, and once executed it will prompt the user for a password and install the trojan.

The binary that is executed by the OSX.Iservice.B variant is a dropper which performs the following operations:

  1. Drops the main malware binary and executes it.

  2. Asks for the user password.

  3. Opens a dmg containing the real Adobe Photoshop CS4 crack.

The main malware binary is embedded in the __data section of the dropper.

We found the trojan’s second installation step very interesting: we discovered that it uses some of the internal functions of Mac OS that relate to the Authorization Services.

The Authorization Services APIs are used by applications in cases where certain functionalities are provided only to specific users with the relevant access rights on the system. The security agent is responsible for prompting the user for their password. It is possible to use the operating system’s authentication facilities to authorize specific applications (see Figure 2).

It is possible to use the OS authentication facilities to authorize specific applications.

Figure 2. It is possible to use the OS authentication facilities to authorize specific applications.

Think about the Lock feature in System Preferences: whenever the user wants to make a change he has to provide his password. Every application has access to the Authorization Services API in order to use the OS itself for authentication. The dialog box can also be customized with an icon and a message that will be displayed before the standard text. In this case, the malware author has not customized the dialog box, and the trojan just prompts the user for the password (which may seem a suspicious request). However, with malware authors showing an increasing interest in the Mac platform, we believe that more advanced UI spoofing tricks may be seen in the future.

The dialog box requests the user’s password.

Figure 3. The dialog box requests the user’s password.

Of course, the whole authentication part could also have been spoofed [1].

Startup and encryption capabilities

When the malware starts, it checks for the presence of its own configuration file: /var/root/.iWorkServices (or /var/root/.DivX for OSX.Iservice.B).

The malware author wasn’t careful enough to remove all of the debug symbols, so some interesting strings such as ‘/Users/jason/diarrhea/aes/aes_modes.c’ are still visible in the code. Although it is not highly sensitive information, this gives us a clue as to the possible username of the creator, the name of the project and the use of the AES algorithm for encryption capabilities.

The configuration files are encrypted using AES with a static key for encryption and decryption. The same key is also used for encrypting and decrypting network traffic. Wrappers around the ‘recv’ and ‘send’ functions allow for the specification of whether or not the traffic needs to be encrypted/decrypted (Figure 4). Some of the malware’s functionalities, such as the peer-to-peer engine, make use of encryption, while others, like the http download routines, use plain text communications (for obvious reasons).

The malware has wrappers around the ‘recv’ and ‘send’ functions.

Figure 4. The malware has wrappers around the ‘recv’ and ‘send’ functions.

Although the use of AES makes the malware harder to analyse and will probably annoy network administrators who won’t be able to identify what kind of protocol it is, it is not at all secure. We believe it is possible to create network signatures for this threat since the encryption key is fixed and some invariant packets are sent and received by the trojan.

If the malware does not detect the presence of the configuration file, a new one will be generated.

After having parsed the configuration file the malware will attempt to contact the following hosts:

  • 69.92.[censored].[censored]:59201

  • qwfojzlk.[censored].com:1024

These hosts were probably the main core of the p2p network – the malware expects their response in order to start the p2p engine.

Botnet and the P2P engine

The botnet is based in a p2p network for communication, and messages exchange between all the infected nodes.

This method of communication is becoming increasingly popular with malware authors, since it provides a more secure channel to control the infected hosts than the usual ‘call to home’. It also allows the network to be kept alive even if the main servers are down – and makes it more difficult to track the controllers and the infected hosts.

Unfortunately, at the time of writing this article the main servers of the botnet were down, so it was not possible to join it in order to capture and analyse the traffic between the servers and other clients.

The p2p engine is built with LUA [2]. The malware author embedded a LUA interpreter and implemented some of the malware functions with it, so it is possible to script over them, and this gives the trojan good extensibility.

Every p2p command is initially registered in a table which holds a command name and a function pointer associated with the command. These functions are registered as LUA functions, thus all the botnet commands are LUA-registered functions (Figure 5).

All the botnet commands are LUA-registered functions.

Figure 5. All the botnet commands are LUA-registered functions.

P2P commands

Once all the commands are registered they can be used as if they were LUA functions.

The following is a list of all the commands that the bot supports. Some of them are part of the peer-to-peer engine itself and have not yet been fully analysed:

CommandNo. of parametersDescription
socks1p2p protocol-related
system1Executes a system command
httpget1/2Downloads a file
httpgeted1/2/3Threaded http download and executes
rand1/2Returns a pseudo-random number given a seed
sleep1Waits for an interval of time
banadd1p2p protocol-related
banclear0p2p protocol-related
p2plock0p2p protocol-related
p2punlock0p2p protocol-related
nodes0p2p protocol-related
leafs0p2p protocol-related
p2pport0p2p protocol-related
p2pmode0p2p protocol-related
p2ppeer0p2p protocol-related
p2ppeerport0p2p protocol-related
p2ppeertype0p2p protocol-related
set2Sets a parameter in the bot configuration file
get1Gets the value of the specified parameter from the bot configuration file
clear1Removes the specified parameter from the bot configuration file
p2pihistsize0p2p protocol-related
p2pihist0p2p protocol-related
platform0At this time returns ‘OSX’
script1Executes a LUA script
sendlogs2Sends logs stored in a file named ‘ff’
uptime0Returns the bot uptime
uid0Returns the bot unique identifier
shell1Binds a shell on the specified port
rshell2Connects back shell to the specified host:port

Botnet Startup and configuration file structure

The configuration file has a very simple structure:


It expects a sequence of NULL-terminated byte tokens.

The startup token is used to specify a startup LUA code in the configuration file.

Only a few of the malware’s internal functions are bound to LUA and, in fact, the embedded interpreter does not even support the basic functions from the standard LUA libraries. Therefore, this startup code must only be composed of botnet-registered commands which will be executed in the malware loading process.

Another reason why we suspect that the malware author is an experienced programmer, and which also makes the malware harder to analyse and debug, is that almost every part of it is multi-threaded.


OSX.Iservice is an interesting piece of malware – not only does it make use of Mac OS internals, but it is also the first Mac botnet that we are aware of. The botnet was reported to have been performing a DDoS attack through a PHP script running on the infected machines [3].

We guess that the person who wrote the malware is not the same as the person who actually ‘used’ it. The code indicates that, wherever possible, the author tried to use the most flexible and extendible approach when creating it – and therefore we would not be surprised to see a new, modified variant in the near future.


[2] LUA programming language.

[3] Hit by an OS X exploit.



Latest articles:

VB2016 paper: APT reports and OPSEC evolution, or: these are not the APT reports you are looking for

While APT reports should have threat actors scrambling to keep up, in reality they are providing APT actors with the information they need to implement new operational security practices and technologies that have defenders working as hard as ever to…

Throwback Thursday: A Troubled World

In early 1991, the world was a troubled place and conflict and violence were being reported globally on a daily basis. With this as a backdrop, the world of "indiscriminate" computer viruses which "victimise in a random and unpredictable manner"…

The journey and evolution of God Mode in 2016: CVE-2016-0189

Exploits for the CVE‑2016‑0189 vulnerability offer both reliability and complexity, so it is little wonder that it was the most commonly exploited vulnerability in 2016. Ankit Anubhav traces the journey and evolution of the 'God Mode' exploitation…

VB2016 paper: Great crypto failures

This VB2016 paper surveys selected recent case studies of unfortunate cryptographic implementations in malware. When considered together, these examples illustrate a picture of design anti-patterns that is either worrying or encouraging, depending on…

Throwback Thursday: The malware battle: reflections and forecasts

At the start of 2004, Jamz Yaneza reflected on the year just ended and pondered what 2004 would have in store for the AV industry.