{
	"id": "72c9b805-a70a-4ac8-b2fe-28de114443c5",
	"created_at": "2026-04-06T00:12:13.800132Z",
	"updated_at": "2026-04-10T13:12:12.902881Z",
	"deleted_at": null,
	"sha1_hash": "951105bbaa4cc43c8980454254b85221244c1aa4",
	"title": "How IoT Botnets Evade Detection and Analysis - Part 1",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1320387,
	"plain_text": "How IoT Botnets Evade Detection and Analysis - Part 1\r\nBy by Nozomi Networks Labs | March 1, 2022\r\nArchived: 2026-04-05 19:41:51 UTC\r\nOn the Hunt for Elusive Malware\r\nMalware families targeting the IoT sector share multiple similarities with their Windows-based counterparts, such\r\nas trying to evade detection by both researchers and security products. Their aim is to stay below the radar as long\r\nas possible. One key technique to stymie reverse engineering botnet code is to obfuscate the code by compressing\r\nor encrypting the executable, called packing.\r\nIn this post, we explore the current status of the packers used by IoT malware, using data collected by Nozomi\r\nNetworks honeypots. We’ll also dig deeper into various obstacles that researchers face when analyzing obfuscated\r\nsamples and show how they can be handled.\r\nIoT Botnet Attack Statistics\r\nHoneypots are vulnerable systems that are deliberately made available to adversaries so that information on\r\nmalicious activity can be collected for research, detection, and defensive purposes. Nozomi Networks Labs runs a\r\nnetwork of passive honeypots across various regions that emulate multiple protocols commonly abused by\r\nattackers. The data they collect is aggregated and used for research and detection efforts.\r\nOver the course of a seven-day period, Nozomi Networks honeypots collected 205 unique samples from attacks.\r\nThe vast majority of the collected files are Linux executable files for 32-bit architectures.\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 1 of 11\n\nStatistics of the different file types collected by our honeypots.\r\nAttackers use packers to obfuscate their code, concealing the original code with the intent of evading detection\r\nand making malware analysis more difficult and time consuming. Of the samples we collected, approximately one\r\nthird were packed using multiple versions of UPX, a free and open-source packer widely used by both legitimate\r\ncompanies and malicious actors. UPX was the only packer used in this set of samples.\r\nPercentage breakdown of UPX-packed samples and unpacked samples collected by the honeypots.\r\nAt the time of the analysis, 49 of 205 samples were not present on VirusTotal, a share site for malware details and\r\nresearch, and thus we decided to focus on these potentially new threats. This subset of files follows a similar\r\npercentage distribution regarding the packer and the version employed. Most of the new files—almost 80%—were\r\nnot packed at all, with the remainder packed with UPX.\r\nBased on initial research, one of these samples appears to belong to the same malware family that showed up in\r\nother internal Threat Intelligence research. It also stands out because of the particular UPX packing structure\r\nmodifications.\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 2 of 11\n\nOf new samples not present on VirusTotal, 80% were not packed, while the rest were packed with\r\nUPX.\r\nUnpacking Challenges\r\nWhen a sample is only packed with UPX, it is very easy to unpack with the standard UPX tool using the -d\r\ncommand line argument. Therefore, attackers will commonly modify the UPX structures of a packed sample so\r\nthat it remains executable, but the standard UPX tool can no longer recognize and unpack it.\r\nSince UPX is an open-source tool, we can check its source code on GitHub to understand its structures and what\r\nfields it uses. (You can see more of its file structure here.)\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 3 of 11\n\nSample UPX file structure.\r\nMost IoT samples packed with UPX modify the l_info and p_info structs in the header. For example, as we have\r\nseen before with the SBIDIOT malware, it’s common for malware authors to modify the l_magic value of the\r\nl_info struct in UPX-packed samples. In this case, unpacking the sample is as trivial as replacing the modified\r\nl_magic value with UPX! and executing upx -d.\r\nIn other cases, like the Mozi IoT malware family, the p_info struct is modified to set p_filesize and p_blocksize to\r\nzero. The solution then involves repairing the two zeroed values by replacing them with the filesize value that is\r\navailable at the trailer of the binary.\r\nHowever, when we tried to unpack the samples of interest, UPX returned an unusual error:\r\nMalware sample fails while testing to determine if it can be unpacked with UPX.\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 4 of 11\n\nIn this case, UPX is telling us that there was a problem with the b_info structure. After some research, we\r\nconcluded that this structure doesn’t seem to be widely used by malware authors. b_info is a structure placed\r\nbefore each compressed block and contains information about its compressed and uncompressed size, along with\r\nthe algorithm and parameters used to compress them. Once we checked the b_info structure in the file, we realized\r\nit hadn’t been zeroed or modified in an obvious way.\r\nDiving deeper into the internals of UPX, we found the exact place in the code that raises this exception. If the\r\ncompressed size (sz_cpr) is bigger than the uncompressed size (sz_unc), UPX will fail. However, their values\r\nwere coherent, so we discarded this modification as the source of the problem. In these lines of code, we can see\r\nthat the most promising reason could be a problem with a difference between the sum of the declared size of the\r\nuncompressed sections and the declared size of the uncompressed file. In our sample, the sum of the value of\r\nsz_unc was bigger than the value of p_filesize, so we modified the appropriate p_info structure to set its p_filesize\r\nfield with a value that wouldn’t trigger this exception.\r\nAfter changing these values, a header checksum exception was raised. Calculating this checksum value was\r\npossible since we had its source code, but it would be time-consuming, so we temporarily moved to another\r\nresearch path. We decided to create packed samples that were as similar as possible to the malicious sample so it\r\nwould be easier to spot the differences.\r\nWith the help of upx --fileinfo we got the parameters needed to pack another executable with almost the same\r\ncompression and decompression algorithm.\r\nExtracting compression information from a malware sample.\r\nTo compress the sample, the attackers used a command similar to upx --best --nrv2d \u003celf_file\u003e. As a starting point\r\nto check differences, we used the rz-diff tool to compare the main decompression functions:\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 5 of 11\n\nCreating an executable with similar packing and comparing unpacking functions.\r\nWe started comparing the differences between the functions, looking for the code we were thinking the attackers\r\nadded to the decompression process. An unexpected difference appeared:\r\nMalware sample packed using UPX 4.0.0.\r\nAt the moment, the stable UPX version is v3.96, and version 4.0.0 is in development. Changelog doesn’t seem to\r\ncontain big changes in how ELF compression works, but there are a lot of commits that affect portions of the code\r\ninvolved in the calculation of these values.\r\nWe then checked how this new version handled the issues we were seeing by downloading the pre-release version\r\nof UPX and compiling it. After only fixing the UPX! strings headers (b_info and p_info structures were left\r\nuntouched) and passing this executable to UPX version 4.0.0, the sample was accurately decompressed.\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 6 of 11\n\nSuccessful extraction with UPX 4.0.0 (commit a46b63).\r\nIt is possible that the attackers realized that this version of UPX (which is still in development) generates\r\nfunctional samples that cannot be extracted by standard production versions of UPX versions used by default by\r\neveryone.\r\nUniversal Manual Unpacking\r\nInstead of digging deeper into the modifications introduced by attackers, there is another approach we can\r\nconsider. The idea here is to stop the debugging process when the code and data are already unpacked but the\r\nunpacked code hasn’t been executed yet, to prevent the subsequent possible data and code modifications, and\r\nwrite down the unpacked code and data back to the disk. This approach is widely used to unpack Windows\r\nsamples, but what about IoT threats? From a high-level perspective, the same logic can certainly be applied to\r\nthem.\r\nHere are several universal techniques that allow us to circumvent packers regardless of what modifications are\r\nintroduced. They generally involve relying on the steps that an unpacker has to do in order to achieve its goal,\r\nmainly:\r\n1. The packed code and data should be read and unpacked\r\n2. A big memory block should be available to host the resulting unpacked sample\r\n3. The result of the unpacking should be written into this big memory block\r\n4. Depending on the existing protection flags for this block, they may need to be adjusted to make code\r\nexecution possible\r\n5. Finally, the control should be transferred to the first instruction of the unpacked code known as the Original\r\nEntry Point (OEP)\r\nSo, how can these techniques help us unpack the samples?\r\n1. Generally, packed code and data have high entropy and can therefore be easily identified in hex editors.\r\nFinding these blocks and tracking their cross-references can help us find the\r\ndecryption/decompression/decoding routine(s).\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 7 of 11\n\n2. Keeping track of memory allocations (mmap syscall) may help us find the future virtual address of the\r\nunpacked code and data.\r\nmmap syscall (rax = 0x09) with a big memory block length requested.\r\n3. Memory or hardware breakpoint on write operation set on the allocated block will help us intercept the moment\r\nwhen the unpacked code and data of interest will be written there.\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 8 of 11\n\nSetting a hardware breakpoint on write operation in IDA.\r\n4. Keeping an eye on the mprotect syscall, which is commonly used to change protection flags, can help identify\r\nthe moment when this will happen.\r\nmprotect syscall followed by an unusual control flow instruction.\r\n5. Looking for unusual control flow instructions can help identify the moment when the unpacker finished its job\r\nand is ready to transfer control to the first instruction of the freshly unpacked code (OEP).\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 9 of 11\n\nThe final unusual control flow instruction leading to the OEP.\r\nFollowing these approaches separately or in combination eventually helps intercept the moment when the\r\nunpacked code and data finally reside in memory readily available to be dumped to the disk for subsequent static\r\nanalysis.\r\nIn addition to these techniques, calling munmap syscall next to transferring control to the OEP is another feature\r\nof UPX that allows researchers to quickly unpack such samples. They can simply intercept it and then follow the\r\nexecution flow\r\nmunmap syscall (rax = 0x0B) executed next to transferring control to the OEP.\r\nConclusions\r\nThe landscape of malware targeting the IoT sector keeps evolving and borrowing many features from the more\r\nwell-known IT sector. Staying up-to-date with the latest trends in this area and being able to handle them helps the\r\nsecurity community combat new threats more efficiently and reduces the potential impact of associated\r\ncyberattacks.\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 10 of 11\n\nYou can read additional research in Part 2 of this blog.\r\nSource: https://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nhttps://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.nozominetworks.com/blog/how-iot-botnets-evade-detection-and-analysis/"
	],
	"report_names": [
		"how-iot-botnets-evade-detection-and-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434333,
	"ts_updated_at": 1775826732,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/951105bbaa4cc43c8980454254b85221244c1aa4.pdf",
		"text": "https://archive.orkl.eu/951105bbaa4cc43c8980454254b85221244c1aa4.txt",
		"img": "https://archive.orkl.eu/951105bbaa4cc43c8980454254b85221244c1aa4.jpg"
	}
}