Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Remove The Calling Routine Or The System Infection Program?


  • Please log in to reply
4 replies to this topic

#1 bluecoal

bluecoal

  • Members
  • 11 posts
  • OFFLINE
  •  
  • Local time:05:35 AM

Posted 18 June 2007 - 04:40 PM

When cleaning an infected system is it more appropriate to remove the routine or registry entry that causes an infection program to run on a system, or to remove the infection program and leave the routine or registry entry that calls it?

BC AdBot (Login to Remove)

 


#2 -David-

-David-

  • Members
  • 10,603 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London
  • Local time:10:35 AM

Posted 19 June 2007 - 11:25 AM

If you've got an entry in startup for example, if you simple delete the registry entry that starts the program up when Windows boots without deleting the relating file, you often find that the file will stop the registry entry from being deleted, especially in malware cases. Other times, the file will simply recreate the deleted registry file if it's startup key is removed. The best course of action is, in my opinion, to delete the offending malware file in safe mode, then rebooting back to normal mode and deleting the relating registry entry. Having said that, you mentioned deleting just one of the two and leaving the other...what is stopping you deleting both? So to summarise: delete file in safe mode > delete registry entry normally > run a scanner to pick up any leftovers. Hope this helps.

#3 bluecoal

bluecoal
  • Topic Starter

  • Members
  • 11 posts
  • OFFLINE
  •  
  • Local time:05:35 AM

Posted 19 June 2007 - 12:07 PM

Hi,

Thanks for answering.

The reason that I asked the question is because of reading about Lop.

I thought, as you said, that the proper procedure would be to delete both things. Say in the case of a Lop 04, fixing the 04 line and deleting the folder. I wanted to see what current procedures are for Lop, and I did a lot of looking at Lop threads last week, and I don't see consistency in procedures.

It is hard to check well, because you need nolop and combofix or comboscan logs to look at everything and those, particularly the combo**** logs, are not often asked for, but I have found some interesting threads.

I see one Lop folder that is not visible to HijackThis that is hardly ever deleted. By extension, this should be present in a significant majority of Lop related logs. Sometimes I don't see the related task scheduler task asked for right away either, so it seems like the fix process goes through some unnecessary cycles. Visible in the log are two folders, an HKLM and an HKLU folder. Sometimes, not always, I see only one asked for in the deletion steps. So I see logs pronounced as clean where there are lop folders left on the machine. In addition, I have seen registry fix files used only a few times, but the combo**** logs would sometimes seem to indicate that they should have been used in other threads as well.

So what I am trying to evaluate is whether I am seeing carelessness, the helper knows a folder is empty so is not concerned about removing it, registry removal considered unnecessary because the program it calls is gone, or what.

In addition there is a new tool that shows up called nolop. In the logs I looked at, only once did it remove files, the rest of the time it just removed the task scheduler job. Not knowing exactly what nolop does, I am having trouble fitting it into the mix too.

In short, I am trying to figure out why approaches to Lop seem to violate what I thought was the standard approach to cleaning things.

Edited by bluecoal, 19 June 2007 - 12:16 PM.


#4 -David-

-David-

  • Members
  • 10,603 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London
  • Local time:10:35 AM

Posted 19 June 2007 - 12:32 PM

I think you need to understand that not all infections follow a set 'routine'. This is the same for a LOP infection; you cannot state that there will be a certain number of folders that will be on the infected PC and these infections change continually. Also, even if the user has been infected with a specific infection, the user's antivirus programs may help deleting some of the component parts of the infection - if a HJT helper doesn't see the files there to be fixed, he cannot assume that there must be things left undetected; we leave it to the tools to flag leftover malware files, or else we'd be there all day searching for files that could be there, and we end up with a huge backlog of Hijackthis threads.

Also, there is not one set method in which LOP should be dealt with, and that's the same for many different infections. I agree there are removal tools, for example NoLop, but for me, I prefer the manually approach - why download an extra tool when you can remove the infection manually? I do not class combofix and comboscan as removal tools, they are tools which produce logs which can help a HJT helper do his job. An active lop infection does contain the scheduled task, some helpers may find it and delete it right away, others may leave it up to the removal tools such as NoLop, and other may wait until the task is uncovered in a log produced by Combofix for example.

#5 bluecoal

bluecoal
  • Topic Starter

  • Members
  • 11 posts
  • OFFLINE
  •  
  • Local time:05:35 AM

Posted 19 June 2007 - 03:06 PM

I think that LOP does have a definite structure and that repairs can follow along in that structure to make them more effective. For example, I think the task scheduler should be checked for right away because if it is not, it can be the cause of repeated tries to remove the problem.

One of the specific reasons for this thread and its title is the task scheduler and its related job. 3 years or so ago when the task scheduler started turning up and was hidden from the normal process of removing something, Metallica came up with the little listing process that we can use. Someone else made a modification to that to also allow seeing file references. That came up with a C:programfiles reference. Even with that information, helpers continued just to delete the task, but not the C:programfiles stuff.

Now, with comboscan or combofix, it can be seen very clearly.

Here is an example:

2007-05-08 17:02 <DIR> d-------- C:\Program Files\Play Upload
2007-05-08 17:02 <DIR> d-------- C:\DOCUME~1\Craig\APPLIC~1\Play Upload
2007-05-08 17:02 <DIR> d-------- C:\DOCUME~1\ALLUSE~1\APPLIC~1\real send film bat\

Notice that there is a corresponding programfiles folder to one of the docs & settings folders. This was in 04 HKCU: C:\DOCUME~1\Craig\APPLIC~1\Play Upload. The other folder was in 04 HKLM: C:\DOCUME~1\ALLUSE~1\APPLIC~1\real send film bat.

If NOLOP or HijackThis startup showed a taskschduler job, if there was a combofix, comboscan, or deckard scan log to look at, it always showed at least one programfiles folder matching one of the docs&settings folders. If there were more than 2 docs & settings folders, there would sometimes be more than 1 programfiles location. Further, in all but 1 of the logs, the programfiles location matched with the HKCU 04 line that has the truncated presentation in the HJT log. (I lost the link for the exception log to do further thinking about it).

So when LOP shows up, I think it has sufficient structure that the task scheduler should be checked in the first LOP response and that C:programfiles should always be checked for a LOP folder if there is a LOP scheduled job present.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users