{
	"id": "5d85e05a-94ae-49ba-a60b-bd08bdb3b43d",
	"created_at": "2026-04-06T00:07:47.285029Z",
	"updated_at": "2026-04-10T13:13:02.525689Z",
	"deleted_at": null,
	"sha1_hash": "0a6b4ccaf1510614047d24ca3c7122e4f3a53e17",
	"title": "XZ Utils Backdoor | Threat Actor Planned to Inject Further Vulnerabilities",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4572364,
	"plain_text": "XZ Utils Backdoor | Threat Actor Planned to Inject Further\r\nVulnerabilities\r\nBy Sarthak Misraa \u0026 Antonio Pirozzi\r\nPublished: 2024-04-10 · Archived: 2026-04-05 18:17:45 UTC\r\nOn Mar 29, 2024 details emerged about CVE-2024-3094, a vulnerability impacting the xz compression libraries\r\nused by Linux distributions.\r\nThe backdoor code was distributed to all rolling distributions. However, it was tailored to target distributions such\r\nas Debian and Fedora, which patch their SSH daemon with liblzma . Further, the backdoor scripts included\r\nsystem checks to guarantee that the object files were solely injected into Debian and Fedora distributions.\r\nSentinelOne analyzed the technical implementation of the xz backdoor and the differences between the two\r\nversions. In this blog post, we describe and explore how subtle changes made by the threat actor in the code\r\ncommits suggest that further backdoors were being planned.\r\nXZ Compromise | A Technical Breakdown\r\nIn the first iteration of the compromise (version 5.6.0), the actor successfully added code to the xz repository that\r\nenabled injection of the backdoor on Debian and Fedora distributions. However, the second iteration (version\r\n5.6.1) adds significantly more maturity by introducing the ability to execute additional shell scripts during the\r\nbuild phase via binary test blobs, presumably to make future updates to the backdoor less suspicious.\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 1 of 8\n\nThe injection of malicious shell scripts occurs during the execution of the configure command, which then\r\ninserts code inside the Makefile to build and replace object files with backdoor-infected counterparts.\r\nAlthough the backdoor and its functionality remain the same across both versions, the setup to inject and replace\r\nobject files differs. These discrepancies offer insights into the motivation and long-term plan of the threat actor.\r\nInitial Setup\r\nThe first piece of the backdoor is the m4/build-to-host.m4 file. This file orchestrates minor modifications and\r\nconceals the extraction and execution of the Stage 1 backdoor file, bad-3-corrupt_lzma2.xz .\r\nNote how the grep command matches one file in the source directory:\r\nOnly one file matches given bytes for both versions\r\nThe actor introduced several new files that contributed to setting up Stage 2 of the backdoor in a later commit with\r\nthe description, “Tests: Add a few test files”.\r\nThe next step extracts and stores the script from the bad-3-corrupt_lzma2.xz file within the variable\r\ngl_[$1]_config .\r\nHere, the extracted script is executed, marking the progression towards the Stage 1 payload of the attack cycle.\r\nStage 1 Payload | System Checks \u0026 Extraction\r\nThe Stage 1 payload can be extracted from the bad-3-corrupt_lzma2.xz file via the following command:\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 2 of 8\n\ncat bad-3-corrupt_lzma2.xz | tr \"\\t \\-_\" \" \\t_\\-\" | xz -d\r\nThis payload is responsible for extracting the Stage 2 payload from good-large_compressed.lzma and executing\r\nthe setup script. There are several variables defined in this step that will be utilized in the later stages.\r\nAnother notable feature of this stage is the repeated use of the head command to discard 1024 bytes (1 KB) but\r\nuse other 2048 bytes (2 KB) in a cyclic manner. This layer of obfuscation extracts another payload and removes\r\njunk data used to hide the payload, as shown in the following code from version 5.6.0:\r\nThis stage in version 5.6.1 has several differences from the previous version. One notable distinction is the\r\ninclusion of an operating system check to ensure that the backdoor is injected only when built on a Linux\r\nmachine, which repeats five times.\r\nAdditionally, minor variations include changing the final byte count in the head command from 724 to 939, and\r\nadjusting the argument for the tr utility to account for this modified offset.\r\nDiff of data extraction step in version 5.6.0 (left) and 5.6.1 (right)\r\nFollowing extraction, this payload is executed by piping it to bash , which advances the attack chain to Stage 2.\r\nStage 2 Payload | Injecting The Backdoor\r\nThe Second Stage Payload is responsible for the extraction, injection and cleaning of the backdoor files on Debian\r\nand Fedora builds. The script is broken in two execution phases:\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 3 of 8\n\nPhase 1: executed during the configure command; injects code into the makefile\r\nPhase 2: executed during the make command; injects the backdoor in object files\r\nThe script injects code in the makefile to execute the malicious code by running the make command. The script\r\nis aware of the phase it is executing in by checking the presence of config.status file and .libs/liblzma_la-crc64_fast.o .\r\nThis stage differs between versions. We believe the newer version seeks to make the backdoor modular so that\r\nother payloads could be injected down the line without adding new code to the build files.\r\n5.6.0_stage_2_backdoor_extracted.sh 048b064241f06b0975c2e20132379b5478af0247\r\n5.6.1_stage_2_backdoor_extracted.sh cc23255b7c051d9c35d769d4e91d168e3f410c01\r\nThe script defines several environment variables that should be considered indicators of compromise when present\r\non a system:\r\nis_arch_extension_supported : a check that is replaced by _get_cpuid from a malicious object file\r\n__get_cpuid : function that is replaced by malicious function exported in the backdoor object file\r\nGood-large_compressed.lzma and bad-3-corrupt_lzma2.xz : Files that contain setup scripts for the\r\nbackdoor\r\nThis step enables several checks which are performed before the backdoor is injected during the build process:\r\nChecks that the GCC compiler is installed\r\nChecks that the operating system is Linux and that the distribution is Debian or Fedora\r\nChecks for the presence of a file named config.status\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 4 of 8\n\nDuring this stage, the difference between versions 5.6.0 and 5.6.1 becomes significant. In 5.6.1, the threat actor\r\nintroduced a code snippet aimed at enhancing the modularity of the backdoor. This modification enables the\r\npotential injection of different variants via test files in subsequent stages.\r\nIf any test file exists within the directory srcdir/tests/files/ and contains the magic bytes ~!:_ W and |_!{\r\n- , the file will be unpacked and subsequently processed to execute the embedded scripts.\r\nDiff showing new code added to version 5.6.1 (right)\r\nThis enables the threat actor to deploy multiple backdoors in upstream packages through binary test files without\r\narousing suspicion in the commit tree. These test binary blobs typically serve the purpose of stress-testing\r\ncompression algorithms, pushing them to their limits by providing unconventional binary data for decompression.\r\nThis backdoor feature addresses a significant challenge faced by the threat actor during the development of the\r\nbackdoor in version 5.6.0. The commit history shows the actor fabricated a pretext to commit new test files in\r\norder to update the backdoor.\r\nGit commit history\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 5 of 8\n\nSuch functionality isn’t limited to a single instance. Another similar code snippet can be observed in the elif\r\nbranch of the script executed during phase 2: make command execution. In this case, a check for magic bytes\r\njV!.^% and %.R.1Z is performed, but the core extraction and execution of the script remain unchanged.\r\nThe remaining part of Stage 2 is consistent across both versions. The backdoored object file is extracted from the\r\nfile good-large_compressed via an intricate awk command.\r\nThis segment is an implementation of a modified RC4 algorithm, which decrypts the payload after processing the\r\ncompressed data, and writes it to liblzma_la-crc64-fast.o . The process remains identical in both versions,\r\ndiffering only in the bytes that are written.\r\nThe backdoor leverages ifunc resolvers, a feature of glibc and a recent addition to the xz project. These\r\nresolvers enable developers to have multiple implementations of a function and dynamically select which one to\r\nuse at runtime through a resolver function. In this context, the backdoor replaces existing functions, i.e\r\ncrc32_resolve() and c rc64_resolve() , to execute different code discreetly. This mechanism provides an ideal\r\nmeans to execute the backdoor’s code without raising suspicion.\r\nThe script then proceeds to modify the source code of crc64_fast.c and compile it dynamically to incorporate\r\nifunc resolvers, linking the backdoored liblzma_la-crc64_fast.o . Once the backdoor is successfully linked\r\nand set up, the script initiates cleanup to remove the artifacts used to build the backdoor.\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 6 of 8\n\nAnalysis of Attack Execution\r\nThe overall compromise spanned over two years. Under the alias Jia Tan, the actor began contributing to the xz\r\nproject on October 29, 2021. Initially, the commits were innocuous and minor. However, the actor gradually\r\nbecame a more active contributor to the project, steadily gaining reputation and trust within the community.\r\nPressure emails\r\nWhile Jia Tan made active contributions to the project, the project maintainer Lasse Collin started receiving\r\nemails from different people that pressured Lasse to transfer maintainership of the project to Jia. It’s\r\npossible that these emails were orchestrated as part of the operation, purportedly originating from non-existent individuals.\r\nAddition Of Modularity in 5.6.1 release\r\nAs outlined above, features that allow the build scripts to directly execute code from test binary files were\r\nadded in the 5.6.1 release to the backdoor. This change indicates the actor planned to infect the xz\r\nrepository with other vulnerabilities as well. This statement is also supported by the later commit made to\r\nbreak the LandLock functionality in xz util (not liblzma).\r\nGit Commit Forgery (disabling LandLock)\r\nThe commit made February 28 2024 breaks the C program that is used to check support for LandLock.\r\nLandlock is a Linux kernel process sandboxing feature that restricts the rights of a set of processes, which\r\nwould give the attacker more latitude to infect an impacted system. These commits are made under author\r\nLasse Collin. It is possible commits were forged for these changes.\r\nAttribution\r\nThe attribution of the operation and the intended targeting are currently unknown. Based on the sophistication and\r\nlong timeframe required to execute this attack, we believe the actor is likely a state-aligned entity. It is plausible\r\nthat this operation was outsourced by someone without necessarily revealing the true target of interest.\r\nConclusion\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 7 of 8\n\nThe operation that led to the xz backdoor demonstrates the risk of supply chain attacks in Open Source Software\r\n(OSS) projects. Open Source is often deemed safe from such attacks, given its scrutiny by a multitude of\r\ncontributors, making it improbable to implant malicious code without detection.\r\nThe operation exploited gaps in the reputation process and the absence of audits on released tarballs. Moreover,\r\ncommits to the LandLock functionality, along with code changes between versions, underscored the actor’s\r\nintention to introduce additional backdoors and sustain access to the repository.\r\nSentinelOne is closely monitoring this supply-chain attack. SentinelOne Singularity detects malicious behaviors\r\nattempted by an adversary via this backdoor.\r\nIndicators of Compromise\r\n5.6.0_stage_1_backdoor_blob.bin 96e42f5baf3f1bad129de247e9e0b30e6bcbd8fe\r\n5.6.0_stage_1_backdoor_extracted.bin 1e14bb58eaa1c1ac3227fd999fe9c3aa80ab25d3\r\n5.6.0_stage_2_backdoor_blob.bin bbeaeac4a1d3849098c2ebbaea526d2404171295\r\n5.6.0_stage_2_backdoor_extracted.sh 048b064241f06b0975c2e20132379b5478af0247\r\n5.6.1_stage_1_backdoor_blob.bin 01e966ce1de7f847d2e44c52fea1eb58c081ea0d\r\n5.6.1_stage_1_backdoor_extracted.sh 894b62c59533996a4376743782e78426a52f8cbc\r\n5.6.1_stage_2_backdoor_blob.bin dcc80761f84592b2c85ab71df2bc10b835121861\r\n5.6.1_stage_2_backdoor_extracted_script.sh cc23255b7c051d9c35d769d4e91d168e3f410c01\r\nliblzma.so.5.6.0 72e8163734d586b6360b24167a3aff2a3c961efb\r\nliblzma.so.5.6.1 8a75968834fc11ba774d7bbdc566d272ff45476c\r\nliblzma.so.5 123e570ac3d28a9f7ce6c30fdb19e20a8c23efae\r\nliblzma_la-crc64-fast.o 0ebf4b63737cdf3e084941c7d02f8eec5ca8d257\r\nliblzma_la-crc64-fast.o cc5c1d8f9924a3939f932a50f666dba03531e6a9\r\nliblzma_la_crc64_fast.o fb8b18fa39f198298c9f553496a18aa94fa75c03\r\nSource: https://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nhttps://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.sentinelone.com/blog/xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities/"
	],
	"report_names": [
		"xz-utils-backdoor-threat-actor-planned-to-inject-further-vulnerabilities"
	],
	"threat_actors": [],
	"ts_created_at": 1775434067,
	"ts_updated_at": 1775826782,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0a6b4ccaf1510614047d24ca3c7122e4f3a53e17.pdf",
		"text": "https://archive.orkl.eu/0a6b4ccaf1510614047d24ca3c7122e4f3a53e17.txt",
		"img": "https://archive.orkl.eu/0a6b4ccaf1510614047d24ca3c7122e4f3a53e17.jpg"
	}
}