Submitted via IRC for soylent_aqua
Specially Crafted ZIP Files Used to Bypass Secure Email Gateways
Attackers are always looking for new tricks to distribute malware without them being detected by antivirus scanners and secure email gateways. This was illustrated in a new phishing campaign that utilized a specially crafted ZIP file that was designed to bypass secure email gateways to distribute the NanoCore RAT.
Every ZIP archive contains a special structure that contains the compressed data and information about the compressed files. Each ZIP archive also contains a single "End of Central Directory” (EOCD) record, which is used to indicate the end of the archive structure.
In a new spam campaign discovered by Trustwave, researchers encountered a spam email pretending to be shipping information from an Export Operation Specialist of USCO Logistics.
Attached to this email was a ZIP archive named SHIPPING_MX00034900_PL_INV_pdf.zip that looked suspicious as its file size was greater than its uncompressed content.
"The attachment “SHIPPING_MX00034900_PL_INV_pdf.zip“ makes this message stand out," Trustwave stated in a report. "The ZIP file had a file size significantly greater than that of its uncompressed content. Typically, the size of the ZIP file should be less than the uncompressed content or, in some cases, ZIP files will grow larger than the original files by a reasonable number of bytes."
When examining the file, the Trustwave researchers discovered that the ZIP archive contained two distinct archive structures, each marked by their own EOCD record.
This is illustrated by the file opened in 010 Editor, which shows two different ZIDENDLOCATOR structures.
Related Stories
Hans Wennborg does a deep dive into the history and evolution of the Zip compression format and underlying algorithms in a blog post. While this lossless compression format became popular around three decades ago, it has its roots in the 1950s and 1970s. Notably, as a result of the "Arc Wars" of the 1980s, hitting BBS users hard, the Zip format was dedicated to the public domain from the start. The main work of the Zip format is performed through use of Lempel-Ziv compression (LZ77) and Huffman coding.
I have been curious about data compression and the Zip file format in particular for a long time. At some point I decided to address that by learning how it works and writing my own Zip program. The implementation turned into an exciting programming exercise; there is great pleasure to be had from creating a well oiled machine that takes data apart, jumbles its bits into a more efficient representation, and puts it all back together again. Hopefully it is interesting to read about too.
This article explains how the Zip file format and its compression scheme work in great detail: LZ77 compression, Huffman coding, Deflate and all. It tells some of the history, and provides a reasonably efficient example implementation written from scratch in C. The source code is available in hwzip-1.0.zip.
Previously:
Specially Crafted ZIP Files Used to Bypass Secure Email Gateways (2019)
Which Compression Format to Use for Archiving? (2019)
The Math Trick Behind MP3s, JPEGs, and Homer Simpson's Face (2019)
Ask Soylent: Internet-communication Archival System (2014)
(Score: 0) by Anonymous Coward on Wednesday November 13 2019, @04:24PM
automated idiot/intrusion detection system checks first header, sees nothing, and marks file as safe.
either that, or their packaging script has a subtle bug...
One more trick for infecting the victims that scan incoming email by some idiotic automated tool.
(Score: 1, Informative) by Anonymous Coward on Wednesday November 13 2019, @08:39PM
This is a great illustration of the two different ways to extract a zip archive.
The easiest way to do it is to seek all the way to the end of the archive and then back up in chunks looking for the central directory and its magic number Once you find it, you already have all the information needed to extract the files, so you can seek to the start of the first file found using the offset in the CD and extract away by iterating all the file entries you have in memory from the CD.
The alternative way is to iterate through the local file headers that are in front of each file and contain the information necessary to extract that file. After you extract a file, you'll be at the start of the next file header and can repeat the process. You are done when you hit the CD entry marking the end.
I can see their thinking here. They probably thought most end-user tools would use the easier process, and therefore extract the malicious payload, because the archive would already have been deemed safe and it makes GUIs and everything else easier. Security tools, which also have to deal with limited space and memory, don't display contents in a GUI, and malicious payloads (like the more common malicious CD where multiple entries point to the same offset) were assumed to just iterate through the archive and would miss the malicious payload after stopping at the EOCD. If someone really wanted to dive into this, they could look up what each of the standard libraries do.
(Score: 0) by Anonymous Coward on Thursday November 14 2019, @01:25PM
Ok, but if you have a second archive that no one can access... how does the malware work.
Your trying to make me RTFA aren't you.
So, I was mostly right, with a few exceptions, the zip will not unpack the Trojan and most archival tools will flag the file as bad/broken.
This seems like a technique that will be filtered for quickly*, and not actually affect too many people.