Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hackers use ZIP file concatenation to evade detection

bleepingcomputer.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Hackers use ZIP file concatenation to evade detection

#101

Post by exmadscientist »

PreInternet01 wrote: post #50
exmadscientist wrote: post #43

Earlier quoted context omitted.

That's fair, but do realize that sometimes people do have to send around archives from the last century (they got archived for a reason!) or created by eldritch-horror tools that just make weird files (which, sometimes, are the gold masters for certain very important outputs...). And it's kind of annoying when these weird but standard files get silently dropped. Especially when that same file went through just fine y…

Oh, nothing gets dropped silently, but bounced right back with `550 5.7.1 Message rejected due to content (Attachment refused: MATCH- code )`. And for anything oversized, funny or otherwise non-standard, we offer a very convenient file transfer service.

The right way to do it!

I wish our infrastructure had been so thoughtful.

Re: Hackers use ZIP file concatenation to evade detection

#102

Post by cxr »

nh2 wrote: post #9

WinRAR does it right, 7zip and Windows Explorer do it wrong according to https://en.m.wikipedia.org/wiki/ZIP_(file_format) > only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives)

The article says that WinRAR "displays both ZIP structures", so, no, it doesn't do it right. Of the three, only Windows Explorer is close to the correct behavior (showing the contents of the ZIP that was appended closest to the end, and ignoring everything else). The exception to its correctness is that they report it may fail to process the ZIP and identify it as being corrupt, which shouldn't happen so long as the endmost ZIP is well-formed.

Re: Hackers use ZIP file concatenation to evade detection

#103

Post by cxr »

nh2 wrote: post #98
leni536 wrote: post #74

Earlier quoted context omitted.

Hmm, it appears that you are right. I vaguely remembered that zip was streamable, but it appears that it only means that it's stream writable, as in you can write zip file contents from a datastream of unknown size, and append the checksum and file size later in the zip file stream. However such a zip file is definitely not stream readable, as the local file header no longer contains the size of the following file da…

Good observations! Indeed: ZIP files are stream-writable, and some ZIP files are stream-readable, but not both: ZIP files that were stream-written are not steam-readable. Also, steaming unzipping always requires that by the time you arrive at the central directory, you delete so-far-unzipped files that don't have entries in it, as those were "deleted". > Then in 4.3.6 it describes the file format, which seems to be f…

> Unfortunately 4.3.6 does not have MUST/MAY wording so we don't really know if this reading was intended by the authors

It's not explicit from the APPNOTE, but that's not the same as saying "we don't really know". We do know—islands of opaque data are allowed and that's the entire reason the format is designed the way it is. Katz designed ZIP for use on machines with floppy drives, and append-only modification of archives spanning multiple media was therefore baked into the scheme from the very roots. He also an produced an implementation that we happen to be able to check, and we know it works that way.

The only way to arrive at another interpretation is to look at APPNOTE in isolation and devoid of context.

> one could argue that this is not necessarily to state, that there is only one EOCDR by definition, and that any previous ones are just garbage data that is to be ignored

That is the correct interpretation; the wording doesn't suggest otherwise.

Re: Hackers use ZIP file concatenation to evade detection

#104

Post by tjoff »

Spivak wrote: post #37
canucker2016 wrote: post #26

Earlier quoted context omitted.

I don't think you understand the reason for the ZIP archive file design. Back in the late 1980s, backup media for consumers was limited to mostly floppy disks, some users had tape/another hard disk. Say you had a variable number of files to compress and write out to a ZIP archive. IF you write out the central directory first, followed by all the individually possibly compressed and/or encrypted files, you'd have to c…

The more general principle is that single source of truth is not ideal for data storage where you're worried about corruption. There's a backup MBR on your hard disk at the end, your ext4 filesystem has many backups of your superblock. When it comes to user data the natural programmer instinct for "is exactly what I expect or fail" which is typically good design, falls to pragmatism where try your hardest to not lose…

Having a backup copy isn't quite the same thing though. It is just a copy of the single source of truth. Not a different implementation or used for a different use case. Also trivial to verify.

Re: Hackers use ZIP file concatenation to evade detection

#105

Post by nh2 »

cxr wrote: post #102
nh2 wrote: post #9

WinRAR does it right, 7zip and Windows Explorer do it wrong according to https://en.m.wikipedia.org/wiki/ZIP_(file_format) > only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives)

The article says that WinRAR "displays both ZIP structures", so, no, it doesn't do it right. Of the three, only Windows Explorer is close to the correct behavior (showing the contents of the ZIP that was appended closest to the end, and ignoring everything else). The exception to its correctness is that they report it may fail to process the ZIP and identify it as being corrupt, which shouldn't happen so long as the…

> The article says that WinRAR "displays both ZIP structures", so, no, it doesn't do it right.

That would be true, but the bleepingcomputer article seems to be misquoting that fact.

The original research they reference (which I also find to be a more sensible article),

https://perception-point.io/blog/evasive-concatenated-zip-tr...

says that WinRAR only shows they last archive contents, and shows a screenshot of that:

> WinRAR, on the other hand, reads the second central directory and displays the contents of the second archive

Re: Hackers use ZIP file concatenation to evade detection

#106

Post by alkonaut »

rocqua wrote: post #84
alkonaut wrote: post #63

Why do scanners need to look inside compressed archives at all? If the malicious file is extracted, it can be detected then. If it’s not extracted and instead used directly from the archive, then the offending code that executes malicious payloads from inside archives should be detectable? Is that the role of AutoIt in this scenario?

Because they want to check on the wire, before it hits an endpoint. Common situation is detecting malware sent through a phishing mail. You want to intercept those before a user can unpack the file.

Yes that was my question: "why, do you want to do that when it sounds like a futile job to do?"

If you have any kind of transformation (whatever trivial ROT or XOR) of the payload then there is no chance of detecting it via pattern matching, and if you need a "program" to process it into its malicious form, then how does detection work?

I understand you want to keep malicious payload from reaching endpoints in a form that would risk being consumed (malformed documents, images causing buffer overflows, executable and script files). But beyond that?

Re: Hackers use ZIP file concatenation to evade detection

#107

Post by spintin »

wahern wrote: post #10

From a security perspective, and as a programmer, I've never liked ZIP files precisely because there are two mechanisms to identify the contents, the per-file header and the central directory. When you're defining a format, protocol, or w'ever, ideally there should be a single source of truth, a single valid & useable parse, etc; basically, the structure of the data or process should be intrinsically constraining. Th…

[dead]

Re: Hackers use ZIP file concatenation to evade detection

#108

Post by cxr »

nh2 wrote: post #105
cxr wrote: post #102

Earlier quoted context omitted.

The article says that WinRAR "displays both ZIP structures", so, no, it doesn't do it right. Of the three, only Windows Explorer is close to the correct behavior (showing the contents of the ZIP that was appended closest to the end, and ignoring everything else). The exception to its correctness is that they report it may fail to process the ZIP and identify it as being corrupt, which shouldn't happen so long as the…

> The article says that WinRAR "displays both ZIP structures", so, no, it doesn't do it right. That would be true, but the bleepingcomputer article seems to be misquoting that fact. The original research they reference (which I also find to be a more sensible article), https://perception-point.io/blog/evasive-concatenated-zip-tr... says that WinRAR only shows they last archive contents, and shows a screenshot of that…

Thanks, that's a much better article (and published on a site that, while slightly annoying on its own, is infested with fewer rudely intrusive and resource-consuming ads).

Reading both, it's clear that (a) you are correct, and (b) the submitted link, besides being materially inaccurate, is shameless reblog spam and should be changed.

Re: Hackers use ZIP file concatenation to evade detection

#109

Post by cxr »

immibis wrote: post #76
poincaredisk wrote: post #65

Earlier quoted context omitted.

>there are two mechanisms to identify the contents, the per-file header and the central directory There is only one right, standard mandated, way to identify the contents (central directory). For one or another reason many implementations ignore it, but I don't think it's fair to say that the zip format in ambiguous.

Sometimes you want to read the file front-to-back in a streaming fashion.

That doesn't change anything wrt what the parent commenter said.

Imagine—

Officer: The reason why I pulled you over is that you were doing 45, but this is a 25 mph school zone right now, and even aside from that the posted speed when this is not a school zone is only 35. So you shouldn't be going faster than that, like you were just now.

Motorist: But sometimes you want to go faster than that.

Re: Hackers use ZIP file concatenation to evade detection

#110

Post by Jerrrrrrry »

seanhunter wrote: post #46
Jerrrrrrry wrote: post #25

Remember, secure encryption, good compression, and truely random data are indistinguishable. It's best to paste that encrypted payload into a JPG with some bullshit magic headers and upload that to a trusted Exfil pivot instead. Or, to get SuperMarioKart.rom to work with your chromeApp-XEMU emulator to play during down-time at work, just rename it to SMB.png, and email it you yourself.

> Remember, secure encryption, good compression, and truely random data are indistinguishable. Yes, and the only reason the bad guys get away with this is the people who trust signature-based scanning at the perimeter to detect all threats. One of the hacks I'm most proud of in my whole career was when we were doing a proof of concept at an enterprise client we were being deliberately obstructed by the internal IT gr…

  >This almost worked, but I found that the first chunk was always failing to transmit through the firewall
Magic numbers/header scanning or, if it was awhile back, BOM (byte order mark) messing stuff up.
Post reply on HN