ESS said a file is infected, THEN says it's not infected - ?!?!?!?

Discussion in 'ESET Smart Security' started by jonkoer, Oct 23, 2009.

Thread Status:
Not open for further replies.
  1. jonkoer

    jonkoer Registered Member

    Joined:
    Nov 28, 2007
    Posts:
    30
    At about 5:00AM, Smart Security popped up, saying it had quarantined a c:\Windows\system32\CMCFG3.DLL file, which was planning to run at system startup, and which contained the Delf.OAX.Trojan. My initial reaction was to be thankful that Eset had caught it. But then, ...

    The file's Created timestamp showed that it had just gotten installed 5 hours prior, 10/23/2009 12:32AM (today).

    I have an automatic backup program which ran at 4:08AM and made a backup copy of the file before ESS detected & quarantined it.

    So I had ESET scan the backup copy - but it found NO infection.

    I then restored the original file from quarantine, to check it. An ESS scan now found it to be clean!!

    CAN ANYONE TELL ME WHY IT DETECTED a Delf.OAX.trojan, THEN A FEW MINUTES LATER SAYS FILE IS CLEAN!!!!

    I also found another file in \system32 folder, named CBLCAT.DLL, which is the same size (116K), and which was created at 12:59AM, shortly after CMCFG3.DLL got installed. Sounded suspicious, so I did a binary compare -- the files differed in only two bytes! VERY Suspicious... But an ESET scan of this file says it is not infected.

    What is going on here? How can a file be infected one minute and clean the next? (Eset did NOT say it had CLEANED the infection, just deleted and quarantined it. -- And in any case, I have a pristine backup copy of the file made an hour before Eset Alerted on it, which Eset now says is clean.

    I did submit the file to Eset, and I'm creating a Support Ticket about this, but based upon my recent experience with Eset Tech Support, I doubt that I will hear anything back from them, so I'm hoping that someone here might be able to shed some light on this question.
     
  2. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,456
    Probably the dll was detected by more sensitive heuristics employed by the startup scanner. Once it's been quarantined and all related references to it removed from the registry, your computer was clean. Dlls themselves are not malicious, you cannot run them alone. A problem would be if you scanned a file with the on-demand scanner using same settings twice in a row and it'd give different results.
     
    Last edited: Oct 23, 2009
  3. jonkoer

    jonkoer Registered Member

    Joined:
    Nov 28, 2007
    Posts:
    30
    Eset told me that it quantined the .dll file. It did not say anything about having removed all references to it in the registry. So if I restored the file, then it should have been detected as a threat again.

    It's not the references to a .dll in the registry that are harmful. It's the .dll file that does the harm, when it runs.

    Let's imagine that some standard Windows component .dll file has been maliciously replaced by a bad .dll with the same name. If Eset removes all references to it in the registry, then when I replace the bad (now quarantined) .dll file with the legitimate one, well, it's not going to work correctly because Eset removed registry references to it. So it seems to me that would not be a very smart way to deal with an infected, bad .dll file.

    Where does Eset show me which registry entries it removed? If indeed it did so.
     
  4. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,456
    This is a wrong assumption. Once a file is cleaned, all references to it are removed from the registry. This is not logged as a separate action as it's part of the cleaning process. Once the references have been removed, the dll was no longer registered in the system and run (e.g. injected in another process).

    Unlike exe files, dlls cannot be run by clicking on them. They are basically harmless if not registered in the system. However, you can submit the file per the instructions here so that standard detection for the dll is added. At any rate, ESET protected you against the malicious dll at the moment it was registered to the system and neutralized it.

    Your assumption is wrong. System dll / sys files are not removed completely. If such a file is detected, you're prompted for an action and the file should be replaced with a clean copy (best before the next computer restart/shutdown).

    Nowhere. Removing malware from the registry is part of the cleaning process. If a file is detected and removed, all references to it are removed from the registry as well.
     
  5. jonkoer

    jonkoer Registered Member

    Joined:
    Nov 28, 2007
    Posts:
    30
    Re: Eset removing all registry references to a file, and not logging this action

    Firstly, what you said here does not make sense: IF a file is cleaned (vs. being deleted/quarantined) by removing the malicious code from it, then it would not be necessary to remove registry references to it, since it will no longer be able to perform malicious actions.

    Secondly, in a case where a detected bad .DLL file cannot be cleaned, and IF what you say is true -- that "all references to [a detected .DLL file] are removed from the registry" -- then this was a very bad design decision on the part of Eset's developers.

    Because:
    1. Many .DLL files are "shared" or "common" -- i.e. A single .DLL file can be used by multiple software programs - legitimate non-malicious programs with entirely different purposes, programs from different companies. E.G., a single .DLL file might be used by a geneaology program, a greeting card program, a resume-writing program, a sound editiing program, & etc. All such programs will have registry entries that refer to that .DLL file's name and location; these registry entries enable the program to call and load the .DLL when needed.

    2. If a legitimate "shared" .DLL file has been replaced by an altered, malicious, infected file of the same name, then, yes, any time it is called (loaded into memory) by any of the software programs that use it, it may perform its malicious actions.

    3. If, as you claim, Eset removes all references to that file from the registry, then even if the malicious .DLL file is removed and the user has now replaced that file with the original, legitimate one, then ALL of the software programs which use that .DLL file will no longer function correctly.

    4. So, by removing registry references to the file, Eset has effectively broken all of the software programs which use it. They will no longer work correctly, and the only way to make them work correctly again would be to reinstall all such programs.

    5. Making matters even worse, you state that when Eset removes all the registry references, "This is not logged as a separate action." Therefore, the user cannot know WHICH of his software programs has been broken and needs to be reinstalled.

    6. I object furthermore, as a matter of principle, to Eset's doing things to my system which it does not log -- hiding what it has done to the system from the owner. ​

    You are making a wrong assumption here: You are assuming that the .DLL file in question is not a shared/common .DLL file and thus was not previously registered to the system. You are assuming that when the malicious .DLL file was saved to disk, and a registry reference to it was created (in my case, to cause it to be loaded at system startup), that this is the FIRST and only registry reference to it. If your assumption is incorrect (i.e., this is a shared .DLL which was already being used by software programs in the system prior to its being infected or replaced with a bad version), then "neutralizing" it by removing all references to it in the registry will have the adverse effect described above.

    What do you mean when you say that "System .DLL/.SYS files are not removed completely"o_Oo_O? First, what do you mean by "system .DLL file" (as opposed to other, "non-system" .DLL files)? And what do you mean by "not removed completely"o_O? Are they "partially" removed?

    Eset does not prompt me to replace the file with a clean copy. It should do so, if the .DLL file that is being removed/quarantined is a "shared" .DLL file that is needed by other legitimate software programs, but it does not.

    If Eset recognizes that this bad .DLL file is a "shared" .DLL that is needed by multiple programs, then it should not be removing "all registry references to it" in the first place, since many of those references are from legitimate. programs. What it should do is to offer/recommend that the bad file be quarantined, and suggest that the user should find a clean copy of the .DLL and put it in its proper location.

    Once again, I strongly object in principle to Eset NOT telling the user which registry entries it has removed from his system, or other changes it has made to his system.

    This is what horrible programs such as Norton and AOL do -- they take control of the user's system, modify it as they wish, without telling the user exactly what they are doing or giving the user the choice of whether or not to perform that action -- in general, acting like they, not the user, own the system.

    This is just a totally wrong-headed notion of what it means to make your program "user-friendly" -- assuming that the users are just too stupid or too lazy to understand and control their system, therefore doing things for them.

    Certainly there are plenty of users out there of whom this is true. But morally, the user should be given that choice up front. Perhaps at installation you should have a checkbox for "I agree to permit Eset to make whatever changes to my system it deems advisable, without asking or informing me of what changes it makes, since I am too stupid or lazy to be bothered with learning about my computer and how to control it."
     
  6. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,456
    Re: Eset removing all registry references to a file, and not logging this action

    1, ESET neutralized the dll when registered in the system
    2, should you need to add standard detection for cases when the dll's not active and registered in the system, submit it to the ESET's lab per the instructions here.

    Cleaning threats works in a smart way. In the case of systems files, no action potentially causing problems with the system is carried out automatically and the user is always prompted for an action. That's all I can comment on your post.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.