{ "id": "b5424474-b334-4ab3-958a-a4850e3322f8", "created_at": "2026-04-06T00:16:40.991611Z", "updated_at": "2026-04-10T03:34:59.796688Z", "deleted_at": null, "sha1_hash": "593b0fa27b48a45d356126294887079a51352a78", "title": "Zoom into Kinsing", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1662209, "plain_text": "Zoom into Kinsing\r\nBy Kaizhe Huang\r\nPublished: 2020-11-23 ยท Archived: 2026-04-02 10:39:26 UTC\r\nFalco Feeds extends the power of Falco by giving open source-focused companies\r\naccess to expert-written rules that are continuously updated as new threats are\r\ndiscovered.\r\nlearn more\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 1 of 11\n\nThe Kinsing attack has recently been reported by security researchers, and it is well known for targeting\r\nmisconfigured cloud native environments. It is also known for its comprehensive attack patterns, as well as\r\ndefense evasion schemes.\r\nA misconfigured host or cluster could be exploited to run any container desired by the attacker. That would cause\r\noutages on your service or be used to perform lateral movement to other services, compromising your data.\r\nIn this blog, we are going to dive into the attack patterns of Kinsing. The better we understand this attack, the\r\nbetter we can defend our cloud native environment.\r\nStarting point\r\nAccording to Shodan, a search engine for internet-connected devices, more than 2,000 Docker engines were\r\nexposed to the internet. Some of those Docker engines weren't configured with authentication, which make\r\nthem a perfect target for Kinsing attacks.\r\nIn our honeypot project, we noticed that a latest version of the Ubuntu container was created without any\r\nprivileged setting. It looked like a normal container running. However, we noticed the entrypoint of the image, as\r\nit was a little bit suspicious.\r\nWhat grabbed our attention was:\r\n1. The code ran apt-get inside a running container. This is not a normal behavior since all of your\r\npackages' installation/update should be done earlier, only once, when building the image.\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 2 of 11\n\n2. Starting cron services inside a running container is also abnormal. You should run periodic tasks at the\r\norchestrator level, using CronJob or Jobs.\r\n3. Downloading a shell script from an unknown IP address also looks suspicious. A whois lookup located\r\nthe IP in a Eastern European country. Also note that most of your services don't need egress traffic to the\r\ninternet.\r\n4. The code ran tail -f /dev/null in order to keep the container running.\r\nUpon closer inspection, it looks like the downloaded d.sh is the malicious script that kicks off the Kinsing attacks.\r\nAfter the script is downloaded, it is executed to do the following:\r\n1) Prepare for running malware by increasing the fd limit, removing syslog, and changing file/directories'\r\npermission.\r\n2) Turn off security services (comments were added to explain the commands):\r\n3) Kill other crypto mining processes and their cronjobs:\r\n4) Delete files related to crypto mining:\r\n5) Download the Kinsing malware and run the following:\r\n1. Create a cronjob to download the malicious script:\r\nIt looks like after executing d.sh, our system would be a mess, and kinsing will be running.\r\nLet's dig into what Kinsing actually does with Sysdig open source.\r\nKinsing the malware\r\nAs a security researcher reported, Kinsing is written in Golang, a high level programming language for cloud\r\nnative application development. It's compiled with Go 1.13.6, which is a fairly new version. When Kinsing was\r\nrunning in our honeypot project, I got a chance to take a closer look at it. I used Sysdig open source to analyze the\r\nsyscalls that executed from Kinsing.\r\nIn summary, Kinsing serves as a convoy to a crypto miner. While successfully running inside the victim's\r\nenvironment, it laterally moves into other machines.\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 3 of 11\n\nKinsing creates a crypto miner\r\nKdevtmpfsi is the crypto miner that will be created and run by Kinsing in the /tmp directory. Given their sizes, it\r\nlooks like that the crypto miner is baked into Kinsing:\r\nFrom the system calls, we have more clarity into how the file is created:\r\nBy using the open-source Sysdig Inspect, Kinsing wrote to a file called /tmp/kdevtmpfsi . After creating the file,\r\nit added permissions to execute.\r\nFinally, the binary will be executed:\r\nOnce the crypto miner is running, Kinsing constantly checks the miner status through reading the process status\r\nfile:\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 4 of 11\n\nIt is also reflected in the source code, that you can reverse engineer with redress:\r\nInside the main function, there is a function isMinerRunning that checks the status of the miner. That way, if\r\nkdevtmpfsi is killed, Kinsing will restart the miner program.\r\nKinsing communicates with a C2 server\r\nLike some other malwares, Kinsing did contact Command and Control (C2) servers. The HTTP requests sent to\r\nthe following URL paths and request methods were captured by Sysdig open-source:\r\nURL Path HTTP Method\r\n/get GET\r\n/o POST\r\n/mg GET\r\n/h GET\r\nEach request returns a few strange characters.\r\nOne request worth highlighting above is the one to \"/get\" in the C2 server. Right after this request, the Kinsing\r\nmalware started to download shell scripts from another server. Below are the three scripts that were downloaded\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 5 of 11\n\nvia HTTP requests:\r\nal.sh\r\ncron.sh\r\nspre.sh\r\nal.sh and cron.sh just repeated the tasks that were done earlier: stop the security mechanism, kill other mining\r\nprocesses, delete other crypto mining cronjob, and add Kinsing's own cronjob.\r\nThe spre.sh, was used to lateral move to other machines through reading the SSH keys on the victims file system\r\n(e.g., files like \"~/.ssh/config\", \"~/.bash_history\").\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 6 of 11\n\nKdevtmpfsi the crypto miner\r\nA crypto-mining attack is just like free riding on Wi-Fi.\r\nJust as your network bandwidth will be shared by the free rider, some (or most) of your CPU or computing\r\nresources will be occupied by the mining processes without your consent. The impact is also similar. If the Wi-Fi\r\nfree rider is downloading movies via BitTorrent using your Wi-Fi network, you may have a poor experience while\r\nwatching Netflix.\r\nWhen there is a mining process running, other applications running in the same node will be severely impacted\r\nsince the mining process may occupy the CPU most of the time. Crypto-mining attacks have become one of the\r\nmost appealing attacks to hackers, as it is an almost guaranteed way of gaining some benefits out of a successful\r\nintrusion. In this section, we will be looking into a few patterns of the crypto miner kdevtmpfsi.\r\nCPU Usage\r\nMost of the crypto miners occupy a lot of CPU cycles, and kdevtmpfsi is no different. The CPU usage goes up\r\nwhen kdevtmpfsi started to run:\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 7 of 11\n\nAs you can see, kdevtmpfsi occupied almost half of the computing power of the node.\r\nIn production, DevOps may find that some services occupy a lot of CPU cycles because of software flaws or\r\noverloaded requests. It still doesn't suggest every CPU hike is caused by crypto miners. However, if CPU hikes\r\nare caused by some unknown processes or unknown containers, you should pay more attention to the hike.\r\nHow kdevtmpfsi prepares to mine\r\nAlthough we followed (and you should too) the best practices to assign resource limits and requests for each\r\nworkload, most of the containerized microservices don't really care whether the worker node is 8, 16, or 32 cores\r\nCPU. They will be scheduled to run by the kube-scheduler based on the request, as well as the worker node's\r\nresource capacity.\r\nBack to kdevtmpfsi. Below is a list of the system files accessed before the miner contacted the miner pool:\r\nFile name What is the file about?\r\n/sys/devices/system/cpu/online\r\nTo know how many CPUs are online and being scheduled\r\n(e.g., 0-7 indicates there is an 8 cores CPU)\r\n/proc/cpuinfo\r\nDisplays what type of processor your system is running,\r\nincluding the number of CPUs present.\r\n/proc/mounts\r\nA symlink to self/mounts which contains a list of the\r\ncurrently mounted devices and their mount points.\r\n/proc/self/cgroup Cgroup information about the caller process.\r\n/sys/bus/cpu/devices/cpu*/online CPUs that are online and being scheduled.\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 8 of 11\n\n/sys/bus/cpu/devices/cpu*/topology/*\r\nCPU topology files that describe a logical CPU's\r\nrelationship to other cores and threads in the same physical\r\npackage.\r\n/sys/bus/cpu/devices/cpu*/cache/index*/* Parameters for the CPU cache attributes.\r\n/sys/kernel/mm/hugepages/*\r\nContains files and information on hugepages, where\r\npagesize could be 1048576 or 2048, corresponding to 1GB\r\nor 2MB of hugepage size.\r\n/sys/bus/node/devices/node*/cpumap The node's cpumap.\r\n/sys/bus/node/devices/node*/meminfo\r\nProvides information about the node's distribution and\r\nmemory utilization. Similar to /proc/meminfo.\r\nsys/bus/node/devices/node*/hugepages The node's huge page size control/query attributes.\r\n/sys/devices/virtual/dmi/*\r\nContains hardware information. It may also contain cloud\r\nservice information (e.g., ec2, t2.xlarge).\r\nAs you can guess, kdevtmpfsi gathers the system information, like CPU, memory, cgroup, etc., to prepare for the\r\nmining.\r\nHow kdevtmpfsi communicates with the miner pool\r\nLike most other crypto miners, kdevtmpfsi also contacts a miner pool. It does so by using JSON-RPC over HTTP.\r\nFirst, kdevtmpfsi sends an login request to the miner pool server:\r\nFrom the login request, we know that the miner actually mines for Monero(XMR). And the login request includes\r\na login ID, password, agent, and supported mining algorithms.\r\nOnce the login has been confirmed, the following response is returned:\r\nKdevtmpfsi received the mining job immediately for the negotiated mining algorithm, as well as the scheme to\r\ncommunicate.\r\nKdevtmpfsi received four more jobs later on:\r\nJob ID: 703276738178843\r\nJob ID: 508335469096263\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 9 of 11\n\nJob ID: 704899485008265\r\nJob ID: 325604739614457\r\nEach job used the same algorithm as negotiated before, with the same seed hash value but a different blob value.\r\nLater on, kdevtmpfsi managed to send a heartbeat-like message to the miner pool with a special method called\r\nkeepalived :\r\nAnd the miner pool server returned with a nod message:\r\nThe heartbeat message was sent about every minute. These communication patterns repeated while the miner was\r\nrunning.\r\nMitigation strategies for Kinsing\r\nBefore we talk about the mitigation strategies, let's recap what suspicious attack patterns were discovered from\r\nKinsing.\r\nQuick recap\r\nIt would make sense to divide patterns found from Kinsing into three categories: process, file and network.\r\nAnd the division helps identify potential IOCs from three different angles:\r\nSuspicious process activities:\r\nLaunch package management tool to download toolkits facilitating attacks, like apt-get.\r\nEnable a cronjob service inside a container.\r\nDisable security services, like firewall, AppArmor, and cloud agents (from a container).\r\nA process launched from suspicious directories, like /tmp and /var/tmp.\r\nUnknown processes occupied a lot of CPU cycle.\r\nKill a bunch of processes, though the process may not exist.\r\nSuspicious file activities:\r\nRemove a bunch of files, though the file may not exist.\r\nAdd execution permission to files newly created (should be configured inside Dockerfile).\r\nRead system and device information.\r\nRead files that may contain secret information (e.g., \"~/.ssh/config\", \"~/.bash_history\").\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 10 of 11\n\nLook for specific sensitive string patterns, like \"id_rsa\" from files.\r\nUpdate cronjob, though cronjob may not be used.\r\nSuspicious network activities:\r\nNetwork traffic to the C2 server and miner pool.\r\nHTTP request contains suspicious URL path (e.g., /o, /mg, /al.sh, /spre.sh).\r\nHeartbeat messages that emit to suspicious IP addresses.\r\nAlthough we can't rely on a single individual suspicious event to unveil the Kinsing attack completely, some of the\r\npatterns above are significant enough to draw the SOC team's attention. So let's talk about how Falco can help\r\ndetect such an attack.\r\nFalco\r\nFalco, a CNCF incubating project, can help detect any anomalous activities in cloud native environments with\r\nrich, out-of-the-box default rules. Below are a few worth highlighting to detect suspicious behavior mentioned\r\npreviously\r\nYou can find the full list of Falco rules here.\r\nConclusion\r\nKinsing malware showed comprehensive patterns during the attack.\r\nWithout a deep insight into the process activities, file activities, and network activities from your cloud native\r\nenvironment, and the help from a smart detection engine, it will be hard to detect such an attack. It will be even\r\nmore difficult to uncover it.\r\nIt is also important to note that a unified monitoring and secure platform will speed up the investigation process.\r\nOnce you identify a single suspicious event, it helps you trace down the event from different angles: resource\r\nusage, network connections, and reading sensitive files.\r\nSuccessfully correlating these events together (e.g., using parent/grandparent process ID) will unveil the kinsing\r\nattack.\r\nThe Sysdig Secure DevOps Platform combines monitoring and securing solutions so you can easily correlate\r\nevents and protect your cloud native environment in a way that wouldn't be possible otherwise. Try it today!\r\nAbout the author\r\nTest drive the right way to defend the cloudwith a security expert\r\nSource: https://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nhttps://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/\r\nPage 11 of 11", "extraction_quality": 1, "language": "EN", "sources": [ "MISPGALAXY", "MITRE", "Malpedia" ], "references": [ "https://sysdig.com/blog/zoom-into-kinsing-kdevtmpfsi/" ], "report_names": [ "zoom-into-kinsing-kdevtmpfsi" ], "threat_actors": [ { "id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2", "created_at": "2022-10-25T16:07:24.471018Z", "updated_at": "2026-04-10T02:00:05.002374Z", "deleted_at": null, "main_name": "Cron", "aliases": [], "source_name": "ETDA:Cron", "tools": [ "Catelites", "Catelites Bot", "CronBot", "TinyZBot" ], "source_id": "ETDA", "reports": null }, { "id": "a6c351ea-01f1-4c9b-af75-cfbb3b269ed3", "created_at": "2023-01-06T13:46:39.390649Z", "updated_at": "2026-04-10T02:00:03.311299Z", "deleted_at": null, "main_name": "Kinsing", "aliases": [ "Money Libra" ], "source_name": "MISPGALAXY:Kinsing", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434600, "ts_updated_at": 1775792099, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/593b0fa27b48a45d356126294887079a51352a78.pdf", "text": "https://archive.orkl.eu/593b0fa27b48a45d356126294887079a51352a78.txt", "img": "https://archive.orkl.eu/593b0fa27b48a45d356126294887079a51352a78.jpg" } }