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.
In the following sections well 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.
Well inspect the evolution and version deployment of the botnet during the research period, from November 2019 until the end of May 2020. And well 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).
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. Well show how those are being accomplished in conjunction with a CrimeOps strategy.
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.
Heres a high-level description of the entities:
Figure 1: KashmirBlack botnet flow diagram
To better understand this diagram weve broken down the flow into pieces in our next week blog The CrimeOps of the KashmirBlack Botnet Part II.
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?
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.
This question is answered in our next week blog The CrimeOps of the KashmirBlack Botnet Part II.
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 botnets 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.
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 hosts 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
Infected by the KashmirBlack botnet, our honeypot was converted into a spamming bot.When trying to access the honeypots 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
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.
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 botnets 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 well 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:
There were three main reasons behind these changes:
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 couldnt 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.
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
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:
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:///adeliap/404.php to hxxps:///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 operations 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 bots 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 well show how this change allowed the C&C to manage the deployment process of new versions of the malicious script to the bots.
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.
Figure 9: Botnet Malicious Script Deployment
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.
Figure 10 below shows the current flow diagram of the KashmirBlack botnet.
Figure 10: KashmirBlack botnet flow diagram
KashmirBlack botnet evolution timeline:
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
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.
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 >
The post CrimeOps of the KashmirBlack Botnet Part I appeared first on Blog.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Ofir Shaty. Read the original post at: https://www.imperva.com/blog/crimeops-of-the-kashmirblack-botnet-part-i/
Read the original:
CrimeOps of the KashmirBlack Botnet Part I - Security Boulevard