In some cases they could add detection for exploit code which was published and have detection in place before some malware author actually used it in a program. But most often the malware program's release prompts the creation of the detection update after some time elapses. This gives active or autoexecuting exploit based worms the time they need to spread fairly widely - but for the "click required" worms and viruses it shouldn't be a problem because there is really no good reason for a user to execute every damned executable they see when they could wait a reasonable amount of time for the malware fighters to add detection capabilities to their scanners.
manager
The current model only enables users to get by without proper safe practices. I like the old model better - you know, the one where AV was a tool to help you to climb to better security instead of a crutch to help your muscles atrophy. Too many people depend on AV to protect them while they engage in risky behavior when a simple change in behavior would leave little for the AV to do.
I think Zvi nailed this one (we'll see when he again responds). You probably have a program running that wants to hide its messages from your view by redirecting any echoes destined to the console to the nul device. The programmer mispelled nul as null and as a result the file is created (or overwritten) whenever the program is run. Now you will need to find out what program is creating (or overwriting) this file.
YES, but since then I left the file there and today's AVG update did NOT trigger a detection. Later I selected to scan selected area(C:\\) and it immediately detected it. So my conclusion is that in fact there was I/O to that file at that original moment. A moment that appears to correspond to nothing.
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
formatting link
seems to have been kept sufficiently up to date to be usable on xp...
there will always be occasional failures, it's just a fact of life...
to try and deal with the failures in preventative measures one must realize there's more to security than just preventative measures, and there's more to preventative measures than just using the best scanner...
within the realm of preventative measures there's OS hardening and keeping your applications/OS up-to-date and patched... there's process whitelisting (i don't know about other software firewalls but kerio personal firewall has something called application launch control which is sort of along those lines)... also, on the behavioural side there's the simple avoidance of new executable material (ie. keep your playing around with new software/cracks/keygens/whatever to a bare minimum)...
besides preventative measures there are also detective and restorative measures... detective measures include virus detectors (we actually use their detective capabilities to try an implement a preventative measure) but also change detectors (integrity checkers), network/registry/filesystem/process monitoring tools, so-called rootkit detection software, an observant user, etc... restorative measures are, of course, the various backup facilities that are available, the dedicated malware removal tools when available, and detailed manual removal instructions when available...
when gauging how effective your security response to an incident was you need to look at the whole picture, not just part... so your preventative measures failed - how quickly were your detective measures able to sound the alarm and how easy was it to recover?
if the only issue is the frequency of preventative failures then look at exactly what security (not necessarily software) vulnerability is involved in those failures and tighten that up...
It's NO FP. A2 flags it also. It's for real. The designer may have been targetting the margin between the real and the false positive in various scanners. It's something new apparently. I may have been an early/alpha case. It appeared on my system from thin air seemingly and on the same day that AVG started seeing it....just a coincidence.....
Are you visiting Neverland? That file REALLY IS a trojan. 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? 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.
Got the sample, and found interesting things in it.
I am writing the follow up, but it will take a few more hours as all three computers are now taken for my grandchildren games. They gave me just a couple of minutes to post this message. :)
Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
formatting link
formatting link
(Hebrew) InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
Create a dummy file with the name "example.txt.pif", and then try to find it in the Windows Explorer.
You won't see the "pif" in the name. Not if you don't change the setting in the registry by hand, at HKEY_CLASSES_ROOT, and put NeverShowExt to zero. Yet, any executable can be renamed as "pif", and if you double click it, it will be /run/, as the command for the piffile is "%1" %*.
A good deal of the Netsky worms abuse this Microsoft "feature"
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.. 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.
It's not magic, it is only a way to trade accuracy for time. A little less accurate, but much quicker. It still requires that a known thing (or known things) be looked for and a judgement made. If you knew for instance that it was a virus you were looking for, there are known attributes of previous viruses that can be looked for. When you start with a complete unknown you have nothing to go on. Do you think heuristics can detect a retrograded patch level?
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.
Hmmm - penetrated? -- invited in more likely.
trigger at
You are the one in Neverland (whatever that means).
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.
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 and won't execute even if assigned an executable extension (.exe for that matter). This confirms my previous statement that the detection as Qdown.s or whatever ARE false alarms!
Digging in the sample code reveals that the use of the NULL file name is deliberate. The code 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.
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.
I also suggest that you search for a file named Qdowas2.dll, just in case.
[...]
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.
If curious what drops the NULL file on your drive then get InVircible, set a trap for "NULL" in its blacklist, and you'll know the moment anything attempts dropping that file again, including the name of the parent process that induces the creation of the file. A by-product would be gaining a sound real-time defense! For the sake of full disclosure, pay attention to my signature, below.
Note that you should not run more than *one* on-access AV defense on the same PC, at any given time!
Notepad opens by default files with the .TXT extension. Therefore, if you run NOTEPAD C:\\NULL then it will look for a file named null.txt and nothing will happen. The dot after null is a delimiter that instructs NOTEPAD to interpret the argument as "null" plain, with no extension. [...]
Because KAV is also susceptible to false positives, although less than some mediocre scanners in the first group.
What I am saying is that you are overly confident in scanners reliability.
There sure is, and I explained how to find out. Speculating on scanners reliability won't get you to the bottom of this. A systematic approach, will. Regards, Zvi
-- NetZ Computing Ltd. ISRAEL
formatting link
formatting link
(Hebrew) InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
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.
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.
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
-- NetZ Computing Ltd. ISRAEL
formatting link
formatting link
(Hebrew) InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.