AbstractAndrew Kovalev and colleagues describe ‘Mayhem’ – a new kind of malware for *nix web servers that has the functions of a traditional Windows bot, but which can act under restricted privileges in the system.
Copyright © 2014 Virus Bulletin
Table of Contents
- Malware representation
- Shared object initialization
- Main loop function
- C&C commands
- Hidden file system
- Analysis of plug-ins
- Analysis of C&Cs
- Comparison with other malware families
Over the last several years, malware writers have clearly come to understand that gaining access to web servers can bring more benefits than infecting users’ PCs. Nowadays, there are millions of completely unprotected web servers with different kinds of vulnerabilities, so it is easy for attackers to upload web shells and gain access to them. Although in the vast majority of cases such access is restricted by the web server’s rights on the target system, attackers successfully find ways to gain maximum advantage. In this article we describe ‘Mayhem’ – a new kind of malware for *nix web servers that has the functions of a traditional Windows bot, but which can act under restricted privileges in the system.
This article should be considered as an addition to the one published by the Malware Must Die team . We faced the Mayhem bot in April 2014, and this paper is a result of our own independent research.  is the only other publication on Mayhem we’ve found. During our research, we also discovered that Mayhem is a continuation of a bigger ‘Fort Disco’ brute-force campaign, disclosed in .
The results of analysing this script with the VirusTotal service are presented in Table 1.
Table 1. The results of checking the PHP dropper using the VirusTotal service.
Figure 1. First part of the PHP dropper.
Figure 2. The contents of the ‘1.sh’ script.2.
Figure 3. The last part of the PHP dropper.
Shared object initialization
During execution of the hooked ‘exit’ function an additional initialization function is called. The workflow of this function is shown in Figure 4. During the initialization, the following steps are performed:
- An ELF file with only an ‘exit’ function is dropped
- The process forks and the child process runs the ELF file and finishes its execution
- The parent process performs further initialization: it tries to connect to the Google DNS service (the IP address is 22.214.171.124), decrypts and parses the configuration file and obtains the parameters of the system.
Figure 4. The workflow of the initialization function.
Figure 5. High-level workflow of the hooked ‘exit’ function.
Main loop function
If the flag indicates that the information has not been sent yet, the malware prepares an HTTP packet that contains the output of the ‘uname -a’ command, the architecture of the infected system, and information about the rights of the system user executing the process. After the packet has been sent, the malware reads the C&C response and if something goes wrong it exits this function. If everything is fine, the malware updates the flag and tries to read and execute other commands in the C&C response.
A high-level workflow of the main loop function is presented in Figure 6.
Figure 6. High-level workflow of the main loop function in the shared object.
Figure 7. Workflow of data received from the C&C server.
Figure 8. Dataflow of strings that are processed by plug-ins.
The 'R' command (outbound)
R,20130826,<system architecture - 64 or 32>,<EI_OSABI value from ‘/usr/bin/host’ ELF header>, ROOT,<output of ‘uname -a command’>If the web server is run with restricted privileges, then the command is the same, but instead of ‘ROOT’ there is the output of getenv(‘AU’) – the URL for the PHP script used to start the malware. If everything is fine, the C&C server returns ‘R,200’.
The 'G' command (inbound)
G,<task ID>If the current task ID is not equal to the one received, the malware will finalize the currently running task and start a number of new working threads. The number of working threads is set by the ‘L’ command.
The 'F' command (outbound)
F,<file name>,0If the malware wants to check if there is a new version of a previously obtained file, it will send:
F,<file name>,<CRC32 sum of the file>If the file is not found on the C&C server, the server will respond:
F,404,<file name>If the file hasn’t been changed since it was received, the C&C will respond:
F,304,-If the new/updated file is found, the server will respond
F,200,<file name>,<BASE64 encoded file data>After receiving the command with data, the malware decodes the BASE64-encoded data, writes it to disk and into a hidden file system. Then it tries to determine whether the received file is a plug-in. If the file is a plug-in, the malware checks its CRC32 sum, which is stored in unused ELF header fields, and loads the plug-in into memory.
The ‘L’ command (inbound)
L,core,<number of working threads>,<sleep timeout>,<socket timeout>After receiving this command, the malware will finalize all working threads, then update the number of working threads, the sleep timeout and the socket timeout.
If the C&C wants the malware to load a plug-in, it will send:
L,<plug-in file name>,<plug-in parameters separated by comma>If the malware receives this command and another plug-in is already running, the running plug-in will be stopped and the new one will be looked up in the hidden file system. If the lookup fails, a file with plug-in will be requested from the C&C via the ‘F’ command. Then the plug-in will be loaded, initialized and run.
The ‘Q’ command (outbound & inbound)
Q,stringAll of these strings are added to the malware’s input queue and will be processed by a plug-in that is being run. If the malware wants to upload the results of its work, it will send:
Q,<plug-in name>, <string with results>then remove these strings from its output queue.
The ‘P’ command (outbound)
P,<flag is a task is run>,<UNKNOWN>,<count of working threads>,<number of read/write requests to servers per second>,<total number of read/write operations to server since this number has been set to zero>
The ‘S’ command (inbound)
- Outbound commands
- R - report home
F - request file
Q - send data
P - report state
- Inbound commands
- G - run new task
L - load plug-in
Q - send data
S - stop current task
Figure 9. The decryption algorithm used in the malware.
An example of the decrypted configuration is shown in Figure 10.
Figure 10. Decrypted configuration of the sample.
|Offset||Size in bytes||Description|
|0||4||This field contains the number of eight-byte blocks in the configuration – in other words, the length of the configuration in eight-byte blocks|
|4||4||Special marker 0xDEADBEEF|
|8||4||Offset to the C&C URL|
|12||4||Sleep time between executions of the main loop function of the malware|
|16||4||Size of file mapping for the hidden file system|
|20||4||Offset to the name of the file that contains the hidden file system|
Table 2. Description of the malware configuration.
Hidden file system
The hidden file system is used to store plug-ins and files with strings to process: lists of URLs, usernames, passwords, etc. The content of one instance of the file system is shown in Figure 11.
Figure 11. The content of one instance of the file system.
Analysis of plug-ins
Figure 12. An example of the structure that describes one of the plug-ins.
This plug-in is used to find websites that contain a remote file inclusion (RFI) vulnerability. During initialization, the plug in downloads a list of patterns and a list of websites to check. Then it sends special HTTP requests to the websites that try to include the ‘http://www.google.com/humans.txt’ file and analyse the corresponding HTTP responses. If the HTTP response contains the ‘we can shake’ substring, then the plug-in decides that the website has a remote file inclusion vulnerability. A part of the list with patterns is shown in Figure 13.
Figure 13. Some patterns used by ‘rfiscan.so’ to find websites that are vulnerable to RFI.
|Q,rfiscan,<host>,<vulnerable URL>||An RFI vulnerability has successfully been found|
|Q,rfiscan,<host>,-||RFI vulnerabilities haven’t been found|
Table 3. Descriptions of ‘rfiscan’ plug-in ‘Q’ commands.
This plug-in is used to enumerate users of WordPress sites. The working function of this plug-in receives a URL, transforms it, and makes HTTP requests with the following query template:
<original query without last part>/?author=<user id>The user ID ranges from 0 to 5. If the corresponding HTTP response contains the substring ‘Location:’ and the destination URL contains the substring ‘/author/’ then the username is extracted from the destination URL. The first user to be found is transmitted to the C&C with the use of ‘Q’ commands. The meanings of the commands are presented in Table 4.
|Q,wpenum,<original URL>,<transformed URL>,<user name>||Username has successfully been found|
|Q,wpenum,<original URL>,<original URL>,no_matches||No username has been found|
|Q,wpenum,<original URL>,-||Connection failed|
Table 4. Descriptions of ‘wpenum’ plug-in ‘Q’ commands.
The working function of this plug-in receives the hostname, makes an HTTP GET request to this host with the ‘/wp-login.PHP’ query, and searches for the substring ‘name=\"log\"’ in the corresponding query. So this plug-in identifies user login pages in sites based on the WordPress CMS. The results are sent to the C&C with the use of ‘Q’ commands. The meanings of the commands are presented in Table 5.
|Q,cmsurls,<hostname>,<URL to login page (ends with ‘wp-login.PHP’)>||URL for login page has successfully been found|
|Q,cmsurls,<hostname>||URL for login page has not been found|
Table 5. Descriptions of ‘cmsurls.so’ plug-in ‘Q’ commands.
This plug-in is used to brute force passwords for sites based on the WordPress and Joomla CMSs. The plug-in doesn’t support HTTPS. During our research, we found a dictionary containing passwords used by the plug-in. The dictionary contains 17,911 passwords. The lengths of the passwords range from 1 to 32 symbols.
This plug-in is also used to brute force passwords for sites, but unlike bruteforce.so, this plug-in supports HTTPS, and regular expressions, and can be configured to brute force almost any login page. An example of such a configuration is presented in Figure 14.
Figure 14. An example configuration of the ‘bruteforceng.so’ plug-in.
This plug-in is used to brute force FTP accounts.
This plug-in is used to crawl web pages and extract useful information. A list of websites to crawl, as well as depth level and other parameters, are obtained from the C&C server. The plug-in also supports HTTPS protocol and uses the SLRE  library to work with regular expressions. The plug-in is very flexible. One of the configuration files for this plug-in is presented in Figure 15. As you can see, in this case the plug-in was used to find and collect pharmacy-related web pages.
Figure 15. A configuration file of the ‘crawlerng.so’ plug-in.
This plug-in is the same as the ‘crawlerng.so’ plug-in. The only difference is that this one works with a list of IP addresses instead of URLs.
Analysis of C&Cs
Figure 16. (List of bots in the C&C administration panel.
Figure 17. Task addition interface in the C&C.
Figure 18. Brute force task in the larger botnet administration panel.
Figure 19. Some results of a brute force task run by the botnet.
The geographical distribution of the infected servers of the botnets is presented in Figure 20. As can be seen, the countries with the highest rates of infection are USA, Russia, Germany and Canada.
Figure 20. Geographic distribution of infected servers in the larger botnet. Darker blue means more infected servers.
We analysed the sources of both active C&C servers. Besides the main page, the sources also contain two additional PHP scripts: config.php and update.php.
The first script contains configuration data: database credentials, MD5 hash of the administrative panel, maximum pending time for tasks, bot wake up time, etc. Part of this script is shown in Figure 21.
Figure 21. Part of the C&C configuration data.
The update.php script is used for waking up bots. This script visits a host with inactive bots and runs the PHP script described in the ‘Malware representation’ section.
We also found that the C&C server supports a number of plug-ins that we haven’t found in the wild. For example, a plug-in that exploits the recently identified ‘Heartbleed’ vulnerability and collects data from vulnerable servers. A piece of code that describes all the available plug-ins is shown in Figure 22.
Figure 22. This piece of code shows that there are a number of plug-ins we haven’t seen in the wild.
We also found that the code of the C&C scripts contains a number of security flaws, but a description of these vulnerabilities is beyond the scope of this article.
Comparison with other malware families
- configuration has the same format
- XTEA algorithm in ECB mode is used for encryption
- 0xDEADBEEF markers are widely used in configuration files and other parts of code
- ELF headers of shared objects are corrupted in the same way.
- Web server botnets offer a unique model of monetization through traffic redirection, drive-by download attacks, black hat SEO, etc.
- Web servers have good uptime, network channels and are more powerful than ordinary personal computers.
- In the *nix world, autoupdate technologies aren’t widely used, especially in comparison with desktops and smartphones. The vast majority of webmasters and system administrators have to update their software manually and test that their infrastructure works correctly. For ordinary websites, serious maintenance is quite expensive and often webmasters don’t have an opportunity to do it. This means it is easy for hackers to find vulnerable web servers and to use such servers in their botnets.
- In the *nix world, the use of anti-virus technologies isn’t widespread. A lot of vendors don’t offer any proactive defence or process memory checking modules. In addition, an ordinary webmaster usually doesn’t want to spend time reading the manuals of such software and solving possible performance issues that might occur.
 Fort Disco Bruteforce Campaign. http://www.arbornetworks.com/asert/2013/08/fort-disco-bruteforce-campaign/.
 Wheeler, D.; Needham, R. Correction to XTEA. http://www.movable-type.co.uk/scripts/xxtea.pdf.
 Wikipedia. Block cipher mode of operation. http://en.wikipedia.org/w/index.PHP?title=Block_cipher_mode_of_operation&oldid=582012907.
 Schneier, B. Applied Cryptography. John Wiley & Sons, 1996.
 Effusion – a new sophisticated injector for Nginx web servers. https://www.virusbtn.com/virusbulletin/archive/2014/01/vb201401-Effusion.