# Kinsing  Demystified

### A Comprehensive Technical Guide


-----

### Table of Contents

###### 03

 04

 07

07

22 Applications Kinsing Target (Vulnerabilities and Misconfigurations)

23 Kinsing’s victims in the wild (OSINT)

###### 31

 32

32 Type I Scripts – comprehensive analysis

35 Type II Scripts – comprehensive analysis

37 Auxiliary scripts analysis

###### 46


-----

y

### Executive summary

Kinsing first surfaced as a cybersecurity threat in 2019 and quickly became a widespread
concern, attacking various applications globally. Despite extensive analysis by security
professionals, little has changed, and as of 2024, new insights continue to emerge about the
Kinsing operation, providing strategies for security teams to better mitigate associated risks.

Since its initial appearance, Kinsing’s modus operandi has largely remained unchanged. It
typically exploits vulnerable or misconfigured applications, executes an infection script, runs
a cryptominer—often concealed by a rootkit—and maintains control over the server using the
Kinsing malware. However, it raises the question: What precisely is Kinsing? Is it the name of the
malware, the threat actor behind it, or both? Our research indicates that there is more to learn
about this significant threat.

Organizations that learn from past interactions and adapt to the ever-changing threat landscape
are better equipped to counter the enduring threat posed by Kinsing and similar adversaries. This
report provides:

- An acknowledgment that defenders have less time than anticipated to address vulnerabilities
and must take further steps to protect their environments.

- A detailed list of the applications and environments targeted by Kinsing.

- An in-depth analysis of Kinsing’s techniques, tactics, and procedures.

- An examination of changing attack trends, the evolution of attack patterns, and the rapid
incorporation of new vulnerabilities upon their discovery.

Understanding Kinsing’s history is fundamental for devising effective defense strategies. Although
regular software updates, and vigilant monitoring are critical for mitigating risks and guarding
against this persistent threat, these measures alone are insufficient. Implementing runtime
behavioral controls to enhance a defense-in-depth strategy is crucial. The historical data on the
Kinsing malware highlights the continuous need for alertness, resilience, and collaboration within
the cybersecurity community.


-----

### Introduction

To provide an accurate sense of the interest in Kinsing, a search for “kinsing” on Google yields
over 180,000 results. Google Trends indicates that interest in Kinsing began in 2019, with
the most significant spike in January 2020, followed by notable peaks in October 2021 and
September 2023. These spikes correspond to various reports about specific applications
targeted by Kinsing, such as Openfire.

###### What Exactly is Kinsing?
Is it the moniker of the malware, the threat actor, or both, as some articles suggest? Despite
numerous reports, our research reveals that there is still significant information to be added to the
body of knowledge.

The most effective way to understand threat actors’ campaigns is to comprehensively review
available reports online. This was our initial step. Although we have been tracking Kinsing
campaigns since their inception in 2019, we aimed to assimilate all possible insights from the
cybersecurity community. We carefully analyzed select publications from our colleagues in the
industry. Some of these works are exceptional pieces of research that illuminate various facets of
Kinsing’s activities. Nevertheless, we sensed that the full picture was not yet complete. Our review
allowed us to consolidate our understanding of Kinsing.

TrustedSec was the first to report on Kinsing, on January 15, 2020, detailing an attack that
exploited CVE-2019-19781 against Citrix NetScaler for remote code execution. Until this report,
the connection between the Citrix attack and Kinsing had not been made. However, we managed
to retrieve the ci.sh script from Kinsing’s current C2 server, maintaining access even as the
threat actor frequently changed download servers throughout our investigation. This script
remained on the download server, unlike some (e.g., rv.sh) that were omitted from newer server
versions. Alibaba Cloud’s security team, often credited as the initial reporters on Kinsing, followed
on January 16, 2020, referring to it as h2Miner.

[Our team, Aqua Nautilus, was the first to name the malware “Kinsing” in a report in April 2020](https://www.aquasec.com/blog/threat-alert-kinsing-malware-container-vulnerability/)
— a name that has since been widely adopted. The first known attack was actually against our
misconfigured Docker API on December 15, 2019. Other reports corroborate that December 2019
marked Kinsing’s emergence in its current campaign.

In November 2020, TrendMicro published a thorough report analyzing Kinsing’s rootkit. The
researchers provided an in-depth analysis of both the download script and the rootkit. Our
analysis confirmed their findings regarding the rootkit’s structure and functionality.

In September 2021, CyberArk published a detailed comparison between the NSPPS malware and
Kinsing malware, highlighting significant similarities in code structure, RC4 encryption keys, and
function names, while also noting some differences. Their conclusion was that despite these
differences, the similarities indicate that both malwares belong to the same family. NSPPS seems
to be an earlier version with remote access Trojan (RAT) functionality, while Kinsing is a more
recent variant with added cryptomining features and other functionalities. These similarities aid
researchers in the analysis and detection process.


-----

Throughout Kinsing’s active period (2019-23), many publications have detailed specific attacks
targeting a variety of vulnerabilities, misconfigurations, and environments. These include:

      - [Liferay CVE-2020-796 (Redteam PL)](https://blog.redteam.pl/2020/06/kinsing-malware-liferay.html)

      - [Unauthenticated Redis servers (TrendMicro)](http://www.trendmicro.com)

      - [Oracle WebLogic CVE-2020-14883 (Akamai)](https://www.akamai.com/blog/security/Kinsing-evolves-adds-windows-to-attack-list)

      - [Log4Shell CVE-2021-44228 (Zscaler)](http://https://www.zscaler.com/blogs/security-research/threatlabz-analysis-log4shell-cve-2021-44228-exploit-attemptshttp://)

      - [Confluence - CVE-2022-26134 (Lacework)](https://www.lacework.com/blog/kinsing-dark-iot-botnet-among-threats-targeting-cve-2022-26134/)

      - [Citrix ADC - CVE-2019-19781 and SaltStack - CVE-2020-11651/2 (Red Canary)](https://redcanary.com/blog/kinsing-malware-citrix-saltstack/)

      - [Kubernetes (Microsoft)](https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/initial-access-techniques-in-kubernetes-environments-used-by/ba-p/3697975)

      - [Apache Nifi (Sans), and many others.](https://isc.sans.edu/diary/Your+Business+Data+and+Machine+Learning+at+Risk+Attacks+Against+Apache+NiFi/29900http://)

[In addition, comprehensive reports like the one from Cysiv have linked several vulnerabilities,](https://www.forescout.com/resources/kinsing-cloud-cryptojacker/)
showcasing the breadth and depth of Kinsing’s exploits.

While we can’t cover every blog, this selection highlights the wealth of write-ups, knowledge,
and interest in Kinsing. Its persistent presence across our various honeypots piqued our curiosity.
We started to probe deeper, asking questions like whether Kinsing is the work of a single threat
actor or if its source code was leaked, leading to its widespread use. We inquired about Kinsing’s
operations, target scope, primary objectives, infrastructure details, the possibility of it being a
botnet (as it appeared in some publications), and more. We didn’t find a singular answer.

The infrastructure choices that we observed when gathering information may suggest a
connection to Russian-speaking countries, which could imply Russian origins for the threat actor,
while the frequent targeting of Chinese servers could suggest Chinese origins.


-----

g g q,,

In the Russian language, “Kinsing” doesn’t translate directly to anything meaningful. The name
seems to be derived from English phonetics and is unrelated to any Russian words.

If we were to search for a phonetic similarity in Russian, we could dissect it: “Kin” has no
standalone meaning, but phonetically it could relate to “кин,” a root for Russian verbs associated
with throwing or motion, such as “кинуть” (to throw). “Sing” phonetically resembles “синг,” which
is meaningless in Russian. However, “синий” translates to “blue.” Thus, “kinsing” could whimsically
translate to “blue throw,” which is nonsensical.

Similarly, examining Mandarin for phonetic matches, “Kin” could resemble “金” (jīn), meaning
“gold,” or “金星” (jīnxīng), meaning “Venus,” the planet. “Sing” doesn’t match directly with
Mandarin, but a similar sound, “星” (xīng), means “star.” Hence, “Kinsing” might whimsically be
interpreted as “golden star,” an interpretation we find more appealing. That said, if you know of a
better significance for Kinsing, we encourage you to contact us.

This report represents our endeavor to explore and address the questions surrounding Kinsing.
With the help of the community, we aim to uncover answers and foster a deeper understanding of
the issue. In this paper, we detail the infrastructure and operations of Kinsing, analyze the targets,
and present insights from forum discussions by those who have experienced the impact of Kinsing
firsthand. Our goal is to compile all pertinent information into this comprehensive report, serving
as a valuable resource for anyone with an interest in Kinsing or those who have been affected by
its activities.


If we were to search for a phonetic similarity in Russian, we could dissect it: “Kin” has no
standalone meaning, but phonetically it could relate to “кин,” a root for Russian verbs associated
with throwing or motion, such as “кинуть” (to throw). “Sing” phonetically resembles “синг,” which
is meaningless in Russian. However, “синий” translates to “blue.” Thus, “kinsing” could whimsically
translate to “blue throw,” which is nonsensical.

Similarly, examining Mandarin for phonetic matches, “Kin” could resemble “金” (jīn), meaning
“gold,” or “金星” (jīnxīng), meaning “Venus,” the planet. “Sing” doesn’t match directly with
Mandarin, but a similar sound, “星” (xīng), means “star.” Hence, “Kinsing” might whimsically be
interpreted as “golden star,” an interpretation we find more appealing. That said, if you know of a
better significance for Kinsing, we encourage you to contact us.


-----

g g q,,

### Uncovering Kinsing’s Techniques, Tactics, and Procedures

In this chapter, we review the architecture of Kinsing’s infrastructure. Drawing on various
publications, we aim to provide a more comprehensive understanding of how Kinsing has
operated over the past four years.

In the second section, we delve into the artifacts associated with Kinsing. Here, we enumerate all
the scripts, binaries, and exploits detected in the wild, drawing on data from our honeypots, other
publications, and an extensive investigation of the Kinsing infrastructure.

The third section presents our analysis of a Kinsing malware sample that we collected.

In the fourth section, we offer an analysis of a rootkit sample used in the Kinsing campaign, which
we also collected.

##### Kinsing’s Architecture

The Kinsing campaign has been operational since 2019, and over this period, many publications
detailing its activities have surfaced. These include in-depth analyses of specific attacks or tools,
as well as comprehensive reports linking multiple attacks. However, there’s a noticeable absence
of a thorough write-up that encompasses the full spectrum of attacks, addresses all components,
and provides a complete overview of Kinsing’s architecture. In this section, we aim to examine the
attack infrastructure and operations of Kinsing, thereby elucidating its architecture.

Figure 1: Kinsing’s Openfire Campaign

**Victim server**

**5.  Runs a cryptominer**
**hidden by rootkit**

**3.  Runs a memory** **4.  Encrypted**
**resident malware** **communication**

**Kinsing’s scan** **Vulnerable** **Kinsing’s C2**
**server** **Openfire** **server**

**Kinsing’s**
**Download server**


-----

g g q,,

We have identified three primary components in the Kinsing campaigns:

Scan and exploit servers: The initial server is responsible for scanning vulnerabilities and
exploiting them. It boasts advanced scanning capabilities, likely employing tools such
## 1
as masscan, and possibly has access to server databases such as Zoomeye or Shodan.
While the Kinsing malware includes masscan capabilities, there’s no definitive proof that
the threat actor actively uses this tool.

Download servers: These servers act as an intermediary for downloading binaries and
scripts. For instance, the threat actor uses one IP address to download the main payload,
## 2
a script that then fetches the Kinsing malware and, occasionally, a rootkit. From another
server, the Kinsing malware downloads a Monero cryptocurrency miner.

Command and control (C2) servers: The final element, the C2 server, manages
communication with compromised servers. After deployment, the Kinsing malware
## 3
connects with these servers. Historically, from April 2019 to August 2020, the threat actor
communicated directly using an IP address. However, from August 2020 to October 2020,
the Kinsing operator started using the vocaltube.ru website for C2 interactions.

Figure 2: the website under the domain vocaltube.ru (c2 server)

This site was registered in August 2020, with the first related VirusTotal event noted in October
2020. This shift in architecture might be a strategy for defense evasion, or it could suggest that
the website was compromised. Although the precise purpose of its usage is unclear, DNS
requests for vocaltube.ru have been detected, along with IP-based communications between the
C2 server and the victim’s machine.


-----

g g q,,

|Ukraine 20 %|Col2|
|---|---|
|||

|Netherlands 10 %|Col2|
|---|---|
|||

|Col1|Col2|
|---|---|
|Russia 68 %||

|Col1|Col2|
|---|---|
|L|uxembourg 2 %|


We analyzed the communication with the C2 server. Over three years, we found very little change
in the IP address of the C2 server. When 185.154.53.140 is resolved when vocaltube.ru is queried.

# C2 IP Address Country ISP Usage in the attacks

1 185.154.53.140 Russia EuroByte LLC 39.4%

2 212.22.77.79 Russia Cloud Solutions LLC 38.2%

3 185.221.154.208 Russia EuroByte LLC 22.3%

4 93.189.46.81 Russia Limited Liability Company NTCOM 0.031%

5 109.248.59.253 Russia Russia High Speed Online LLC 0.010%

6 194.169.160.157 Russia Ztv Corp LLC 0.010%

7 185.224.212.104 Russia 2Day Telecom LLP 0.003%

The group of IP addresses used to download the scripts and binaries was a bit bigger (41) and
distributed mostly among Eastern European countries:

Graph 1: Geo-location distribution of ‘Download servers’

Ukraine 20%

Netherlands 10%

Russia 68%

Luxembourg 2%


-----

g g q,,

##### Kinsing’s Attack Tools

We conducted an extensive analysis of the Kinsing C2 artifacts’ download server over four weeks.
During this time, we observed that Kinsing frequently replaced its download servers. To gain
a deeper understanding of the threat actor’s intentions and what they aimed to expose on the
internet as part of their campaign, we executed several queries.

The following are some key stats and insights we gathered during this period:

The campaign has been active since 2019 and
continues to operate.
## 1

The core components of the attack include the Kinsing malware and
a cryptocurrency miner.
## 2

Three distinct groups of artifacts
are identified.
## 3

The campaign targets
75 different applications.
## 4

Each week there was a new script that exploited a new remote code
execution (RCE) vulnerability.
## 5

Kinsing targets applications and infrastructure across the entire cloud software
development life cycle (SDLC).
## 6

Kinsing targets various operating systems with different tools. For instance, Kinsing
often uses shell and Bash scripts to exploit Linux servers. We’ve also seen that Kinsing is
## 7
targeting Openfire on Windows servers using a PowerShell script. When running on Unix,
it’s usually looking to download a binary that runs on x86 or arm.

Most targeted applications
(91%) are open source.
## 8

While Kinsing mainly targets runtime applications (67%) it also targets various other
areas in cloud native environments, such as CI/CD (Jenkins), APIs (Kubernetes, Docker
## 9
daemon), and code.


-----

Figure 3: Sankey diagram of the campaign year OSS or not and targeted cloud environment. Example:
Postgresql is an open-source database that was first targeted by Kinsing in 2019

Campaign Start Year Targeted environment

in the SDLC

2019: 6

Open-Source
or Not

**Runtime: 42**

2020: 19

**Open-source: 71**

**Database: 9**

2021: 34

**Cloud Infrastructure: 8**

2022: 9

**Proprietary Software: 7**

**Code: 1**

**CI/CD: 1**

2023: 10

**Security: 1**

In this chart we show the relations between the first time (year) the software was targeted (Left).
Type of software, Open-source or proprietary (Middle), and which environment is targeted in the
Software Development Life Cycle (Right).


-----

g g q,,

Our investigation revealed three distinct groups of artifacts:

Type I and Type II scripts: These are scripts that are downloaded after initial access is gained.
These are the main payload, designed to support the attack by deploying the Kinsing malware, a
cryptominer and often a rootkit, as well as to kill competition and evade detection.

Auxiliary scripts: These scripts are designed to accomplish initial access by exploiting a
vulnerability, prepare the victim’s environment, and deploy a backdoor.

Binaries: These are binaries that take part of the attack as a second payload, such as the Kinsing
malware, the cryptominer, or exploits that are aimed to gain initial access, such as a Java class.

###### Type I and Type II Scripts – Differences and Commonalities

Both Type I and Type II scripts are designed to operate on compromised servers as primary
payloads, orchestrating the attack. They share common functions, such as downloading attack
components, eliminating competing malware, and evading detection.

However, there are notable differences. Type I scripts resemble a lengthy grocery list, appearing
as a patchwork of snippets that include competition elimination and defense evasion tactics
accumulated over time. In contrast, Type II scripts are more succinct, comprising only 454 lines
compared with the 825 lines in Type I scripts, making them about half the size. As shown in Graph
2, Type I scripts primarily focus on eliminating competition (76%) and dedicate less to defense
evasion. Type II scripts, however, place greater emphasis on defense evasion, both in terms of the
percentage of the script dedicated to this and the actual number of code lines, primarily through
deploying a rootkit.

Initially, we hypothesized that the differences between these script types were due to their age,
presuming that Type I scripts were older than Type II. As supporting evidence, we saw that most
of the recently written scripts were affiliated with the Type II group. However, this wasn’t the case.
We also considered the nature of the targeted systems but found that both scripts target the
same applications, such as Laravel and Postgres. Therefore, the exact reason for the existence of
two script types remains known only to the threat actor.

Type I scripts start with #!/bin/sh while Type II scripts start with #!/bin/bash. While these
might seem like minor textual differences, they actually represent a huge difference. When
comparing two servers, one using sh (the Bourne shell) and the other using bash (the Bourne
Again shell), there are several key differences to consider in terms of tools, features, and
privileges. Bash is an enhanced and extended version of 55 T sh, so it includes all the features
of sh plus additional functionalities. For instance, Type II scripts, (designed to run on Bourne Again
shell, bash) end with `history -c, which typically isn’t a built-in command in the Bourne shell`
(sh).


-----

g g q,,

Another point of interest is the 75% decrease in the volume of snippets aimed at eliminating
competition between Type I and Type II scripts. This raises several questions: Is there less
competition among attackers on certain applications, or has the overall competition in the cloud
diminished over time? Has Kinsing shifted its focus from battling for server control to enhancing
its scan-detect-infect capabilities? Or has it become agnostic to competition, which might impede
its main goal of mining operations and increase the risk of detection. It’s also possible that the
threat actor initially included an abundance of snippets to eliminate any competition, but over
time, they refined their approach, tailoring it to specific campaigns and cloud-native environments.

Graph 2: Type I scripts composition of goal,
based on snippet analysis


##### 4.2%


Kill Competition
Support Attack
Defense Evasion

##### 76.4%


##### 19.4%


Graph 3: Type II scripts composition of goal,
based on snippet analysis


##### 53.3%


Kill Competition
Support Attack
Defense Evasion

##### 11%

 35.7%


-----

###### Binaries

These 12 binaries are dropped during different stages and types of attacks. Some (kinsing and
```
kdevtmpfsi) appear in almost all of the attacks, while others support specific needs in specific

```
servers.

Binaries: b, curl-aarch64, curl-amd64, kinsing, kinsing_aarch64, kinsing2,
```
libsystem.so, LifExp.class, xmrig.exe, and kdevtmpfsi

```
Kinsing binaries: The binaries `kinsing, kinsing2, kinsing_aarch64 and b are all the`
kinsing malware, as described below in the “Kinsing Malware” section.

The cryptominers: The binaries xmrig.exe, kdevtmpfsl, x, x2, x_arm and x2_arm are
all an `xmrig miner, as described below in the “Kinsing’s Mining Campaign” section.`

The binary lifexp.class: This is an exploit of the Liferay RCE vulnerability (CVE-2020-7961).

Figure 4: the Liferay exploit


-----

g g q,,

##### Attack Volume

Upon analyzing the Kinsing campaigns against our honeypots, we discerned varying attack
trends. Some honeypots were assaulted dozens of times daily, while others experienced only
several attacks. On average, honeypots were targeted by Kinsing eight times per day, with the
number of attacks ranging from three to 50. For example, our misconfigured Docker API honeypot
faced an average of 50 attacks daily, fluctuating from hundreds to several daily. This pattern was
consistent with other honeypots. Our Jenkins honeypot underwent an average of 0.2 to 13 attacks
per day, depending on the month, while PostgreSQL encountered between 0.8 and 60 daily
attacks on average.

These attacks varied across specific software types, suggesting that the Kinsing threat actor
is continually shifting targets, focusing on particular applications at different times. When new
vulnerabilities are disclosed, they naturally become a priority, but they may also gain increased
attention months later.

Our Shodan search revealed 2.5 million instances of the various applications targeted, indicating
that Kinsing’s scanning operation is probing millions of instances.

Our research indicates that the Kinsing threat actor incorporates new vulnerabilities upon their
release. Over three months, we observed Kinsing targeting five new vulnerabilities as soon as
they were included in the attack scripts.

##### Kinsing Malware

In September 2021, CyberArk published “Kinsing: The Malware with Two Faces,” a wonderful blog
that analyzes the binary of Kinsing while comparing it with another malware family: NSPPS. We
took this analysis as a baseline for our analysis and compared the differences.

In their blog, CyberArk found several samples of Kinsing. One of the samples
(SHA256: d247687e9bdb8c4189ac54d10efd29aee12ca2af78b94a693113f382619a175b) was
analyzed thoroughly and considered as a baseline in the blog. CyberArk noted that the binary
weighed 16.87 mb. Other samples were found to be smaller, weighing 5 to 6 mb. The researcher
speculated that the difference in size between the various samples in the wild may have stemmed
from Kinsing testing various versions of the malware or researchers only published partial part of
the binaries they analyzed.

In our work we tested our database to understand how many samples of kinsing we had. We
found 1,550 distinct binaries that bear the name kinsing or kinsing%%%%% (when % is a
random digit or letter).


-----

g g q,,


### 62.70%
###### of the attacks

SHA256
5d2530b809fd069f97b30a5938d471dd2145341b5793a70656aad6045445cf6d

### 27.98%
###### of the attacks

SHA256
787e2c94e6d9ce5ec01f5cbe9ee2518431eca8523155526d6dc85934c9c5787c

### 0.23%
###### of the attacks

SHA256
564739ea8fa5926d4fa5c9734fed462061960a22e6b8d5c06e94969d97891bf2

### 0.09%
###### of the attacks

SHA256
631d0eac8278f4c8090dcc89c905eebdac5ad03db6cf33be1f0a5a39ce6fff1a

### 0.09%
###### of the attacks

SHA256
d14b31a0e14615badab1ffcd6086c36f32c21a0cd40df93843efd42295e451bd

As seen above, the top five samples appeared in the various attacks covering more than 90% of
all the attacks we’ve seen. That means that the most interesting samples are 5d253 and 787e2.
We focused on the first sample and compared it with the findings in CyberArk’s report to learn
about the changes in the kinsing binary over time.

The first distinguished difference is in terms of size. As mentioned above, sample d2476 was
16.87 mb, while our sample 5d253 was 6.02 mb. When reviewing the differences between the two
samples, we see that the main functionality cited in the CyberArk report remained the same. One
of the main differences was that the older version used pkger, which is a tool for embedding static
files into Go binaries. These functions can’t be found in the newer versions.


-----

g g q,,

When inspecting what is calling this function you can see that it’s called to use the file ‘x’.

Figure 5: Downloading the cryptominer and renaming it to `kdevtmpfsi`

Next, it’s written to /tmp under the name kdevtmpfsi, which is obviously the cryptominer, so in
the older version of kinsing the malware contained an embedded version of the cryptominer
that was used.

We now have a new hypothesis to raise to compete with or challenge the one raised by CyberArk
researchers. It could be that the threat actor was looking to or did test the use of a binary with the
cryptominer embedded inside. It looks like it did catch – probably not then (because we know that
kinsing MO is to download the cryptominer from a remote source) and definitely not now because
we see de facto that most of the binaries weight 5 to 6 mbs.

We found various functions that appear in both files. One of them is gopsutil. In the older
kinsing, the version is v2.19.10, while in the newer it’s v3.21.11.


-----

In addition, we also inspected the kinsing dynamically. Using Tracee, an open source runtime
security tool, we collected network logs and monitored the communication. As seen in the table
below, these are the C2 communication recorded:

# URL Request Additional Goal Response
Type Input

1 /i GET Set log OK

2 /l POST Data Sends log data to C2 OK
server

3 /r POST Sends results OK

4 /o POST “{“Id”:802, Send Exec output OK

Data”:””}” to C2 server

5 /s POST “{ “User”:”jFcypPQo”, Send new SOCKS5 OK

“Pass”:”AcFAYwAE”, server’s user/pass/TCP
“Port”:31119 }” port to C2 server

6 /ms POST “{“Pid”:0}” Send miner’s process OK
ID

7 /mg GET Checks if the cryptominer 301 or
is running and provides The PID number example:
the PID of the miner “{“Pid”:0}”

8 /ki POST Request kill process data Example:

{“Exe”: [“app/Cli”, “.perf.c”,
“perfctl”, “kthreaddi”,
“kthreaddk”, “xmrig”,
<<TRUNCATED>>
“atlas.x86”, “dotsh”],
“Files”: [], “Lol”: [“lol”]}

9 /h2 GET Health/connectivity OK
check

10 /get GET Fetch the next “task” Example:
from C2 server {“Id”:802,

“Type”:”download_and_
exec”,
“Progress”:227960,
“Total”:1254856, “Thread”:1,
“Port”:1, “Timeout”:1,
“Data”:
http[:]//194[.]38.22.53/spre.
sh
}


-----

g g q,,

##### Kinsing’s Mining Campaigns

The main goal of Kinsing is to mine Monero. It does this by running a version of XMRIG. Over the
years, we haven’t seen any significant changes in this binary.

We analyzed the miner processes and found that it used the wallet 44MtPEE…


Figure 6: the cryptominer configuration


Figure 7: the cryptominer mining blocks


We inspected the wallet over two months and estimated that its average annual revenue would
be 18 XMR, or 3,100 USD, which is quite modest for this kind of operation. It could be that we’ve
failed to understand the full scope of the mining operation.

Figure 8: Kinsing’s wallet activity


-----

g g q,,

##### Kinsing’s Rootkits

In the Type II scripts, a rootkit is downloaded and executed to conceal the presence of Kinsing’s
attack components on the infected system.

Figure 9: Altering LD_preload by Kinsing

As illustrated in Figure 9, the rootkit is installed into the /etc/libsystem.so directory. Then,
the /etc/ld.so.preload file is manipulated to ensure that the rootkit is loaded early in the
process startup sequence, even before standard libraries like libc.so. This technique ensures that
the rootkit is deeply embedded and hard to detect.

###### Technical Analysis of the Rootkit

The rootkit contains encrypted lists of what to hide and how to hide it, including specific files
and network connections. It hooks into various system functions to control what’s visible and
what isn’t. For example, it can hide its own process files and network connections from system
monitoring tools.

The rootkit specifically targets files and processes related to the Kinsing malware (like kinsing,
```
kdevtmpfsi, and lib_system.so) and makes them invisible to normal system inspection tools.

```
Rootkits often hook into various system functions to manipulate the behavior of an operating
system, often for malicious purposes like hiding their presence or the presence of other malware.
Here’s an elaboration on what each of the listed functions typically does and how a rootkit might
manipulate them:
```
     access: Checks user’s permissions for a file. Kinsing’s rootkit hooks various files to

## 1 return that these files (kinsing, kdevtmpfsi, etca) don’t exist.

###### rmdir: Removes a directory. Kinsing’s rootkit could intercept commands aimed at
```
deleting certain directories like those containing malware components.
## 2

###### open: Opens a file. Kinsing’s rootkits might hook this to hide the opening of certain
files or to intercept and modify data being read from or written to a file.
## 3

###### readdir / readdir64: Reads directory entries. Kinsing’s rootkit can manipulate
these functions to hide specific directories or files from directory listings.
## 4

```
         access: Checks user’s permissions for a file. Kinsing’s rootkit hooks various files to

## 1 return that these files (kinsing, kdevtmpfsi, etca) don’t exist.

###### rmdir: Removes a directory. Kinsing’s rootkit could intercept commands aimed at
```
deleting certain directories like those containing malware components.
## 2

###### open: Opens a file. Kinsing’s rootkits might hook this to hide the opening of certain
files or to intercept and modify data being read from or written to a file.
## 3

###### readdir / readdir64: Reads directory entries. Kinsing’s rootkit can manipulate
these functions to hide specific directories or files from directory listings.
## 4


-----

g g q,,

```
         stat / stat64 and __xstat / __xstat64: Retrieves information about a file.

```
Kinsing’s rootkit might alter the results to hide file modifications or the existence of
## 5
certain files.

###### lstat / lstat64 and __lxstat / __lxstat64: Similar to stat, but for symbolic
links. Kinsing’s rootkit can manipulate these to hide or change information about links,
## 6
especially those pointing to malicious files.

###### fopen / fopen64: Opens a file and returns a file stream. Kinsing’s rootkit might hook
this to control access to specific files or to manipulate file contents.
## 7

###### link: Creates a new hard link to an existing file. Kinsing’s rootkit could use this to
create unauthorized links to sensitive files or to protect malware files.
## 8

###### unlink: Deletes a name from the filesystem. If a name was the last link to a file and
no processes have the file open, the file is deleted. Kinsing’s rootkit might intercept this
## 9
to prevent deletion of certain files.

###### unlinkat: Similar to unlink, but can operate on a directory file descriptor. Kinsing’s
rootkit might hook this to protect specific files or directories from being deleted.
## 10

By hooking these functions, the kinsing rootkit can effectively control how the operating system
interacts with files, directories, and file information. This allows the rootkit to hide its presence
and the presence of other malware, manipulate file operations, and maintain persistence on the
infected system. Such manipulations can be very challenging to detect and remove.

It’s worth mentioning [TrendMicro’s excellent analys is from 2020, and since it’s exactly the same](https://www.trendmicro.com/en_us/research/20/k/analysis-of-kinsing-malwares-use-of-rootkit.html)
hash value:

(SHA256=C38C21120D8C17688F9AEB2AF5BDAFB6B75E1D2673B025B720E50232F888808A)
we can conclude that the Kinsing threat actor is satisfied with this tool and thus invested no
attention to improve the rootkit over these past three years.


-----

g g

### Kinsing’s Targets

Targets can be categorized into two groups: the applications and environments that Kinsing
targets, and the personal accounts of the victims encountered in the wild. In this chapter, we
present an analysis of both aspects.

##### Applications that Kinsing Targets (Vulnerabilities and Misconfigurations)

Over the past five years, we’ve identified at least 75 software applications that have been
targeted by Kinsing. Our observations indicate that Kinsing exploits both vulnerabilities and
misconfigurations. For example, there are instances of misconfigured Docker APIs without
authentication, allowing anyone to deploy a container. In such cases, an Alpine container is
deployed with a malicious command that downloads and executes the script d.sh. It appears
that the majority of the software targeted by Kinsing is targeted because of vulnerabilities.
Notably, the recent vulnerabilities in Openfire and RocketMQ were exploited within one to two
weeks after their disclosure.

In Appendix 3, we provide a comprehensive list of the applications and environments targeted, as
per our analysis. Our analysis is not exhaustive. Even with the assistance of ChatGPT, we were
unable to complete the list of targets, as some remain unclassified. We encourage you to share
your insights or hypotheses regarding the potential targeted applications or environments, which
could help us in presenting a more complete assessment of the threat landscape.

Figure 10: Kinsing’s targeted applications


-----

g g

##### Kinsing’s victims in the wild (OSINT)

You can see many questions in programmers’ forums such as Stack Overflow, ask ubuntu, GitHub,

and forums for a specific application that Kinsing targeted, as well as a plethora of questions in
Chinese-speaking forums.

Figure 11: Initial Postgres remote code execution comand

In most cases the programmers ask
if they were infected by a malware,
indicating that they observe high CPU
by Kdevtmpfsi and sometimes mention
a process by the name Kinsing. Often,
they add the download script evidence
and sometimes the targeted application,
which all help to build a mosaic of
Kinsing’s history over time. For instance,
here you can find a question about
an unwanted PostgreSQL query. As
illustrated in Figure 11, a table is created
and a record with a bash command is
inserted.

Figure 12: decoded postgress payload

While decoding the base64 is fairly
easy, without doing so, it’s very hard to
understand what’s going on here. Once
it’s decoded, as illustrated in Figure
12, there are some basic commands of
process kill, implementation of curl and
a command to download the primary
payload pg2.sh.


-----

[Another example taken from the Laravel forum on Reddit, as the programmer is providing some](https://www.reddit.com/r/laravel/comments/lh6r5h/psa_laravel_842_has_vulnerability_cve20213129/?rdt=37510)
evidence of infection and how this can be detected and fixed.

These examples illustrate the justified and understandable security knowledge and experience
gaps that programmers, data engineers and other practitioners display when facing these
troubling indications. The abundance of such indications also illustrates Kinsing’s scope and the
extent of its attacks.

Figure 13: A forum post about Kinsing


-----

pp g g p g

### Mapping Kinsing’s Campaigns to the MITRE ATT&CK Framework

Our investigation showed that Kinsing has used some common techniques throughout the
campaigns (further details in Appendix 2):


-----

g

### Detection and mitigation

Kinsing targets Linux and Windows systems, often by exploiting vulnerabilities in web
applications or misconfigurations such as Docker API and Kubernetes to run cryptominers. To
detect Kinsing and similar malware, one can employ a combination of methods:

###### Threat intelligence

 - Information: Keep up to date with the latest threat intelligence reports on tactics, techniques,
and procedures used by Kinsing operators.

 - Known Indicators of Compromise (IoCs): such as the ones included in this report.

 - Awareness: Train staff to recognize signs of a compromise, such as phishing attempts that
could introduce Kinsing into the network.

###### Vulnerability management

 - Patch management: Regularly update and patch systems to close off vulnerabilities that
Kinsing could exploit.

 - Configuration audits: Regularly audit configurations, especially for exposed services like
Docker, to ensure they’re not misconfigured.

###### Container security

 - Docker daemon security: Ensure the Docker daemon isn’t exposed to the internet without
proper authentication.

 - Container monitoring: Implement monitoring solutions specifically designed for containerized
environments.

###### Behavioral analysis

 - Anomaly detection: Employ ystems that can learn baseline behavior and detect anomalies.

 - CPU and memory usage monitoring: Continuous high usage can indicate cryptomining
activity.

 - System performance monitoring: A sudden drop in system performance might suggest
malicious processes are running.

 - Unusual processes: Look for processes that aren’t typically part of the system’s operations.

 - Process names: Kinsing may attempt to masquerade as a legitimate process but may be
detected by close inspection of process names and paths.

 - Unusual outbound traffic: Check for an increased volume of outbound traffic, especially to
known mining pools.

 - Network connections: Look for connections to suspicious IP addresses and ports typically
used by miners.

 - Unexpected changes: Monitor for unexpected changes to system files and directories.

 - Rootkits: Look for signs of rootkit installation that can hide malicious activity.


-----

g y q

### Enhancing Cloud Security with  Aqua CNAPP

In today’s landscape of escalating cyber threats, organizations need to establish a
comprehensive multi-layered security strategy to safeguard their digital transformation. The
Aqua Cloud Native Application Protection Platform (CNAPP) provides robust end-to-end
protection for your cloud native applications, mitigating risks across the full lifecycle and
fortifying workloads against attacks in production.

To prevent potential threats like Kinsing, proactive measures such as hardening workloads
pre-deployment are crucial. Aqua CNAPP allows security teams to detect and mitigate known
vulnerabilities in their container images, helping prioritize patching based on many factors such
as active exploitation in the wild and the availability of PoC (proof-of-concept) exploits. This
significantly reduces the attack surface and closes off potential entry points for attackers.

Figure 14: The Aqua platform fails the build when a high rank vulnerability is detected


-----

g y q

While vulnerability scanning and timely patching play a pivotal role in prevention, ensuring runtime
protection is equally essential. Aqua CNAPP addresses this need with intelligence-driven runtime
protection and quickly deploys granular controls layered throughout your environment. Drift
prevention seamlessly enforces the container immutability to identify and block unauthorized
processes in running containers with no downtime.

Beyond traditional signature-based malware detection, Aqua CNAPP offers advanced protection
against unknown and zero-day threats. Leveraging real-world threat intelligence from Aqua
Nautilus, eBPF-based behavioral detection enables security teams to identify and respond to
behavioral anomalies that may indicate a compromise, such as manual command executions and
lateral movements associated with Kinsing attacks.

For example, here’s how Aqua detects the Kinsing attack exploiting the Openfire vulnerability:

Figure 15: Openfire vulnerability CVE-2023-32315 details in the Aqua platform


-----

g y q

Figure 16: The Kinsing attack timeline in the Aqua platform

Figure 17: Drift detection in the Aqua platform: The file kdevtmpfsi (a Monero cryptominer) is
downloaded into the container


-----

g y q

Aqua CNAPP offers comprehensive protection for cloud native workloads everywhere they run
– whether in the public cloud, on-premises, or across hybrid and multi-cloud environments. By
leveraging Aqua CNAPP, organizations can enhance their ability to detect and mitigate threats
in real time, thereby ensuring a robust security posture even against advanced and persistent
threats.


Aqua Nautilus is a security research team whose mission is to analyze the evolving cloud native threat landscape, uncovering new threats targeting
containers, Kubernetes, serverless, applications’ software supply chains and cloud infrastructure. The team aims to help Aqua customers and the
community at large protect against the unknown, zero-day and emerging threats, turning insights from real-world attacks into powerful, intelligence-driven
[protection within the Aqua Platform. For more infomation, visit https://www.aquasec.com/research/](https://www.aquasec.com/research/http://)

###### Schedule demo ›

Copyright ©2024 Aqua Security Software Ltd., All Rights Reserved
Copyright ©2024 Aqua Security Software Ltd., All Rights Reserved


-----

pp

### Appendix 1: IOCs Table

[https://github.com/nautilus-aqua/Kinsing-Indication-of-Compromise](https://github.com/nautilus-aqua/Kinsing-Indication-of-Compromise
)


-----

pp p y p

### Appendix 2: In-Depth Analysis of Scripts

##### Type I Scripts – Comprehensive Analysis

We analyzed 44 Type I scripts. They are 97% similar; the only difference is in one snippet
responsible for creating a cron job to download the script from the attacker’s C2 server. The
difference is within the name of the script, as each script calls itself. We analyzed each row in the
script based on three major concepts: contributing to the attack flow, defense evasion items, and
killing competition.

Type l scripts: scg.sh, sup.sh, wpf.sh, an.sh, cp2.sh, do.sh, ex.sh, hb.sh,
```
kn.sh, ku.sh, lf.sh, lh2.sh, lr.sh, md.sh, mo.sh, ni.sh, pa.sh, pg.sh,
ph2.sh, sa.sh, sc.sh, sp.sh, st.sh, tf.sh, tm.sh, tr.sh, vb.sh, ws.sh,
a.sh, c.sh, d.sh, f.sh, j.sh, k.sh, m.sh, n.sh, o.sh, p.sh, r.sh, s.sh,
t.sh, w.sh, spr.sh, unk.sh

###### Contributing to the attack flow

```
These snippets are designed to facilitate the attack of Kinsing:

1. Setting the kinsing file according to the server’s architecture.

Figure 18: Kinsing binaries download code


-----

pp p y p

2. Setting up a backdoor, by creating a cron job to download the shell script (the current main
payload) again. In Figure 19 below, you can see that the code is designed to look in crontab
for the IP address. If the IP isn’t found the code is designed to download the script `wpf.sh,`
into crontab.

Figure 19: setting a `cronjob`

###### Defense evasion items

These snippets are designed to evade detection of the malicious activities:

1. Stopping and deleting security tools (selinux, aegis and apparmor).

Figure 20: disabling and removing security applications


-----

pp p y p

2. In Figure 21 below, you can see two commands that significantly alter the security posture of
the victim system by removing firewall protections. The command ufw disable turns off the
UFW firewall and stops UFW from enforcing any of its configured rules. The second command
```
  iptables -F, is flushing iptables rules effectively removes all filtering and forwarding rules.

```
Figure 21: disabling firewall and flushing iptables

###### Killing competition

These snippets are designed to stop competitors’ malicious activities:

1. Stopping processes: The snippet, in Figure 22 below, targets specific processes for termination
while iterating through all entries in the /proc directory.

Figure 22: iterating over /proc directory

2. Killing processes: In Figure 23 below, there are few examples of commands aimed at detecting
specific processes or IP addresses or text in files in order to kill the relevant processes, which
are all part of competitors’ campaigns.

Figure 23: terminating competing attacks


-----

pp p y p

##### Type II Scripts – comprehensive analysis

We analyzed 27 type II scripts. Like the Type I scripts, these scripts bear 97% similarity. We
analyzed each row in the script based on 3 major concepts: contributing to the attack flow,
defense evasion items and killing competition.

Type II scripts: `lr2.sh, pg2.sh, tr2.sh, vml.sh, se.sh, ae.sh, ap.sh, bg.sh,`
```
ce.sh, cf.sh, cp.sh, ge.sh, gi.sh, gl.sh, ki.sh, lh.sh, mi.sh, mt.sh,
ph.sh, py.sh, rm.sh, sm.sh, vm.sh, xx.sh, kos.sh, tc.sh, acb.sh

```
Below we will cover only the differences from Type I scripts.

###### Contributing to the attack flow

1. Implementing a curl function in case curl, wget or other utilities aren’t installed on the
server.

Figure 24: implementing a curl application


-----

pp p y p

###### Defense evasion items

1. Deploying a rootkit to hide the malicious processes. You can read more about it in the rootkit

section in the main section of the report.

Figure 25: rootkit download and deployment code

###### Killing competition

1. Extended list of specific processes for termination while this snippet is iterating through all the
entries in the /proc directory (compared with Type I scripts).

2. The long list of process kills is now divided into functions, as can be seen in Figures 26 and 27
below:

Figure 26: cleaning cron from competing attacks Figure 27: eliminating competing attacks


-----

pp p y p

##### Auxiliary scripts analysis

These 14 scripts are often dedicated to specific applications that are dropped and executed as
part of the attack kill chain and set a specific purpose. In this section we review each of these
scripts.

Auxiliary scripts: cron.sh, al.sh, 1.ps1, ci.sh, du.sh, rv.sh, cpr.sh, cpu.sh,
```
uninstall.sh, wbw.xml, wb.xml, k.xml, kk.xml, ll.sh
cron.sh

```
This script contains 161 rows that are designed to kill the competition (see Type I or Type II scripts
above), a few lines of defense evasion, and persistence by creation of a cron job that downloads
and runs the script unk.sh, which is a Type I script, possibly standing for “unified Kinsing.”
```
al.sh

```
This script is designed to disable and remove specific security and monitoring components related
to Alibaba Cloud and Tencent Cloud services from a Linux system, as can be seen in Figure 20.


-----

pp p y p
```
The PowerShell 1.ps1

```
This PowerShell script appears to be involved in downloading, installing, and executing a
cryptominer on the host system.

The script sets up a number of variables for URLs, file sizes, and names related to a
cryptocurrency miner (xmrig.exe) and its configuration file (config.json)

The script checks if the miner executable and its configuration file exists at the specified paths. If
they do, it checks their sizes against the expected sizes and updates them if they don’t match. If
the files don’t exist, the script downloads them using the update function. Next, the PowerShell
checks if the miner process is running. If it’s not running, it starts the miner process in a hidden
window.

Figure 28: some snippets from the powershell


-----

pp p y p
```
ci.sh

```
This is actually not an auxiliary script. It’s a script that launches an attack on the Citrix NetScaler
application. As opposed to Type I and Type II scripts, there are three different cron jobs to ensure
persistence on the Citrix server.

Furthermore, in this case, Kinsing malware isn’t downloaded. This is the most distinct signature of
this threat actor yet, but in this case another binary is downloaded by the name of klli
(MD5 568f7b1d6c2239e208ba97886acc0b1e). This, however, is found on the Kinsing download
server and thus we affiliate this attack with the Kinsing campaigns.

Figure 29: From the ci.sh script
```
du.sh

```
The initial script is encoded (base64).

Figure 30: the du.sh script


-----

pp p y p

When decoded, the script seems to be designed to ensure that only one instance of a process
named kinsing that is using the file /tmp/linux.lock is running. If there are multiple such
processes, it kills all of them except the one using the file.

Figure 31: The decoded script


-----

pp p y p
```
rv.sh

```
[This is an open-source reverse shell script that can be found on GitHub - here.](https://github.com/lukechilds/reverse-shell)
As illustrated in Figure 32 below, the Kinsing threat actor modified the script to open a reverse
shell to a server under his control.

Figure 32: the rv.sh script, a reverse shell script


-----

pp p y p
```
cpr.sh

```
This script looks like it’s cleaning Kinsing from the server. Maybe it’s a revert script to clean
Kinsing from an infected system or a preparation script before cp, to prepare the server for
infection.

Figure 33: the cpr.sh script


-----

pp p y p
```
uninstall.sh

```
This script is very similar to the al.sh script which cleans the defense controls of Alibaba Cloud.

Figure 34: the uninstall script


-----

pp p y p
```
wb.xml and wbw.xml

```
These two xml files seem to have the same purpose. Both are designed to exploit the Oracle
[WebLogic Server RCE vulnerability CVE-2020-14883. On Linux servers the wb.sh shell script is](https://avd.aquasec.com/nvd/2020/cve-2020-14883/)
dropped and executed.

Figure 35: Weblogic Linux exploiting script

On Windows machines, a PowerShell (1.ps1) is dropped and executed.

Figure 36: Weblogic Windows exploiting script
```
k.xml and kk.xml

```
The purpose of these payloads is to exploit XML parsers that are vulnerable to XML external
entity attacks. If the attack is successful, the attacker can read the contents of the `/opt/`
###### zimbra/conf/localconfig.xml or ../conf/localconfig.xml file by examining the value of
the wocaq entity. This can lead to information disclosure, potentially revealing sensitive data or
configurations.

Figure 37: k.xml exploit

Figure 38: kk.xml exploit


-----

pp p y p
```
ll.sh

```
This is an extended snippet that appears both in Type I and Type II scripts. It’s a list of specific
processes for termination while this snippet is iterating through all the entries in the /proc
directory. It could be that the Kinsing threat actor often updates this snippet and thus created an
external script to support a frequent content update.

Figure 39: iterating over /proc directory


-----

pp

### Appendix 3: MITRE table with details


CVE/Misconfiguration

CVE-2021-41773

CVE-2022-24706

4.1-rce

CVE-2020-10684

CVE-2020-9480

CVE-2020-5902

CVE-2021-26084

unauthenticated

CVE-2022-26134

Unsolved

Unsolved

Misconfiguration

CVE-2019-17564

CVE-2021-41773

CVE-2020-17519

CVE-2023-35042

CVE-2021-22205

Weak password

CVE-2017-15718

CVE-2017-15718

unauthenticated

CVE-2018-1000861

CVE-2023-25194

CVE-2019-7609

CVE-2016-4326

Unsolved

Misconfiguration

CVE-2020-7961


Application

Apache

Apache CouchDB

Apereo CAS

Ansible

Apache Spark

BIG-IP TMUI

Confluence

Celery

Confluence

Unsolved

Unsolved

Docker API

Apache Dubbo

Apache HTTP

Apache Flink

GeoServer

GitLab CE

GlassFish

Hadoop Yarn

Hadoop Yarn

H2 database

Jenkins

Kafka

Kibana

Knife

Unsolved

Kubernetes

Liferay


Script

a.sh

acb.sh

ae.sh

an.sh

ap.sh

bg.sh

c.sh

ce.sh

cf.sh

cp.sh

cp2.sh

d.sh

do.sh

ex.sh

f.sh

ge.sh

gi.sh

gl.sh

h.sh

h2.sh

hb.sh

j.sh

k.sh

ki.sh

kn.sh

kos.sh

ku.sh

lf.sh


Classification

Type I

Type II

Type II

Type I

Type II

Type II

Type I

Type II

Type II

Type II

Type I

Type I

Type I

Type I

Type I

Type II

Type II

Type II

Type I

Type I

Type

Type I

Type I

Type II

Type I

Type II

Type I

Type I


-----

pp

Script Classification Application CVE/Misconfiguration


lh.sh

lh2.sh

lr.sh

lr2.sh

m.sh

md.sh

mi.sh

mo.sh

mt.sh

n.sh

ni.sh

o.sh

p.sh

pa.sh

pg.sh

pg2.sh

ph.sh

ph2.sh

py.sh

r.sh

rm.sh

s.sh

sa.sh

sc.sh

scg.sh

se.sh

sm.sh

sp.sh


Type II

Type I

Type I

Type II

Type I

Type I

Type II

Type I

Type II

Type I

Type I

Type I

Type I

Type I

Type I

Type II

Type II

Type I

Type II

Type I

Type II

Type I

Type I

Type I

Type I

Type II

Type II

Type I


log4j

log4j

Laravel Ignition

Laravel Ignition

Magento

Unsolved

Micro Focus
Operation Bridge
Manager

MobileIron Core &
Connector

Metabase

Unsolved

Apache NiFi

Unsolved

PHP-FPM

PhpMyAdmin

postgresql

postgresql

PHPUnit

PHPUnit

Python PIL/Pillow

Redis

Apache Rocketmq

Solr Dataimport

SaltStack

Scrapyd daemon

Spring Cloud Gateway

Unsolved

SambaCry

Supervisor
3.0a1 – 3.3.2 RCE


CVE-2021-44228

CVE-2021-44228

CVE-2021-3129

CVE-2021-3129

CVE-2022-24086

Unsolved

CVE-2020-11854

CVE-2020-15505

CVE 2023-38646

Unsolved

Weak password

Unsolved

CVE-2019-11043

CVE-2016-5734

unauthenticated

unauthenticated

CVE-2017-9841

CVE-2017-9841

CVE-2018-16509

unauthenticated

CVE-2023-33246

CVE-2019-0193

CVE-2020-11651

XXE

CVE-2022-22947

Unsolved

CVE-2017-7494

CVE/Misconfiguration


spr.sh Other Apache Spark CVE-2022-33891


-----

pp

Script Classification Application CVE/Misconfiguration


spri.sh

st.sh

sup.sh

t.sh

tc.sh

tf.sh

tm.sh

tr.sh

tr2.sh

unk.sh

vb.sh

vm.sh

vml.sh

vml.sh

w.sh

wb.sh

wpf.sh

ws.sh

xx.sh


Type I

Type I

Type I

Type I

Type II

Type I

Type I

Type I

Type II

Type I

Type I

Type I

Type II

Type I

Type I

Type I

Type I

Type I

Type II


Unsolved

Strapi

Supervisor11610

ThinkPHP5RCE

Apache Tomcat

ThinkCMF

TerraMaster NAS
(TNAS)

Unsolved

Unsolved

Ubuntu

Unsolved

Unsolved

Unsolved

Unsolved

Weave Scope

WebLogic server

Word press file
manager

WSO2 products

XXL-JOB RCE


Unsolved

CVE-2019-19609

CVE-2017-11610

CVE-2017-9841

Weak password

ThinkCMF X1.6.0

CVE-2022-24990

Unsolved

Unsolved

General

Unsolved

Unsolved

Unsolved

Unsolved

Unauthenticated

CVE-2020-14883 /
CVE-2020-14882 /
CVE-2020-14750

CVE-2020-25213

CVE-2022-29464

CVE-2020-23814


-----

pp

### Appendix 3: MITRE table with details


Tactic Technique MITRE ID


Kinsing’s Operation


Reconnaissance Active Scanning: T1595.002 Kinsing’s scanning
Vulnerability Scanning infrastructure is
looking for vulnerabilities
and misconfigurations.


Defense Impair Defenses:
Evasion Disable or Modify
System Firewall

Defense Impair Defenses:
Evasion Disable or Modify
Tools

Defense Indicator
Evasion Removal on Host:
File Deletion

Defense File and Directory
Evasion Permissions
Modification: Linux and
Mac File and Directory
Permissions
Modification

Persistence Event Triggered
Execution: Unix Shell
Configuration
Modification

Execution Command and
Scripting Interpreter:
Unix Shell


T1546.004 In the main payload
kinsing is modifying
```
         .ssh/authorized_keys

```
to maintain access.

T1059.004 Kinsing is execution of
shell commands and
scripts.


T1562.004 In the main payload
kinsing is disabling the
ufw firewall and flushing
```
         iptables.

```
T1562.001 In the main payload
kinsing is disabling
security tools and
services like apparmor
and selinux.

T1070.004 In the main payload
kinsing is deleting logs
(/var/log/syslog)
and other files to cover
tracks.


T1222.001


In the main payload
kinsing is changing
attributes of various
directories
(chattr commands) to
prevent detection.


-----

pp

Tactic Technique MITRE ID Kinsing’s Operation


Credential Account
Access Discovery: Local
Account


T1087.001 In the main payload
kinsing is deleting users
(userdel) to hinder
account discovery.


Impact Data Destruction T1485 In the main payload
kinsing is deleting files to
impair functionality and
cover tracks.

Impact Inhibit System T1490 In the main payload
Recovery kinsing is deleting logs
(/var/log/syslog)
and other files to cover
tracks.

Execution Native API T1106 In the main payload
kinsing is killing
processes through native
APIs.n.

Discovery Network Service T1046 In the main payload
Scanning kinsing is using netstat
to discover network
services and potentially
identify targets for
further actions.


Persistence Create or Modify System
Process: Systemd
Service


T1543.003 In the main payload
kinsing is installing a
systemd service for
persistence.


Persistence Scheduled Task/Job: T1053.005 In the main payload
Scheduled Task kinsing is installing a
systemd service for
persistence.

Execution User Execution: T1204.002 In the main payload
Malicious File kinsing is executing
a malicious binary to
maintain persistence
or perform malicious
actions.


-----

pp

Tactic Technique MITRE ID Kinsing’s Operation


Command and Application Layer
Control Protocol: Web
Protocols


T1071.001 In the main payload
kinsing is using curl or
```
         wget to communicate

```
with command and
control (C2) servers.


Resource Acquire Infrastructure: T1583.001 Kinsing is using
Development Domain vocaltube.ru as a
domain. Not sure he
owns it.


Initial Access Exploit
Public-Facing
Application


T1190 In many cases this
is the initial access
vector kinsing is using,
for instance Openfire,
Wordpress etc.


Credential Brute Force T1110.001 Kinsing is trying to
Access exploit applications and
services such as SSH,
Tomcat admin and others

Persistence Create or Modify T1543.004 Kinsing is creating a
System Process systemd service named
“Bot” in the Type II
scripts

Defense Obfuscated Files or T1027.002 Kinsing’s malware and
Evasion Information rootkit are often packed
often by UPX

Discovery File and Directory T1083 In the main payload
Discovery kinsing is running on
the /proc and other
filesystems to detect
processes

Command and Application Layer T1071.004 Kinsing is using
Control Protocol: DNS vocaltube.ru to retrieve
the C2 server IP address.

Command and Application Layer T1090.002 Kinsing is using proxies
Control Protocol: Proxy for the mining operation.


-----

pp

Tactic Technique MITRE ID Kinsing’s Operation

Exfiltration Exfiltration Over C2 T1041 The kinsing malware can
Channel exfiltrate data over the
C2 server.

Execution System Services: T1569.002 In the main payload
Service Stop kinsing is issuing
commands to stop
various services, a
technique that could be
used to hinder security
services or other critical
functionalities on the
system.


Execution Command and
Scripting Interpreter:
PowerShell


T1059.001 The script is written in
PowerShell, a powerful
scripting language used
for automating tasks on
Windows systems, which
can be used for malicious
purposes in this context.


Command and Ingress Tool Transfer T1105 The script downloads
Control external files (miner
and config), which
is indicative of
transferring tools or
files into a compromised
environment.

Defense Impair Defenses: T1629.003 Stopping processes
Evasion Disable or Modify Tools might also be used to
disable security tools
that are running on the
system.

Defense Modify Registry T1112 The script uses
Evasion `SchTasks.exe to`
create a scheduled task
for persistence, which
involves modifying the
Windows registry.


-----

pp

Tactic Technique MITRE ID Kinsing’s Operation

Defense Obfuscate/Encrypt Files T1140 The script du.sh is
Evasion encoded in base64,
there are further
examples to kinsing
encoding (base64)
snippets


Defense Masquerading: Match
Evasion Legitimate Name or
Location


T1036.005 In Linux the miner is
called `kdevtmpfsi,`
in Windows the miner
is named “sysupdate.
exe”, which could be an
attempt to masquerade
as a legitimate system
update process.


Execution Container Administration T1609 Kinsing is running
Command `Ubuntu:latest on`
misconfigured docker
API with a malicious
cmd that downloads
and executes the main
payload d.sh

Execution Deploy Container T1609 Kinsing is running
```
                                 Ubuntu:latest on

```
misconfigured docker
API with a malicious
cmd that downloads
and executes the main
payload d.sh

Initial Access External Remote T1133 Kinsing was executed
Services in an Ubuntu container
deployed via an open
Docker daemon API.


Defense File and Directory
Evasion Permissions Modification:
Linux and Mac File and
Directory Permissions
Modification


T1222.002 Kinsing has used chmod
to modify permissions on
key files for use.


Discovery Process Discovery T1057 Kinsing has used ps to
list processes.


-----

pp

Tactic Technique MITRE ID Kinsing’s Operation

Lateral Remote Services: SSH T1021.004 Kinsing has used SSH for
Movement lateral movement.

Discovery Remote System T1018 Kinsing has used a script
Discovery to parse files like `/etc/`
```
                                 hosts and SSH known_

###### hosts to discover
```
remote systems.

Impact Resource Hijacking T1496 Kinsing has created
and run a Bitcoin
cryptocurrency miner.

Persistence Scheduled Task/Job: T1053.003 Kinsing has used crontab
Cron to download and run
shell scripts every minute
to ensure persistence.

Credential Unsecured Credentials: Kinsing has searched
Access Bash History `bash_history for`

T1552.003

credentials.

Credential Unsecured Credentials: T1552.004 Kinsing has searched for
Access Private Keys private keys.

Initial Access Valid Accounts T1078 Kinsing has used valid
SSH credentials to
access remote hosts.

Defense Rootkit T1014 Kinsing is using a rootkit
Evasion to hide the cryptomining
operation.

Execution Command and Scripting T1059.006 Kinsing is execution
Interpreter: Python python commands for
instance in the rv.sh
script


-----