Trojan horse Downloader.Generic.ML

[Art]

It is a good idea for scanners to completely ignore
extensions and determine filetypes by their internal structure - but
this adds too much scanning time I suppose.

Not terribly long ago, F-Prot for DOS started using internal structure
by default. I haven't checked, but I've been sort of ASSuming that
internal structure basis is being used quite commonly now with av
scanners. Something to look into.

Art

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

 

[Roger Wilco]

Are you visiting Neverland? That file REALLY IS a trojan.

It really is "detected" as a trojan - doesn't mean it is one. How can
you execute it as is? It may be something that can be made executable
(Qbasic/run c:\null if it were a qbasic program) but as is what harm is
it? Do you want a program that detects everything that can be made into
something threatening? Text files (like the QBASIC program)? This post
maybe?

Deltree /y c:\windows

I could easily write a batch file that makes part of this post's content
into an executable deltree trojan. Sorry if this causes FP's for some
people reading this post - but this post is not a deltree trojan despite
what scanners may think.

And A2 confirmed
that. And it's detection
seems to have been triggered by some I/O to c:\null from left field. Maybe
something penetrated my Belkin wireless router and then ZA?

Hmmm - penetrated? -- invited in more likely.

OR maybe
somebody close has broken my 26 hex char WEP key and come in that way. OR
maybe there is still some undetected infection that happened to trigger at
that moment the spawning of the real trojan c:\null.

You are the one in Neverland (whatever that means).

 

[Zvi Netiv]

Are you visiting Neverland? That file REALLY IS a trojan. And A2 confirmed
that.

Relax, the file isn't a real Trojan nor a Trojan at all (just code fragments of
what may have been part of anything else, like an installer, or attempted
malware) and it isn't the first time that several AV are in "agreement" on a
false positive, nor the last.

And it's detection
seems to have been triggered by some I/O to c:\null from left field.

On-access AV intercept CreateFile calls in ring 0. Not every call initiates
file verification, only those with the "correct" parameters as set by the AV
designer (and sometimes by user option settings). Viewing a directory by
Explorer, for example, is all that is needed to initiate the AV to check files
that display with their own icon, as the file is opened by Explorer for reading
the icon resource.

Maybe
something penetrated my Belkin wireless router and then ZA? OR maybe
somebody close has broken my 26 hex char WEP key and come in that way. OR
maybe there is still some undetected infection that happened to trigger at
that moment the spawning of the real trojan c:\null.

Your on-access defense won't detect the uploading of anything, not even a "real"
virus or Trojan, in real time, when done from a remote PC. The reason is that
there is no meat to chew on for the AV at the time the destination file is
inspected. Here is what happens, step by step: A call to initiate a file
transfer is sent from remote. The local file system responds by creating a
local file and opens it for output. This is the cue for the AV to intervene,
take control and inspect the file just opened. Obviously, the AV will find
nothing as nothing was yet transferred. Control is then returned to the
interrupted process and the transfer will happily resume. If you asked yourself
how come that systems get infected under the nose of AV with the very last
definitions, then here is your answer.

IMO, the date AVG first flagged the NULL file isn't the date that file was
created.

Lastly, the NULL file isn't benign from its content. But it isn't the real
thing either, and you are tormenting yourself for no good reason, on a wild
goose chase.

Regards, Zvi

 

[Zvi Netiv]

[...]
That file may be a malware related file, but it itself is not malware
(it is not executable and as such is not a threat) and any scanner that
detects it as such is wrong (but some would do so purposefully to get
better scores in AV comparative tests - like detecting boot sector
viruses in "files" like .bak backup files..

Based on the NULL sample inspection:

The file has a PE structure (Mark Zbikowsky's marker, 16 bit EXE stub, PE
extended header and sections) but it isn't directly executable. Which doesn't
mean much as many non-executable objects used in Windows have that structure,
like font files, to mention one example.

It could be malware related, but it could be anything else just the same.

The only way it could be
executable is if it is an OLE2 filetype (.doc) that has been renamed
extensionless. It is a good idea for scanners to completely ignore
extensions and determine filetypes by their internal structure - but
this adds too much scanning time I suppose.

Most scanners have the option to scan "all files", regardless of their extension
name. Generally, it's a bad idea to scan all files as it increases both false
alarms and scan time.

As for on-access AV, I wouldn't recommend it checking all files, under no
circumstances.

Regards, Zvi

 

[Zvi Netiv]

Ron Reaugh wrote:

[snip the rest of the integrity checker discussion]

A url or two please.

google on "integrity checker" and you'll find plenty... back in the day
(before windows) i rather liked integrity master and advanced disk
infoscope... i just did a status check on them (i *neglect* to use
integrity checkers myself, but there are mitigating circumstances there)
and although integrity master doesn't seem to be handling current file
systems all that cleanly, adinf (http://www.adinf.com) seems to have
been kept sufficiently up to date to be usable on xp...

What prevented Integrity Master, and checkers in the same category (e.g. CRC,
MD5, etc.), from becoming widely used in AV, are the following reasons:

1. Plain integrity ("plain" here refers to the processing of the entire file,
not to the method used) is useless for AV purposes as it's unable to
discriminate between legitimate changes and malware related changes.

2. Integrity records obtained by IM and its likes were useless in restoring
modified objects to their original state. This last capability is now less
important due to the complexity in restoring 32 bit objects from an "integrity
signature" (the size of the signature required for that is prohibitively large),
but was cardinal in the days of DOS.

The above reasoning was adopted by the AV industry soon after the 1991 AV
Products Developers conference held in Washington D.C., where I first presented
the AV adapted integrity checker *and restorer* concept. The idea were soon
implemented in products such as in NAV's "inoculation", Eliashim's PIC (now
Aladin's), Thunderbyte Tbsetup/Tbclean, and in others.

Today, *real-time* integrity monitoring is successfully implemented in
InVircible's Interceptor (see www.invircible.com/item/81 ).

Regards, Zvi

 

[Kevin Reiter]

seems to have been triggered by some I/O to c:\null from left field. Maybe
something penetrated my Belkin wireless router and then ZA? OR maybe
somebody close has broken my 26 hex char WEP key and come in that way. OR
maybe there is still some undetected infection that happened to trigger at
that moment the spawning of the real trojan c:\null.

WEP keys can be cracked in minutes now...

Just perform a forensics analysis on the drive and load another drive.
That (loading a new drive, not the analysis) would've taken less time than
all the back and forth flames and insults within this thread that haven't
really solved anything.

If you can duplicate it, then document it and contact some companies and
pass on the info. Examine the c:\null file yourself to see what the
content is, and then make your own call on what exactly it is, based on
the content (if possible.)

And Belkin routers aren't the world's greatest, and neither is ZA as far
as firewalls go. It's entirely possible that something managed to get
past both of them, especially if it was invited from the inside.

Then again, just is just my .02 on this thread, which I will now be
ignoring, since it isn't contributing to anything except more insults.


-Kevin
(All flames/insults will be forwarded to /dev/null)

 

[kurt wismer]

Zvi Netiv wrote:
[snip]

What prevented Integrity Master, and checkers in the same category (e.g. CRC,
MD5, etc.), from becoming widely used in AV, are the following reasons:

1. Plain integrity ("plain" here refers to the processing of the entire file,
not to the method used) is useless for AV purposes as it's unable to
discriminate between legitimate changes and malware related changes.

as malware can make arbitrary changes, processing the entire file is
required... if you're only worried about parasitic infection then sure,
for some types of files you may only need to check a subset of the
entire file, but integrity checkers aren't *just* for detecting that
sort of thing...

of course we've had this disagreement for a good long time now... you
feel integrity checkers should behave like your product but your product
has been highly specialized/optimized for detecting infection... plain
integrity checkers detect a broader range of changes and, correctly or
incorrectly, leave the interpretation of those changes up to a
non-autonomous agent also known as the user (which is the real reason
the non-technical majority never adopted them)...

2. Integrity records obtained by IM and its likes were useless in restoring
modified objects to their original state. This last capability is now less
important due to the complexity in restoring 32 bit objects from an "integrity
signature" (the size of the signature required for that is prohibitively large),
but was cardinal in the days of DOS.

there are those who feel that programmatically restoring
infected/corrupted objects to their original state is a losing
proposition... some anti-virus vendors (like sophos) don't offer virus
disinfection for most file infecting viruses because of this philosophy...

while the average joe may certainly prefer a magic bullet (and there are
plenty of examples of people expressing exactly that), i'm not about to
penalize a technology for failing to be a panacea - i'd rather penalize
a proponent of it for falsely leading users to believe it is a panacea...

plain integrity checkers are purely detective mechanisms... they do not
prevent and they do not restore, but they are (when used properly)
practically infallible at detecting change...

 

[Ron Reaugh]

A quick and partial analysis of the "NULL" sample yields interesting findings:
Although the file has the structure of a 32 bit executable, it isn't one

So not being a "32 bit executable" means what exactly? How many different
forms of executables are there? What about a DOS 6 device driver?

and
won't execute even if assigned an executable extension (.exe for that matter).

Relevance?

This confirms my previous statement that the detection as Qdown.s or whatever
ARE false alarms!

That it isn't by your findings a "32 bit executable" and therefore a false
alarm does NOT follow logically. The detection did coincide with some
nefarious virus like activity and was therefore NOT a false alarm. That the
detection did coincide with a file that seems to contain code further seems
to suggest that it's not a false alarm.

Digging in the sample code reveals that the use of the NULL file name is
deliberate.

That conflicts with your assertion that the detection was a false alarm.

The code

"it isn't one and won't execute "...."The code"...are opposite statements.
Whether the code gets executed depends entirely or what/who loads the code
and then jumps to the entry point. In this arena the definition of an
executable or virus code needs to be very precise. Whether it runs by
entering it's name at the DOS prompt isn't relevant.

also suggests that the NULL file may be renamed at some
stage through the Wininit procedure, probably to QDOWAS2.DLL. What's clear
beyond doubt is that NULL per se isn't a Trojan.

The opposite appears to be the case although c:\null may be just a part of
the overall trojan or an intentional misdirection.

For the sake of completeness, I suggest that you look with Notepad in your
%Windir%\WININIT.BAK file (it contains a backup of the last instructions
executed by Wininit.exe). If your NULL file was involved in the installation of
anything through Wininit, then you will find there traces in Wininit.bak of what
it did, in plain text. The time and date of Wininit.bak will also tell when
this happened.

All the entries there are one of the following two:
NUL=C:\WINDOWS\TTFCACHE
C:\WINDOWS\SYSTEM\CP_28605.NLS=C:\WINDOWS\SYSTEM\TBMA0B0.TMP

The second appears ~15:1 over the first. Both appear multiple times.

I also suggest that you search for a file named Qdowas2.dll, just in case.

Qdowas2.dll isn't found by Find on this W98se system nor is it found a on
similarly configured other nearby W98se system I tried

[...]

c:\null is still there. Today AVG updated and nothing happened. I'm
assuming therefore that in the original incident that some I/O did occur to
c:\null and that I/O was from out of left field. Nothing was supposed to be
doing that.

You are asking the wrong questions and looking in the wrong places for answers.

For starters, on-access AV aren't supposed to check non-executable files, even
if they have an executable structure! Doing so would yield excessive false
alarms (just demonstrated!) and would slow down processing considerably.

SO, why did AVG suddenly trigger(find it)? Check all files was NOT turned
on and I wasn't doing any kind of explorer window on c:\ or anywhere else.

If curious what drops the NULL file on your drive

An action that you claim AVG wouldn't have noticed.

 

[Ron Reaugh]

That file may be a malware related file, but it itself is not malware

Well it's kinda like the gun, the bullet and the smoke in the smokin gun.
All three are in fact part of the malware.

(it is not executable

WHO SAYS? Where there's code there's a possible fire.

and as such is not a threat) and any scanner that
detects it as such is wrong

That assertion is highly suspect in this case.

 

[Ron Reaugh]

It really is "detected" as a trojan - doesn't mean it is one. How can
you execute it as is?

Not relevant. It contains code. You find the loader.

It may be something that can be made executable
(Qbasic/run c:\null if it were a qbasic program) but as is what harm is
it? Do you want a program that detects everything that can be made into
something threatening? Text files (like the QBASIC program)? This post
maybe?

You forgot to include the fact that half the scanners find it. In fact AVG
starting finding it on the VERY DAY it found it on my system. AVG's day
before's def file used at www.virustotal.com did NOT find it. Just a
fortuitous introduction of a new false positive by AVG that corresponds to
some unusual activity of my system?? What is starting to appear to be the
most likely situation here? AVG and some others seem to know something you
don't maybe?

 

[Ron Reaugh]

Relax, the file isn't a real Trojan nor a Trojan at all (just code fragments of
what may have been part of anything else, like an installer, or attempted
malware) and it isn't the first time that several AV are in "agreement" on a
false positive, nor the last.

Careful parsing of your posts/assertions lead one to see that it is a self
contradictory circle on this. The strong evidence is that it was NOT a
false positive by a logical definition of 'positive'. Someone in this
thread said "A systematic approach, will." I couldn't agree more.

On-access AV intercept CreateFile calls in ring 0. Not every call initiates
file verification, only those with the "correct" parameters as set by the AV
designer (and sometimes by user option settings).

So AVG could have been newly updated that day(6/15 I think) to look for this
C:\NULL behavior which it believes is a detectable symptom of nefarious
activity: a positive.

Viewing a directory by
Explorer, for example, is all that is needed to initiate the AV to check files
that display with their own icon,

No such user activity occurred proximate to this incident.

as the file is opened by Explorer for reading
the icon resource.


Your on-access defense won't detect the uploading of anything, not even a "real"
virus or Trojan, in real time, when done from a remote PC. The reason is that
there is no meat to chew on for the AV at the time the destination file is
inspected. Here is what happens, step by step: A call to initiate a file
transfer is sent from remote. The local file system responds by creating a
local file and opens it for output. This is the cue for the AV to intervene,
take control and inspect the file just opened. Obviously, the AV will find
nothing as nothing was yet transferred. Control is then returned to the
interrupted process and the transfer will happily resume. If you asked yourself
how come that systems get infected under the nose of AV with the very last
definitions, then here is your answer.

HUH, the detection DID occur. It happened in real time and NOT scan time at
a moment that seems NOT to coincide with any usual virus time system
activity.

IMO, the date AVG first flagged the NULL file

It's initial detection was in real time on I think 6/15.

isn't the date that file was
created.

The file's date was 5/5/5.

Lastly, the NULL file isn't benign from its content. But it isn't the real
thing either,

That doesn't pass logical muster. I parse that statement to mean that there
was NO FALSE positive in this case.

and you are tormenting yourself for no good reason, on a wild
goose chase.

Seems NOT. AVG warned me about something unwanted. AVG apparently was NOT
crying wolf. The fact that AVG seems to have worked outside the range of
your experience isn't relevant.

Regards,

Ron Reaugh

 

[Ron Reaugh]

[...]
That file may be a malware related file, but it itself is not malware
(it is not executable and as such is not a threat) and any scanner that
detects it as such is wrong (but some would do so purposefully to get
better scores in AV comparative tests - like detecting boot sector
viruses in "files" like .bak backup files..

Based on the NULL sample inspection:

The file has a PE structure (Mark Zbikowsky's marker, 16 bit EXE stub, PE
extended header and sections) but it isn't directly executable.

Again, the false positive assertion seems to be in grave doubt.

Which doesn't
mean much as many non-executable objects used in Windows have that structure,
like font files, to mention one example.

It could be malware related, but it could be anything else just the same.

You said it DID CONTAIN a reference to c:\null and that implies something
uninvited.

 

[Ron Reaugh]

-snip

What prevented Integrity Master,

I'm an earlier user of that.

Today, *real-time* integrity monitoring is successfully implemented in
InVircible's Interceptor (see www.invircible.com/item/81 ).

I'm gonna have to take a look at that.

 

[Ron Reaugh]

WEP keys can be cracked in minutes now...

Some WEP keys or most all WEP keys? By a competent hacker or only by the
NSA? What's better than WEP, not easily cracked, widely & robustly
implemented and easy to install/maintain? A 26 char hex key in minutes
seems like it'd take something with Blue in it's name.

Just perform a forensics analysis on the drive and load another drive.

Define in detail please or provide URL.

That (loading a new drive, not the analysis) would've taken less time than
all the back and forth flames and insults within this thread that haven't
really solved anything.

If you can duplicate it, then document it and contact some companies and
pass on the info. Examine the c:\null file yourself to see what the
content is, and then make your own call on what exactly it is, based on
the content (if possible.)

And Belkin routers aren't the world's greatest,

Can you provide any reviews? What are its weaknesses? What's better in the
reasonably priced wireless router market?

and neither is ZA as far
as firewalls go.

Are there any known(previously exploited) hacks through a Belkin and ZA in
series?

It's entirely possible that something managed to get
past both of them, especially if it was invited from the inside.

Seems that case as also does the possibility of an undetected internal
trojan on this machine or on the local LAN is the likely path/culprit.

 

[Ron Reaugh]

-snip

while the average joe may certainly prefer a magic bullet (and there are
plenty of examples of people expressing exactly that), i'm not about to
penalize a technology for failing to be a panacea - i'd rather penalize
a proponent of it for falsely leading users to believe it is a panacea...
YES!

plain integrity checkers are purely detective mechanisms... they do not
prevent and they do not restore, but they are (when used properly)
practically infallible at detecting change...

Right.

 

[Roger Wilco]

WHO SAYS? Where there's code there's a possible fire.

Right - hence my QBASIC "text" file scenario. If I wrote a batchfile
that fed that textfile to the QBASIC interpreter, then the batchfile
would be the trojan threat - not the "text" file itself. Sure, I
probably wouldn't want that textfile sitting around, but it is no more a
trojan than deltree.exe is when a deltree.bat trojan is found.

That assertion is highly suspect in this case.

All files could be a threat - most program files undergo stages of
translation before ending up as an executable image. Even a PE file is
an admixture of code, data, and program control data for the loader to
use in building the executable image. Up until the point where tha user
is taken out of the loop (the remaining points in the path to execution
of the program are automated) the program is not a threat. Once the
program is in a state where the next action taken by the user (invoking
the program) is the last action he need take - the program file is
usually termed "executable". Take a zipped (archive) file for instance -
it is not a threat, and there is no reason to scan it at this point; but
if Microsoft decided that users wanted to have double-click
functionality that automatically extracted files from an archive and
then automatically executed extracted program files named "install.exe"
or "setup.exe" then we would have to consider zipfiles as executables on
that system.

Your c:\null file still requires something more before it can become a
threat, and so should not be detected as a threat. A .doc file on the
other hand might be associated with Microsoft "Word" and the path to
execution of embedded macros is automated - so .doc files are
"executable" under this condition. Incidentally, it used to be the case
that OLE2 .doc files renamed to an extensionless filename (like NULL for
instance) would be recognized when invoked as OLE2 filetype and opened
in "Word" automatically running embedded macros. As long as the actual
file structure is not OLE2, then your file was not "executable" sans
extension.

 

[Roger Wilco]

-snip


I'm an earlier user of that.


I'm gonna have to take a look at that.

Have a look around his site for other helpful schemes he incorporates
into InVircible.

Good recovery stuff too.

 

[Ron Reaugh]

Right - hence my QBASIC "text" file scenario. If I wrote a batchfile
that fed that textfile to the QBASIC interpreter, then the batchfile
would be the trojan threat - not the "text" file itself.

YES, the text file itself is and I'd expect a good checker to find and
eliminate it if it was in fact part of a multistepped attack/penetration.

Sure, I
probably wouldn't want that textfile sitting around, but it is no more a
trojan than deltree.exe is when a deltree.bat trojan is found.

WRONG, deltree is part of a protected class...the OS itself. The WHOLE
goal is protect the OS's integrity and intended functionality.

All files could be a threat - most program files undergo stages of
translation before ending up as an executable image. Even a PE file is
an admixture of code, data, and program control data for the loader to
use in building the executable image. Up until the point where tha user
is taken out of the loop (the remaining points in the path to execution
of the program are automated) the program is not a threat.

NO, that makes assumptions that a/the standard loading functions are being
used.

Once the
program is in a state where the next action taken by the user (invoking
the program) is the last action he need take - the program file is
usually termed "executable". Take a zipped (archive) file for instance -
it is not a threat, and there is no reason to scan it at this point; but
if Microsoft decided that users wanted to have double-click
functionality that automatically extracted files from an archive and
then automatically executed extracted program files named "install.exe"
or "setup.exe" then we would have to consider zipfiles as executables on
that system.

Not relevant.

Your c:\null file still requires something more before it can become a
threat,

It is a threat or at least the tracks of a threat or at least a misdirection
from a threat. The file didn't belong there. The file didn't get there by
any ordinary and intended process. AVG detected it in real time and not by
any user initiated scan. All indications are that there was NO FALSE
positive. All the other circumstances surrounding this seem to support
that. The fact that the file doesn't fit some parochial definition of a
threat/executable isn't relevant.

and so should not be detected as a threat.
NO!

A .doc file on the
other hand might be associated with Microsoft "Word" and the path to
execution of embedded macros is automated - so .doc files are
"executable" under this condition. Incidentally, it used to be the case
that OLE2 .doc files renamed to an extensionless filename (like NULL for
instance) would be recognized when invoked as OLE2 filetype and opened
in "Word" automatically running embedded macros. As long as the actual
file structure is not OLE2, then your file was not "executable" sans
extension.

You are too deep in arcana and missing the point.

 

[James Egan]

Some WEP keys or most all WEP keys? By a competent hacker or only by the
NSA? What's better than WEP, not easily cracked, widely & robustly
implemented and easy to install/maintain? A 26 char hex key in minutes
seems like it'd take something with Blue in it's name.

Don't pay too much attention to the size of the key. You don't need to
know the wep key to decrypt a packet if you know the cipher stream
used to encrypt it. The initialisation vector used to generate cipher
streams is only 24 bits (16-17 million possible streams) and is sent
in the clear with the packet.

Hacking tools like airsnort http://airsnort.shmoo.com/faq.html collect
particular packets within these 16 million possibilities and can
deduce keys automatically.

These days WPA is the norm since WEP is so easy to break. Having said
that, there are enough wireless networks around running no encryption
at all to keep the hackers occupied. Why hack into yours when there
will be one around the corner that doesn't require any hacking?

Whether you can upgrade to WPA with your win9x kit depends on the
wireless equipment in use. With Linksys wireless cards, WEP is as good
as it gets without upgrading to winxp and using the built in wireless
support. Don't know about other hardware but certainly you should pay
a visit to the manufacturer's website to see if there's a WPA update
available.


Jim.

 

[Ron Reaugh]

Don't pay too much attention to the size of the key. You don't need to
know the wep key to decrypt a packet if you know the cipher stream
used to encrypt it. The initialisation vector used to generate cipher
streams is only 24 bits (16-17 million possible streams) and is sent
in the clear with the packet.

Hacking tools like airsnort http://airsnort.shmoo.com/faq.html collect
particular packets within these 16 million possibilities and can
deduce keys automatically.

Deduce the whole original 26 hex char key or just that particular packet?
How much time/effort does it take a competent hacker to get the whole 26 hex
char key and have full immediate access to the WiFi net?

These days WPA is the norm since WEP is so easy to break. Having said
that, there are enough wireless networks around running no encryption
at all to keep the hackers occupied. Why hack into yours when there
will be one around the corner that doesn't require any hacking?

Whether you can upgrade to WPA with your win9x kit depends on the
wireless equipment in use. With Linksys wireless cards, WEP is as good
as it gets without upgrading to winxp and using the built in wireless
support. Don't know about other hardware but certainly you should pay
a visit to the manufacturer's website to see if there's a WPA update
available.

I'll have a look at WPA. Is WPA secure outside an NSA effort?