{ "id": "5b4762b7-294b-4f4e-99c5-d8dbd9cffb2c", "created_at": "2026-04-06T00:06:48.251498Z", "updated_at": "2026-04-10T13:11:58.958269Z", "deleted_at": null, "sha1_hash": "bf2ba1eab3c3caf436b986170988782cec11c299", "title": "{\"®eve®se\": \"Enginee®ing\"}", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 346092, "plain_text": "{\"®eve®se\": \"Enginee®ing\"}\r\nPublished: 2021-01-18 · Archived: 2026-04-05 16:29:06 UTC\r\n In this past few days I stumble to some new and old variant of ICEID malware that uses .png steganography to hide\r\nand execute its encrypted shellcode. In this article I will share how the structure of the Iceid png payload look like\r\nand how to extract its encrypted shellcode.\r\nLoader Compression:\r\nsame as the other malware, IceID Loader changes its Crypter to execute its main module in memory. From old\r\nvariant where the encrypted code stub and decryption module is place in the RSRC section as a data .rsrc entry (RC4\r\nencrypted) to applib compression like the figure below.\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 1 of 8\n\nfigure 1: The aplib decompressed module of ICEID\r\nPNG Header:\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 2 of 8\n\nBefore we deal with the ICEID PNG steganography, I think it is a good idea to have some preview what PNG file\r\nheader format is. It will give as a clear preview how ICEID parse the .PNG header and look for its encrypted\r\nshellcode.\r\nThe PNG file format started with 8-bytes signature header \"89 50 4e 47 0d 0a 1a 0a\". after this header is a chunk\r\nstructure or series of chunk structures that contains either a \"critical chunks\" like \"IHDR\", \"IDAT\" and etc... or\r\n\"Ancillary chunks\" that may contain some attribute related to the color, pixel or metadata of the png file like\r\n\"sRGB\", \"gAMA\" and many more.\r\neach PNG chunks layout consist of 4 parts or 4 structure member. the figure below show the 4 parts in IHDR chunk\r\ntype.\r\nfigure 2: PNG File header Format\r\nICEID PNG Module Decryptor:\r\nNow that we have some insight how PNG file format look like, lets dive in to the ICEID PNG decryptor module\r\n(\"let's call it PNG module\") that we already extracted earlier in the memory. This part is really interesting\r\nespecially in parsing the header. :)\r\nThe PNG module start by executing a thread that will do the following:\r\n1. decrypt its data section (C\u0026C url link) using same approach how it decrypt the shellcode in PNG payload file.\r\n2. it will check the existence of the PNG file in %appdata%\u003crandomname\u003e/, if not\r\n3.  it will try to download it to its C\u0026C server\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 3 of 8\n\n4. then it will parse and check the png file to extract and execute its shellcode.\r\nThe first task is decrypting the C\u0026C server URL link that are place in data section that are encrypted in RC4\r\nalgorithm. the structure of data it used in decrypting this data section can be seen before a call  function that will do\r\nthe decryption part.\r\nfigure 3: Encrypted Data Structure\r\nThe first 8 bytes of the encrypted data section is the RC4 key and the rest is the encrypted data.\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 4 of 8\n\nfigure 4: decrypting C\u0026C server URL link\r\nNext it will create a random name folder in %appdata% using the \"username\" of the infected machine. \r\nwith the use of RDTSC command to generate random character. If the module didn't find the png payload in the said\r\nfolder it will try to contact the C\u0026C server to download it.\r\nfigure 5: looking for the PNG payload file\r\nParsing PNG Header:\r\nafter reading the PNG and save it in the memory, it will start the checking in offset 0x8 (skipping the PNG header)\r\nwhich is the \"chunk_data_length\" of the first chunk type in the header which in our case is \"IHDR\". The way how it\r\nparse the header to look for \"IDAT\" chunk_type structure is by adding:\r\nnext_chunk_type_struct = size(chunk_data) + chunk_data_length (4 bytes) + chunk_type (4byes) +\r\nchunk_crc32 (4 bytes)\r\nexcept for the start chunk_type structure where you need to include or add the PNG header size which 8 bytes.\r\nfor this topic, I created a simple python script that will parse this header and give you the basic information about the\r\nheader. it also parse the chunk_data but I place it in the debug.log of this script.\r\nfigure 6: parsing the header\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 5 of 8\n\nByte Flag and Decryption Key:\r\nas soon as it found the IDAT chunk_type structure it will check first if the chunk_data_length \u003e 5 then it will skip\r\nthe chunk_data_length , chunk_type and chunk_crc32 by adding 0x0c to the current pointer of the \"IDAT\" chunk\r\nheader. the byte in this position looks like a validity flag of the PNG. If this byte is zero, the PNG module will check\r\nanother value which is one of the parameter to the function that parse the png header which is also zero, so in this\r\ncase it will exit the flag. \r\nfigure 7: byte flag\r\nafter this byte is the 8 byte RC4 decryption key followed by the encrypted shellcode using this RC4 key. the python\r\nscript I mentioned earlier will parse the RC4 key, extract the shellcode and check the shellcode header and entrypoint\r\nby dis-assembling it using capstone python library.\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 6 of 8\n\nfigure 8: script tool parser\r\nConclusion:\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 7 of 8\n\nIn this analysis we learned how PNG file can be used as a weapon to hide the malicious code and how malware\r\nkeeps on updating their tools to bypassed detection.\r\nAlso thanks to the community for sharing the samples :)\r\nSamples:\r\nsha1: 9a07f8513844e7d3f96c99024fffe6e891338424\r\nsha1: 1ab6006621c354649217a011cd7ca8eb357c3db4\r\nsha1: c1faa9cb4aa7779028008375e7932051ee786a52\r\nsha1: 481bc0cbdcae1cd40b70b93388bf4086781b44b4\r\nhttps://www.virustotal.com/gui/file/45520a22cdf580f091ae46c45be318c3bb4d3e41d161ba8326a2e29f30c025d4/details\r\nhttps://www.virustotal.com/gui/file/e6e0adcc94c3c4979ea1659c7125a11aa7cdabe24a36f63bfe1f2aeee2c5d3a1/detection\r\nhttps://www.virustotal.com/gui/file/cc1030c4c7486f5295444acb205fa9c9947ad41427b6b181d74e7e5fe4e6f8a9/details\r\nhttps://www.virustotal.com/gui/file/f6ea81aaf9a07e24a82b07254a8ed4fcf63d5a8e6ea7b57062f4c5baf9ef8bf2/detection\r\nReferences:\r\nhttps://en.wikipedia.org/wiki/Portable_Network_Graphics\r\nhttp://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/12/new-version-of-icedid-trojan-uses-steganographic-payloads/\r\nhttps://www.malware-traffic-analysis.net/2020/12/11/index.html\r\nSource: https://tccontre.blogspot.com/2021/01/\r\nhttps://tccontre.blogspot.com/2021/01/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://tccontre.blogspot.com/2021/01/" ], "report_names": [ "01" ], "threat_actors": [], "ts_created_at": 1775434008, "ts_updated_at": 1775826718, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/bf2ba1eab3c3caf436b986170988782cec11c299.pdf", "text": "https://archive.orkl.eu/bf2ba1eab3c3caf436b986170988782cec11c299.txt", "img": "https://archive.orkl.eu/bf2ba1eab3c3caf436b986170988782cec11c299.jpg" } }