{
	"id": "809effdc-65ec-4b03-b01b-ee91c44fd6c6",
	"created_at": "2026-04-06T00:13:16.752205Z",
	"updated_at": "2026-04-10T03:30:57.350048Z",
	"deleted_at": null,
	"sha1_hash": "de73385bdf06787fddde545f8cc356be9f752bb0",
	"title": "Deconstructing Voidlink: Why New AI and Cloud-Native Threats Require a New Class of Defense",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3818580,
	"plain_text": "Deconstructing Voidlink: Why New AI and Cloud-Native Threats\r\nRequire a New Class of Defense\r\nBy Isovalent\r\nArchived: 2026-04-05 16:10:07 UTC\r\nVoidLink’s emergence serves as a stark reminder that AI and automation aren’t just for defenders. The new\r\nmalware toolkit blends rapid innovation with deep technical modularity, pushing the boundaries of what we expect\r\nfrom modern threats.\r\nVoidLink is one of the newest, more effective malware frameworks designed and generated largely with the\r\nassistance of AI tooling. Research shows the toolkit's rapid development cycle with functional code in less than\r\na week, corroborated by technical analysis of the attack stages that shows a sophisticated framework designed to\r\nbypass standard cloud security perimeters.\r\nWe use Tetragon, the leading eBPF runtime security visibility tool, to investigate the behavior of VoidLink and\r\nthen mitigate the toolkits startup sequence using runtime security controls. If you are looking for a walkthrough of\r\nthe detection policy, please navigate to the policy example and walkthrough below. \r\nQuick FAQ’s\r\nWhat is VoidLink: A Linux malware toolkit characterized by its modularity, technical sophistication, and\r\ndevelopment process. VoidLink combines custom loaders, implants, kernel rootkits, and more than 30\r\nplug-in modules , allowing attackers to maintain persistent access across a wide range of Linux\r\nenvironments, including cloud, containerized, and bare-metal Linux systems.\r\nWhen was VoidLink discovered: First discovered and publicized in December 2025. It appears to have\r\nbeen built in late Fall 2025, over the course of ~1 week.\r\nWho developed VoidLink: Attributed to a Chinese affiliation (unknown exact organization), leveraging\r\nAI models and coding agents (e.g. TRAE SOLO ) to automate and accelerate development.\r\nWhat does VoidLink target: Built to target Linux systems, specifically for cloud workloads, containers,\r\nand Kubernetes environments.\r\nWhat makes VoidLink unique: VoidLink’s AI-driven development, modular plugin architecture, and\r\nadaptive runtime capabilities targeting cloud, container, and Kubernetes workloads. It includes adaptive\r\ntechniques to map out target environments, understand their security tooling, and take dynamic steps to\r\navoid detection.\r\nHow to update or patch: There is no single patch to apply, instead Security teams need controls in place\r\nto detect and block Voidlink’s attempts to hide activities within standard system processes.\r\nHow does Isovalent detect and mitigate: Tetragon acts as the low-level sensor, providing eBPF-powered\r\nkernel introspection. The Tetragon sensor monitors all file access and process execution with incredibly\r\nlow overhead, allowing you to see exactly what VoidLink is attempting in real-time without slowing down\r\nthe business.\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 1 of 9\n\nWho is using VoidLink: For more information on known ATP groups using VoidLink, check out the Talos\r\nthreat research post .\r\nSolving the visibility challenge\r\nWhile VoidLink is highly sophisticated, runtime monitoring identifies the characteristic syscall and file creation\r\nevents it relies on to establish a foothold in cloud workloads.\r\nVoidlink operates with intent to evade, disguising its processes by mimicking legitimate system names and\r\nbehaviors (as we see in policy examples below covering stage [0] early name change syscalls) and dynamically\r\nevading legacy EDR tools. By leveraging process name changes and embedding itself within standard system\r\ntasks, it blends malicious activity into routine operations, making detection through conventional monitoring or\r\napplication-level logging extremely difficult.\r\nTetragon exposes this kernel-level activity:\r\nTetragon detects when a process binary calls the kernel function prctl by hooking into security_task_prctl .\r\nIn the snippet from the Tetra CLI above, Tetragon detected arguments for the binary\r\n[ /usr/local/bin/voidlink/stage0 ] to change its process attributes to resemble a legitimate system worker\r\nkworker/u16:0 .\r\nDetecting sophisticated threats requires observing system behavior beyond the application layer. Tetragon\r\naddresses this gap by implementing deep kernel-level visibility, monitoring actions as they pass through the kernel\r\nin real time, not just as they are reported by user space.\r\neBPF policies continuously monitor file access, process execution, and sensitive syscalls with minimal system\r\noverhead. By living in the kernel, these policies are the optimal control point to observe and act on suspicious\r\nbehaviors.\r\nTetragon both alerts on and blocks events directly within the kernel. Enforcement mechanisms include overriding\r\nthe syscall’s return value (preventing the action’s execution), and issuing a signal to immediately terminate the\r\noffending process, halting the malware execution chain.\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 2 of 9\n\nNeutralizing the threat: blocking and mitigation\r\nIt’s not enough to just detect Voidlink; teams have to stop the attack chain before it implants the system. Tetragon\r\nsupports two main enforcement actions: override (returning an error, e.g., -1 ) and process termination\r\n( SIGKILL ).\r\nOverride blocks the immediate malicious action (as with the name change event we see further below) by\r\ndisallowing the syscall to complete successfully. However, the malware chain may remain active after receiving\r\nthe null value (so, even if it is expecting the name change to return successfully, the chain may continue to the\r\nnext step even with a –1 ) and still attempt further actions.\r\nThis is where a layered policy halts the process. SIGKILL  immediately terminates the process; this signal cannot\r\nbe caught or ignored by user space code, halting the malware and stopping any subsequent stages (such as loading\r\nplugins or establishing connection to the C2).\r\nIn practice, using both actions together, override to block the specific action and SIGKILL to stop the process,\r\nprovides the strongest guarantee of interruption and containment. We use this layered approach in the policy\r\nbelow for a hardened policy.\r\nVoidLink attack framework and sequence\r\nVoidlink is best understood as a modular, AI-developed malware framework engineered to target modern cloud\r\nand containerized workloads. It establishes a connection to the target system, and then provides the attacker a\r\nvariety of tools to complete their intended outcome (steal data, change files, access logs or a specific system).\r\nThe malware leverages custom loaders, kernel and user-mode rootkits, and a dynamic plugin system that allows\r\nfor real-time adaptation to cloud-native targets, including Kubernetes-managed containers and short-lived\r\nworkloads.\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 3 of 9\n\nTechnically, Voidlink is designed to bypass standard cloud security perimeters, embedding itself at multiple layers\r\nto maintain persistence and facilitate lateral movement. The modular design supports covert data exfiltration and\r\non-demand capability loading, making many legacy defenses insufficient to handle uncovering the initial attack\r\nsequence and the dynamic core plugins. In highly distributed cloud and containerized environments, layered\r\nruntime enforcement and continuous kernel-level monitoring are now operational requirements for proper defense\r\nin depth.\r\nThis attack flow diagram from Check Point Research shows the attack pattern of the malware toolkit, with early\r\nstages being used for obfuscation and implanting before moving into more targeted attack patterns to exfiltrate\r\ndata or reach sensitive workloads. Stages [0] and [1] implant the malware onto the workload and establish the\r\ncommand-and-control (C2) server to relay specific actions and plugins (e.g. establish SSH tunnel, container\r\nescape, scan local logs, and more).\r\nThis overview is complemented by Sysdig’s research, which details the specific syscall sequences observed\r\nduring the early stages of the attack. If you are curious about the encoding of each sequence and attack stage, we\r\nencourage you to read that blog here. In the next section, we take the known attack pattern and use Tetragon\r\npolicies to hook into the sequence and block VoidLink from executing.\r\nDetect and mitigate VoidLink with Tetragon\r\nBy living in the kernel Tetragon is particularly effective in capturing and acting on low-level syscall-level events,\r\nparticularly those associated with the process manipulation and C2 activity that pass through the kernel and are\r\ncore to VoidLink’s known attack stages.\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 4 of 9\n\nStage [0] detection and mitigation\r\nVoidLink’s initial attack stage mask the process names, creates new memory files, and establishes C2\r\nconnections using syscalls prctl (for changing process names), connect (for network operations), fork\r\n(create new child processes), memfd_create (create memory file), and more. Let’s break down detecting and\r\nblocking during this early attack phase.\r\nIn the attack chain, VoidLink takes a routine sequence during stage [0] that involves invoking the prctl syscall\r\n(short for process control)and changing its name to something benign ( kworker/ , watchdog/ , etc). This re-naming attempts to keep the process relatively unflagged for anomalous behavior. However, this syscall sequence\r\ngives an ideal early hook point for the policy to detect and kill the attack chain.\r\nWe’ve modified the policy to obfuscate the full list of args and index values, let’s dive into the high-level\r\nimportant bits.\r\nThis policy detects and prevents obfuscation techniques used by Voidlink, which attempts to evade detection in\r\nstage [0] by changing its name to mimic legitimate system processes. This is not a standard action and is\r\nnotable in production environments.\r\nThe policy attaches to the security_task_prctl kernel hook , called whenever a process attempts to use the\r\nprctl syscall. prctl has a number of use cases in the kernel, and here specifically, the option PR_SET_NAME\r\n( values = 15 ) changes the process name.\r\nThe eBPF policy sits in the kernel, observing all prctl events to check if they are attempting to set a new name\r\nfor the process, and if so, do they match the listed values ( \"kworker/\" , \"watchdog/\" ) in the policy.\r\nWhen, the policy detects a process attempting to rename itself with a prefix matching the listed values, it triggers\r\ntwo enforcement actions: 1)  SIGKILL to terminate the process immediately and 2) Override the syscall to\r\nprevent the name change from executing successfully. This blocks the malicious activity at the kernel level and\r\nstops the offending process before it can continue its execution.\r\nThese policies can be modified simply to generate alerts instead of enforce or increase the scope of values covered\r\n(here we have only listed a sample).\r\nAdditionally, this same policy framework addresses the other syscalls in the startup sequence. In the example, we\r\ntargeted prctl , but each syscall ( connect , recv_from , memfd_create ) provides the ideal hook point to layer\r\nin other pre-built policies that block VoidLink’s startup sequence.\r\nControl channel detection and mitigation\r\nIf the attacker successfully implants after stages [0] + [1], the C2 server communicates which plugins to execute\r\nand on what targets. The toolkit relies on a \"magic number\" (unused, non-standard value) to signal the kernel\r\nrootkit to listen for subsequent instructions. This technique is typical in advanced malware, using covert values in\r\nsyscalls to bypass standard detection and trigger custom behaviors.\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 5 of 9\n\nHow it works is the rootkit uses a kernel module to hook into prctl events and listen for the magic number\r\n(0x564C). If the toolkit’s hook observes the magic number, then it uses arguments 2 and 3 passed in the same\r\nevent to take a specific action. [Ie. If arg2 = 12 , then activate the container escape malware.] This simplifies the\r\ndetection workflow, as we only have to hunt for the magic number.\r\nWe’ve also modified this policy to obfuscate certain fields, let’s break down the important bits.\r\nThe eBPF policy sits in the kernel, observing when a  prctl call is made with the VoidLink-specific magic\r\nnumber ( 0x564C , decimal 22092 ) as the first argument, an indicator the rootkit is receiving a command from\r\nthe C2 infrastructure. This number has no other common use case, and is only relevant to the VoidLink execution\r\nchain.\r\nOn detecting the magic number, the policy immediately issues a SIGKILL to terminate the process and overrides\r\nthe syscall, blocking command execution at the kernel level. Same as the actions in the first policy, this targeted\r\napproach gives teams reliable detection and mitigation of VoidLink’s attack chain, actively stopping an ongoing\r\nattack and shutting down escalation through other follow-on techniques.\r\nScaling the shield across modern cloud\r\nProtecting one cluster is easy; protecting a global cloud footprint is hard. Variations in cluster configurations,\r\nephemeral container workloads, and multi-cloud topologies require unified and scalable approaches to policy\r\nmanagement and enforcement.\r\nCisco Security Cloud gives security and platform teams the single point of control to define, deploy, and update\r\nruntime policies across all environments from a single interface. This brings consistent coverage, rapid policy\r\npropagation, and real-time insight into workload security posture at scale.\r\nThrough the central Security Cloud dashboard, Security teams seamlessly operationalize and audit VoidLink\r\nprotections across their entire infrastructure, reducing manual overhead and hardening security. As threats evolve,\r\nthis model allows defenses to adapt fleet-wide in minutes not days or weeks.\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 6 of 9\n\nIn this first dashboard, a security admin sees a list of shields (compensating controls) that protect against known\r\nCVE’s. On the second line from the top, we see a shield for the Critical severity CVE-2024-47176 . This policy\r\nis actively deployed in monitoring mode. With labels, SecOps teams quickly apply tags to each event to filter for\r\nfurther incident response or create downstream automation logic when an alert / enforcement event is triggered.\r\nTesting\r\nIn just a few clicks, this is the central hub for monitoring and embedding protection policies across the fleet.\r\nIn the next dashboard below, we see that the security team has selected the shield for CVE-2024-21626, a runc\r\n vulnerability for container environments. Here the SecOps team easily sees metadata around the policy itself\r\n(creation date, updated on, deployed where, and by whom), details on the specific workloads where it has been\r\napplied, CVE details and context, and full transparency of the actual policy (obfuscated with an example policy).\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 7 of 9\n\nNo more security black boxes; teams see and modify security policies across their fleet, having full control over\r\nwhat to observe and where to act.\r\nLearn more and see Tetragon in action\r\nVoidLink provides a glimpse into the evolving threat landscape facing cloud-native environments, where\r\nadversaries leverage AI and advanced modular techniques to outpace conventional defenses.\r\nWith Tetragon, Cisco delivers real-time, kernel-level security enforcement that powers security teams to detect\r\nand stop these threats before they take hold. To learn how Cisco Security Cloud and Isovalent help safeguard your\r\nglobal infrastructure, connect with us!  \r\nDo you have any questions?\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 8 of 9\n\nReferences\r\nOverview of VoidLink background and architecture\r\nBackground and development of VoidLink\r\nAdditional background and development\r\nTechnical break down of compiled kernel rootkits\r\nTargeting of cloud and container environments\r\nUse of AI to create malware toolkit\r\nAPT and UAT groups using VoidLink\r\nSource: https://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nhttps://isovalent.com/blog/post/voidlink-cloud-malware-detection/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MISPGALAXY"
	],
	"references": [
		"https://isovalent.com/blog/post/voidlink-cloud-malware-detection/"
	],
	"report_names": [
		"voidlink-cloud-malware-detection"
	],
	"threat_actors": [
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-10T02:00:03.325163Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434396,
	"ts_updated_at": 1775791857,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/de73385bdf06787fddde545f8cc356be9f752bb0.pdf",
		"text": "https://archive.orkl.eu/de73385bdf06787fddde545f8cc356be9f752bb0.txt",
		"img": "https://archive.orkl.eu/de73385bdf06787fddde545f8cc356be9f752bb0.jpg"
	}
}