Government Security
Network Security Resources

Jump to content


System Disinfection

- - - - - trojan tools worm patch payload infection backdoor
  • Please log in to reply
23 replies to this topic

#1 Kenny


    Former Commander In Chief

  • Retired Admin
  • 6,747 posts

Posted 24 May 2003 - 12:43 AM

System Disinfection

Jong Purisima and Vincent Tiu, TrendLabs

The prevalence of malware that target systems as a whole, rather than the traditional 'files in a system', has risen in the past few years. We have seen numerous methods of exploitation, while some malware programs combine the traditional file infections with system infections that can result in catastrophic problems.

With these changes, additional technology has been implemented to provide better detection for all the components of contemporary malware. As new exploits and techniques are discovered, the ability to support detection of their malicious byproducts is all the more vital.

System Disinfection

As the battle for malware detection continues, a new one has emerged: system disinfection.

For a user, the problem with an infected system does not end with detection of the malware. Detection merely provides a reference point for restoring the system to its accepted functional state and, in general, more time will be invested in disinfecting it.

System disinfection can be defined as 'restoring a system to an acceptable and working state'. Of course, it is possible to carry out a 'full' restoration, however, the diversity of systems and system configurations makes this very difficult. The aim of disinfection is to enable the system to work as it did in its pre-infected state, without having to perform any re-installation.

Since Windows is currently the most commonly attacked system, it will be the focus of this article.

Detection of an Infected System

A very important part of system disinfection is the correct identification of an infected system. When a scanner detects a malware program that is supposedly a system infector, it does not necessarily follow that the system is already infected. Detection of such a program should, however, be used as a basis for carrying out further checks.

The opposite is also true: if a scanner has not detected any system-infecting malware, it does not necessarily mean that the system is not infected.

In order to understand the underlying concepts of disinfection, infection should be defined. Currently there are two types of system infection. The first are Memory-File- Registry infectors. These use any combination of the three (memory, file and Registry) in order to take control of a system. To check for infection of this type, a memory scanner, file scanner and a Registry scanner may be used.

The second type of system infector uses memory only - a good example is CodeRed. This type has no physical trace (in a file or in the Registry) and is a little harder to identify.

In a similar manner to its file counterparts, misidentifying a system as infected can cause problems, since attempting to clean a system that is already clean can lead to further damages - caution is advised.

Once a system has been identified as infected, the disinfection process can begin.


A critical aspect of system disinfection is removing the malware from memory. This is critical since the operating system will not allow the removal of files if a process or service is still resident in memory. Furthermore, removing the malware from memory removes the malware program's control over the system, thus preventing it, for example, from restoring its physical counterpart or re-infecting.

Memory residence can be classified as either a process or a service. Processes should be killed, while services should be stopped. To kill a process, we can use the KillProcess() APIs, while, to stop a service, we can use the SCManager() APIs.

Memory cleaning should start with a memory scan to identify where the malware resides. Once its location is identified, based on the malware analysis, you can define whether it is a process or a service and kill the process or stop the service accordingly.

It is good practice to re-scan the memory after supposedly removing the malware from memory. This is to make sure that the malicious program has not spawned another process or service before you have killed or stopped it - for example, the Bymer.A worm spawns multiple copies of itself in memory and then executes them one at a time.

Another technique for remaining resident in memory has been seen in Magistr.A, which attaches itself as a thread to the explorer.exe process. Yet another method is to exploit buffer overflow, as in the case of CodeRed which exploited the buffer overflow in IIS to reside in the same process as its victim. In both cases, the thread or the process should be terminated in memory to stop the malicious program and, if necessary, restart the original service. Remember that all processes and services started by the malware should be killed or stopped in order to ensure that the program is no longer resident in memory.


Another method of taking control of a system is to add or modify Registry entries. Malware programs often use this method together with a file which is run upon system startup as the result of adding a link to it in the AutoRun Registry folders.

Cleaning up the Registry entries should always be malwarespecific. We must perform the exact reverse of the changes the malware has made in the Registry, which should be as simple as removing what was added or restoring what was modified. Removing and restoring Registry entries can be done using the Registry APIs.

Another method that malware programs use to make sure that they will be executed is the modification of entries inside the HKEY_CLASSES_ROOT folder in the Registry. Inside this folder, the malware can select any extension, which it uses to trigger itself when files with this extension are opened. A good example is the worm Yaha.A, which modifies the default Registry entry for .EXE files so that, whenever files with EXE extensions are executed, Yaha.A is executed first. Restoring the original default value in the Registry will clean this.

Some malicious programs try to modify the Registry entries with the intention not only of gaining control over systems, but also of compromising network security and rendering infected systems more vulnerable to Trojan attacks. An example is Nimda.A, which modifies the Registry to share all drives from C to Z as well as adding the user 'guest' to the 'administrators' group on NT systems. Again, restoring the default value on those entries that have been modified should clean up the system.

Other malicious programs attempt to modify the default home page, Office Macro Warnings, Internet browser's security settings and other miscellaneous settings that are contained within the Registry. Since restoring these to their previous value would be difficult, unless the old values have been recorded, restoring them to their default values should be sufficient to allow the system to function in its clean state.


A more prevalent method in system infection is the use of a physical file, paired with a modification to the Registry. This modification results in the file being executed at startup or during any other special event. In either case, the 'dropped file' must be removed as part of the system cleanup.

Most AV scanners should be able to remove a dropped file by selecting 'delete' as the post-detection action. However, if the file is protected by memory residency or other special techniques, it may not be straightforward to accomplish such a task. This is why cleaning the memory and the Registry must be carried out first, removing any links which might prevent the file from being deleted or modified.

Some malware programs try to append themselves to system files in order to gain control of systems. Such is the case for MTX.A, which modifies the system file WSOCK32.DLL in order to utilize its mail routines. Again, most AV scanners should be able to clean the newly-infected file, but may have some problems with sharing violations. In this case, system disinfection would be the same as traditional file cleaning techniques, but must be executed once the link mentioned above has been broken.

The worm Ska.A, on the other hand, renames the existing WSOCK32.DLL to WSOCK32.SKA and then replaces WSOCK32.DLL with itself. In cases like this, deleting the Ska.A detected file (WSOCK32.DLL) is one part of the cleaning process, and restoring the original file's preinfected name completes the process.

Of course, there are other file-related malware modifications. For example, modifying Windows configuration files such as WIN.INI, SYSTEM.INI and Autoexec.bat by adding a link to a malware file. In these cases, the system configuration files should be cleaned after the physical files they link to have been deleted.

Other system modifications, like planting backdoors and security policy compromises introduced by malware programs should be disinfected as well. FunLove, for example, will patch NTOSKRNL.EXE to disable the system's access rights checking and at the same time patches NTLDR, forcing it to skip the integrity checking of NTOSKRNL.EXE. These modifications must be reversed.

As with Registry cleaning, additions or changes to system configuration files should be deleted or restored to their default values (if the original values can no longer be found).


After an infected system has been cleaned, it would be advantageous to introduce some means of preventing reinfection. A good example is the case of FunLove, in which a dummy file or directory named 'FLCSS.EXE' can be added in the Windows System directory. FunLove will cease to infect any system that has this entry in the System folder of Windows. Another good example is to put a dummy file or folder named 'NOTWORM' in the C drive. This renders CodeRed.A dormant - its payload and replication mechanisms will not be triggered.

However, such preventive measures should be considered only during crisis and should not be used as a sole method of combating re-infection: future variants may not use the dummy files or folders that you have positioned.

However, this is a good opportunity to inform the user of exploit patches that can combat the re-infection of their systems. For example, using the patch provided in Microsoft Security Bulletin MS01-033 would block any IIS vulnerability exploited by CodeRed. Remember that the use of security patches to prevent infection in the first place is a much better solution than the workarounds. Security patches should be used whenever possible.

Fix Tools

Standalone fix tools have become accepted solutions for system disinfection during alerts or outbreaks. Advantages of fix tools are that they are small (most would fit on a standard 1.44 MB floppy disk), can be downloaded quickly, and can be executed on their own.

A downside, however, is that the tools are malware-specific, which means that there is one tool for every malware program or family of malware programs.

Another major drawback of using this approach is that it can not be deployed from a central location, which means that if an enterprise of 10,000 infected machines is to be cleaned, you may need to deploy the fix tool on each of those machines individually.

Furthermore, since most of these fix tools do not have their own fully-developed scanners, false positives in identifying infected files or an infected memory may occur. As mentioned previously, cleaning an uninfected file or memory may result in even more catastrophic damages.

Other Problems

One current problem of system disinfection is that sometimes a system reboot is required to remove traces of the malware totally. This should cause little concern on desktop environments but may be a big issue when it comes to servers and production-related machines.

The reliability of disinfection should also be considered. Disinfection methods should be able to work in all Windows flavours, in all language versions and should not affect any other software installed on the system.


It would be safe to say that future system disinfection techniques will depend on the behaviour of future malware. However, improvements to current techniques can be made in the following areas:
Reliability in identifying the infection.
Minimizing server downtime during infection cleanup.
Expandability and manageability of disinfection tools.
Deployment of tools and centralization, within largescale infections.
Vulnerability assessment tools which provide information on possible malware entry points.
Integration of these tools into AV products as an additional solution.

And the battle rages on ...
Kenny aka ComSec

Please read the Forum Rules !!!


#2 u533m3n0t


    Staff Sergeant

  • Sergeant Major
  • 267 posts

Posted 24 December 2003 - 09:49 AM

TDS3 is an awesome tools for detecting current and mutated trojans. (Not sure if you folks have heard of it, but if you haven't already given it a try, here's a link for you...


With the freeware version of the software, you have to manually update it every day (And they do update it daily), but even the freeware version has very powerful and useful tools any administrator or network security personel would deem useful.

Have a Merry Christmas All :D
Very Best Regards,
Johnny "U533m3n0t"

There are those who talk about it and those who do it. Which are you?

#3 VorteX


    Private First Class

  • Members
  • 44 posts

Posted 30 December 2003 - 10:01 AM

tds simply s*cks, it fails to detect many trojans/backdoors and files can be easily manipulated to avoid detection, i suggest to rather use kaspersky to battle against these kinda malware, it has a much better detection rate and also detects a lot of virii/worms which tds isn't capable of detecting

#4 u533m3n0t


    Staff Sergeant

  • Sergeant Major
  • 267 posts

Posted 02 January 2004 - 07:18 AM

Thanks for the info Vortex. I'll give it a try. Hadn't had any probs with TDS so long as I manually updated daily, but that's for home use and not work, so probably not as big of a target at home. Again, thanks :)
Very Best Regards,
Johnny "U533m3n0t"

There are those who talk about it and those who do it. Which are you?

#5 u533m3n0t


    Staff Sergeant

  • Sergeant Major
  • 267 posts

Posted 10 January 2004 - 10:19 AM

One of my good friends who recommended TDS to me sent me this link which I think you'll find interesting as well...

Gives a rating of the antivirus,anti trojan software, anti spyware, etc, and how they rate, along with a rating of how user friendly they are.

Very Best Regards,
Johnny "U533m3n0t"

There are those who talk about it and those who do it. Which are you?

#6 Faceless Master

Faceless Master

    Staff Sergeant

  • Members
  • 259 posts

Posted 11 January 2004 - 02:53 AM

I my opinion Kaspersky is the best antivirus.
You can download it from
~Faceless Master

#7 Spookie


    Staff Sergeant

  • Sergeant Major
  • 293 posts

Posted 11 January 2004 - 10:43 AM

Cool topic.

One of the things I find interesting about this relates to what I recently viewed on a Car and Driver show. 3 muscle cars created by Porsche, Ferrari, and Ford.

The Ford was labled as the better muscle car, but personally I would prefer to see the Ferrari in my drive way. The point to this is that regardless of what may be the best, people will always go with what suits them.

On the AV side of the house, I've played around with several and came away with a better understanding of what I really wanted in an AV product. Times have changed since then but the site I used as a reference is still around and has some pretty good information.

One of the things I was looking for during that time period was an AV tool that wouldnt be dictated to, and yet had a good engine that could get the job done.

I reviewed several during that time period.
AVX -Now BitDefender
Command Central - Now Authentium
Panda AV
and a few others I can't recall at the moment.

DIRT was one of the prime topics back then and F-Prot was one of the most recommended AV's back then. They had a good speel about DIRT but I opted to go with Command Central because of the FProt engine is used with Command Central.

Times have changed and so has the malware. I use Nod32 now. I'm sure members here will have there comments about Nod32, both good and bad but that was my personal pref.

When it comes to AVs though they will more likely than not be a re-active type of action then a proactive. Heuristics will be a key element I think in any AV product. But when your dealing with Trojans I think thats a different animal. Still an animal but different none the less. Thats like hunting for little gophers vs that psycho mountain lion.

Anyway sorry about the long rambling. Heres the other link I mentioned previously.

Anti-Virus Testing
Beauty is only a light switch away

#8 beardednose


    Retired GSO First Lieutenant

  • Sergeant Major
  • 1,917 posts

Posted 12 January 2004 - 09:52 AM

I'm implementing some malware and spyware detection software and I want to test the different packages against each other.

However, I need a list of URLs that "provide" this *ware when you go to it without requesting it. I could also use a list of software that piggybacks this crap into it.

So far, I haven't been able to locate this stuff on the net. Can you help me out? All the sites that track this stuff don't list the URLs you should avoid. That's the list I want.

If you list the URLs, don't make the links hot (we don't want everyone infected).

Thanks for your help.
Don't post just a THANKS! Here's why...

Forum Rules you need to know...RuLeS

#9 Spookie


    Staff Sergeant

  • Sergeant Major
  • 293 posts

Posted 12 January 2004 - 03:23 PM also has some info that may be of interest to you in your research. If I understood your request right.

Also you may want to try poopware.hta or in google.

You AV will pop + on the zip file .

Pease let me know how your research progressed beardednose.

Edited by Spookie, 12 January 2004 - 08:33 PM.

Beauty is only a light switch away

#10 Spookie


    Staff Sergeant

  • Sergeant Major
  • 293 posts

Posted 13 January 2004 - 01:42 PM

Beauty is only a light switch away

#11 u533m3n0t


    Staff Sergeant

  • Sergeant Major
  • 267 posts

Posted 03 February 2004 - 06:15 AM

Are there any trojan detection programs as good as TDS that are free that anyone can give kudos to? I know Kaspersky was mentioned, but am looking for an app that'll play nicely with Symantec AV, (I know it sucks, but it's what I have to utilize.), and hunts strictly for Trojans/backdoors, etc.
Very Best Regards,
Johnny "U533m3n0t"

There are those who talk about it and those who do it. Which are you?

#12 u533m3n0t


    Staff Sergeant

  • Sergeant Major
  • 267 posts

Posted 05 March 2004 - 09:15 AM

Grabbed and trialed Kaspersky, and you are right. It's some awesome software. I do see a trend in the newer virii targeting them, lending me to believe that they may be getting too popular on the market. I tried one that Spookie recommended to me called RAV which was awesome (caught stuff that Kaspersky even missed), but as everyone is probably aware of...Microsoft bought them out, and you can't even download the demo any longer. I'd be interested to know what your thoughts are on securing equipment. Surely Kaspersky isn't all you would use? You seem well versed on the exploit world, so I guessed you to be a good source for setting up a pretty good defense as well.
Very Best Regards,
Johnny "U533m3n0t"

There are those who talk about it and those who do it. Which are you?

#13 u533m3n0t


    Staff Sergeant

  • Sergeant Major
  • 267 posts

Posted 31 March 2004 - 12:59 PM

Hmm...thread seems to be fading out. I also tried Nod32, which seemed to hang tough with Kaspersky and surpass it in some areas. But then, AV programs are "flavor of the day" selections now aren't they? :D
Very Best Regards,
Johnny "U533m3n0t"

There are those who talk about it and those who do it. Which are you?

#14 bonarez


    Retired GSO Second Lieutenant

  • Sergeant Major
  • 1,252 posts

Posted 31 March 2004 - 02:23 PM

after the possibilities I've seen any antivirus and/or firewall can be fooled with ease, I've started using some rootkit detection software I've found on, called klister and patchfinder, both tools are still under development, but they realy are worth taking a look at:

I've also started using (part of) a secure.bat file from this forum and dcombulator from to kill some services/shares om my windows machines.

on my debian machine I've started using rootkithunter, whitch is really good!!

still I'm still learning a lot about security.. so I'm really interested in software to detect dll injection and other techniques... any tips from you guys would really be appreciated :D

ps: I don't like software that costs money, all the software I've mentioned is free!
"Ask the right question and you will receive the right answer. I'm just very sensitive about the right syntax"

Read the rules before you post

#15 belgther


    Sergeant First Class

  • Sergeant Major
  • 650 posts

Posted 17 January 2005 - 01:31 PM

once, my system was infected with a trojan that was a dll file injected in main windows processes... so i scanned the files seperately with KAV, and i ordered to delete that file... it said it would be deleted after restarting... so i restarted it and everything was fine...
"The wisest one is the one who knows himself/herself." Quote of the life
belgther... aka... belgther

Also tagged with one or more of these keywords: trojan, tools, worm, patch, payload, infection, backdoor