{
	"id": "734716a8-a532-4047-a98c-f7f712da584e",
	"created_at": "2026-04-06T00:11:14.947542Z",
	"updated_at": "2026-04-10T13:12:40.554665Z",
	"deleted_at": null,
	"sha1_hash": "b6e82d429d7d226a54178e8b97e0b4294551bb2b",
	"title": "Commodity .NET Packers Uses Steganography Payloads | Proofpoint US",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2153453,
	"plain_text": "Commodity .NET Packers Uses Steganography Payloads | Proofpoint US\r\nBy December 07, 2020 Proofpoint Threat Research Team\r\nPublished: 2020-12-02 · Archived: 2026-04-05 16:48:18 UTC\r\nMost malware is distributed in \"packed\" form: typically an executable containing code to evade antivirus detection and\r\nsandboxes before extracting and executing the intended payload. \r\nThere are many commodity packers written in Microsoft .NET, usually but not always containing malware also written in\r\n.NET. \r\nWe discuss two prevalent such packers used to distribute a wide variety of malware but hiding the intended payload in\r\nimages. \r\nSteganography \r\nSteganography is the technique of sending hidden messages in apparently innocent forms. For hiding data in images, the\r\nmain techniques are: \r\nStore the hidden data at the end of an image file \r\nStore the hidden data within the image metadata (e.g., EXIF) \r\nStore the hidden data within the actual pixel data \r\nTo be truly \"hidden\" the latter would arguably mean using only the least significant bits of the data so that the image appears\r\n\"normal\" when rendered. \r\nThe packers discussed here generally use the entire image pixel data so aren't truly \"hidden\"; if they were displayed, the\r\nimages would appear random. \r\n \"CyaX\" packer \r\nIn this packer, the .NET executable contains a square PNG image in a .NET resource, which is typically a large proportion\r\nof the whole file size. \r\nThe image can be decoded to an intermediate executable, which contains a .NET resource which in turn can be decoded to\r\nthe payload. Sometimes the intermediate executable uses an additional commodity packer such as ConfuserEx or .NET\r\nReactor.  \r\nDetails \r\nThe first stage payload is decoded from the Blue, Green, Red, and Alpha (BGRA) channels taking pixels in columns. Some\r\nversions use Red, Green, and Blue (RGB) channels instead. \r\nFor example, in sample SHA256 - 026b38e8eb0e4f505dc5601246143e7e77bbd2630b91df50622e7a14e0728675: \r\nFigure 1: Image taken from sample SHA256: 026b38e8eb0e4f505dc5601246143e7e77bbd2630b91df50622e7a14e0728675 \r\nUsing channels BGRA from the image we get data starting: \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 1 of 10\n\nIn general, the extracted data is then XORed with a short XOR key or the first 16 bytes of the data\r\nand possibly decompressed with gzip, yielding an intermediate stage .NET executable.    \r\nFor the above sample, the XOR key is (in hex) \"74 43 74 17 74 02 74 23 74\", which gives the executable: \r\n \r\nThis intermediate stage is often itself packed with ConfuserEx, but after unpacking that, it contains a .NET resource which\r\ncontains the payload, typically XORed with two keys:, a short (often truncated Unicode) one, followed by a 16-byte key\r\nstored at the start of the resulting file. \r\nIn the above sample, the intermediate executable is packed with .NET Reactor. After deobfuscation with a tool such\r\nas de4dot, the deobfuscated executable contains a resource \"2EJp1.resources\" which starts: \r\n \r\nXORing with key \"00 77 00 55 00 6c 00 59 00 71 00 79 00 4e\" (\"wUlYqyNZJIbjVN\" in Unicode, truncated to half the\r\nlength): \r\n \r\n  and then XORing with the first 16 bytes of the result gives the payload, Agent Tesla (a prevalent information stealer) in this\r\ncase: \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 2 of 10\n\nIn some early versions of this packer, this .NET resource was named \"CyaX_Sharp.Properties.Resources.resources\" hence\r\nthe name we have given to this packer family. \r\nGzip variant \r\nAs mentioned above, some samples use the Red, Green, and Blue (RGB) channels, and some compress the intermediate\r\nexecutable with gzip. \r\nFor example, in sample SHA256 - 083521fa4522245adc968b1b7dd18da29b193fd41572114c9d7dd927918234ea:   \r\nFigure 2: Image taken from sample SHA256: \r\n083521fa4522245adc968b1b7dd18da29b193fd41572114c9d7dd927918234ea \r\nthe image uses RGB channels which decode to: \r\n  \r\nXORing with key (in hex) \"24 04 33\" gives:\r\n \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 3 of 10\n\nwhich is a 4-byte DWORD containing the uncompressed file size, followed by a gzip-ed file, starting with a 10-\r\nbyte gzip header, which decompresses to the intermediate .NET executable: \r\n  \r\n  This contains a .NET resource \"d2o6x4FhIdl.resources\" starting: \r\n \r\nwhich when XORed with keys \"00 66 00 43 00 73 00 6b 00 62 00 67 00\" (\"fCskbgkLbLArI\" in Unicode,\r\ntruncated) and then \"07 2e 8c d5 50 23 1b e3  be be 38 4f 0f 4b 8d ca\" gives:\r\n \r\nwhich contains the payload, Agent Tesla again.\r\nSteganographic variant  \r\nIn a recent variation of this packer, the first stage payload is actually stored in a second PNG image extracted from the least\r\nsignificant bits of the Red, Green, and Blue channels in the first image, taking pixels in rows (so \"proper\" steganography in\r\nthis case). The intermediate stage .NET executable is then extracted from the Blue, Green, Red, and Alpha channels of the\r\nsecond image with pixels taken in columns, without XOR this time. \r\nFor example, in sample SHA256 – 04794ec7e7eb5c6611aada660fb1716a91e01503fb4703c7d2f2099c089c9017:  \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 4 of 10\n\nFigure 3: Image taken from sample SHA256:  04794ec7e7eb5c6611aada660fb1716a91e01503fb4703c7d2f2099c089c9017 \r\nthe image has RGB channels and, taking pixels by rows first rather than columns, leads to: \r\n \r\n(There is also an Alpha channel, with all values set to 0xff.) \r\nTaking groups of 8 bytes and then the least significant bits in reverse order gives us (for example \"ff 01 00 ff 01 00 fe 01\" -\u003e\r\n\"10011011\" -\u003e 0x9b): \r\n \r\nThis is a file size stored in a DWORD (0x1e09b) followed by the second PNG image. Using BGRA and columns first, this\r\ndecodes to:  \r\n \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 5 of 10\n\nwhich contains a .NET resource \"biGzxmYEphCl\": \r\n  \r\nwhich when XORed with \"4c 00 6b 00 74 00 79 00 54 00 65 00 66 00 65 00\" (\"LktyTefe\" in Unicode): \r\n \r\ngives the payload, which in this case is Remcos RAT. \r\n\"Hectobmp\" packer \r\nIn this packer, the .NET executable contains typically several hundred small images in .NET resources, which each contain a\r\npart of the payload and need to be reassembled in the correct order. \r\nEarlier versions used the BMP file format, and later versions have switched to using PNG. The name we have given to this\r\npacker comes from \"hecto-\" from the metric system prefix for a hundred. \r\nDetails \r\n \r\nFigure 4: .NET resources list (from ILSpy) \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 6 of 10\n\nFor example, in sample SHA256 – 0091c6bdceecf3e0143b4eaaefca1cd56cbfdfc55f99c167f9dd1f3a48928bb5: \r\n \r\nFigure 5: First image taken from sample SHA256:\r\n0091c6bdceecf3e0143b4eaaefca1cd56cbfdfc55f99c167f9dd1f3a48928bb5 \r\nwhich contains 135 images, the first image decodes, using Green, Red and Blue channels, rows first, to: \r\n \r\nThis includes the start of a Windows executable.\r\nThe size of the chunk extracted from each image is stored in the first four bytes (DWORD), 0x30d in this case, less 15, and\r\nthe required chunk of data starts at the 6th byte. \r\nThe chunks need to be assembled in numerical order of the resource names, which is different from the alphabetical order\r\nthey appear in the file which is: \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 7 of 10\n\nand the order they are referenced in the .NET metadata which is: \r\n \r\n  The reassembled payload in this case is Loki Bot Stealer. \r\nIn the following sample, SHA256 – 09c8cbd9cdfda1fcb7c6a051887213dc3e3ccf00a5877eca3d3e374f077b98d5, the images\r\nare BMPs and the first one looks like: \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 8 of 10\n\nFigure 6: Image taken from sample SHA256: 09c8cbd9cdfda1fcb7c6a051887213dc3e3ccf00a5877eca3d3e374f077b98d5 \r\nThe image decodes to the following, with chunk size highlighted in green, chunk data highlighted in yellow and blue: \r\n \r\nIn this case, when assembled from the images, the payload is compressed using zlib Deflate, starting at byte\r\n0xb0, highlighted in blue. \r\nDecompressing gives: \r\nwhich again is Agent Tesla in this case. \r\nConclusion \r\nGenerally, packers have different features that allow them to circumvent detection mechanisms by appearing as benign files,\r\nbeing difficult to reverse engineer, or incorporating sandbox evasion techniques. In this blog we've looked at two packers\r\nwhich use embedded images to hide the payload, one using a single image and the other using hundreds of them. These are\r\njust a few of the many tools threat actors have at their disposal to aid in distributing malware, collecting sensitive\r\ninformation, and gaining unauthorized access to systems.  \r\nIOCs  \r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 9 of 10\n\nIOC  Type  Description \r\n026b38e8eb0e4f505dc5601246143e7e77bbd2630b91df50622e7a14e0728675  SHA256  CyaX PNG sample with channels BGRA \r\nc8c79ba04ab76c96db913f05b4b5bab36e7e0148fd72148df170a4be94d879a3  SHA256 \r\nAgent Tesla payload in\r\n026b38e8eb0e4f505dc5601246143e7e77bbd2630b91df\r\n083521fa4522245adc968b1b7dd18da29b193fd41572114c9d7dd927918234ea  SHA256  CyaX PNG sample with gzipped data \r\na6f7edd2654412c25d7c565cb5b52e1382799a8b86d6bc44e965b554f6344618  SHA256 \r\nAgent Tesla payload in\r\n083521fa4522245adc968b1b7dd18da29b193fd4157211\r\n04794ec7e7eb5c6611aada660fb1716a91e01503fb4703c7d2f2099c089c9017  SHA256  CyaX PNG sample with double steganography \r\n6d9c861bf6f1495a4bddc7c745eb5b504692b4d6eae31e89453f0829760b1b90  SHA256 \r\nRemcos RAT payload in\r\n04794ec7e7eb5c6611aada660fb1716a91e01503fb4703c\r\n0091c6bdceecf3e0143b4eaaefca1cd56cbfdfc55f99c167f9dd1f3a48928bb5  SHA256  Hectobmp sample with PNGs \r\n1180c158968faaf0a4951e9a0c59996f0fb29cdad9443aa2097efb5bc7f123f4  SHA256 \r\nLoki Bot payload in\r\n0091c6bdceecf3e0143b4eaaefca1cd56cbfdfc55f99c167f\r\n09c8cbd9cdfda1fcb7c6a051887213dc3e3ccf00a5877eca3d3e374f077b98d5  SHA256  Hectobmp sample with BMPs \r\nc3b85d8291281d73cfdd8373cb2b32cdc4c3a602233f99ab3cbbd34bd4e3c99b  SHA256 \r\nAgent Tesla payload in\r\n09c8cbd9cdfda1fcb7c6a051887213dc3e3ccf00a5877eca\r\nReferences \r\nDe4dot  \r\nILSpy  \r\nAgent Tesla: A day in a life of IR, Full description of an Agent Tesla campaign using CyaX packer (steganographic variant) \r\nSource: https://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nhttps://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.proofpoint.com/us/blog/threat-insight/commodity-net-packers-use-embedded-images-hide-payloads"
	],
	"report_names": [
		"commodity-net-packers-use-embedded-images-hide-payloads"
	],
	"threat_actors": [],
	"ts_created_at": 1775434274,
	"ts_updated_at": 1775826760,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b6e82d429d7d226a54178e8b97e0b4294551bb2b.pdf",
		"text": "https://archive.orkl.eu/b6e82d429d7d226a54178e8b97e0b4294551bb2b.txt",
		"img": "https://archive.orkl.eu/b6e82d429d7d226a54178e8b97e0b4294551bb2b.jpg"
	}
}