Re: Different packing = different scan results (remember Zlob posts?)

"Virus Guy" wrote:

The file is 71,456 bytes, and is UPX packed. It has a digital
signature of "KAS NET" according to the file properties.

When unpacked with UPX: http://upx.sourceforge.net, the resulting file
is 83,232 bytes and has no digital signature attribute. Previous
scanning by Jotti had indicated that this file was packed with
PE_PATCH and UPACK.

Hmmmm -- the file at that URL doesn't match that description. I get
69,776 and 81,552 bytes unpacked...

<<snip>>
The following detected something ONLY in the original (packed) file:

AntiVir: TR/Dldr.Zlob.HQ.1
Avira: TR/Dldr.Zlob.HQ.1
BitDefender: Trojan.Downloader.Zlob.HQ
Ikarus: Trojan.Favadd
Panda: Suspicious file

Probably because that (and possibly other packed forms) was the only one
they had received samples of...

The following detected the same thing in BOTH files:

Fortinet: W32/Zlob.LJ!dldr
Kaspersky: Trojan-Downloader.Win32.Zlob.lj
NOD32v2: Win32/TrojanDownloader.Zlob.LD
VBA32: Trojan-Downloader.Win32.Zlob.lj

Because their engines do UPX and/or generic decompression (if they do UPX
they probably also do the same for other common/popular packers, but that
doesn't really matter here).

Note that there is no over-lap between the above 2 groups in the
name/identifier used, but there is considerable similarity within the
groups. For example AntiVir, Avira and BitDefender use the term
"Zlob.HQ", while Fortinet, Kaspersky, and VBA32 use "Zlob.LJ".

This is normal virus naming inconsistency -- nothing to take from it at
all apart from the fact that the AV developers can't agree on a way to
standardize malware names...

Conclusions:

1) Many hi-profile AV software is not detecting any threat in these
files. Either they are deficient, or the files are clean and
this is a false alarm.

You missed at least one option -- your understanding of how popular AV
software works is deficient...

Known virus/malware scanning technology requires that the developer or
maintainer of such software gets and analyses samples of new viruses/
malware so as to add detection (and possibly cleanup) to their product.

You found a new-ish malware that not everyone has received a sample of
or has not yet had time to add detection of (or has, but has not yet
shipped its detection update, or Jotti and Virus Total have not picked
up that update yet).

This happens all the time. Many dozens to hundreds of times a day now,
in fact...

If that is deficient it is because the whole model is deficient, not
because any given product is. Most days I see multiple new malware files
that are missed by some or all of the scanners you say detected one or
both forms of this malware, and yet are detected by some of the scanners
you say detected neither form of this. By your rationale above, these
files mean we should also say that the scanners you suggest the above
data shows are not inadequate, are in fact, inadequate by your own
standard.

And, I'm sure I only need look back less than 24 hours to find an example
of (what was then) a new malware file that NOT ONE of the products you
listed detected at all (even in their most false-positive-prone extra,
ultra heuristics mode _AND_ in some cases even with pre-release, beta and
pre-beta (current lab build) DAT/DEF/etc files).

So they're all deficient if we are to apply your reasoning...

2) The AV software that signaled a positive detection only in the
first (packed) file but not the unpacked file must not have
the ability to unpack PE_Patch and /or UPACK'd files, and the
only thing that can account for their positive detection of the
first file is that they are relying on MD5 (or equivalent) hash.

Not for the full file...

Hashing-like approaches across partial file blocks for certian file
locations are used in most/all products for identifying (some) static
malware files, but no decent product uses full-file hashing for a plethora
of reasons I'll not bore you with.


--
Nick FitzGerald


.