Operating Memory Virus

Hello Everyone
How does one get rid of an Operating Memory Virus? A complete and deep scan of the HDD reveals no virus but upon scanning an individual file with deep heuristics we find this:

"probably unknown NewHeur_PE virus found in operating memory."

Thank you.

 

I am pretty sure that is false positive. BUT, I would wait for someone with more NOD32 knowledge comments here before deciding for sure

 

Hi,
Please do a full scan of your PC using the /ah command line. Thus NOD will show which file is infected by a possible new virus and you can zip them and send it to samples@nod32.com for further analyzis of that file.

 

If possible, please post a list of applications you have installed, I have a tip what the fp could be.

 

We are using the third-party right-click option which includes /AH /ALL /SHEXT. There is no more information but the only option of "Leave".

We have installed more than 300 programmes on this machine. If you like can you PM us your suspicion and we can confirm or deny its' installation? We understand that you do not wish to mention it publicly so as not to cast aspersions in case that programme is not one of ours that is installed.

Thank you.

 

Hi one of my friends had a similar prob,something(prob a trojan in his case) had altered the registry scanning with adaware sorted his prob
Dont know if this is any use to you Steve

 

We have also done a complete Spybot S&D, Ad-Aware and A² scan and nothing was revealed. All up to date of course.
When we scanned with Ad-Aware it had found one tracking cookie (in C:\Windows\Cookies) (with a cgi-bin in it!) which we deleted. Also upon running RegCleaner 4.3 we saw just one entry we did not recognise. We did some research on it and it seemed to indicate a file for a HP printer but since RegCleaner indicated that it was a new program and since we did not install any HP drivers or files lately we got rid of it figureing that if it was a legitimate file we could always get another copy.

Well guess what? In the middle of this post, we thought we would do one last NOD32 right-click scan on the same test file and look below what we saw! We are clean again!!!

 

I also have this when I use this program: Kana WallChanger

 

Hi Q section did the created date of the offening "nasty" correspond with any install on your system? and since deleting it has anything that should work stopped working or started working incorrectly?(hardware or software)
I'm very curious looking at programs you have installed to defend your system as to where it came from and how it got through!
Steve

 

steve1955
We blundered in one of the most classical mistakes one could do whilst checking for malware. We neglected to notice the date of the two files in question! Oh well, nothing seems different with either software or hardware either during the infestation or after.

Let that be a lesson to everyone reading this. Please before you delete possible bad files note the date and time of the file in question and do a system search for any files with the same date/time stamp as that will probably result in a very good clue as to how the infestation occurred even if it is a false positive or not.

Thank you everyone for your input!

To quote the name of our best first security friend who started us along the way - Free At Last!

 

Qsection>

You have brought a crucial issue back into light here


The fact is:
TODAY's antivirus apps are powerless against memory-resident virii simply because the "memory guards" DO NOT SCAN THE MEMORY - they are on-access scanners, which only scan the HDD when it is being accessed, but not the memory (although of course they do reside in memory).

Now an AV's on-demand scanner (not on-access scanner), such as nod's, will automatically scan RAM. But then again, as it's only the on-demand scanner, RAM is only scanned upon launch by the user - and how is the user to "guess" if there's a virus in memory?

Now the memory guards of some ATs (anti-trojans) such as TrojanHunter and TDS do continuously scan the memory for trojans. Unfortunately, it is not so for AVs - this is what makes them vulnerable to infected runtime-packers, as these files, unlike archives, unpack directly into memory, thus bypassing the AV's on-access scanner..

 

Some AVs can scan runtime packers before they are accesed(the good ones any way)so they really shouldn't be a problem as long as they are scanned before you unpack them any malware should be detected before it gets on your system( to test if the AV installed on your system is effective in this just scan a runtime packer,if it gives number of files scanned as 1 it is not scanning inside and you could be vulnerable to malware hidden inside on of these

 

But the problem is, no AV can possibly scan all types of runtime packers, simply because these can come in an infinite number of variants - for example, what about custom-made packers?

KAV is deemed the best for packers - it can scan inside over 600 types. Yet even this AV is vulnerable to unknown packing methods.

So the only solution is for the resident guard to scan the memory, like trojanhunter does for trojans. A virus may be able to hide inside a new packers, but it has to show its true colours sooner or later once loaded in RAM..

 

You have to distinguish between viruses and trojans/worms.

1.
A virus dropper (first generation) can be compressed with a run-time packer. However, the second generation of a file infection virus will be detected.

I addition, a virus may have it's own encryption engine (like zmist). However, good AV scanners are able to detect such encrypted viruses.

2.
A worm (unless it is a file infecting worm) can be easily compressed with a run-time packer (see NetSky). However, an AV producer will be able to add a signature for the compressed variant pretty soon.

3.
A trojan does not replicate itself and it can be easily compressed. Therfore, trojan's are the real problem.

KAV has a static unpacking engine. Ewido security suite has a dynamic unpacking engine (emulation). Both engines complement each other very well! For example, KAV will be unable to unpack a modified UPX stub. Ewido will have no problem at all with such tricks. On the other hand, Ewido will be unable to unpack certain packers which KAV can handle.

There will still be a few packers/crypters etc. which no unpacking engine can handle. In such case you may use a scanner which uses signatures from uncompressed parts of a file (like Trojan Hunter or McAfee). You may also try a heuristic like it is used by NOD32 (with /ah settings).

If a trojan is nonetheless missed you can use a memory scanner (BOClean, TDS, TH) and hope that the trojan has not been patched or encrypted in memory (e.g., with a commercial protector like Xtreme Protector).

Conclusion: Use several scanners. Use your brain. Use a personal firewall. Use a system firewall.

 

... and your credit card as well The overall price of it all - ouch..


And btw, no prob I know the difference between virii & trojans lol; my point was, AVs should implement the same methods that some ATs use against trojans, ie. the resident modules should continuously scan the memory to thwart virii that are packed in non-standard fashion..

Imagine if AV vendors had to add, for each virus, all its packed signatures, taking into account all the existing packing methods & their variants - the size of the def base would be multiplied a thousand-fold, and besides it would still not be impervious to virii hidden inside custom-made packers

Heuristics are a good idea as well - but then again, it's hit & miss, even with the most advanced such as nod's "super-heuristics"..

It would be interesting to see how apps such as TDS & Trojanhunter handle trojans encrypted in memory - I'd surmise that encrypted or not, a trojan or any other malicious app HAS to shed its cloaking sooner or later once in memory, before it can be executed..

 

I have a simple rule:-If I receive anything compressed in any way that I can't scan I bin it! (if its legit sender can always contact you in other ways)
Steve

 

Yep, perhaps that's a wise idea.

But if the exe is compressed in such a way you can't scan it, then how can you tell if it's compressed in the first place? http://forum.emule-project.net/html/emoticons/huh.gif

 

An exe by being an exe has to be compressed unless you actually have the files that it is going to run in uncompressed form doesn't it?

 

No no what I meant was:

how to tell the difference between an uncompressed executable (ie left "as is", not packed after compilation) and a runtime packer of unknown packing format (which is also an exe, but packed this time), since it's impossible to scan within the latter?

 

If it was uncompressed it wouldn't be an .exe file as such it would be a collection of files the set-up wanted to run along with the "instructions" of where to install files to on a system and a set of instructions of what reg entries to create,you could easily scan these and read install/reg insructions using notepad(any word viewer)