Protecting Kubernetes workloads against the Kinsing Malware with AccuKnox
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 […]
Reading Time: 3 minutes
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:
- Update the contents of the container using the package manager
- Install dependency software with the package manager
- Initiate a cron service
- Download and execute a shell script
- 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.
- Launches the package manager to meet dependencies
- The malware kills all crypto mining processes and their cronjobs
- Removes files related to crypto-mining
- The malware is downloaded from the internet and stored in the /var/tmp directory
- 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, 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
The Policy: In-paper
1 apiVersion: security.kubearmor.com/v1
2 kind: KubeArmorPolicy
4 name: ksp-mitre-kinsing-cryptomining-malware-block
6 message: “Incident! Kinsing crypto mining attack is Blocked”
7 tags : [“MITRE”, “T1496”, “S0599”, “MALWARE”, “T1059.004”, “T1059”, “Crypto Mining”, “CVE-2020-7961”]
10 app: frontend #replace suspected pod’s label here
12 severity: 1
14 – path: /tmp/kdevtmpfsi
15 – path: /var/tmp/kinsing
16 action: Block
18 severity: 2
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
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
Must read articles
- Zero Trust (ZT) – The Future of Cloud Security
- Zero Trust (ZT) Architecture, Framework and Model
- Cloud Security Governance, Risk and Compliance (GRC)
- How to Pick the Right CNAPP (Cloud Native Application Protection Platform) Vendor
- What is Driving the Need for CSPM (Cloud Security Posture Management)
- Agent vs Agentless Multi Cloud Security
You cannot secure what you cannot see.
Your most sensitive information is stored on endpoints and in the cloud. Protect what is most important from cyberattacks. Real-time autonomous protection for your network's edges.