CrimeOps of the KashmirBlack Botnet – Part I

Introduction

Being in a research team exposes us to a variety of attacks on different platforms, of different types, scope, and volume. It also gives us the opportunity to select particularly interesting attacks that target our customers and to analyze them.
This blog will give you a taste of the CrimeOps (criminal operations) behind one of these attacks – the KashmirBlack botnet.

Abstract

In the following sections we’ll describe the DevOps behind the KashmirBlack botnet, discuss the purpose of the botnet, and the journey we took during our research. For the bits-and-bytes about the entities, the operation and the infection technique of the KashmirBlack botnet, please wait for our next week blog “The CrimeOps of the KashmirBlack Botnet – Part II”.

The KashmirBlack botnet mainly infects popular CMS platforms. It utilizes dozens of known vulnerabilities on its victims’ servers, performing millions of attacks per day on average, on thousands of victims in more than 30 different countries around the world.
In order to make this ‘magic’ work properly, with minimal interruptions, there should be a proper architecture design and stable infrastructure, with a solid DevOps implementation to overcome the challenges of the delivery process.

Its well-designed infrastructure makes it easy to expand and add new exploits or payloads without much effort, and it uses sophisticated methods to camouflage itself, stay undetected, and protect its operation.

It has a complex operation managed by one C&C (Command and Control) server and uses more than 60 – mostly innocent surrogate – servers as part of its infrastructure. It handles hundreds of bots, each communicating with the C&C to receive new targets, perform brute force attacks, install backdoors, and expand the size of the botnet.

We’ll inspect the evolution and version deployment of the botnet during the research period, from November 2019 until the end of May 2020. And we’ll see how it uses cloud-based services such as Github, Pastebin and Dropbox as ways to hide and control the botnet operation, and show how it has entered new domains such as cryptominers and site defacement.

In the Appendix you can find indicators of compromise (IOC).

The CrimeOps Behind the KashmirBlack Botnet

According to Wikipedia, ‘ DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from Agile methodology ’.

Simply put, CrimeOps is the utilization of DevOps practices to facilitate crime – the DevOps behind the KasmirBlack botnet and its infrastructure support continuous delivery processes to enable an agile software development cycle. We’ll show how those are being accomplished in conjunction with a CrimeOps strategy.

Botnet Overview

Figure 1 below offers a hint to the complexity of the botnet and the different entities that play a role in this operation. The color of the entities reflect their characteristics: red for malicious services created by the owner of the botnet, orange for victims used by the botent, green for innocente.

Here’s a high-level description of the entities:

• A C&C server is a centralized machine that controls the machines which make up the botnet
• ‘Repository A’ stores the botnet malicious script for communication with the C&C
• ‘Repository B’ stores bundles of exploits and payloads
• A ‘spreading bot’ constantly communicates with the C&C to receive instructions to attack other victims. In the case of a successful attack the bot will report back to the C&C regarding the new victim that converted into a ‘pending bot’.
• A ‘pending bot’ waits for the C&C to approach and define its purpose in the botnet

Figure 1: KashmirBlack botnet flow diagram

To better understand this diagram we’ve broken down the flow into pieces in our next week blog “The CrimeOps of the KashmirBlack Botnet – Part II”.

The Crime Behind The Ops

Security research investigation can sometimes be like a crime scene investigation. However, our crime scene will be spread all over the network, with no body in place. We, therefore, need to collect the clues and fingerprints that will allow us to construct a picture of the virtual crime.
Here is the journey of our research.

We started our surveillance on the KashmirBlack botnet in January 2020 and began to uncover the operation piece by piece, by answering three main questions: When? How? And What?

When did the botnet start?

The KashmirBlack botnet operation, as we know it, started in around November 2019. We have two pieces of evidence that support this timeline. The first, found in our data lake, shows the earliest exploitation attempts of PHPUnit RCE vulnerability (CVE-2017-9841) to infect our customers with the KashmirBlack malicious script. The other is the date of one of the exploits in ‘repository B’ – November 6, 2019.

How does the botnet spread?

This question is answered in our next week blog “The CrimeOps of the KashmirBlack Botnet – Part II”.

What is the purpose of the botnet?

To answer this question we had to take a more active approach to the investigation. We went undercover and impersonated a ‘spreading bot’ in the botnet and, without actually attacking any targets, started to collect information about the botnet’s victims. Then, in order to understand the purpose of those victims as ‘pending bots’, we had to become a victim ourselves. We created a CMS honeypot and attacked it with our ‘spreading bot’, as such we became a ‘pending bot’ in the KashmirBlack botnet.

We witnessed five types of purposes for the botnet: crypto mining, spamming, defacement, spreading and pending bot.
The next section will describe more deeply some of the purposes mentioned above.

Monero Crypto Mining

According to Wikipedia, ‘Monero is actively encouraged to those seeking financial privacy, since payments and account balances remain entirely hidden, which is not the standard for most cryptocurrencies’.
The KashmirBlack botnet uses the ‘XMRig’ miner to mine Monero coins to a remote wallet on a HashVault pool.
Examining its code gave us a glimpse into the wallet from where we could see that the mining operation started on March 31, 2020.

The attacker payment address is: 44qSPEgLnC5CF7ajChi4UZK5Z89tiaXiwcU8BGJ1yNB8NcrwhuiSrRRb3gSmhaGLAB8ERuJs3FhdmAgJfiGjHA9mM21DHE8

Taking into account that the mining operation was limited to a maximum of 50% of the infected host’s CPU, with a hash rate of 16,000 hashes per second, we could conclude that there were around 80 infected victim hosts.

Figure 2: The attacker mining activity

Spamming

Infected by the KashmirBlack botnet, our honeypot was converted into a spamming bot.
When trying to access the honeypot’s login page, the visitor was redirected to: hxxp://134.249.116.78 which performed an additional redirection to one of many clickbait sites.

Figure 3: One of spamming bot redirection to clickbait site

Defacement – The Indonesian Crew

One important piece of evidence we collected from the KashmirBlack botnet concerned the identity of the attacker behind the operation.
Below we can see the defacement signature:

Figure 4: KashmirBlack Defacing attack signature

We suspect the owner of the KashmirBlack botnet is the hacker Exect1337 – a member of the Indonesian hacker crew ‘PhantomGhost’.
Figure 5 below is a screenshot of another defacement attack performed by the PhantomGhost crew:

Figure 5: Site that was hacked by the Indonesian hackers crew ‘PhantomGhost’

In the Appendix you can find ‘Appendix C IOC’ to check if your site has been infected.

Botnet Evolution and CrimeOps

The KashmirBlack botnet has a massive infrastructure that gives it the ability to transform very quickly and easily.
Once the infrastructure is in place, minor modifications can change the entire botnet’s purpose. Every component is independent and can be easily replaced by another of the same type without interfering with the botnet operation. In this section we’ll describe the evolution of the botnet over the research period and the DevOps strategy that enables it to carry out its crimes.

The evolution of the botnet focuses on two main domains: the botnet expansion process in terms of exploits and payloads deployment, and the other on the infrastructure to make it more agile.

Exploits & Payloads Deployment Process

November 2019, ‘repository B’ contained 15 exploits and payloads, in comparison for today where the repository contains more than 20.
Our assumption is that until March 2020, the maintainer of the botnet focused only on expansion, the build phase. Once the botnet becomes big enough new payloads start emerging.

On March 15, 2020, we noticed a new payload had been added under ‘repository B’. This payload downloads a cryptominer into the ‘spreading bot’ machine to start mining for Monero coins. Later, on May 1, 2020, another exploit and payload bundle was added, and used for site defacement. Further updates with minor changes inside the exploit code were conducted on May 11, 2020.

Each deployment to ‘repository B’, triggered a process that cloned all the bundles into the repository. This indicates some sort of CI/CD process used by the KashmirBlack botnet maintainer.

Infrastructure Changes

The earliest record of KashmirBlack botnet included one server used as ‘repository A’ and one server used as ‘repository B’.

May 15, 2020, saw the start of a more significant change.
Infrastructure changes were carried out over the next week and a half, including:

1. Adding a new entity – ‘repository A load balancer’ – to get the address of ‘repository A’
2. Adding multiple repositories to expand ‘repository A’
3. Adding multiple repositories to expand ‘repository B’

There were three main reasons behind these changes:

1. Make the botnet more dynamic and scalable – achieved by change 1
2. Redundancy & FailOver – achieved by change 2 & 3
3. Load balancing – achieved by change 2 & 3

Load Balancing & Redundancy

As the botnet size increased, so too did the load on the repositories, as more bots fetched files from these repositories. Secondly, since some of the repositories were actually legitimate sites, they couldn’t be considered to be permanent entities in which to store payloads and exploits. By increasing the number of repositories, the botnet achieved two important features – redundancy and load balancing.

‘Repository A’ had been scaled from a single server to at least seven servers.
‘Repository B’ had been scaled from a single server to 74 domains, hosted on 53 different hosts.

Scalability

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.
Figure 6 below shows this infrastructure change.

Figure 6: The infrastructure change of ‘repository A load balancer’

Internal Changes – Securing The C&C

The C&C is the most sensitive and important component in the entire operation. Securing it is vital.
Two internal changes were made in order to avoid interfering with the C&C:

1. Reporting address change
2. Bot IP tracking

As described above, we impersonated a ‘spreading bot’ and triggered a fake reporting request to the C&C with our honeypot details. One and a half hours later, the attacker visited our honeypot and tried to infect it with the botnet malicious script.
We assume the attacker grew suspicious and, as a result, decided to change the logic of communication with C&C.

On May 8, 2020, three days after our honeypot was infected, we saw an update of the reporting address from hxxps://<C&C_server>/adeliap/404.php to hxxps://<C&C_server>/adeliap/405.php.

On May 26, 2020, the botnet malicious script was updated with a bot tracking mechanism designed to achieve two goals. The first was to secure the botnet and the second was to manage the deployment process of malicious script updates.
At the time we interrupted the botnet operation’s natural flow with our honeypot, the botnet had no measures in place to know which bot performed which attack.
But the simple architecture change of adding the registration of a bot’s IP and country while it communicated with the C&C allowed the C&C to track the operation of each bot in the botnet. Figures 7 and 8 show the previous version vs. the current version of the C&C communication.

Figure 7: Previous C&C communication

Figure 8: Current C&C communication

In the next section we’ll show how this change allowed the C&C to manage the deployment process of new versions of the malicious script to the bots.

Malicious Script Deployment Process

The above infrastructure changes created a situation where some spreading bots were communicating with the botnet entities by using the new infrastructure while others were only aware of the old one. In order to align them all, a new payload was added under ‘repository B’ with the updated malicious script. Now, the C&C could instruct all old spreading bots to fetch a new malicious script and register it in the C&C. This step helped to manage the deployment process of new versions of the malicious script to all spreading bots.

Figure 9 below shows the ‘spreading bot’ transformation.
The orange entities represent the old infrastructure while the blue represent the new infrastructure.

1. C&C instructs the ‘spreading bot’ to download the updated malicious script from ‘repository B’
2. The ‘spreading bot’ downloads the new malicious script from ‘repository B’
3. Old ‘spreading bot’ transforms into a new ‘spreading bot’

Figure 9: Botnet Malicious Script Deployment

Migrating the C&C to a cloud-based service

Another interesting infrastructure emerged during a regular monitoring activity on September 24, 2020. The KashmirBlack botnet entered a new evolutionary stage by using a cloud-based service, Dropbox, to replace the C&C. We saw evidence that the Dropbox API is being used to fetch attack instructions and upload attack reports from ‘spreading bots’.
Moving to Dropbox allows the botnet to hide illegitimate criminal activity behind legitimate web services. It is yet another step towards camouflaging the botnet traffic, securing the C&C operation and, most importantly, making it difficult to trace the botnet back to the hacker behind the operation.

New KashmirBlack Infrastructure Flow Diagram

Figure 10 below shows the current flow diagram of the KashmirBlack botnet.

Figure 10: KashmirBlack botnet flow diagram

KashmirBlack botnet evolution timeline:

• November 6, 2019 – oldest exploit and payload bundle uploaded to ‘repository B’
• November 25, 2019 – oldest indication for KashmirBlack botnet activity
• January 31, 2020 – other exploit and payload bundles uploaded to ‘repository B’
• Match 31, 2020 – cryptominer payload added to ‘repository B’
• May 1, 2020 – defacement exploit and payload bundle added to ‘repository B’
• May 5, 2020 – fake report to the C&C with honeypot details
• May 5, 2020 – attacker visited the honeypot
• May 6, 2020 – second fake report to the C&C with honeypot details
• May 8, 2020 – internal change to the botnet’s reporting address
• May 9, 2020 – attacker’s second visit to the honeypot
• May 11, 2020 – exploit and payload bundles updated
• May 2020 – KashmirBlack Github repository hidden
• May 15-17, 2020 – new repositories created as future additions for ‘repository B’
• May 21, 2020 – ew repositories created as future additions for ‘repository A’
• May 24, 2020 – multiple new ‘repository B’ usage begins
• May 26, 2020 – KashmirBlack malicious script updated to address ‘repository A load balancer’
• May 31, 2020 – End of research period

Figure 11 below shows the events of the botnet evolution on a timeline.
Purple indicates activities that are related to the expansion process (exploit and payload bundle deployment), Green indicates activities that are related to infrastructure changes,
Orange indicates our interference with the botnet activity,
Gray indicates general activities.

Figure 11: KashmirBlack botnet evolution timeline

×

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 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.

We saw how building and maintaining a botnet is very similar to an application development process. It requires code maintenance, version control, infrastructure, and deployment cycles.
The hacker behind the botnet needs to act as architect, developer, and DevOps. To create a stable botnet that will carry out the intended CrimeOps, the hacker needs to design both the operation and its entities. In addition, he needs to think about factors such as backups, failover, redundancy, scalability, and more.

The KashmirBlack botnet consists of many entities. There are several traces that indicate a server is compromised and taking part in the botnet. Each entity in the botnet has different indications of infection. For additional details about IoC see the Appendix.

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.

Read: CrimeOps of the KashmirBlack Botnet – Part II –>