Trojan horse Downloader.Generic.ML

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

Regards, Zvi

-- NetZ Computing Ltd. ISRAEL

Zvi Netiv wrote: [snip]

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

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

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.

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.

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

Good recovery stuff too.

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?

Relevance?

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.

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

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

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

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.

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

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.

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

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.

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

That assertion is highly suspect in this case.

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.

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.

No such user activity occurred proximate to this incident.

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.

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

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

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

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

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

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

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

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

I'm an earlier user of that.

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

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.

Define in detail please or provide URL[s].

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

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

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.

-snip

YES!

Right.

??? wep always uses rc4 so you always know the stream cipher used to encrypt...

that's not the real issue though - the real issue is that with an output feedback stream cipher (like rc4), if you encrypt 2 messages (packets) with the same key (wep key + initialization vector) you can cancel out the key by XORing the 2 encrypted messages together... to keep this condition from happening you should change the wep key before the initialization vector has a chance to go through every possible value - but as has been shown not too long ago, the initialization vector can be forced through all possible values in a matter of minutes with properly crafted traffic...

so to ron: it's not a matter of breaking a 26 character hex key, it's actually no more difficult than getting the device to cycle between all possible 24bit initialization vectors... that's a much smaller number of possibilities and is easily accomplished in minutes...

lets save some time - zvi is an anti-virus developer/designer/vendor/what-have-you... if he says that something he's analyzed isn't a virus/worm/trojan then it probably isn't...

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.

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

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

Not relevant.

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.

NO!

You are too deep in arcana and missing the point.

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?

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

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

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.

It depends on the volume of your wireless output. The airsnort FAQ (as above url) will give you an idea of how long it could take to find yours.

Apart from having better encryption, it deals with some of the flaws of WEP eg. changing keys every few minutes and using proper hash authentication instead of crc based.

It's not perfect but it's much better than WEP if used with a long master key.

Jim.

NO, I simply followed his own logic and assertions which proved to be circular. His definitions are also parochial. Any expert should be able to express his views or opinions in plain logic without resorting to arcana. That's especially in this case which has very special properties. His own analysis included the assertion c:\\null "isn't benign".