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

61–70 of 111 posts

Re: Hackers use ZIP file concatenation to evade detection

#61

Post by cogman10 »

telgareith wrote: post #32
cogman10 wrote: post #7

Earlier quoted context omitted.

Would probably still work. There's just too many formats which makes it very hard for a content blocker to really stop. I pity the programmer that has to decode the 1000 versions of xls to find the binary blob that could be a virus.

1000? No. There's two. Openxml and the original xls. OpenXML can be scanned for issues like any other XML file. Alas, it's more difficult to get excel to accept that it shouldn't delete leading zeros than it is to check a spreadsheet's sus-o-scale.

1000 is an over exaggeration, but it is not just 2 standards.

xls morphed with every version of Microsoft Excel. MS Excel has pretty good backwards compatibility, but making an xls parser is notoriously hard because of the many differences between versions.

Re: Hackers use ZIP file concatenation to evade detection

#62

Post by MereInterest »

thrdbndndn wrote: post #58
rakoo wrote: post #40

Earlier quoted context omitted.

That's a very bad way of solving that issue. If transmission is a problem, either use a proper retry-friendly protocol (such as bittorrent) or split the file. Using hacks on the data format just leads to additional pain

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

Re: Hackers use ZIP file concatenation to evade detection

#63

Post by alkonaut »

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?

Re: Hackers use ZIP file concatenation to evade detection

#64

Post by murderfs »

meehai wrote: post #42
rakoo wrote: post #40

Earlier quoted context omitted.

That's a very bad way of solving that issue. If transmission is a problem, either use a proper retry-friendly protocol (such as bittorrent) or split the file. Using hacks on the data format just leads to additional pain

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…

Why do you believe that archiving and compressing belong in the same layer more than sharding does? The unixy tool isn't zip, it's tar | gzip.

Re: Hackers use ZIP file concatenation to evade detection

#65

Post by poincaredisk »

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…

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

Re: Hackers use ZIP file concatenation to evade detection

#66

Post by kd5bjo »

meehai wrote: post #48
TeMPOraL wrote: post #47

Earlier quoted context omitted.

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.

I meant that they should be separate tools that can be piped together. For example: you have 1 directory of many files (1Gb in total) `zip out.zip dir/` This results in a single out.zip file that is, let's say 500Mb (1:2 compression) If you want to shard it, you have a separate tool, let's call it `shard` that works on any type of byte streams: `shard -I out.zip -O out_shards/ --shard_size 100Mb` This results in `out…

The key thing that you get by integrating the two tools is the ability to more easily extract a single file from a multipart archive— Instead of having to reconstruct the entire file, you can look in the part/diskette with the index to find out which other part/diskette you need to use to get at the file you want.

Re: Hackers use ZIP file concatenation to evade detection

#67

Post by trollbridge »

tedk-42 wrote: post #22
_pdp_ wrote: post #15

This attack vector has been known for at least 17 years, if not longer. https://gnucitizen.org/blog/java-jar-attacks-and-features/ https://gnucitizen.org/blog/gifars-and-other-issues/

I'm with you. I've evaded all sorts of scanning tools by base64 encoding data (i.e. binary data) to and copy pasting the text from insecure to highly secured environments. At the end of the day, these malware databases rely on hashing and detecting for known bad hashes and there are lots of command line tools to help get over that sort of thing like zip/tar etc.

I used to have a workflow for updating code inside a very highly secure environment that relied on exactly this:

Run build of prior version, run build of current version, run diff against them, compress with xz -9, base64 encode, generate output, base64 encode, e-mail it to myself, copy text of email, type "openssl base64 -d | unxz | bash", right click.

E-mailing this was completely fine according to the stringent security protocols but e-mailing a zip of the code, etc. was absolutely 100% not. That would have to go on the vendor's formal portal.

(Eventually I just opened my own "portal" to upload binaries to, put the vendor I worked for's logo on it, and issued a statement saying it was an official place to download binaries from the vendor. But sometimes their WAF would still mangle downloads or flag them as a risk, so I made sure builds had options of coming in an obfuscated base64 format.)

Re: Hackers use ZIP file concatenation to evade detection

#68

Post by edflsafoiewq »

murderfs wrote: post #64
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…

Why do you believe that archiving and compressing belong in the same layer more than sharding does? The unixy tool isn't zip, it's tar | gzip.

tar|gzip does not allow random access to files. You have to decompress the whole tarball (up to the file you want).

Re: Hackers use ZIP file concatenation to evade detection

#69

Post by _0xdd »

rakoo wrote: post #40
thrdbndndn wrote: post #33

Earlier quoted context omitted.

Still useful today. Try to transmit a 100G file through any service is usually a pain especially if one end has non-stable Internet.

That's a very bad way of solving that issue. If transmission is a problem, either use a proper retry-friendly protocol (such as bittorrent) or split the file. Using hacks on the data format just leads to additional pain

I've had good luck using tools like piping large files through `mbuffer`[1] such as ZFS snapshots, and it's worked like a charm.

[1] https://man.freebsd.org/cgi/man.cgi?query=mbuffer&sektion=1&...

Re: Hackers use ZIP file concatenation to evade detection

#70

Post by nwellinghoff »

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…

You could have just done ssh reverse shell to a public jump server you control? Might have been easier.
Post reply on HN