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

2Executive summary

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 theKinsing 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 theKinsing malware. However, it raises the question: What precisely is Kinsing? Is it the name of themalware, 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 landscapeare 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.

3

Introduction

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, withthe 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 thebody 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 thecybersecurity community. We carefully analyzed select publications from our colleagues in theindustry. Some of these works are exceptional pieces of research that illuminate various facets ofKinsing’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 thethreat 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
— 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 andKinsing malware, highlighting significant similarities in code structure, RC4 encryption keys, andfunction names, while also noting some differences. Their conclusion was that despite thesedifferences, 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.

4Introduction

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)
Unauthenticated Redis servers (TrendMicro)
Oracle WebLogic CVE-2020-14883 (Akamai)
Log4Shell CVE-2021-44228 (Zscaler)
Confluence - CVE-2022-26134 (Lacework)
Citrix ADC - CVE-2019-19781 and SaltStack - CVE-2020-11651/2 (Red Canary)
Kubernetes (Microsoft)
Apache Nifi (Sans), and many others.

In addition, comprehensive reports like the one from Cysiv have linked several vulnerabilities,
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 abotnet (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 aconnection to Russian-speaking countries, which could imply Russian origins for the threat actor,
while the frequent targeting of Chinese servers could suggest Chinese origins.

5Uncovering Kinsing’s Techniques, Tactics and, Procedures

FUN FACTIn the Russian language, “Kinsing” doesn’t translate directly to anything meaningful. The nameseems 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 nostandalone meaning, but phonetically it could relate to “кин,” a root for Russian verbs associatedwith throwing or motion, such as “кинуть” (to throw). “Sing” phonetically resembles “синг,” whichis meaningless in Russian. However, “синий” translates to “blue.” Thus, “kinsing” could whimsicallytranslate 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 withMandarin, but a similar sound, “星” (xīng), means “star.” Hence, “Kinsing” might whimsically beinterpreted as “golden star,” an interpretation we find more appealing. That said, if you know of abetter 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.

6Uncovering Kinsing’s Techniques, Tactics and, Procedures

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, otherpublications, 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 absenceof 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 theattack 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
resident malware

Kinsing’s scanserverVulnerable
Openfire

4. Encrypted
communication

Kinsing’s C2serverKinsing’s
Download server

7Uncovering Kinsing’s Techniques, Tactics and, Procedures

We have identified three primary components in the Kinsing campaigns:

1
2
3

Scan and exploit servers: The initial server is responsible for scanning vulnerabilities andexploiting them. It boasts advanced scanning capabilities, likely employing tools suchas 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 thatthe threat actor actively uses this tool.
Download servers: These servers act as an intermediary for downloading binaries andscripts. For instance, the threat actor uses one IP address to download the main payload,a script that then fetches the Kinsing malware and, occasionally, a rootkit. From anotherserver, 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
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 thatthe 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 theC2 server and the victim’s machine.

8Uncovering Kinsing’s Techniques, Tactics and, Procedures

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 AddressCountry

ISP

Usage in the attacks

1

185.154.53.140

RussiaEuroByte LLC

39.4%

2

212.22.77.79

RussiaCloud Solutions LLC

38.2%

3

185.221.154.208

RussiaEuroByte LLC

22.3%

4 93.189.46.81

RussiaLimited Liability Company NTCOM

0.031%

5

109.248.59.253

RussiaRussia High Speed Online LLC

0.010%

6

194.169.160.157

RussiaZtv Corp LLC

0.010%

7

185.224.212.104

Russia2Day Telecom LLP

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

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

Netherlands

10%

UkraineLuxembourg

20%

2%

Russia68%

9

Uncovering Kinsing’s Techniques, Tactics and, Procedures

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 gaina deeper understanding of the threat actor’s intentions and what they aimed to expose on theinternet as part of their campaign, we executed several queries.
The following are some key stats and insights we gathered during this period:

1

The campaign has been active since 2019 andcontinues to operate.

2

The core components of the attack include the Kinsing malware anda cryptocurrency miner.

3

Three distinct groups of artifacts
are identified.

4

The campaign targets
75 different applications.

5

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

6

Kinsing targets applications and infrastructure across the entire cloud softwaredevelopment life cycle (SDLC).

7
8
9

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 istargeting 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.
While Kinsing mainly targets runtime applications (67%) it also targets various otherareas in cloud native environments, such as CI/CD (Jenkins), APIs (Kubernetes, Docker
daemon), and code.

10Uncovering Kinsing’s Techniques, Tactics and, Procedures

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: 6Open-Sourceor Not
Runtime: 42

2020: 19

Open-source: 71
Database: 92021: 34

Cloud Infrastructure: 82022: 92023: 10

Proprietary Software: 7

Code: 1

CI/CD: 1

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

11Uncovering Kinsing’s Techniques, Tactics and, Procedures

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, acryptominer 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 avulnerability, 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 Graph2, 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 thepercentage of the script dedicated to this and the actual number of code lines, primarily throughdeploying 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 mostof 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 thesame 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 thesemight 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, andprivileges. Bash is an enhanced and extended version of 55 T sh, so it includes all the featuresof 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).

12

Uncovering Kinsing’s Techniques, Tactics and, Procedures

Another point of interest is the 75% decrease in the volume of snippets aimed at eliminatingcompetition between Type I and Type II scripts. This raises several questions: Is there lesscompetition 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 thethreat actor initially included an abundance of snippets to eliminate any competition, but overtime, 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%
19.4%

Kill Competition
Support Attack
Defense Evasion

76.4%

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

53.3%

Kill Competition
Support Attack
Defense Evasion

11%

35.7%
13

Uncovering Kinsing’s Techniques, Tactics and, Procedures

Binaries
These 12 binaries are dropped during different stages and types of attacks. Some (kinsing andkdevtmpfsi) appear in almost all of the attacks, while others support specific needs in specificservers.
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 thekinsing 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

14

Uncovering Kinsing’s Techniques, Tactics and, Procedures

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 thenumber 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 wasconsistent 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 newvulnerabilities 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, indicatingthat Kinsing’s scanning operation is probing millions of instances.
Our research indicates that the Kinsing threat actor incorporates new vulnerabilities upon theirrelease. 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 blogthat 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 ofthe 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 arandom digit or letter).

15

Uncovering Kinsing’s Techniques, Tactics and, Procedures

62.70%of the attacks
SHA2565d2530b809fd069f97b30a5938d471dd2145341b5793a70656aad6045445cf6d

27.98%of the attacks

SHA256787e2c94e6d9ce5ec01f5cbe9ee2518431eca8523155526d6dc85934c9c5787c

0.23%

of the attacks
SHA256564739ea8fa5926d4fa5c9734fed462061960a22e6b8d5c06e94969d97891bf2

0.09%

of the attacks
SHA256631d0eac8278f4c8090dcc89c905eebdac5ad03db6cf33be1f0a5a39ce6fff1a

0.09%

of the attacks
SHA256d14b31a0e14615badab1ffcd6086c36f32c21a0cd40df93843efd42295e451bd

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. Oneof 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.
16Uncovering Kinsing’s Techniques, Tactics and, Procedures

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 cryptominerthat 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 thecryptominer embedded inside. It looks like it did catch – probably not then (because we know thatkinsing 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.

17

Uncovering Kinsing’s Techniques, Tactics and, Procedures

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 tablebelow, these are the C2 communication recorded:#

URL

Request
Type

1

/i

GET

2

/l

POST

3

/r

POST

4

/o

POST

5

/s

6

Additional
Input

Goal

Response

Set logOK

Sends log data to C2serverOK

Sends results

OK“{“Id”:802,
Data”:””}”

Send Exec output
to C2 server

OK

POST

“{ “User”:”jFcypPQo”,“Pass”:”AcFAYwAE”,“Port”:31119 }”Send new SOCKS5
server’s user/pass/TCP
port to C2 server

OK

/ms

POST

“{“Pid”:0}”Send miner’s process
ID

OK

7

/mg

GET

Checks if the cryptominer
is running and provides
the PID of the miner

301 or
The PID number example:“{“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
check

OK

10 /getGET

Fetch the next “task”
from C2 server

Example:{“Id”:802,“Type”:”download_and_exec”,“Progress”:227960,“Total”:1254856, “Thread”:1,“Port”:1, “Timeout”:1,“Data”:
http[:]//194[.]38.22.53/spre.
sh
}

Data

18

Uncovering Kinsing’s Techniques, Tactics and, Procedures

Kinsing’s Mining Campaigns
The main goal of Kinsing is to mine Monero. It does this by running a version of XMRIG. Over theyears, 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

19

Uncovering Kinsing’s Techniques, Tactics and, Procedures

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 theprocess startup sequence, even before standard libraries like libc.so. This technique ensures thatthe 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 andwhat isn’t. For example, it can hide its own process files and network connections from systemmonitoring 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 mightmanipulate them:1

access: Checks user’s permissions for a file. Kinsing’s rootkit hooks various files toreturn that these files (kinsing, kdevtmpfsi, etca) don’t exist.

2

rmdir: Removes a directory. Kinsing’s rootkit could intercept commands aimed atdeleting certain directories like those containing malware components.

3

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.

4

readdir / readdir64: Reads directory entries. Kinsing’s rootkit can manipulatethese functions to hide specific directories or files from directory listings.
20

Uncovering Kinsing’s Techniques, Tactics and, Procedures

5stat / stat64 and __xstat / __xstat64: Retrieves information about a file.
Kinsing’s rootkit might alter the results to hide file modifications or the existence of
certain files.

6

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,
especially those pointing to malicious files.

7

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

8

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

9

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

10

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.

By hooking these functions, the kinsing rootkit can effectively control how the operating systeminteracts 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 theinfected 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 samehash value:(SHA256=C38C21120D8C17688F9AEB2AF5BDAFB6B75E1D2673B025B720E50232F888808A)
we can conclude that the Kinsing threat actor is satisfied with this tool and thus invested noattention to improve the rootkit over these past three years.

21

Kinsing’s Targets

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 andMisconfigurations)Over the past five years, we’ve identified at least 75 software applications that have beentargeted by Kinsing. Our observations indicate that Kinsing exploits both vulnerabilities andmisconfigurations. For example, there are instances of misconfigured Docker APIs withoutauthentication, allowing anyone to deploy a container. In such cases, an Alpine container isdeployed 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 wereunable to complete the list of targets, as some remain unclassified. We encourage you to shareyour 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

22

Kinsing’s Targets

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 ofKinsing’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 isinserted.

Figure 12: decoded postgress payload

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

23

Kinsing’s Targets

Another example taken from the Laravel forum on Reddit, as the programmer is providing someevidence of infection and how this can be detected and fixed.
These examples illustrate the justified and understandable security knowledge and experiencegaps that programmers, data engineers and other practitioners display when facing thesetroubling indications. The abundance of such indications also illustrates Kinsing’s scope and theextent of its attacks.

Figure 13: A forum post about Kinsing

24Mapping Kinsing's Campaigns to the MITRE ATT&CK Framework

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):

ReconnaissanceResource
Development

Initial Access

Execution

Persistance

Defense evasion

Credential
AccessDiscovery

Command andControl

Exfiltration

ImpactActiveScanning:
Vulnerability
Scanning(T1595.002)

AcquireInfrastructure:
Server(T1583.004)

ExploitPublic-Facing
Application(T1190)Commandand ScriptingInterpreter:
Unix Shell(T1059.004)

Create orModifySystemProcess: Unix
Shell
Configuration
Modification(T1543.004)

ImpairDefenses:
Disable or
ModifySystemFirewall(T1562.004)

Account
Discovery:
Local Account(T1087.001)

Network
Service
Scanning(T1046)Lateral Tool
Transfer(T1570)Application
Layer
Protocol: Web
Protocols(T1071.001)

Exfiltration
Over C2Channel(T1041)

Data
Destruction(T1485)AcquireInfrastructure:
Domains(T1583.001)

Valid
Accounts(T1078)Native API(T1106)Create orModifySystemProcess:
Systemd
Service(T1543.003)

ImpairDefenses:
Disable or
Modify Tools(T1562.001)

Brute Force:
Passwordguessing(T1110.001)

File and
Directory
Discovery(T1083)

RemoteServices: SSH(T1021.004)

Proxy:
External
Proxy(T1090.002)

Inhibit System
Recovery(T1490)User
Execution:
Malicious File
(T1204.002)

Scheduled
Task:
Scheduled
Task(T1053.005)

Indicator
Removal on
Host: File
Deletion(T1070.004)

UnsecuredCredentials:
Bash History(T1552.003)

Process
Discovery(T1057)

RemoteSystemDiscovery(T1018)Ingress Tool
Transfer(T1105)

Resource
Hijacking(T1496)

Commandand ScriptingInterpreter:
PowerShell(T1059.001)

File and
Directory
Permissions
Modification:
Linux File andDirectory
Permissions
Modification(T1546.004)

File and
Directory
Permissions
Modification:
Linux File andDirectory
Permissions
Modification(T1222.001)

UnsecuredCredentials:
Private Keys
(T1552.004)

SystemServices:
Service
Execution(T1569.002)

Obfuscated
Scheduled
Task/Job: Cron Files orInformation:(T1053.003)
SoftwarePacking(T1027.002)

Container
Administration Command(T1609)Disabling
Security Tools(T1485)

Application
Layer
Protocol: DNS(T1090.004)

DeployContainer(T1610)External
RemoteServices(T1133)

Masquerading: MatchLegitimate
Name or
Location(T1036.005)

Scheduled
Task/Job: Cron
(T1053.003)

File and
Directory
Permissions
Modification:
Linux File andDirectory
Permissions
Modification(T1222.002)

Commandand ScriptingInterpreter:
Python(T1059.006)

25

Detection and mitigation

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

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 toknown mining pools.
• Network connections: Look for connections to suspicious IP addresses and ports typicallyused 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.

26

Enchancing Cloud Security with Aqua CNAPP

Enhancing Cloud Security with
Aqua CNAPPIn today’s landscape of escalating cyber threats, organizations need to establish acomprehensive 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 andfortifying 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 suchas active exploitation in the wild and the availability of PoC (proof-of-concept) exploits. Thissignificantly 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 detected27

Enchancing Cloud Security with Aqua CNAPP

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. Driftprevention seamlessly enforces the container immutability to identify and block unauthorizedprocesses 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 tobehavioral anomalies that may indicate a compromise, such as manual command executions andlateral 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

28

Enchancing Cloud Security with Aqua CNAPP

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

29

Enchancing Cloud Security with Aqua CNAPP

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. Byleveraging 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 thecommunity 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/

Schedule demo ›Copyright ©2024 Aqua Security Software Ltd., All Rights Reserved
Copyright ©2024 Aqua Security Software Ltd., All Rights Reserved30Appendix 1: IOCs Table

Appendix 1: IOCs Table
https://github.com/nautilus-aqua/Kinsing-Indication-of-Compromise31Appendix 2: In-Depth Analysis of Scripts

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 thescript based on three major concepts: contributing to the attack flow, defense evasion items, andkilling 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 code32Appendix 2: In-Depth Analysis of Scripts

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

33

Appendix 2: In-Depth Analysis of Scripts

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

34

Appendix 2: In-Depth Analysis of Scripts

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

Figure 24: implementing a curl application

35

Appendix 2: In-Depth Analysis of Scripts

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

36

Appendix 2: In-Depth Analysis of Scripts

Auxiliary scripts analysis
These 14 scripts are often dedicated to specific applications that are dropped and executed aspart of the attack kill chain and set a specific purpose. In this section we review each of thesescripts.
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.shcron.shThis 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.shThis 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.

37

Appendix 2: In-Depth Analysis of Scripts

The PowerShell 1.ps1
This PowerShell script appears to be involved in downloading, installing, and executing acryptominer on the host system.
The script sets up a number of variables for URLs, file sizes, and names related to acryptocurrency 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. Ifthey 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 PowerShellchecks 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 powershell38

Appendix 2: In-Depth Analysis of Scripts

ci.shThis 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 ofthis 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

39

Appendix 2: In-Depth Analysis of Scripts

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 suchprocesses, it kills all of them except the one using the file.

Figure 31: The decoded script40

Appendix 2: In-Depth Analysis of Scripts

rv.shThis is an open-source reverse shell script that can be found on GitHub - here.
As illustrated in Figure 32 below, the Kinsing threat actor modified the script to open a reverseshell to a server under his control.
Figure 32: the rv.sh script, a reverse shell script

41

Appendix 2: In-Depth Analysis of Scripts

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

42

Appendix 2: In-Depth Analysis of Scripts

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

Figure 34: the uninstall script

43

Appendix 2: In-Depth Analysis of Scripts

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
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 ofthe wocaq entity. This can lead to information disclosure, potentially revealing sensitive data or
configurations.
Figure 37: k.xml exploit

Figure 38: kk.xml exploit

44

Appendix 2: In-Depth Analysis of Scripts

ll.shThis is an extended snippet that appears both in Type I and Type II scripts. It’s a list of specificprocesses 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 directory45

Appendix 3: MITRE table with details

Appendix 3: MITRE table with details
ScriptClassification

Application

CVE/Misconfiguration

a.shType I

ApacheCVE-2021-41773

acb.shType II

Apache CouchDB

CVE-2022-24706

ae.sh

Type II

Apereo CAS

4.1-rcean.shType I

AnsibleCVE-2020-10684

ap.sh

Type II

Apache SparkCVE-2020-9480

bg.shType IIBIG-IP TMUI

CVE-2020-5902

c.sh

Type I

ConfluenceCVE-2021-26084

ce.sh

Type II

Celeryunauthenticatedcf.shType II

ConfluenceCVE-2022-26134

cp.sh

Type II

Unsolved

Unsolved

cp2.shType I

Unsolved

Unsolvedd.shType I

Docker API

Misconfiguration

do.shType I

Apache Dubbo

CVE-2019-17564

ex.shType I

Apache HTTP

CVE-2021-41773

f.sh

Type I

Apache Flink

CVE-2020-17519

ge.shType II

GeoServer

CVE-2023-35042

gi.sh

Type II

GitLab CE

CVE-2021-22205

gl.shType II

GlassFish

Weak password

h.shType I

Hadoop Yarn

CVE-2017-15718

h2.sh

Type I

Hadoop Yarn

CVE-2017-15718

hb.sh

Type

H2 database

unauthenticatedj.shType I

Jenkins

CVE-2018-1000861

k.shType I

Kafka

CVE-2023-25194

ki.sh

Type II

KibanaCVE-2019-7609

kn.sh

Type I

Knife

CVE-2016-4326

kos.shType II

Unsolved

Unsolvedku.shType I

Kubernetes

Misconfiguration

lf.shType I

Liferay

CVE-2020-7961

46Appendix 3: MITRE table with details

ScriptClassification

Application

CVE/Misconfiguration

lh.shType II

log4j

CVE-2021-44228

lh2.shType I

log4j

CVE-2021-44228

lr.sh

Type I

Laravel Ignition

CVE-2021-3129

lr2.shType II

Laravel Ignition

CVE-2021-3129

m.shType I

MagentoCVE-2022-24086

md.shType I

Unsolved

Unsolvedmi.shType II

Micro Focus
Operation Bridge
Manager

CVE-2020-11854

mo.shType I

MobileIron Core &Connector

CVE-2020-15505

mt.sh

Type II

Metabase

CVE 2023-38646

n.shType I

Unsolved

Unsolvedni.shType I

Apache NiFi

Weak passwordo.shType I

Unsolved

Unsolvedp.shType I

PHP-FPM

CVE-2019-11043

pa.sh

Type I

PhpMyAdmin

CVE-2016-5734

pg.sh

Type I

postgresql

unauthenticatedpg2.shType II

postgresql

unauthenticatedph.shType II

PHPUnitCVE-2017-9841

ph2.shType IPHPUnitCVE-2017-9841

py.sh

Type II

Python PIL/Pillow

CVE-2018-16509

r.shType I

Redis

unauthenticatedrm.shType II

Apache Rocketmq

CVE-2023-33246

s.shType I

Solr Dataimport

CVE-2019-0193

sa.sh

Type I

SaltStackCVE-2020-11651

sc.sh

Type I

Scrapyd daemon

XXE

scg.shType I

Spring Cloud Gateway

CVE-2022-22947

se.shType II

Unsolved

Unsolvedsm.shType II

SambaCry

CVE-2017-7494

sp.sh

Type I

Supervisor
3.0a1 – 3.3.2 RCE

CVE/Misconfiguration

spr.shOther

Apache SparkCVE-2022-33891
47

Appendix 3: MITRE table with details

ScriptClassification

Application

CVE/Misconfiguration

spri.shType I

Unsolved

Unsolvedst.shType I

Strapi

CVE-2019-19609

sup.shType I

Supervisor11610

CVE-2017-11610

t.sh

Type I

ThinkPHP5RCE

CVE-2017-9841

tc.sh

Type II

Apache Tomcat

Weak password

tf.shType I

ThinkCMF

ThinkCMF X1.6.0

tm.sh

Type I

TerraMaster NAS(TNAS)

CVE-2022-24990

tr.shType I

Unsolved

Unsolved

tr2.shType II

Unsolved

Unsolved

unk.shType I

UbuntuGeneralvb.shType I

Unsolved

Unsolved

vm.shType I

Unsolved

Unsolved

vml.shType II

Unsolved

Unsolved

vml.shType I

Unsolved

Unsolvedw.shType I

Weave Scope

Unauthenticatedwb.shType I

WebLogic server

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

wpf.shType I

Word press file
manager

CVE-2020-25213

ws.sh

Type I

WSO2 products

CVE-2022-29464

xx.shType IIXXL-JOB RCE

CVE-2020-23814

48

Appendix 3: MITRE table with details

Appendix 3: MITRE table with details
TacticTechnique

MITRE ID

Kinsing’s Operation

Reconnaissance

Active Scanning:
Vulnerability Scanning

T1595.002

Kinsing’s scanninginfrastructure islooking for vulnerabilities
and misconfigurations.

DefenseEvasionImpair Defenses:
Disable or Modify
System Firewall

T1562.004

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

DefenseEvasionImpair Defenses:
Disable or Modify
Tools

T1562.001

In the main payload
kinsing is disabling
security tools andservices like apparmorand selinux.

DefenseEvasionIndicator
Removal on Host:
File Deletion

T1070.004

In the main payload
kinsing is deleting logs(/var/log/syslog)
and other files to covertracks.

DefenseEvasionFile and Directory
Permissions
Modification: Linux and
Mac File and Directory
Permissions
Modification

T1222.001

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

Persistence

Event Triggered
Execution: Unix Shell
Configuration
Modification

T1546.004

In the main payload
kinsing is modifying.ssh/authorized_keys
to maintain access.

Execution

Command andScripting Interpreter:
Unix Shell

T1059.004

Kinsing is execution ofshell commands andscripts.

49

Appendix 3: MITRE table with details

TacticTechnique

MITRE ID

Kinsing’s Operation

Credential
Access

Account
Discovery: Local
Account

T1087.001

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

ImpactData Destruction

T1485

In the main payload
kinsing is deleting files to
impair functionality andcover tracks.

ImpactInhibit System
Recovery

T1490

In the main payload
kinsing is deleting logs(/var/log/syslog)
and other files to covertracks.

Execution

Native API

T1106

In the main payload
kinsing is killing
processes through native
APIs.n.

Discovery

Network Service
Scanning

T1046

In the main payload
kinsing is using netstat
to discover network
services and potentially
identify targets forfurther actions.

Persistence

Create or Modify System
Process: Systemd
Service

T1543.003

In the main payload
kinsing is installing asystemd service for
persistence.

Persistence

Scheduled Task/Job:
Scheduled Task

T1053.005

In the main payload
kinsing is installing asystemd service for
persistence.

Execution

User Execution:
Malicious File

T1204.002

In the main payload
kinsing is executing
a malicious binary tomaintain persistenceor perform malicious
actions.
50

Appendix 3: MITRE table with details

TacticTechnique

MITRE ID

Kinsing’s Operation

Command andControl

Application Layer
Protocol: Web
Protocols

T1071.001

In the main payload
kinsing is using curl or
wget to communicate
with command andcontrol (C2) servers.

Resource
Development

Acquire Infrastructure:
DomainT1583.001

Kinsing is using
vocaltube.ru as adomain. Not sure heowns it.

Initial Access

ExploitPublic-Facing
Application

T1190

In many cases thisis the initial accessvector kinsing is using,for instance Openfire,
Wordpress etc.

Credential
Access

Brute Force

T1110.001

Kinsing is trying to
exploit applications andservices such as SSH,
Tomcat admin and others

Persistence

Create or Modify
System Process

T1543.004

Kinsing is creating asystemd service named“Bot” in the Type II
scripts

DefenseEvasionObfuscated Files orInformation

T1027.002

Kinsing’s malware androotkit are often packed
often by UPX

Discovery

File and Directory
Discovery

T1083

In the main payload
kinsing is running on
the /proc and otherfilesystems to detect
processes

Command andControl

Application Layer
Protocol: DNS

T1071.004

Kinsing is using
vocaltube.ru to retrieve
the C2 server IP address.

Command andControl

Application Layer
Protocol: Proxy

T1090.002

Kinsing is using proxies
for the mining operation.
51

Appendix 3: MITRE table with details

TacticTechnique

MITRE ID

Kinsing’s Operation

Exfiltration

Exfiltration Over C2
ChannelT1041

The kinsing malware can
exfiltrate data over the
C2 server.

Execution

System Services:
Service Stop

T1569.002

In the main payload
kinsing is issuingcommands to stop
various services, atechnique that could be
used to hinder security
services or other critical
functionalities on thesystem.

Execution

Command andScripting Interpreter:
PowerShell

T1059.001

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

Command andControl

Ingress Tool Transfer

T1105

The script downloads
external files (minerand config), whichis indicative oftransferring tools or
files into a compromised
environment.

DefenseEvasionImpair Defenses:
Disable or Modify Tools

T1629.003

Stopping processes
might also be used todisable security toolsthat are running on thesystem.

DefenseEvasion

Modify RegistryT1112

The script uses
SchTasks.exe tocreate a scheduled task
for persistence, which
involves modifying theWindows registry.

52

Appendix 3: MITRE table with details

TacticTechnique

MITRE ID

Kinsing’s Operation

DefenseEvasionObfuscate/Encrypt Files

T1140

The script du.sh is
encoded in base64,
there are further
examples to kinsing
encoding (base64)
snippets

DefenseEvasionMasquerading: Match
Legitimate Name or
Location

T1036.005

In Linux the miner iscalled 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
Command

T1609

Kinsing is running
Ubuntu:latest on
misconfigured docker
API with a malicious
cmd that downloads
and executes the main
payload d.shExecution

Deploy Container

T1609

Kinsing is running
Ubuntu:latest on
misconfigured docker
API with a malicious
cmd that downloads
and executes the main
payload d.shInitial Access

External Remote
Services

T1133

Kinsing was executedin an Ubuntu container
deployed via an open
Docker daemon API.

DefenseEvasionFile and Directory
Permissions Modification:
Linux and Mac File andDirectory Permissions
Modification

T1222.002

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

Discovery

Process Discovery

T1057

Kinsing has used ps tolist processes.
53

Appendix 3: MITRE table with details

TacticTechnique

MITRE ID

Kinsing’s Operation

LateralMovement

Remote Services: SSH

T1021.004

Kinsing has used SSH for
lateral movement.

Discovery

Remote System
Discovery

T1018

Kinsing has used a script
to parse files like /etc/
hosts and SSH known_
hosts to discover
remote systems.

ImpactResource Hijacking

T1496

Kinsing has created
and run a Bitcoin
cryptocurrency miner.

Persistence

Scheduled Task/Job:
Cron

T1053.003

Kinsing has used crontab
to download and run
shell scripts every minuteto ensure persistence.

Credential
AccessUnsecured Credentials:
Bash History

Credential
AccessUnsecured Credentials:
Private Keys

T1552.004

Kinsing has searched for
private keys.

Initial Access

Valid Accounts

T1078

Kinsing has used valid
SSH credentials toaccess remote hosts.

DefenseEvasionRootkit

T1014

Kinsing is using a rootkit
to hide the cryptomining
operation.

Execution

Command and ScriptingInterpreter: Python

T1059.006

Kinsing is execution
python commands for
instance in the rv.shscript

T1552.003

Kinsing has searchedbash_history for
credentials.

54