{
	"id": "78f49e10-5f78-4675-9c4d-9b5be367a85a",
	"created_at": "2026-04-06T00:20:05.871003Z",
	"updated_at": "2026-04-10T03:36:13.72527Z",
	"deleted_at": null,
	"sha1_hash": "d7abc1943c01d1c4321f23ac3350b2806b69ccfe",
	"title": "How Hackers Use Binary Padding to Outsmart Sandboxes and Infiltrate Your Systems",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 674038,
	"plain_text": "How Hackers Use Binary Padding to Outsmart Sandboxes and\r\nInfiltrate Your Systems\r\nBy Ryan Robinson\r\nPublished: 2023-05-18 · Archived: 2026-04-05 18:38:59 UTC\r\nWhat is binary padding? How can you detect against threats using junk data in various ways to evade defensive\r\nsystems and sandboxes? Read on to learn more.\r\nBinary padding is the process of adding extra or junk data to a portable executable (PE) file that, while not\r\nchanging the behavior of the binary, changes certain characteristics that can help with either obfuscating relevant\r\ncode or defeating sandboxing solutions and detections. \r\nThis technique is not novel. It has been employed in various forms for several years to achieve different effects, all\r\nof which are related to evading defense mechanisms. So why are we talking about it now? We have noticed\r\nrecently a lot of phishing campaigns using binary padding while targeting victims, for example Emotet and QBot.\r\n(Skip down to read more about this “PufferPhishing” technique.)\r\nThis blog will take a look into the what, the why, and the who when it comes to binary padding as an evasive\r\ntechnique for cyberattacks. \r\nWhy Would Attackers Use Binary Padding?\r\nHistorically, malware was small in size. A lot of logic for malware can be programmed into a very small\r\nexecutable. A small size for malware was a requirement not long ago, as computers had slower internet and not a\r\nhuge amount of RAM. Large binaries used to be limited to files like installers or games, as these contain a large\r\namount of resources such as extra files, images and libraries in order to function. Over 10 years ago, if a file was\r\nvery large, for example over 5 MB in size, it would have been an indicator of non-maliciousness.\r\nThese days not so much. As computers today have magnitudes more memory and disk space compared to twenty\r\nyears ago, file size of a binary became less of an issue. This has allowed new compilers and programming\r\nlanguages to optimize differently without considering the final binary size. New programming languages such as\r\nRust and Go default to statically link libraries to the final binary which helps improve performance, but results in\r\na larger final binary. For example, a “Hello, World” Go binary has a size in the megabytes.\r\nBinary padding comes with many benefits for malware authors, let’s discuss a few of them and the pros and cons\r\nfor each.\r\nBinary Padding Can Defeat Sandboxes with Size Limits\r\nOne of the most simple reasons for binary padding is to simply make the file bigger! This attempts to avoid\r\nanalysis from automated malware analysis tools, such as traditional sandboxes, since most have an upper limit on\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 1 of 12\n\nthe size of files being submitted. It also hinders analysis of the file as someone trying to submit the file might not\r\nbe able to upload such a large file in reasonable time limits, since the upload requires network transfer to the\r\nsandbox. This simple but effective technique allows malware to avoid being analyzed by virtue of being too big to\r\nfit in the front door. \r\nFor security vendors, the solution is simple: raise the limit of file size. This arms race comes with added costs for\r\nsecurity vendors, but also adds cost to the malware author, the larger they need to make their malware to usurp the\r\nlimits also makes the malware much bulkier and harder to transport to the victim. (There is an easy method that\r\nmalware authors are able to use to make their inflated files easier to transport that we will talk about later in this\r\nblog.)\r\nExceeding Sandbox Size Limits with Binary Padding\r\nPros for the attacker Cons for the attacker\r\n– Simple to implement for the malware\r\nauthor\r\n– Effectively defeats most sandbox solutions\r\n– Multiple ways to achieve\r\n– Easy for cybersecurity tools to detect\r\n– Malware with binary padding can be\r\nreversed\r\n– Hard to transport files\r\n– Does not defeat tools with no size limit\r\nUsing Binary Padding to Change the Hash\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 2 of 12\n\n“I’m not like other executables.” Binary padding can also be used to change the hash for a malware. This\r\ntechnique can be effective to avoid hash-based detections, but not systems with genetic-based detection. The\r\ntechnique is achieved by a malware creating a copy of itself and inserting random data into it, thus ensuring that a\r\ncryptographic hash, for example MD5 or SHA, of the file will be unique for each. It is easy to achieve as only one\r\nbit is needed to be changed to change the hash.\r\nThe reason why this works is due to a concept in cryptography called diffusion. Diffusion means that if one bit of\r\nan input into a cryptographic hashing function is changed, then much of the output (digest) is also changed. This\r\nmeans that similar inputs do not produce similar outputs, hiding any relationship between the digest and the\r\nplaintext. This has the effect of avoiding hash-based detections, as we can see it is trivial to change the hash. This\r\nis less of an effective technique as most modern malware detection solutions have moved beyond hash-based and\r\nuse genetic, signature, or behavior-based detections. \r\nAn example with the string diffusion:\r\nString MD5 Hash Digest\r\nDiffusion c9fc4714730359980e89007f327c5b7d\r\nDiffuzion 2e24821ec7e23fe19d8ec494a801928a\r\nNotice how changing one letter completely changes the above hash digest?\r\nBinary Padding to Create Unique Hashes\r\nPros for the attacker Cons for the attacker\r\n– Easy to achieve for the\r\nmalware author\r\n– Defeats hash-based\r\ndetections\r\n– Multiple ways to\r\nachieve\r\n– Slightly antiquated, it does not defeat more modern malware\r\ndetection methods such as signatures or genetic detection\r\n– Often requires the malware to create a copy of itself to modify,\r\nwhich can be suspicious behavior to detect in itself\r\nAn example of this technique being used is by the Orangeworm group with their Kwampirs backdoor; it achieves\r\nit by inserting a randomly generated string into the middle of the binary.\r\nBinary Padding for Obfuscation\r\nPadding, such as junk code, can be added to an executable solely for the purpose of creating so much junk and\r\nnoise that it bogs down analysts when looking at the file, that it has the effect of obfuscating the relevant\r\nmalicious code. Many would be familiar with the technique used in legislation of a rider; an extra provision added\r\nto a bill, hiding behind the main body of text hoping to fly under the radar in order not to be noticed. It is a similar\r\nconcept with junk code obfuscation.  Junk code has the effect of hindering manual analysis by a reverse engineer\r\nthat does not have the tools or skills to avoid falling into the trap. While this is effective at hindering manual\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 3 of 12\n\nanalysis, it does not always have the ability to pass automated analysis tools as they can analyze code at volumes\r\nthat cannot be performed by a human. The presence of junk code in itself can be a suspicious indicator of\r\nmaliciousness; what can be less discreet than a malware containing the works of Shakespeare inside it?\r\nBinary Padding for Obfuscation\r\nPros for the attacker Cons for the attacker\r\n– Can confuse malware analysts\r\n– Hinders debugging\r\n– Has some of the same positive effects of\r\ninflating the binary size\r\n– Can cause false negatives\r\n– Can cause decompilers and disassemblers to\r\ntake a very long time to open the file\r\n– Less likely to defeat automated analysis\r\ntechniques\r\n– Can be a suspicious indicator in itself\r\n– Can cause more resource consumption,\r\nhindering the performance of the malware\r\n– Limited effectiveness on skilled analysts\r\n– Has the same negative effects of inflating\r\nthe binary size\r\nProblem for Threat Actors\r\nThe main problem for threat actors is that with binary padding, the increased file size can be hard to distribute.\r\nThreat actors want a file that is huge on disk, but does not take ages to deliver. Not everyone has an extremely fast\r\ninternet, and therefore it would be inconvenient to a threat actor wishing to distribute malware to make it take\r\nhours to download. \r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 4 of 12\n\nWhat is their solution to this? The malware author can use a downloader that dynamically pads a binary after\r\ndownloading it. An example of this is the threat group BRONZE BUTLER. BRONZE BUTLER targeted Japanese\r\nbusinesses with malware using padding. This was achieved by using a downloader that would download a payload\r\nand then insert the character ‘0’ at the end of the file to inflate the size to 50-100 MB.\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 5 of 12\n\nThis comes with extra baggage that the malware author might not wish to have. Firstly the downloader itself\r\nmight be detected, which can defeat the purpose of using binary padding to avoid detection. Next is also that it\r\ncreates more network traffic that might be detected. The C2 might already be known to distribute malware, and it\r\ncan be blocked or detected at this point. The use of a C2 can add an extra single point of failure in the chain where\r\nsomething might break. Also the payload that is fetched might be detected in memory or over the network before\r\nthe padding is performed, so it might be analyzed before the padding has a chance to take effect. \r\nThere is another way to achieve padding without the same baggage that comes from using downloaders and C2\r\nservers, exploiting compression. We will talk about this technique below, which we are calling “PufferPhishing”\r\ndue to its active use in malicious phishing attachments. This is not a new technique, but is ever more being\r\nexploited by threat actors in phishing campaigns. \r\nPufferPhishing: Binary Padding Combined with Compression\r\nRecently we have noticed an uptick in the use of binary padding to evade analysis size limits… but with a smart\r\ntechnique to ensure that the files are still deliverable, by exploiting the efficiency of compression algorithms.\r\nMalware authors are creating padding that uses resources and overlays in order to create malware that is hundreds\r\nof MBs in size, but is able to compress to over 90% of its original bulk due to its efficiency in compression. This\r\nmeans that malware can be created to circumvent sandbox size limits but also solve the file transport problem that\r\ncomes with that technique. It is the binary padding equivalent of having your cake and eating it too!\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 6 of 12\n\nHow Does the PufferPhishing Technique Work?\r\nThe technique works by using repeating sequences of bytes padded inside binaries to inflate the size of the binary.\r\nBut the nature of the repeating bytes used allows it to be compressed to over 90% of its original size, commonly in\r\nthe ZIP file format. \r\nZIP archive file format most commonly uses the DEFLATE compression format, incorporating LZ77 and\r\nHuffman coding. It is very good at compressing sequences of repeating data. DEFLATE compression works so\r\nwell on repeating bytes that it’s worth showing an example:\r\nCreating a file of size 5 KB, with the repeating character a will compress to 22 bytes with DEFLATE. A 99.56%\r\ndecrease in size. Whereas a file with the string below will only compress to 45 bytes: \r\naabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz\r\nThis is a 13.46% decrease in size. Through DEFLATE, the file with the repeating bytes will be smaller than the\r\nfile with less repeating bytes even though the former file was around 100x bigger decompressed! This shows how\r\nthe use of repeating data (or a very low entropy) can be exploited to make very large malware files that are easy to\r\ntransport. The following CyberChef recipes have been created to help demonstrate:\r\nFile 1 (Repeating Bytes/Large File): Compression, Entropy\r\nFile 2 (More Entropy/Smaller File): Compression, Entropy\r\nCompression likes lower entropy. Entropy is a measure of how random the data inside a file is. Since compression\r\nalgorithms work by finding patterns to encode in a smaller format, a smaller entropy of data in a file will lead to\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 7 of 12\n\nbetter compression ratios.\r\n What does this look like incorporated into malware?\r\nExamples of Malware with Binary Padding\r\nOverlay\r\nIn March 2023, a Trend Micro blog noted Emotet using binary padding in the overlay in order to inflate the file\r\nsize. Using 00-byte padding allowed the PE file to be compressed from a sizes of over 500 MB to ZIP files less\r\nthan 1 MB:\r\n61bb1c8adaaffc629e60db7e4a171538c5d625a6d79d225e03310c684efd7581\r\nThis file contains a very large DLL inside with padding in the overlay. The sections end at the file end at\r\n0x9a200 .\r\nJunk data is appended past the defined end of the PE. Most of it being the null byte.\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 8 of 12\n\n99.9% of the file is padding. The padding in the overlay is not loaded to memory when the PE is executed. This\r\nallows it to take up less space in memory than it does on disk. \r\nResources\r\nThe resource section of a PE is used for many items that are used as resources by the binary, this can be things\r\nsuch as images, audio, icons, and videos, but it can be abused. Very commonly the padding is placed in the\r\nresource section of malware. An example of this being used is in phishing emails, sending ZIP files that contain a\r\nWindows Installer (MSI) file: \r\n34bcf0a864b6c7f4ecca92f1216ed58da4018c719552cfb62fee940924a91154\r\nThe MSI file is in Composite Document File V2 Document (CDF) format with an embedded DLL file that is\r\npadded using the resource section. The use of the CDF format also adds another layer of defense evasion that\r\nmight bypass security detections that only work on PE files. The DLL is padded in the resource section with a\r\nstream of repeating bytes. \r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 9 of 12\n\nThe MSI file is almost 500 MB but is able to be compressed to a size of around 2 MB, a huge reduction in size. \r\nSpace Between Sections\r\nSimilar to the overlay, malware authors can also play with the space between sections. Data can be inserted in\r\nbetween the sections of a PE to inflate the size. \r\nThis technique has been used by researchers in order to deceive malware classification.\r\nGiant Variable\r\nMalware authors can also use really large strings in order to pad malware in the data section. This technique is not\r\noften used as it can be easily detected, through looking for large strings. This technique involves simply creating\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 10 of 12\n\nextremely large strings in the code of the malware that are not used specifically for the functionality of the\r\nmalware itself. An example can be easily shown with a simple C program printing out very large strings.\r\nThese strings are stored in the data section of the PE. Since they are just sequences of repeating characters, they\r\nhave very little entropy, and can help with compression. The graph below shows the drop in entropy of where\r\nthese strings are stored. One issue that a threat actor might stumble into with this technique is that depending on\r\nthe compiler, there can be a limit on the maximum length of a string literal. This could force the threat actor to use\r\nmany smaller strings instead of one massive string for padding.\r\nCompressing this file in ZIP format will lead to a 64% deflation size. \r\nHow Intezer Fights Binary Padding\r\nBinary padding can be a simple and effective way to bypass security defenses, it is one technique out of many that\r\nare in a malware authors arsenal. This technique combined with other techniques, such as compression, can be\r\nchained to create innovative payloads that hinder analysis and detection. \r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 11 of 12\n\nIntezer is able to remove padding from samples to make it much more manageable to analyze. Take for example\r\nthis Laplas Clipper sample. It is padded to over 600 MB through using the overlay technique! Intezer is able to\r\nunpack the sample from the ZIP file and remove the overlay. Give it a go yourself with padded samples. Submit\r\nthe parent ZIP and Intezer will do the rest. \r\nSource: https://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nhttps://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://intezer.com/blog/research/how-hackers-use-binary-padding-to-outsmart-sandboxes/"
	],
	"report_names": [
		"how-hackers-use-binary-padding-to-outsmart-sandboxes"
	],
	"threat_actors": [
		{
			"id": "c4acd072-595e-4d33-9ce9-bbf41010bb1a",
			"created_at": "2023-01-06T13:46:38.751893Z",
			"updated_at": "2026-04-10T02:00:03.088252Z",
			"deleted_at": null,
			"main_name": "Orangeworm",
			"aliases": [],
			"source_name": "MISPGALAXY:Orangeworm",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3e0bc1b7-0dd7-444a-964b-64dfb5145c8f",
			"created_at": "2022-10-25T15:50:23.413202Z",
			"updated_at": "2026-04-10T02:00:05.388465Z",
			"deleted_at": null,
			"main_name": "Orangeworm",
			"aliases": [
				"Orangeworm"
			],
			"source_name": "MITRE:Orangeworm",
			"tools": [
				"Kwampirs",
				"netstat",
				"ipconfig",
				"cmd",
				"Arp",
				"Systeminfo"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "bbefc37d-475c-4d4d-b80b-7a55f896de82",
			"created_at": "2022-10-25T15:50:23.571783Z",
			"updated_at": "2026-04-10T02:00:05.302196Z",
			"deleted_at": null,
			"main_name": "BRONZE BUTLER",
			"aliases": [
				"BRONZE BUTLER",
				"REDBALDKNIGHT"
			],
			"source_name": "MITRE:BRONZE BUTLER",
			"tools": [
				"Mimikatz",
				"build_downer",
				"cmd",
				"ABK",
				"at",
				"BBK",
				"schtasks",
				"down_new",
				"Daserf",
				"ShadowPad",
				"Windows Credential Editor",
				"gsecdump"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf",
			"created_at": "2023-01-06T13:46:38.626906Z",
			"updated_at": "2026-04-10T02:00:03.043681Z",
			"deleted_at": null,
			"main_name": "Tick",
			"aliases": [
				"G0060",
				"Stalker Taurus",
				"PLA Unit 61419",
				"Swirl Typhoon",
				"Nian",
				"BRONZE BUTLER",
				"REDBALDKNIGHT",
				"STALKER PANDA"
			],
			"source_name": "MISPGALAXY:Tick",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "6a60b1ba-609f-4bed-b15b-3ffc050d2ac6",
			"created_at": "2022-10-25T16:07:24.033083Z",
			"updated_at": "2026-04-10T02:00:04.846068Z",
			"deleted_at": null,
			"main_name": "Orangeworm",
			"aliases": [
				"G0071"
			],
			"source_name": "ETDA:Orangeworm",
			"tools": [
				"Kwampirs",
				"LOLBAS",
				"LOLBins",
				"Living off the Land"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "54e55585-1025-49d2-9de8-90fc7a631f45",
			"created_at": "2025-08-07T02:03:24.563488Z",
			"updated_at": "2026-04-10T02:00:03.715427Z",
			"deleted_at": null,
			"main_name": "BRONZE BUTLER",
			"aliases": [
				"CTG-2006 ",
				"Daserf",
				"Stalker Panda ",
				"Swirl Typhoon ",
				"Tick "
			],
			"source_name": "Secureworks:BRONZE BUTLER",
			"tools": [
				"ABK",
				"BBK",
				"Casper",
				"DGet",
				"Daserf",
				"Datper",
				"Ghostdown",
				"Gofarer",
				"MSGet",
				"Mimikatz",
				"Netboy",
				"RarStar",
				"Screen Capture Tool",
				"ShadowPad",
				"ShadowPy",
				"T-SMB",
				"down_new",
				"gsecdump"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b",
			"created_at": "2022-10-25T16:07:23.419513Z",
			"updated_at": "2026-04-10T02:00:04.591062Z",
			"deleted_at": null,
			"main_name": "Bronze Butler",
			"aliases": [
				"Bronze Butler",
				"CTG-2006",
				"G0060",
				"Operation ENDTRADE",
				"RedBaldNight",
				"Stalker Panda",
				"Stalker Taurus",
				"Swirl Typhoon",
				"TEMP.Tick",
				"Tick"
			],
			"source_name": "ETDA:Bronze Butler",
			"tools": [
				"8.t Dropper",
				"8.t RTF exploit builder",
				"8t_dropper",
				"9002 RAT",
				"AngryRebel",
				"Blogspot",
				"Daserf",
				"Datper",
				"Elirks",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"HOMEUNIX",
				"HidraQ",
				"HomamDownloader",
				"Homux",
				"Hydraq",
				"Lilith",
				"Lilith RAT",
				"McRAT",
				"MdmBot",
				"Mimikatz",
				"Minzen",
				"Moudour",
				"Muirim",
				"Mydoor",
				"Nioupale",
				"PCRat",
				"POISONPLUG.SHADOW",
				"Roarur",
				"RoyalRoad",
				"ShadowPad Winnti",
				"ShadowWali",
				"ShadowWalker",
				"SymonLoader",
				"WCE",
				"Wali",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"XShellGhost",
				"XXMM",
				"gsecdump",
				"rarstar"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434805,
	"ts_updated_at": 1775792173,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d7abc1943c01d1c4321f23ac3350b2806b69ccfe.pdf",
		"text": "https://archive.orkl.eu/d7abc1943c01d1c4321f23ac3350b2806b69ccfe.txt",
		"img": "https://archive.orkl.eu/d7abc1943c01d1c4321f23ac3350b2806b69ccfe.jpg"
	}
}