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

[Virus Guy]

The file in question was located here:

http://www.media-codec.com /v4 /mediacodec-v4.143.exe

It is still available at that location.

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.

In any case, I submitted both the original file (71kb) and the
UPX-unpacked version (83kb) to the now-working Virus Total website.

The following AV software found nothing in both files:

Avast, AVG, Cat, Clam, DrWeb, E-trust Inoculate, E-trust-vet, Ewido
F-prot, McAfee, Norman, Sophos, Symantec, TheHacker, UNA

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

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

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

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.

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.

 

[Nick FitzGerald]

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

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.

 

[Virus Guy]

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

Well isin't that interesting.

I just downloaded it (I assumed it was a static file) but I get this:

April 21 8:40 am:

Packed (as down-loaded): 70,672 bytes
Unpacked (with UPX): 82,448 bytes

On April 14 (10 am) I got 71,456 and 83,232 bytes

Virus Total is currently NOT RESPONDING at all, so I'm not able to run
the new versions to see what they contain.

The website www.media-codec.com seems designed to just deliver these
files - practically no content on the site about who or what they
(media-codec.com) is.

------------
Domain Name: MEDIA-CODEC.COM

Registrant:
Lemos Adamantios
([email protected])
aktis 119, vouliagmeni
athens, GR

Creation Date: 08-Apr-2006
Expiration Date: 08-Apr-2007
------------

The domain was registered very recently.

The domain "securitywarnings.net" is suspect:

------------
Domain Name: SECURITYWARNINGS.NET

Registrant:
Mag Dicacik
(****@sexpicsporn.com)
P.O Box 3728 Praha
4749 CZ

Creation Date: 14-Nov-2005
Expiration Date: 14-Nov-2006
------------

Sexpicsporn.com?

The ip address for www.media-codec.com resolves to 85.255.116.252,
which seems to be located in the Ukraine.

I think it's a no-brainer that www.media-codec.com is designed
specifically to deliver the trojan Zlob.

Group 1: (detection only in original packed file)

Group 2: (detection in both packed and unpacked file)

This is normal virus naming inconsistency -- nothing to take from
it at all

I'm fully aware that different names are frequently given to the same
malware by the AV vendors.

In this case, we have basically 2 different names or variants: HQ and
LJ.

But what are the odds that the 2 names would be split along the lines
of the groupings listed above?

That would indicate some commonality or cooperation within:

Group 1: AntiVir, Avira, BitDefender

Group 2: Fortinet, Kaspersky, Nod32, VBA32

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

Please provide some additional backup or clarity for that statement.

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.

Of that I am well aware, and made no claim to the contrary.

You found a new-ish malware ...

This happens all the time.

Naturally, every piece of malware is "new" at least once in it's
life. The fact that some AV software is detecting Zlob and others
aren't provides a strong basis to say that some AV software IS
deficient (in this case) in their ability to gather, analyze, and
include new malware in their detection inventory.

If that is deficient it is because the whole model is deficient,
not because any given product is.

Oh, I see now. I touched a nerve because your favorite AV software
was among the group that didn't detect the malware (or perhaps it
detected Zlob only in the packed file?).

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.

AV software is inadequate if it signals a positive detection in a
packed or compressed version of a malware sample, but signals a
negative detection when the file is unpacked.

For example, if someone downloads and installs the above zlob file,
and during the course of installation the trojan deletes it's own
compressed archive, then AV software that signals a positive detection
on the compressed archive will naturally NOT detect the presence of
the infection because the original archive is no longer present.
Most people would be pissed if that's how their AV software behaved.

And, I'm sure I only need look back less than 24 hours ...

What bug got up your ass?

Face it. Some AV software is better than others, some are faster than
others at incorporating new detections, and some can signal a positive
detection no matter how many ways the file is packed or unpacked.

 

[Art]

The file in question was located here:

http://www.media-codec.com /v4 /mediacodec-v4.143.exe

It is still available at that location.

All I can find at that site (from all four d/l links) is v4.107 and
it's clean according to KAV.

Art

http://home.epix.net/~artnpeg

 

[Adam Piggott]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The file in question was located here:

http://www.media-codec.com /v4 /mediacodec-v4.143.exe

It is still available at that location.

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

(Mostly in response to your first conclusion of it being a false positive
and/or clean)

It's certificate has been revoked by Thawte, probably a sign it's malware.
That domain name as well as that of the domain's email contact are also on
the block list of my web filtering service so either I've come across it in
my travels or it's present in the publicly-available block lists that I use.
Also of note is that the domain is registered with estdomains which are
currently very popular for malware sites.

The Ecodec and Vcodec "brands" have been in use by malware pushers for a
while now - I believe that they may be installed via exploits or other
malware - so this is likely to be a sibling.

- From the install's EULA:
"SOFTWARE INSTALLATION: Components bundled with our software may report to
Licensor and/or its affiliates the installation status of certain marketing
offers, such as toolbars, and also generalized installation information,
such as language preference and operating system version, to assist
Licensor in its product development. No personal information will be
communicated to MEDIA-CODEC or its affiliates during this process. Licensor
may change homepage on user's computer and may offer additional components
through our version of checking/update system. These components include:
toolbar, popup ads manager, advertisements messenger, pc protection
software, shortcuts manager."

On my Windows 2000 testing system the installer does seem to create
ecodec.exe but then deletes it, leaving only an uninstaller. With a bit of
jiggery-pokery I managed to get at the ecodec.exe file and run it.
Hey-presto it just deletes itself as well! *shrug*

Adam Piggott, Proprietor, Proactive Services (Computing).
http://www.proactiveservices.co.uk/

Please replace dot invalid with dot uk to email me.
Apply personally for PGP public key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)

iD8DBQFESQQO7uRVdtPsXDkRAsgDAJ4/mMEVWDw6nzXRG+HILT8KZW1bHgCeJnx/
APprSZ9WZs9vkkU3tw8LOpM=
=9g0/
-----END PGP SIGNATURE-----

 

[David H. Lipman]

From: "Virus Guy" <[email protected]>

|
| The file in question was located here:
|
| http://www.media-codec.com /v4 /mediacodec-v4.143.exe
|
| It is still available at that location.
|
| 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.
|
| In any case, I submitted both the original file (71kb) and the
| UPX-unpacked version (83kb) to the now-working Virus Total website.
|
| The following AV software found nothing in both files:
|
| Avast, AVG, Cat, Clam, DrWeb, E-trust Inoculate, E-trust-vet, Ewido
| F-prot, McAfee, Norman, Sophos, Symantec, TheHacker, UNA
|
| 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
|
| 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
|
| 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".
|
| 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.
|
| 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.

That site is auto-generating new variants of the ZLob Trojan on a regular and periodic
bassis.

A SpyBot technician had examined that site and wrote to me...

"i checked the site, and the samples are autogenerate like a cronjob (see the filedate). "

---<result>----
15.04.2006 01:18 71.376 mediacodec-v4.104.exe
15.04.2006 01:18 71.376 mediacodec-v4.105.exe
15.04.2006 01:18 71.376 mediacodec-v4.106.exe
15.04.2006 01:18 71.376 mediacodec-v4.107.exe
15.04.2006 01:18 71.376 mediacodec-v4.108.exe
15.04.2006 01:18 71.376 mediacodec-v4.109.exe
15.04.2006 01:18 71.376 mediacodec-v4.110.exe
15.04.2006 01:18 71.376 mediacodec-v4.111.exe
15.04.2006 01:18 71.376 mediacodec-v4.112.exe
15.04.2006 01:18 71.376 mediacodec-v4.113.exe
15.04.2006 01:19 71.376 mediacodec-v4.114.exe
15.04.2006 01:19 71.376 mediacodec-v4.115.exe
15.04.2006 01:19 71.376 mediacodec-v4.116.exe
15.04.2006 01:19 71.376 mediacodec-v4.117.exe
15.04.2006 01:19 71.376 mediacodec-v4.118.exe
15.04.2006 01:19 71.376 mediacodec-v4.119.exe
15.04.2006 01:19 71.376 mediacodec-v4.120.exe
15.04.2006 01:19 71.376 mediacodec-v4.121.exe
15.04.2006 01:19 71.376 mediacodec-v4.122.exe
15.04.2006 01:19 71.376 mediacodec-v4.123.exe
15.04.2006 01:19 71.376 mediacodec-v4.124.exe
15.04.2006 01:19 71.376 mediacodec-v4.125.exe
15.04.2006 01:19 71.376 mediacodec-v4.126.exe
15.04.2006 01:19 71.376 mediacodec-v4.127.exe
15.04.2006 01:19 71.376 mediacodec-v4.128.exe
15.04.2006 01:19 71.376 mediacodec-v4.129.exe
15.04.2006 01:19 71.376 mediacodec-v4.130.exe
15.04.2006 01:19 71.376 mediacodec-v4.131.exe
15.04.2006 01:19 71.376 mediacodec-v4.132.exe

< snip >

--<result md5>---
a0f2654035e785828dd43fe05c131b02 mediacodec-v4.104.exe
b144037dbf6003bca3c9514ac8c32108 mediacodec-v4.105.exe
c647cd66e383003061b509b50cc64b95 mediacodec-v4.106.exe
edc9a96f130df95ddae39e4fb0005f42 mediacodec-v4.107.exe
8a3d804f951716dbaa4ef195a870e1ae mediacodec-v4.108.exe
da0b16632851b54625638ec561ef2f15 mediacodec-v4.109.exe

< snip >

 

[Virus Guy]

That site is auto-generating new variants of the ZLob Trojan on
a regular and periodic bassis.

Dave - what do you make of the differential detection of a threat
within this file by the various AV vendors when the file and it's
UPX-unpacked equivalent is scanned by them?

 

[David H. Lipman]

From: "Virus Guy" <[email protected]>

| "David H. Lipman" wrote:
||
| Dave - what do you make of the differential detection of a threat
| within this file by the various AV vendors when the file and it's
| UPX-unpacked equivalent is scanned by them?

Often new variants of an infector are just repacked versions of a previous version. What
the AV comapnies use to create signatures is unknow but with some a re-packed infector needs
new signatures. In some cases like kaspersky the AV software will unpack the file and then
scan the file.

In this case I am not enlightened in what is being done with the generateion of all these
new variants. It also seems strange to me that they can autogenerate so many variants so
easily that there is something so different in them that makes the new variants undetectable
when there must be something so common about them that the AV signatures should be focused
on their commonality instead.

 

[Adam Piggott]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In this case I am not enlightened in what is being done with the generateion of all these
new variants. It also seems strange to me that they can autogenerate so many variants so
easily that there is something so different in them that makes the new variants undetectable
when there must be something so common about them that the AV signatures should be focused
on their commonality instead.

I believe that a lot of them are UPX packed and the contents encrypted
which makes extraction without execution extremely difficult, if feasible
at all. All they need to do is encrypt the original content with a
different hash each time and voilà, a very different file with the same
contents. Set up a cron job and you can pump out variants as fast as you
can upload them!

Signature-based detections fall flat on their face here I think (unless you
just go straight for any packed encrypted content), which is why heuristics
like NOD32's method of executing the content in a sandbox is the way to go.


Adam Piggott, Proprietor, Proactive Services (Computing).
http://www.proactiveservices.co.uk/

Please replace dot invalid with dot uk to email me.
Apply personally for PGP public key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)

iD8DBQFESjAG7uRVdtPsXDkRAvknAKCHBUBtUBMzHZksm3UfuD9oYl9yBwCeKA98
yLJh0kC5UMYKGH4KJoFVqu8=
=KPaB
-----END PGP SIGNATURE-----

 

[Virus Guy]

Often new variants of an infector are just repacked versions
of a previous version.

Yes, and that is my point.

AV software needs to fully unpack a suspect file to get to the root
files that need to be scanned. Any AV software that can't perform a
UPX unpack isin't worth a pinch of salt.

In the current situation, when I obtained a second copy of the
media-codec file and submitted both the original and the upx-unpacked
version, I see that:

a) Kaspersky, NOD, and VBA id's the original file as ZLOB.LZ (fortinet
and panda calls it "suspicious").

b) Only Kaspersky and NOD id's the UPX-unpacked version as ZLOB.LZ.
(and fortinet calls it suspicious).

Note that VBA detected ZLOB in the original but NOT the unpacked file.

To change the subject slightly, note that the varient name has changed
from ZLOB.HQ to ZLOB.LZ (was there enough of a change in the infector
to warrant changing the varient name - especially if the infector is
machine-generated?)

Only Kaspersky and NOD have shown that they can detect this infector
reliably across different versions of the source file (also regardless
of packed or unpacked).

It's time for AV software to list the types of unpacking they are
capable of as part of their performance specs, as we are now in the
age of dynamic packing designed to throw off AV software that uses MD5
hashes of the external delivery package.

 

[kurt wismer]

I believe that a lot of them are UPX packed and the contents encrypted
which makes extraction without execution extremely difficult, if feasible
at all. All they need to do is encrypt the original content with a
different hash each time and voilà, a very different file with the same
contents. Set up a cron job and you can pump out variants as fast as you
can upload them!

Signature-based detections fall flat on their face here I think (unless you
just go straight for any packed encrypted content), which is why heuristics
like NOD32's method of executing the content in a sandbox is the way to go.

those encrypted samples have to decrypt themselves in order to operate
properly, and to do that the decryption key has to be included in the
file... it used to be that scanners would employ code emulation to deal
polymorphism and metamorphism... it should be possible to use the same
technology here...

 

[Art]

All I can find at that site (from all four d/l links) is v4.107 and
it's clean according to KAV.

Hah! Today, the v.4.107.exe is flagged by KAV as
Trojan-Downloader.Win32.Zlob.ma

Art
http://home.epix.net/~artnpeg

 

[Virus Guy]

Hah! Today, the v.4.107.exe is flagged by KAV as
Trojan-Downloader.Win32.Zlob.ma

Yes, I see that one of the samples I DL'd previously (and was detected
as .LZ by Kaspersky, NOD and VBA) is now being id'd as .ma by
Kaspersky (?).

Also, Dr. Web is now id'ing that file as "Trojan.Popuper", which is
strange since it appears that 2 months ago Dr. Web was giving a
similar ID to what others were calling ADSPY/CashDeluxe.

I went to Google to see what other pages are making references to
"media-codec.com".

I found a dead link, but the cached version is still functional:

http://72.14.203.104/
search?q=cache:88N3twzb8CQJ:www.videosgalleries.com/mr/mixed/s1g1/movie3.php%3Fbgcolor%3DFFAD16%26border%3DAC2601%26id%3D620++%22www.media-codec.com+%22&hl=en&gl=ca&ct=clnk&cd=5

(take out the space to make it functional).

The page displays something with an orange background, then tries to
dl our famous mediacodec friend (version 620 in this case).

The website triggering this behaviour is:

http://www.videosgalleries.com

Which is blocked by the MVPS hosts file.

It's clear now that anyone mentioning that they recently DL'd a codec
to watch something (and the codec DL seems to be the trigger point for
computer misbehaviour) was undoubtedly visiting a porn site, and the
user was intending to watch a porn video. There are plenty of
indications that that's how this infector is delivered - not through
searching the web for codecs.

------------
Domain Name: VIDEOSGALLERIES.COM
Registration Service Provided By: ESTDOMAINS
Contact: +1.3027224217

Website: http://www.estdomains.com

Registrant:
Mag Dicacik ****@sexpicsporn.com)
P.O Box 3728
Praha null,4749 CZ
Tel. +420.484020829504

Creation Date: 11-Nov-2005
Expiration Date: 11-Nov-2006
--------------

Again there's the reference to the domain "sexpicsporn.com"

Note that there are other domains that are behaving the same way (some
of which are are not being blocked by MVPS):

5starvideos.com
mybestthumbs.com
wowfuck.com