Introduction

Crypto mining has become owing to its advanced foundations. Particularly environments like Kubernetes are a simple target as you do not know where the container image is built, and what it is doing with proactive observing.

One of such malware which used the exposed Docker API port to infect and then attempted to spread to other containers on the host is Kinsing Malware! This malware runs a crypto-miner program inside the container and kills any other miners (if running) and deletes the trace by making use of the cron service.

We’ll be talking about the working of the malware in brief and how we can effectively protect our containers from Kinsing using
KubeArmor, an opensource Runtime protection tool for Kubernetes & other cloud Workloads from AccuKnox

Learn the Attack Pattern

The Kinsing malware does multiple things from inside the container, which can be explained as:

1. Update the contents of the container using the package manager
2. Install dependency software with the package manager
3. Initiate a cron service
4. Download and execute a shell script
5. Tail the /dev/null to keep the container running indefinitely

Kinsing Malware Workflow

Initiating the Attack

We will be using a Kinsing binary hosted on GitHub along with the shell script needed to initiate the attack. Kinsing serves as a convoy to a crypto-miner Kdevtmpfsi, which will be created and run by Kinsing in the /tmp directory.
Let us take a close look at the action.

Run the following command from an exploited ubuntu container to initiate the attack

Once the container is updated and the binary wget is installed the executable shell script is downloaded and executed which lead s to the installation of Kinsing and the miner Kdevtmpfsi

Let us take a look at the resource usage before and after the execution of the above commands.

The resource consumption increased by almost 19 times the initial values. Upon close inspection, we were able to see that the Kinsing malware was successfully downloaded and started the miner agent Kdevtmpfsi

Defending against the Attack

With some research, we were able to identify some common patterns the malware exhibited over the attack cycle.

1. Launches the package manager to meet dependencies
2. The malware kills all crypto mining processes and their cronjobs
3. Removes files related to crypto-mining
4. The malware is downloaded from the internet and stored in the /var/tmp directory
5. Executing the kinsing binary spawns a new process Kdevtmpfsi under /tmp directory

Although we can’t rely on a single individual suspicious event to unveil the Kinsing attack completely, some of the patterns above are significant enough to draw the SOC team’s attention. So let’s talk about how KubeArmor can help defend against such an attack.

KubeArmor

KubeArmor, a cloud-native runtime security enforcement system that restricts the behaviour (such as process execution, file access, and networking operation) of containers and nodes at the system level.

Armed with the knowledge from 4rd and 5th points mentioned above, we were able to patch up the issue by enforcing a simple policy via
KubeArmor

The Policy: In-paper

1 apiVersion: security.kubearmor.com/v1
2 kind: KubeArmorPolicy
3 metadata:
4     name: ksp-mitre-kinsing-cryptomining-malware-block
5 spec:
6     message: “Incident! Kinsing crypto mining attack is Blocked”
7     tags : [“MITRE”, “T1496”, “S0599”, “MALWARE”, “T1059.004”, “T1059”, “Crypto Mining”,             “CVE-2020-7961”]
8     selector:
9          matchLabels:
10             app: frontend #replace suspected pod’s label here
11     process:
12         severity: 1
13         matchPaths:
14             – path: /tmp/kdevtmpfsi
15             – path: /var/tmp/kinsing
16        action: Block
17 file:
18     severity: 2
19     matchPaths:
20           – path: /tmp/kdevtmpfsi
21            – path: /var/tmp/kinsing
22           – path: /tmp/zzz
23     action: Audit

The Policy coupled with KubeArmor makes sure that the kinsing and kdevtmpfsi binaries are not allowed to execute as well as any access to files named kinsing, zzz and kdevtmpfsi under any folder hierarchy will be audited and alerted.

The Policy: In-action

Checking the pod resource usage before and after applying the policy

Looking into the infected pod we could see that most of the malware processes are
<defunct>

Conclusion

Kinsing malware indicated a repetitive pattern during an attack leading to a discoverable attack signature. Without a profound knowledge of the process activities, file activities, and network activities from your cloud-native environment and the assistance from a keen discovery engine, it’ll be difficult to identify such an attack. It’ll be troublesome to uncover any such ongoing malicious activity.

By utilizing KubeArmor we were able to effectively protect against Kinsing malware and KubeArmor was also able to defunct the running malicious processes