F5 researchers recently discovered a new campaign targeting Jenkins automation servers that exploits an unauthenticated code execution vulnerability (CVE-2017-1000353).1 This is yet another in a series of campaigns already running that target Jenkins servers, such as the campaign we wrote about in February that uses XMRig to mine Monero. This latest campaign uses a 15-year-old process name faker tool, XHide, to hide its malicious process and kills its competition by terminating other mining processes running on the exploited server.
Delivering a Serialized Payload
Again, we are witnessing attackers taking over the server using an Insecure Deserialization vulnerability, A8 in the 2017 OWASP TOP 102 The first request sent by the attacker contains a serialized Java object with the malicious payload.
Figure 1: The request holds a serialized Java object containing the malicious payload, command encoded in base64.
The serialized object contains a base64-encoded string which decodes to the following:
Figure 2: Base64 string decoded to a bash command
This decoded base64 string contains a command that first attempts to download the malicious file using wget. If that fails, curl is then used. The resulting downloaded file is then run by bash. Let’s look into the downloaded bash script.
Spearhead Bash Script
The spearhead bash script is downloaded from a Chinese Git website, GitEE. Only a single project with a single branch resides in the attacker’s repository.
Figure 3: Attacker’s project activity on GitEE
Although the attacker has not touched most of the files for the past three months (since April 22, 2018), four files were updated the week of July 2.
Figure 4: Attacker’s project files, four updated the week of July 2, 2018
After examining the updated files, we found a new wallet address that appears not to be in use at the moment.
The downloaded spearhead bash script, logo.jpg, holds various commands, while the jpg extension is another attempt to blend the attacker’s files with other legitimate files on the target server.
The first few commands terminate multiple processes running on the exploited system. While reviewing the pkill commands, it seems that the main goal is to kill the competition because most process names are related to known cryptocurrency miners, for example, kworker34,3 sourplum,4 and various process names on imf-conference.org.5
Figure 5: pkill commands that terminate competing miners’ processes on the exploited system
The next few commands download more malicious files to the exploited server using both curl and wget.
Figure 6: curl and wget commands download the campaign’s malicious files to the exploited system
Following the downloads using these commands, many files are left on the system:
- a
- config.json
- cron.d
- x
- dir.dir
- h32
- h64
- run
- Java
- upd
- x86_64
If the server is already infected with the deployed malware and its process is already running on the system, the bash.pid file will contain its process ID and the command “cat bash.pid | xargs kill” will kill the malware’s process so the new malware variant can be installed instead.
The last commands in the logo.jpg spearhead file change all downloaded files permissions to allow them to run and then runs the “x” file.
Figure 7: Changing downloaded files permissions and running file “x”
Persistence
The sole purpose of the file named “x” is to run the file named “a” in the background. Using “nohup” (no hang-up) will keep the “a” process running, even if the original exploitation shell session is disconnected (see Figures 8 and 9).
Figure 8: Running the “a” file in the background with “nohup” keeps the malicious session from being terminated
Figure 9: The “a” file sets cronjobs and rewrites the upd file
This code is very similar to a piece of code published on October 26, 2017 in a question on the Stack Overflow coding forum, shown in Figure 10.6 The file names and most of the commands are identical, but the author could not be identified.
Figure 10: Attacker’s code on Stack Overflow
The upd file is rewritten to check whether the malware process is currently running, and a cronjob is set to run it every minute. This is done by inspecting the pid in the bash.pid file. If it is not running, the run file is started. This behavior functions as a watchdog to keep the malware running in case of a crash or a deliberate termination.
An additional task sets a cronjob to download and run a file hosted on hxxp://3389.space/lx/logo.jpg every six hours. This file wasn’t available for download at the time of this writing.
Figure 11: The “run” file is running initially and in the case of a crash
The run script runs a process faker executable, either h32 or h64, supporting both x86 and x64 architectures, passing it the Java file name as the parameter. The process ID of the running process is then saved to the bash.pid file that we referenced earlier.
Faking the Malware Command Line
In this campaign, the attacker uses a process faker tool from 2002, called XHide, by Schizoprenic Xnuxer Research.
Figure 12: The XHide process faker tool menu
Looking into the h32 and h64 files, we see how XHide hides the process’ original command: it changes the malware cmdline information (as saved in /proc/$pid/cmdline on a Linux system) without changing the malware file name. This is done by overwriting argv[0] in the software, which changes the command line related to the executed process. Using the “ps -ax” command will show the fake command line for the malware process but running ps -a will still show the original malware file name because it derives the information from the “Name” field in /proc/$pid/status.
In this case, the composed command runs the java ELF, giving its process the less suspected cmdline /usr/sbin/sshd related to the commonly used SSH server. This is an old and uncommon practice in this kind of operation, and we haven’t encountered it before. Instead, the attacker usually changes the malware file name and then runs it.
The Mining Malware
The main goal of the Java executable is to mine the notorious Monero cryptocurrency. The first noticeable text includes XMRig options, which implies XMRig is embedded into this malware.
Figure 13: The XMRig menu is embedded into the malware’s code
Although the attacker employed creative means to persist and hide in the system, he or she didn’t make an effort to obfuscate the malware, and we were able to immediately find the wallet address in the malware strings.
Figure 14: The mining operation wallet address and the mining pool both appear in plaintext in the malware’s code
The Mining Operation
By examining the attacker’s wallet address on the mining pool, we can see the earnings to date.
Figure 15: The mining wallet address statistics, more than 39 Monero coins mined to date
More than thirty-nine Monero crypto-coins have been mined to date, which at the time of this writing was valued at about $5,100.00 USD. Examining the transactions log on the mining pool, we can see that the earliest logged payment to this wallet address was received on March 11, 2018.
The hash rate for this mining operation ranges between 50 and 60 KH/s, which indicates this operation employs dozens to hundreds of mining servers.
Figure 16: The mining operation hash rate indicates that multiple servers are employed
Indications of Compromise
- Files:
- a
- config.json
- cron.d
- x
- dir.dir
- h32
- h64
- run
- Java
- upd
- x86_64
(These files will most likely exist under /tmp/.tmp/ folder but finding these bunch in a different folder is a strong indication as well)
- logo.jpg – should be concerning if the file is an executable. System admins can use the following command to search for this IoC: find / -name logo.jpg | xargs file | grep executable
- Cronjobs:
- Cronjobs downloading logo.jpg using curl or wget
- Processses:
- A Java process with a cmdline “/usr/sbin/sshd”
The following command can ease the process of finding the offending process:
pid=$(ps -a | grep java | cut -d " " -f 1); ps -ax | grep $pid
- A Java process with a cmdline “/usr/sbin/sshd”
And, as with any malicious mining operation, keeping track of your CPU usage is always a good idea.
Crypto-Mining Operations
Lately, we’re encountering more and more creative (although not more sophisticated) malicious crypto-mining campaigns. For example, in June, we encountered an operation that compiled its own C# downloader and used a Chinese forum as its command and control server. Another campaign, also encountered in June, used two different exploits with VBScript as the spearhead script. Killing competitors’ processes is also noticeable in multiple campaigns. It’s seems that more and more threat actors are discovering the ease of setup and potential profit that lies in malicious crypto mining and they want a piece of the pie. These newcomers try a variety of new approaches to gain a competitive advantage in the battle for mining resources.
