Prev: What is this, (TR/Dldr.small.cml.7)
Next: Q on AdAwareSE
From: Virus Guy on 21 Apr 2006 21:53
"David H. Lipman" wrote:

> 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?
From: David H. Lipman on 22 Apr 2006 08:52
From: "Virus Guy" <Virus(a)Guy.com>

| "David H. Lipman" wrote:
|
>> 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?

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.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm


From: Adam Piggott on 22 Apr 2006 09:30
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David H. Lipman wrote:

> 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-----
From: Virus Guy on 22 Apr 2006 10:05
"David H. Lipman" wrote:

> 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.
From: kurt wismer on 22 Apr 2006 12:13
Adam Piggott wrote:
> David H. Lipman wrote:
>
>> 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.

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

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: What is this, (TR/Dldr.small.cml.7)
Next: Q on AdAwareSE