Kinsing malware
Kinsing is a malware family, written in the Go programming language, that primarily targets Linux servers and cloud and container environments to mine cryptocurrency. It takes its name from the binary dropped on infected systems and is also known as H2Miner. First analyzed in early 2020, it behaves like a worm, spreading on its own by scanning for and compromising exposed or misconfigured systems, and it remains active and evolving today. Because its main goal is to hijack a server's processing power to mine cryptocurrency, it is a form of cryptojacking. The name Kinsing is used both for the malware itself and for the financially motivated activity that deploys it. This entry explains what Kinsing is, how it infects systems and what it does once inside, what it targets, how it has evolved, and how organizations detect and defend against it.
Key takeaways
- Kinsing is Go-based cryptojacking malware that hijacks Linux servers and cloud infrastructure to mine the Monero cryptocurrency, typically using the XMRig miner.
- It spreads like a worm. It scans the internet for exposed or misconfigured systems and compromises them automatically, without needing a specific target.
- It exploits known weaknesses. Misconfigured Docker APIs, weak credentials, and a rotating set of known vulnerabilities are its main routes in.
- It works to stay hidden. Kinsing disables security tools, kills rival miners, uses rootkit techniques to conceal itself, and reinstalls through cron jobs.
- It is still active and expanding. It keeps adding new vulnerabilities and has broadened toward Windows and multi-stage tooling beyond pure mining.
How Kinsing infects systems
Kinsing does not rely on a single entry point. It continuously scans the internet for systems it can compromise, and uses whichever weakness it finds. Its common routes in include:
- Misconfigured and exposed services. Publicly exposed Docker APIs and other unsecured services and open ports are a frequent way in, particularly in cloud and container setups.
- Weak credentials. Brute-forcing or guessing weak passwords on exposed services gives the malware direct access.
- Known software vulnerabilities. Kinsing exploits unpatched flaws in widely used server software to run its code remotely, and it keeps older vulnerabilities in active use long after patches exist.
Once it has a foothold, Kinsing is usually delivered by a shell script that downloads and runs the main Go binary. The vulnerabilities it has abused over time span many popular server technologies, which is part of why it has stayed relevant. Representative examples are below.
What Kinsing does once inside
After gaining access, Kinsing follows a consistent pattern designed to maximize mining time and stay undetected:
- Prepares the ground. It disables or evades security tools and clears traces, using system utilities to remove logs and change file attributes so its files are harder to touch.
- Removes the competition. Kinsing looks for other cryptominers already on the host, in running processes and scheduled tasks, and kills them so it has the machine's resources to itself.
- Deploys the miner. It downloads and runs a cryptominer, typically XMRig, configured to mine Monero into the attacker's wallet, which is the point of the whole operation.
- Establishes persistence. It adds cron jobs or system services that re-download and relaunch the malware regularly, so removing the miner alone does not clean the system.
- Hides itself. It uses process masquerading and rootkit techniques, including a userland rootkit loaded through the system's library preload mechanism, to conceal its processes, files, and network connections from routine inspection.
The immediate effect is that the server's processor is consumed by mining, which shows up as unusually high and sustained resource usage, slower performance, and higher running costs in the cloud. Beyond mining, compromised servers can be used for other purposes, such as spreading the malware further or being folded into a botnet, so a Kinsing infection also signals that a system was exposed enough to be taken over at all.
What Kinsing targets
Kinsing is opportunistic rather than targeted. It goes after any reachable system that fits its playbook, which in practice means:
- Linux servers, its original and primary environment.
- Containers and orchestration, especially Docker and Kubernetes, where a single exposed API or misconfiguration can lead to compromise.
- Cloud-native infrastructure, where internet-facing services and rapid deployment can leave gaps, and where a hijacked instance runs up mining costs unnoticed.
Because it is opportunistic, any organization running exposed or unpatched Linux, container, or cloud workloads is a potential target, regardless of size or sector. A single overlooked, internet-facing service is often all it needs.
How Kinsing has evolved
Kinsing has not stood still since 2020. It continuously folds newly disclosed vulnerabilities into its toolkit, often within days of public proof-of-concept code, while keeping older ones in rotation because unpatched systems remain common. It has been observed expanding beyond Linux toward Windows, where its miner has been disguised under a legitimate-sounding name to blend in. More recent activity has paired the mining operation with additional post-exploitation tooling and backdoors, suggesting the operators are willing to use their access for more than cryptomining. The consistent theme is adaptation: Kinsing follows the vulnerabilities and the infrastructure, which is why it has remained a persistent threat to cloud and container environments for years.
How to detect and defend against Kinsing
Because Kinsing exploits exposure and known weaknesses rather than novel techniques, defending against it is largely a matter of hygiene backed by monitoring:
- Secure and patch exposed services. Lock down Docker and container APIs, avoid exposing services like Redis to the internet, close unnecessary ports, and patch known vulnerabilities promptly, since Kinsing relies on delayed patching.
- Enforce strong credentials. Replace weak and default passwords and apply multi-factor authentication on management interfaces to remove the brute-force route.
- Watch for the tell-tale signs. Sustained high CPU usage, unfamiliar miner processes such as XMRig, unexpected cron jobs, and disabled security tools are strong indicators of a Kinsing infection.
- Monitor cloud and container behavior. Use runtime and behavioral monitoring across cloud and container workloads to catch the malicious activity that follows a compromise, not just the initial exploit.
- Segment and limit blast radius. Network segmentation and least-privilege configuration reduce how far the malware can spread and what a compromised workload can reach.
Removing Kinsing usually means more than killing the miner: its persistence mechanisms will reinstall it, so responders isolate the host, remove the malicious cron jobs, services, and files, and, most important, close the exposure or vulnerability that let it in. For a system that has been deeply compromised, rebuilding from a known-good state is often the safest option.
Expert insight: A symptom worth taking seriously
It is tempting to treat cryptojacking as a nuisance rather than a real incident. The malware does not encrypt files or steal data in the way ransomware or an information stealer does, and the visible symptom is often just a slow, expensive server. But that framing understates the risk. A Kinsing infection is proof that a system was reachable and weak enough to be compromised automatically, by opportunistic malware that was not even aiming for that organization specifically. Whatever found its way in through that gap could just as easily have been something far more damaging, and indeed Kinsing itself has begun carrying additional backdoors beyond its miner.
This is where the response matters as much as the cleanup. Sekoia is a European cybersecurity vendor whose in-house Threat Detection & Research (TDR) team tracks threats like Kinsing directly, including through honeypots that observe how the malware exploits new vulnerabilities in the wild, and that intelligence feeds the platform. Rather than treating a spike in processor usage as an isolated performance issue, Sekoia's AI SOC platform correlates signals across endpoint, network, and cloud and maps them to the MITRE ATT&CK framework, so that the exploitation, defense evasion, and persistence behind a cryptominer are recognized as one intrusion and, importantly, so is the exposure that allowed it. The practical takeaway is to treat a cryptojacking infection as the security failure it represents: fix the underlying exposure, not just the symptom, because the next thing to find that gap may not settle for mining.