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

91–100 of 111 posts

Re: Hackers use ZIP file concatenation to evade detection

#91

Post by rakoo »

notimetorelax wrote: post #72
MereInterest wrote: post #62

Earlier quoted context omitted.

Splitting the file doesn’t need to be part of the file format itself. I could split a file into N parts, then concatenate the parts together at a later time, regardless of what is actually in the file. The OP was saying that zip files can specify their own special type of splitting, done within the format itself, rather than operating on the raw bytes of a saved file.

Why would you use manual tools to achieve what ZIP archive can give you out of the box? E.g. if you do this manually you’d need to worry about file checksum to ensure you put it together correctly.

Because, as said before, zip managing splits ends with two sources of truth in the file format that can differ while the whole file still being valid

Re: Hackers use ZIP file concatenation to evade detection

#92

Post by rakoo »

TeMPOraL wrote: post #47
meehai wrote: post #42

Earlier quoted context omitted.

couldn't agree more! We need to separate and design modules as unitary as possible: - zip should ARCHIVE/COMPRESS, i.e. reduce the file size and create a single file from the file system point of view. The complexity should go in the compression algorithm. - Sharding/sending multiple coherent pieces of the same file (zip or not) is a different module and should be handled by specialized and agnostic protocols that do…

Well, 1) is zip with compression into single file, 2) is zip without compression into multiple files. You can also combine the two. And in all cases, you need a container format. The tasks are related enough that I don't really see the problem here.

The problem seems to be that each individual split part is valid in itself. This means that the entire file, with the central directory at the end, can diverge from each entry. This is the original issue.

Re: Hackers use ZIP file concatenation to evade detection

#93

Post by Jerrrrrrry »

Hendrikto wrote: post #57
seanhunter wrote: post #46

Earlier quoted context omitted.

> 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…

I did basically the same, to get some important CLI tools past the company firewall, just a few months back. Crazy that this is easier than dealing with the bullshit politics, to get some essentials tools to do my job. German public service is a joke. I quit since.

  >I quit since.
apparently they have too :)

Re: Hackers use ZIP file concatenation to evade detection

#94

Post by Twirrim »

MereInterest wrote: post #62
thrdbndndn wrote: post #58

Earlier quoted context omitted.

> or split the file Wait, I'm confused. Isn't this what OP was talking about?

Splitting the file doesn’t need to be part of the file format itself. I could split a file into N parts, then concatenate the parts together at a later time, regardless of what is actually in the file. The OP was saying that zip files can specify their own special type of splitting, done within the format itself, rather than operating on the raw bytes of a saved file.

> Splitting the file doesn’t need to be part of the file format itself. I could split a file into N parts, then concatenate the parts together at a later time, regardless of what is actually in the file.

I'm inclined to agree with you.

You can see good examples of this with the various multi-part upload APIs used by cloud object storage platforms like S3. There's nothing particularly fancy about it. Each part is individually retry-able, with checksumming of parts and the whole, so you get nice and reliable approaches.

On the *nix side, you can just run split over a file, to the desired size, and you can just cat all the parts together, super simple. It would be simple to have a CLI or full UI tool that would handle the pause between `cat`s as you swapped in and out various media, if we hark back to the zip archive across floppy disks days.

Re: Hackers use ZIP file concatenation to evade detection

#95

Post by Jerrrrrrry »

rocqua wrote: post #83
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.

Good compression should still be cryptographically distinguishable from true randomness right? Sure the various measures of entropy should be high, but I always just assumed that compression wouldn't pass almost any cryptographic randomness test.

not 'good' but maximum compression, yes.

Re: Hackers use ZIP file concatenation to evade detection

#96

Post by justsomehnguy »

hombre_fatal wrote: post #78
MereInterest wrote: post #62

Earlier quoted context omitted.

Splitting the file doesn’t need to be part of the file format itself. I could split a file into N parts, then concatenate the parts together at a later time, regardless of what is actually in the file. The OP was saying that zip files can specify their own special type of splitting, done within the format itself, rather than operating on the raw bytes of a saved file.

Without knowing the specifics of what's being talked about, I guess it makes sense that zip did that because the OS doesn't make it easy for the average user to concatenate files, and it would be hard to concatenate 10+ files in the right order. If you have to use a cli then it's not really a solution for most people, nor is it something I want to have to do anyways. The OS level solution might be a naming convention…

> the OS doesn't make it easy for the average user to concatenate files

Bwah! You are probably thinking too much GUI.

    X301 c:\Users\justsomehnguy>copy /?
    Copies one or more files to another location.

    COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/L] [/A | /B ] source [/A | /B]
         [+ source [/A | /B] [+ ...]] [destination [/A | /B]]

    [skipped]

    To append files, specify a single file for destination, but multiple files
    for source (using wildcards or file1+file2+file3 format).

Re: Hackers use ZIP file concatenation to evade detection

#97

Post by yapyap »

theoreticalmal wrote: post #21
avidiax wrote: post #3

This is sometimes used non-maliciously to concatenate zipped eBooks to a JPEG of the cover art. 4Chan's /lit/ board used to do this, but I can't find any reference to it anymore. https://entropymine.wordpress.com/2018/11/01/about-that-jpeg... https://github.com/Anti-Forensics/tucker

I think the reason it’s not used anymore is because it was used maliciously to share CSAM on other boards and 4chan banned uploading anything that looks like a concatenated zip

:/

Re: Hackers use ZIP file concatenation to evade detection

#98

Post by nh2 »

leni536 wrote: post #74
nh2 wrote: post #54

Earlier quoted context omitted.

Source what you're referring to / explanation? In ZIP, later info wins. I don't see how that isn't always streamable.

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 fundamentally incompatible to altering zip files by appending data, as the resulting file would not conform to this format.

My interpretation of the spec and specifically of 4.3.6 is that it is informational for how ZIP files usually look, and that you may store arbitrary data in between files; such data then doesn't count as "files". This reading then does allow appending and concatenation.

Unfortunately 4.3.6 does not have MUST/MAY wording so we don't really know if this reading was intended by the authors (maybe they clarify it in the future), but allowing this reading seems rather useful because it permits append-only modification of existing ZIP files. (The wording /'A ZIP file MUST have only one "end of central directory record"'/ suggests somehow that the authors didn't intend this, but again 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.)

Re: Hackers use ZIP file concatenation to evade detection

#99

Post by thrdbndndn »

justsomehnguy wrote: post #96
hombre_fatal wrote: post #78

Earlier quoted context omitted.

Without knowing the specifics of what's being talked about, I guess it makes sense that zip did that because the OS doesn't make it easy for the average user to concatenate files, and it would be hard to concatenate 10+ files in the right order. If you have to use a cli then it's not really a solution for most people, nor is it something I want to have to do anyways. The OS level solution might be a naming convention…

> the OS doesn't make it easy for the average user to concatenate files Bwah! You are probably thinking too much GUI. X301 c:\Users\justsomehnguy>copy /? Copies one or more files to another location. COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/L] [/A | /B ] source [/A | /B] [+ source [/A | /B] [+ ...]] [destination [/A | /B]] [skipped] To append files, specify a single file for destination, but multiple files for source (u…

Try to concatenate 1000 files with natural sorting names using `copy`. I did this regularly and I have to write a python script it make it easier.

It's much easier to just right click any of the zip part files and let 7-zip to unzip it, and it will tell me if any part is missing or corrupt.

Re: Hackers use ZIP file concatenation to evade detection

#100

Post by 47282847 »

avidiax wrote: post #3

This is sometimes used non-maliciously to concatenate zipped eBooks to a JPEG of the cover art. 4Chan's /lit/ board used to do this, but I can't find any reference to it anymore. https://entropymine.wordpress.com/2018/11/01/about-that-jpeg... https://github.com/Anti-Forensics/tucker

FYI, the blog post describes a zip file embedded in the ICC profile data of a JPEG in order to survive web image transformations, whereas the linked Tucker script is just appending the zip to the image.
Post reply on HN