CrimeOps of the KashmirBlack Botnet – Part II

Introduction

The previous blog – “CrimeOps of the KasmirBlack Botnet – Part I” – described the DevOps behind the botnet. It showed how its well-designed infrastructure makes it easy to expand and add new exploits or payloads without much effort, and explained the evolution and version deployment of the botnet.

The blog mentioned the delivery process of the botnet’s exploits and payloads, the steps made to secure the C&C, and the infrastructure changes taken to make the botnet more dynamic and scalable, while achieving redundancy, failover and load balancing.

Three questions were raised: What? When? And How? – although only the first two were answered.

This blog will uncover the bits-and-bytes behind the third question: How?

We will explain how the KashmirBlack botnet operates, describe its entities, and dive into the spreading technique.

The botnet infrastructure is composed of nine types of entities, each of which plays a specific role in the complex botnet operation. All share the same goal, however; to expand the botnet by delivering KashmirBlack malicious script to victim servers, to carry out its crimes.

We’ll take a walk into the darker side of the KashmirBlack botnet, and explore the techniques used by the malicious script to stay under the radar, communicate with the C&C, send instructions to other bots in the botnet and track the entire operation. Breaking down the botnet spreading technique, we’ll show the different vulnerabilities the botnet’s malicious script exploits and discuss the different types of payload outcomes.

In the “Summary” section you can find indicators of compromise (IOC), remediation, and the impact on Imperva customers.

The Botnet Entities

Let’s take a glimpse into the heart of the botnet and all the pieces that make up this complex infrastructure.

Figure 1: KashmirBlack botnet flow diagram

The C&C

The C&C server is a centralized machine able to send commands and receive telemetries from machines that are part of a botnet.

The KashmirBlack C&C, located in Indonesia, has three main roles:

• Supply a Perl script that infects the victim server with the botnet malicious script
• Receive reports of findings and attack results from bots
• Supply bots with attack instructions

Figure 2 below shows the login page of the C&C:

Figure 2: C&C login page

When checking the ‘C&C’ URL in VirusTotal it appears to be a malicious site detected by only one vendor.

Figure 3: VirusTotal check for the C&C URL

We suspect the server is owned by the attacker since, unlike most sites, there is no main page under the domain name.

Repository A

The original ‘repository A’ is a printer component shopping site that was hacked by the attacker and is now used as a repository to store files.
This entity plays a role in the infection by supplying the botnet malicious script – to communicate with the C&C.
After the May 2020 infrastructure change, ‘repository A’ was extended to seven repositories.

When checking the ‘repository A’ URL in VirusTotal it appears to be a legitimate site.

Figure 4: ‘repository A’ shopping site

The files are hidden inside the css path (hxxps://<site’s domain>>/css) among other css files used by the innocent web server. The malicious files are zip files camouflaged with a .css extension. All the files uploaded to the repository by the attacker are password-protected to ensure their content can’t be revealed should someone find them.

Repository A Load Balancer

As the botnet size increased, so too did the load on the repositories, as more bots fetched files from these repositories.

The addition of a new entity, ‘repository A load balancer’, allowed scalability. A request to the load balancer returned the address of one of the multiple repositories in ‘repository A’. To integrate this change into the botnet operation, an additional change in the botnet malicious script was required.

Repository B

The original ‘repository B’ is another allegedly legitimate site, according to VirusTotal. The site is classified as an educational institution and is used by the hacker to store bundles of exploits and payloads.

Figure 5: ‘repository B’ educational institution site

Similar to ‘repository A’, the attacker uses a .css extension to hide traces under the /css directory.
Figure 6 below shows the content of ‘repository B’ of exploit and payload files with the prefix of inmemory.
The first file was uploaded on November 6, 2019; the earliest evidence we’ve found for the KashmirBlack botnet operation.

Figure 6: ‘/css’ directory content of ‘repository B’

As part of the infrastructure change, ‘repository B’ was extended to 74 repositories.

KashmirBlack GitHub Repository

The GitHub repository participated in the attack phase by allowing the attacker to download PHP webshells.
The attacker used GitHub as a version control to store his files, among which were crypto miners and multiple webshells used to control, upload, or dump the entire database of a victim server.

Figure 7: The attacker repository

We tracked the attacker’s activity over time, and the malicious files maintained under the repository.
The account was opened in July 2017. There was activity from November 2019, the time the botnet started its operation, with further subsequent activity including the XMRig miner that was uploaded in March 2020.
The account was deleted in May 2020, probably as a reaction to the discovery of our honeypot by the hacker behind KashmirBlack.

Pastebin

Pastebin is a website that allows anonymous users to share plain text through public posts called ‘pastes’.
The Pastebin entity in the operation was used as a quick and easy means of accessing download backdoors throughout the infection.

Figure 8: Webshell used by the attacker stored in pastebin

Bot

A bot is considered as a server over which the attacker has control.
In the KashmirBlack botnet there are two types of bots:

• Spreading bot
• Pending bot

Spreading Bot:
A ‘spreading bot’ constantly communicates with the C&C to receive attack instructions, and is used for infecting new machines, thus expanding the botnet.

Pending Bot:
A ‘pending bot’ is a victim site that is attacked by a ‘spreading bot’ and, as a result, is under the control of the C&C. Once a victim site turns into a ‘pending bot’, it stays in idle mode until the C&C approaches and changes its purpose.
A ‘pending bot’, unlike a ‘spreading bot’, does not initiate communication with the C&C.

This repurposing can result in several outcomes – spreading bot, spam, cryptomining, or becoming a repository entity in the infrastructure.

Figure 9 shows the actions (exploit or repurpose) and the outcome of spreading and pending bots.

Figure 9: bot entities actions and outcomes

Victim server

A victim server is a site running CMS platforms, such as WordPress, Joomla! or, Drupal, targeted by the C&C.
By analyzing the attack instructions received by our dummy ‘spreading bot’, we discovered that most of the attack’s target victim sites were located in the US.

Spreading Technique

The Different Exploits and Their Outcomes

The below table shows the exploits being used by the ‘spreading bot’ and their outcomes.
Only one exploit – PHPUnit RCE – results in an infection that causes a victim site to become a new ‘spreading bot’ in the botnet.
Otherwise, 14 exploits result in an infection that leads to a victim site becoming a new ‘pending bot’ in the botnet, and one results in defacement.

The following sections describe the spreading technique used by the KashmirBlack botnet.

Entry Point

The spreading technique relies on the fact that many Linux servers come out of the box with Python and Perl installed, which makes the attack easy to carry out.
A ‘spreading bot’ tries to infect a victim server with the botnet malicious script that constantly communicates with the C&C. In other words, it adds the victim server to the KashmirBlack botnet as a new ‘spreading bot’.

The PHPUnit RCE vulnerability allows the attacker to inject a php code that will be executed on the victim server (for additional details you can read: ‘The resurrection of PHPUnit RCE Vulnerability’). During the analysis of the vulnerability, we came across an HTTP POST request to eval-stdin.php made by a ‘spreading bot’ in an attempt to exploit CVE-2017-9841. The below request in Figure 10, infects the victim and adds it to the KashmirBlack botnet.

Figure 10: HTTP POST request to infect the victim

The code in Figure 11 is located in the request body of the above POST request:

Figure 11: The POST request body

The code downloads a Perl script from the C&C, executes it and deletes any traces.

Traber Perl script

The Perl script, traber.pl, mentioned in Figure 12, is a combination of Perl and base64 encoded commands:

Figure 12: traber Perl script

Traber.pl eventually creates a new cron job to be executed every three minutes.
Crontab is a UNIX command that creates a table or list of jobs scheduled to run at regular intervals on the system.

The cron job

We decoded the above cron job:

Figure 13: The decoded crontab job

Every three minutes, the ‘spreading bot’ would perform a request to the ‘load balancer’ to get the address of one of the multiple repositories in ‘repository A’, which stores the KashmirBlack botnet malicious script that communicates with the C&C.

The cron job was trying to stay undetected by creating a unique and deep path under /tmp folder, using several hidden folders to store the malicious script called ‘update.py’.

During the entire cron job, we could see evidence of a highly cautious attacker who was careful to ensure his actions always remained under the radar.

Entry Point Summary

The entire process of turning a victim into a ‘spreading bot’ starts with exploiting PHPUnit RCE vulnerability (CVE-2017-9841) on the victim’s server, causing php code to be executed, and downloading ‘traber.pl’ perl script from the C&C. It then continues with a scheduling job which downloads the malicious script from ‘repository A’, before executing a Python script ‘update.py’ to communicate with the C&C.

Figure 14: KashmirBlack ‘spreading bot infection flow diagram

Botnet Malicious Script (update.py)

Now we are going to reveal the mechanism used to control and operate the KashmirBlack botnet.
The infected victim from the above spreading process becomes a new ‘spreading bot’, constantly communicating with the C&C to receive attack instructions. In the section below we’ll describe the attack structure in depth.

The initial communication with the C&C is via ‘update.py’ script.
The malicious script grabs attack instructions by sending an HTTP GET request to hxxp://<C&C_server>/archerhome/index.php:

Figure 15: HTTP GET request to get instructions

This HTTP request utilizes some specially crafted headers:

• User Agent: ArcherGhost8
• IP: < Bot Ip >
• Upgrade-Insecure-Requests: 1
• COUNTRYCODE: < Country two letters code >

The C&C will not respond unless these are in place.
This is a ‘security’ measure the attacker uses to keep unwanted actors from receiving attack information from the C&C.

Attack Instructions
The response for the HTTP GET request to ‘index.php’ will return attack instructions formatted in JSON:

Figure 16: JSON with attack instructions form the CC

The structure:

• ‘script’ – commands that will be executed by the ‘spreading bot’ server
• ‘payload’ – list of victim sites that will be attacked by the ‘spreading bot’ server
• ‘argv’ – the hostname/IP that hosts the victim sites

Receiving Attack Instructions

While impersonating a ‘spreading bot’, we received attack instructions from the C&C for several months. Based on the collected instructions, we found that a ‘spreading bot’ attacks an average of 240 hosts – or 3,450 victim sites – per day.

Note:
Although we don’t know the exact number of bots in the botnet, we can assume its size from the data we collected,and suspect that it’s in the region of hundreds of thousands of bots.

285 (spreading bots IPs we saw in our data) * 240 (attacked victims) = around 70,000 (Victim Servers attacks per day)

Assuming that only 1 percent of the attacks are successful, it means that around 700 bots are added to the botnet every day. The operation continued for at least 11 months – approximately 330 days. Without considering that the number of attacks increases exponentially every day, we will have the following over the 11 month period:
330 (days) * 700 (bots per day) = 230,000 bots.

The 285 IPs we identified as KashmirBlack spreading bots that attacked our customers are probably only a fraction of the entire botnet, so the potential of this growth is much bigger.

We suspect that the C&C has a scanner that searches for sites running CMS platforms, creates an attack instruction JSON with the new found sites, and pushes it into a queue waiting for bots to receive them and attack.

As of today there are more than 20 distinct exploits (the ‘script’ field). The next section will focus on the exploit execution.

The Exploit

The exploit script given as part of the attack instruction has the following structure:

Figure 17: Exploit script

The ‘spreading bot’ downloads a bundle of exploit and payload from hxxps://‘repository B’/css/inmemoryXXX.css. It then executes the exploit to attack victim sites defined in the attack instruction.

The execution consists of four steps:

1. 1. Exploit a vulnerability
   2. Deliver a malicious payload
   3. Verify delivery
   4. Report to the C&C upon success

The Payload

There are two types of payloads for spreading the KashmirBlack botnet

• traber.pl – to transform a victim server into a ‘spreading bot’
• sssp.php backdoor – to transform a victim server into a ‘pending bot’

The Backdoor

The ‘sssp’ Backdoor uploaded to the victim site is a simple PHP webshell to upload files, and is used to gain persistence access to the victim’s site.

Figure 18: PHP Backdoor Code

Techniques used by the malicious script

The ‘sssp’ backdoor is constructed with different extensions, for example:
[‘sssp.php’,’sssp.phtml’,’sssp.php.pjpg’,’sssp.pHp’,’sssp.php.fla’,’sssp.pHp5′]. This is an evasion technique to remain undetected or being blocked by security methods used to prevent malicious file upload.

The POST request to upload the backdoor uses 269 random User-Agent headers, which is also an evasion technique:

…

Figure 19-20: Random User Agent Header

Figure 21 below shows the steps of the report phase on a successful backdoor upload:

1. The C&C reporting address is base64-encoded to avoid mentioning the C&C address in clear text. Decoding it reveals the C&C address: hxxps://<C&C_server>/adeliap/405.php
2. The POST request uses a specially crafted User Agent (‘ArcherGhost’)
3. The JSON reports of the new backdoor in place is encoded before being sent to the C&C

Figure 21: The ‘senddata’ function that reports to the CC

Malicious Script Technique Overview

The victim infected in the spreading process becomes a new ‘spreading bot’ in the KashmirBlack botnet. As a ‘spreading bot’ running the ‘update.py’ malicious script, it communicates with the C&C every three minutes to receive an attack instruction.
The attack instruction contains a list of victim sites that will be attacked and the remote location of an exploit bundle. The ‘spreading bot’ downloads the exploit and payload bundle from ‘repository B’. It then runs the exploit on the victim site, delivering one of two payloads – one transforming the victim site into a ‘spreading bot’, and the other transforming it into a pending bot. In a successful attempt, the ‘spreading bot’ will report to the C&C.

Figure 22: KashmirBlack botnet spreading flow diagram

×

Nov 26 Upcoming Webinar

The True Cost of API Insecurity and Bot Attacks in 2024

Register Now

Summary

This blog describes a complex and constantly evolving botnet operation; only possible with a great and well-designed infrastructure.

During our research we witnessed its evolution from a medium-volume botnet with basic abilities to a massive infrastructure that is here to stay.

Indicators of Compromise

The KashmirBlack botnet infection varies. There are several traces that indicate a server is compromised and taking part in the botnet. Each role in the botnet has different indications of infection. For additional details see appendix C.

How to Remediate?

There are several actions that should be performed in case your server is infected by the KashmirBlack botnet:

• • Kill malicious processes
  • Remove malicious files
  • Remove suspicious / unfamiliar cron jobs

• Remove unused plugins and themes

The site administrator should ensure the CMS core files and third party modules are always up-to-date and properly configured. In addition, access should be denied to sensitive files and paths such as install.php, wp-config.php, and eval-stdin.php.
Strong and unique passwords are recommended, as they are the first defence against brute force attacks.

Nowadays, when cybercrime is so common and new vulnerabilities are disclosed on a daily basis, we highly recommend deploying a web application firewall (WAF) to ensure your site is protected.

How do Imperva products protect you from KashmirBlack?

Imperva WAF customers are protected and are not affected by the botnet operation. The WAF has a layered approach to block such activity.
The Bad Bots policy will detect the malicious traffic of the bots to the site and the Malicious File Upload policy will block webshell upload. In addition Remote Code Execution signatures will prevent the payloads execution and the Backdoor Protection mechanism will prevent backdoor usage by the attacker.

Be safe & secure,
Imperva.