Prev: MVPS hosts file - web page
Next: Discount Wholesale G-STAR Jeans <free shipping paypal payment>
From: FromTheRafters on 29 Jul 2010 19:34
"Lars Uffmann" <aral(a)nurfuerspam.de> wrote in message
news:8bap23Fd65U1(a)mid.dfncis.de...
> Hey everyone!
>
> Struck with nostalgia, I wanted to download all the messagemates at
> http://www.screenmates.com/archives.htm
> recently, and I discovered some new ones (and not all of the old ones
> :(

I used to have this one, I renamed it rundll32.exe and put it in the
system directory on my W98 machine.

http://www.processlist.com/info/esheep.html

There were several versions out at that time - none of them legit, but
some weren't modified from the Village Center Inc original.


From: Ant on 29 Jul 2010 19:42
"VanguardLH" wrote:

> I see nothing in Ant's or David's response that proves this file is not
> infected or malware. Running through a debugger means looking at the
> code as it currently chooses to execute. If the malware is currently
> quiescent (i.e., it is dormant), the code won't proceed into the block
> containing the malware. It may get triggered by some event later. Ant
> did not claim to analyze all the code (unless that what was meant by
> "file structure") but just traced its execution using a debugger as it
> happened to run that time on his host.

The file I downloaded (DeathwishDog.exe) is a standard GUI application
written in MS VC++ 5.0 with the usual message processing loop. I
inspected the file strucure and content in a PE editor, the code in a
disassembler and there's nothing suspicious about it. I'm very used to
analysing malware/infected files and I know the signs. I also ran it
under a debugger with suitable breakpoints on API functions (e.g. for
accessing the registry, file system & network) and no unexpected calls
were made. I also single-stepped enough of the code to see there were
no special checks to call what might be otherwise dormant malicious
routines.

However, there are command line parameters which cause it to behave
differently.

If run with the argument "-1 filename", where filename is any file
name, it will copy itself to that file (overwiting if it exists) and
run that file with the arguement "-2 [path]\DeathwishDog.exe". The
new process, with the new argument, then deletes DeathwishDog.exe and
exits. So the effect of all that is simply to move it to a new file.

If the file names are missing (with -1 or -2) or it can't delete the
file it sits in an infinite loop! That's bad programming.

Also note that it only creates the file mmates.ini if you tell it to
visit the website and it creates DeskToppers.ini (both saved in the
windows directory) only if you customise the settings. It also has the
abillity to interact with other screenmates/messagemates applications.


From: Ant on 29 Jul 2010 20:32
"Ant" wrote:

> If run with the argument "-1 filename", where filename is any file
> name, it will copy itself to that file (overwiting if it exists) and
> run that file with the arguement "-2 [path]\DeathwishDog.exe". The
> new process, with the new argument, then deletes DeathwishDog.exe and
> exits. So the effect of all that is simply to move it to a new file.
>
> If the file names are missing (with -1 or -2) or it can't delete the
> file it sits in an infinite loop! That's bad programming.

Correction: If the name is missing with -1 it creates a garbage name
and uses that. I'm sure I found another case where it loops but can't
reproduce it now.


From: Lars Uffmann on 2 Aug 2010 03:48
On 07/29/2010 07:11 PM, VanguardLH wrote:
>> Otoh we already kinda know it's a false positive thanks to Ant, and
>> David also found it reported by AntiVir...
>
> Why was it a "false" positive if you find another highly regarded AV
> program also alerting on the same suspect file?

That was two separate statements, as marked by the "and" linking them,
as opposed to a "because".

> code as it currently chooses to execute. If the malware is currently
> quiescent (i.e., it is dormant), the code won't proceed into the block
> containing the malware. It may get triggered by some event later. Ant
> did not claim to analyze all the code (unless that what was meant by
> "file structure") but just traced its execution using a debugger as it
> happened to run that time on his host.

Of course you are right in that there is no "proof" that this file is
harmless, however it being detected as JOKE/DeathWish by some AV
software is a strong indicator. And we already debated the likeliness of
various cases earlier in the thread, which you clearly didn't read, or
deliberately chose to ignore.

> be a false positive but not likely after 19 days later for when the
> malware's signature was added to several AV programs and when more than
> one AV program issues an alert.

Wrong. Your statement would mean that false positives are hardly ever
kept in signature files and just as seldomly are propagated from one AV
software to others.

> What's so special about this 3rd party executable that you MUST have it?

It's called nostalgia, if you live in a world of "musts" and "must nots"
then you have my pity.

> datestamp is irrelevant because, one, you are downloading the file and
> will get a new timestamp and, two, the timestamp can be altered using
> the touch or other similar command to alter that file attribute.

Thanks for the lesson on file timestamps. Had you read my initial post,
you could have saved the energy that went into typing though.

> Sandboxes aren't perfect. [..] The user then moves the malware to their non-sandboxed
> environment and then the malware engages. Sandboxes are just more
> software and it is still possible to leak outside of a sandbox.

You clearly fail at listening/reading. Again. In the environment I
described, there is no reason to move most software out of a sandboxed
environment, because the software runs in such by default and for good
reasons without implications on the usability. And "sandboxes aren't
perfect" is a useless statement: it is neither true nor false, it is
simply a statement with no applicability. No bigger piece of software
can be perfect, if only for the fact that there are different approaches
to the same solution. However, that also applies to AV software. That
is, anyways, no reason to not consider applying a different philosophy
to operating systems and execution of third party software.

> A little old but still applicable. I also watched a recorded seminar
> where the speaker showed many principles possible (by malware) to detect
> if running in a virtualized environment and also how to leak out of it.

So you watch webcasts and think you're an expert, eh? I much preferred
the useful responses of everyone else on the thread.

> The locks on your house doors and perhaps a siren alarm (and maybe even
> connected to a security service) is probably all you use to protect your
> home [..] Well, all that is possible but it's not
> reasonable or feasible for most of us.

You clearly have too much time on your hands... And...

> I don't really want to get into a lengthy discussion [..] I just wanted to express my
> opinion this one time.

You failed on this first point.

> My original intent was only to address your
> concern about the suspect file and that it appears more than one
> anti-virus program is alerting on it and to ponder why you really think
> you need this file which looks to be non-critical and perhaps not even
> really that important.

And you should have stuck to this.

Thanks for taking your time, but I seriously don't feel like reading
through a novel (of dubious relevance at best) when simply trying to
find out whether or not a certain malware detection is a false positive.

Cheers,

Lars
First  |  Prev  | 
Pages: 1 2 3
Prev: MVPS hosts file - web page
Next: Discount Wholesale G-STAR Jeans <free shipping paypal payment>